> I wasn't around during the development of the WebDAV code, so I'm
> loathe to just jump in and start changing things, but why isn't
> 'HEAD' exempted from the NullResource as well, given that HTTP specs
> state that HEAD *must* return the same headers that a GET would
> provide (ignoring for the moment the Collector issue thread over
> whether HEAD should provide the length of the source of a document or
> its fully rendered content - let's just try to make sure both methods
> work on the *same object*). What was the reasoning behind the
> decision? These changes happened way back in the Dark Ages (late
> March 1999 or so, earlier in the month, this code was added to
> OFS.Folder with the initial WebDAV support). A trip through the
> WayBackMachine™ shows no discussion in the Zope-dev lists in early
> 1999 when this was being worked on, and no real mention of WebDAV in
> Zope for most of the rest of that year (on Zope-dev or the general
> Zope list). Am I mistaking this for a problem?
The HEAD method is a bit of problem generally -- by the book it
should return the exact same thing as a GET sans the content body.
In a dynamic system like Zope about the only way I can think of
to have the right thing happen would be to have goo in the
publisher that turns a HEAD into a GET to let normal GET control
flow happen, then have the response bits know that this has
happened and discard the content body.
<...sound of retching...>
In any case, treating HEAD like the other lesser-used HTTP methods
like DELETE, etc. is probably not the right thing to do, but what
exactly the right thing should be is unclear.
Another fun tidbit is that DAV clients often use HEAD to test for
the existence of resources and other things, so if HEAD is treated
*exactly* like a GET in Z2 you'll get problems due to acquisition
(you might get a HEAD response for an acquired object that isn't
really there, which will make DAV clients go insane).
That convoluted code in the publisher pre-dates the idea of a
dedicated DAV server -- probably the right thing to do today would
be to have the DAV server config the publisher to never acquire,
then you dont have unresolvable ambiguities.
Brian Lloyd [EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -