[Zope3-dev] Re: HTTP 405: Method Not Allowed

[Philipp von Weitershausen]

Albertas Agejevas wrote:
> Hi,
> 
> I discovered a problem with Zope 3 while developing ReSTive interfaces
> for schoolbell, which utilize the HTTPPublication and the
> HTTPRequestFactory.
> 
> When the user sends a request for a method that is not supported by
> the object, the HTTP spec (RFC 2616) mandates response code 405,
> Method Not Supported.  This response must include an 'Allow' header
> listing all the methods allowed for this object.
> 
> Currently, in the generic case, Zope 3 raises a ComponentLookupError
> in zope.app.publication.http line 74, and a 500 response is served.

I can't find that particular line of code. Are you talking about 
HTTPPublication.callObject where it looks up the view 
(zapi.getMultiAdapter) which might result in a ComponentLookupError in 
case the adapter can't be looked up?

> The obvious fix is to raise a special exception if a corresponding
> view is not found, which would have a view to return a 405 response:
> 
>   class MethodNotAllowed(Exception):
>       implements(IMethodNotAllowed)
> 
>       def __init__(self, object, request):
>           self.allow = [name for name, adapter
>                         in zapi.getAdapters((object, request), Interface)
>                         if hasattr(adapter, name)]
> 
>       def __str__(self):
>           return 'Allow: %s' % self.allow
> 
> 
>   class MethodNotAllowedView:
> 
>       def __init__(self, error, request):
>           self.error = error
>           self.request = request
> 
>       def __call__(self):
>           self.request.response.setHeader('Allow', ', '.join(self.error.allow))
>           self.request.response.setStatus(405)
>           return 'Method Not Allowed'

This looks good. I'm +1 on this.

> The problem with this approach is that there are DELETE and PUT views
> defined for "*", which try to adapt the container to IWriteDirectory,
> IFileFactory, or adapt an existing object to IWriteFile.  So, such
> error view would advertise that PUT and DELETE are available on all
> objects.
> 
> If these methods are called on objects that do not have appropriate
> adapters, a TypeError is raised, with the 500 response.

Well, maybe that should change then. These views could easily raise 
MethodNotAllowed, couldn't they? If they can't find the necessary 
adapters, the their functionality is obviously not available and they 
should raise an appropriate error.

> I believe correct 405 handling is the business of the HTTP publication
> machinery, the client apps should not worry about that.
> 
> Any ideas on how to proceed?

Your proposed solution sounds good to me.

Philipp