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