In my travails through the ZPublisher and WebDAV, I've come up with 
another fun thing.

As far as I can tell, traversal via acquisition doesn't make any sense 
for a WebDAV request. If I have /foo and /bar, but not /bar/foo, then 
traversal to /bar/foo over WebDAV should not acquire /foo and wrap it in 

One reason for this (apart from being utterly confusing) is that it 
breaks PUT requests to a NullResource: If I try to PUT to /bar/foo it 
should create a new object there, not overwrite /foo.

There is actually some convoluted support for detecting this in 

         # Note - no_acquire_flag is necessary to support
         # things like DAV.  We have to make sure
         # that the target object is not acquired
         # if the request_method is other than GET
         # or POST. Otherwise, you could never use
         # PUT to add a new object named 'test' if
         # an object 'test' existed above it in the
         # heirarchy -- you'd always get the
         # existing object :(
         if (no_acquire_flag and
             hasattr(parents[1], 'aq_base') and
             not hasattr(parents[1],'__bobo_traverse__')):
             if not (hasattr(parents[1].aq_base, entry_name) or
                 raise AttributeError, entry_name

This doesn't really work, though. The object is acquired, and then all 
it does is to check that the PUT() method object is a true attribute of 
the acquired object. But even then, raising AttributeError is wrong.

What should happen, I think, is that in 
DefaultPublishTraverse.publishTraverse() we should *not* attempt to 
acquire for webdav requests. Instead, we should try direct attribute 
access and then __getitem__() access (which is the next thing it tries 
after getattr() acquisition). This would then allow the folder to return 
a NullResource (as OFS.ObjectManager does, for example).

Any objections? It's a relatively simple condition in 


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to