Hi, 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 /bar. 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 ZPublisher.BaseRequest: # 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 parents[1].aq_base.has_key(entry_name)): 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 DfaultPublishTraverse.publishTraverse(). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book