Hi! I also tested Zope behind Apache. An unaltered Proxy Pass directive should also pass the WebDAV traffic unchanged. It does so for me, and apparently also for you, Chris. But I am rather sure that Apache can be configured to return a limited "OPTIONS" list. Just don't know how. What did you do, Jason?
If I want WebDAV to kick in I simply point the client at the correct port. Since it is easy to include the port number in the URL this hack neatly fixes the problem.
That's a good idea. It does make me wonder if Zope should actually answer WebDAV REQUEST's on it's HTTP port in any case. I think it probably should...
First of all: Pointing directly to a non-80 port is not that good. People who are working from behind a corporate firewall will not be able to get the files. But of course one can get around that by simply setting up another Proxy Pass rule, so that, just as an example, http://www.myserver.com/file.doc will be served HTTP and http://dav.myserver.com/file.doc will be served with WebDAV options enabled. In terms of mere standards compatibility, Zope is right. WebDAV SHOULD work as an extension to a normal HTTP server, on the same port and such. The OPTIONS request is meant to be the means for the client to find out whether the server speaks WebDAV. But in real life, we'll probably have to accept that MS does it wrong. I guess that adding an option for a WebDAV-free HTTP port to Zope will be the best fix, so that one can either use the "combined" port (which is the current default), the already existing WebDAV port that serves objects always as sources (i.e. unrendered), and a "pure-HTTP" (or should we call it "MS-compatibility") port. If the same effect can also be reached with Apache/ProxyPass, that would be an option for most people, too. Joachim