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

Philipp von Weitershausen philipp at weitershausen.de
Thu Apr 7 17:18:39 EDT 2005


Albertas Agejevas wrote:
> On Thu, Apr 07, 2005 at 10:06:38PM +0200, Philipp von Weitershausen wrote:
> 
>>Albertas Agejevas wrote:
>>
>>>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?
> 
> Sorry, I had a dirty sandbox.  Yes, I was talking about that line.
> 
>>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.
> 
> They could, but the problem is with introspection of which methods are
> availble, for the mandatory Allow: header.

Ah. Dang.

Well, we have a sort of analogy to this for metadata. Views needing 
annotations are not registered for * but for IAnnotatable, so those 
views always work because they work with objects that promise something 
by marker interface.

So, to compare, we might need the concept of a "filesystem 
representable" object. That concept would stand for "you can get 
IReadFile/IWriteFile adapters for that object"; so, those HTTP views 
needing filesystem representation adapters would only be registered for 
filesystem representable objects, and that would obviously always work.

In any case, the current fact that we sort of promise a method on an 
object and then don't keep that promise is not okay.

Philipp


More information about the Zope3-dev mailing list