[Zope] HEAD method in 2.0.0b1

[Brian Lloyd]

> From: Brian Lloyd <Brian@digicool.com>
> > Is 'addPostingForm' a Zope object (DTML Document / Method)
> > or a Python method?
> 
> It is a DTML method that is added programaticaly when an 
> article is created.
> 
>     self.defaultDocFile('addPostingForm','Add Posting Form', 
> 	'Squishdot/addPostingForm') 
> 
>     def defaultDocFile(self,id,title,file): 
>         f=open('%s/Products/%s.dtml' % (SOFTWARE_HOME,file)) 
>         file=f.read() 
>         f.close() 
>         self.manage_addDTMLMethod(id,title,file) 
> 
> The entire code is in the Squishdot product available on the 
> Zope web site.
> 
> 	Thanks
> 
> 	Bruce


Eureka! I can tell you what's going on here. If you try to do a
HEAD on the addPostingForm in your actual Squishdot instance:

http://www.technocrat.net/addPostingForm 

...it works as expected (200 OK). However, if you try it on
one of the messages:

http://www.technocrat.net/933640798/addPostingForm 

...you'll get a Not Found. This is, in fact, an intentional behavior
though I could be convinced that it is wrong (though that may have
some impact on WebDAV support).

Basically, the object /933640798/addPostingForm doesn't _technically_
exist - it is accessible because of acquisition, but the actual object
lives in /. The rules for what HTTP methods should and shouldn't be
willing to work with acquired objects are basically that:

  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?



Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com