[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