NullResource not created for OPTIONS requests

[Jacob Holm]

According to http://www.webdav.org/specs/rfc2518.html, a NullResource is: "A resource which responds with a 404 (Not Found) to any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK. A NULL resource MUST NOT appear as a member of its parent collection."

The current implementation in zope.app.http.traversal.ContainerTraverser.nullResource only creates a NullResource for PUT and MKCOL.

Some implementations (e.g. "Microsoft Data Access Internet Publishing Provider DAV") try OPTIONS before MKCOL, and fail if they get a 404.

I'd like permission to add at 'OPTIONS' and 'LOCK' to the list of methods that we return a NullResource for.

[Philipp von Weitershausen (philikon)]

On 16 Nov 2007, at 20:23 , Jacob Holm wrote:
> According to http://www.webdav.org/specs/rfc2518.html, a NullResource
> is: "A resource which responds with a 404 (Not Found) to any HTTP/1.1
> or DAV method except for PUT, MKCOL, OPTIONS and LOCK. A NULL resource
> MUST NOT appear as a member of its parent collection."
>
> The current implementation in
> zope.app.http.traversal.ContainerTraverser.nullResource only
> creates a
> NullResource for PUT and MKCOL.
>
> Some implementations (e.g. "Microsoft Data Access Internet Publishing
> Provider DAV") try OPTIONS before MKCOL, and fail if they get a 404.
>
> I'd like permission to add at 'OPTIONS' and 'LOCK' to the list of
> methods that we return a NullResource for.

Could you round up a patch that includes (f)tests for such client
behaviour?

[Stephan Richter (srichter)]

I think that's fine. Note though, that there is a new WebDAV implementation out there, z3c.dav, that might have already fixed the problem.

[Jacob Holm (jacobholm)]

To Philipp: Yes, I'll create a patch. I'll even check it in if I hear no objections...

To Stephan: Thanks for the hint, but I am already aware of z3c.dav (I am using it in the project I am working on, and I just posted a couple of bug reports there as well). It does not have its own way of creating NullResource objects (yet?), so this issue is likely to also apply to most users of that package. Anyway, it seems like I should just fix this and move on. Thank you for the support.

[Jacob Holm (jacobholm)]

Here is the patch. It does the following:
1) Add OPTIONS and LOCK to the list of request methods we create NullResources for.
2) Add unit tests for the new behavior.
3) Add a "NullOPTIONS" view because NullResources do not support the same methods as regular resources (e.g. no GET, HEAD, POST)
4) Refactor the regular OPTIONS view slightly to allow reuse in the NullOPTIONS view.
5) Add unit+functional tests for the two OPTIONS views.

Any comments?

[Christophe Combelles (ccomb)]

Has this patch been applied?

[Jacob Holm (jacobholm)]

No, sorry. I ran out of time, then forgot about it. I think there was a problem with enabling NullResources for LOCK requests though. To do it properly requires some additional support in zope.locking and zope.app.container (or possibly in a new package). IIRC adding just OPTIONS solves the original problem, so changing the patch to do just that might be reasonable.

I don't have time to dig into this now. Feel free to take over if you like.