[Zope] HEAD method in 2.0.0b1

[bruce@perens.com]

Brian,

What happens in the case of a web cache? Assume an object is cached, and the
cache's client does a GET to the cache for that object. The cache queries Zope
using HEAD to determine if the object is still current. Zope returns 404, and
the cache returns 404 to the client's GET . This is assuming a lot about how
caches work - I haven't tested it.

	Thanks

	Bruce


>   o GET, POST and PUT generally work on an acquired object
> 
>   o DAV methods (PROPFIND, COPY, MOVE, etc.) do _not_ work
>     with acquired objects for a variety of reasons.
> 
> HEAD, unfortunately, is something of a special case. Strictly
> speaking, it should perform exactly as a GET but with no
> entity body returned. However, some semi-intelligent DAV clients
> (ahem, ahem, IE5) seem to think its easier to use HEAD in some
> cases than the specified DAV methods for doing certain things.
> 
> For instance, when you try to drop a new file into a web folder (IE5
> DAV, basically), it will do a HEAD on the url to see if the object
> already exists. However, if HEAD allows acquired objects, then when
> you try to add a file to a folder where: 1) an object with that name
> doesn't actually exist in the folder but 2) an object with that name
> _does_ exist in a higher folder, then HEAD will seem to report that
> there _is_ already a file with that name in the folder (and the DAV
> client will probably give you a prompt like: "this item already exists,
> should I overwrite it?", which probably seems pretty strange to the
> user).
> 
> There is, unfortunately, no way to tell whether the client calling
> the HEAD method is a DAV client or a normal HTTP client (the DAV
> group considers this a feature).
> 
> The current way of doing things (HEAD only working on non-acquired 
> objects) has worked out pretty well so far, mainly because:
> 
>   o most of the time, acquired DTML Documents / Methods are
>     used as part of application design or view on content
>     objects, rather than being considered content objects
>     themselves.
> 
>   o HEAD is mainly used to determine when a content-ish
>     object has changed or to determine its existence, so
>     it usually ends up getting called on a "real" object
>     rather than on acquired "phantoms".
> 
> One approach that could be taken is to provide some sort of
> knob so that you could make it do what you feel is appropriate
> for your installation (allow vs. not allow acquired objects for
> HEAD requests). Perhaps if the environment variable
> NO_DUMB_DAV_CLIENTS were defined when Zope started up, it
> could be willing to allow acquired objects to respond to
> HEAD requests. I really sort of hate to add yet more special-
> case knobs unless people have a real world need for them though.
> 
> Thoughts?