Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > In my doco wandering, I tried to mount the cocoon DAV repository > (found in the 'davmap' directory of the webdav block) under macosx as > a disk, but fails. I tried with mod_dav on httpd 2.0.47 and it works. > > Further inspection (with the good old tcpflow) indicates that the > cocoon OPTION handshake: > > 127.000.000.001.53028-127.000.000.001.08888: OPTIONS > /samples/webdav/davmap/repo/ HTTP/1.1 > User-Agent: WebDAVFS/1.2.3 (01238000) Darwin/6.8 (Power Macintosh) > Accept: */* > Host: localhost:8888 > Content-Length: 0 > > 127.000.000.001.08888-127.000.000.001.53028: HTTP/1.1 200 OK > Date: Fri, 31 Oct 2003 22:49:51 GMT > Server: Jetty/4.2.9 (Mac OS X/10.2.8 ppc java/1.4.1_01) > X-Cocoon-Version: 2.1.3-dev > Allow: OPTIONS, GET, HEAD, POST, DELETE,TRACE, PROPFIND, PROPPATCH, > COPY, MOVE > DAV: DAV:1 > Content-Type: text/xml > Content-Length: 46 > > <?xml version="1.0" encoding="UTF-8"?> > <page/> > > Is not that palatable by WebDAVFS (the mach-O DAV client) while > > 127.000.000.001.53029-127.000.000.001.00080: OPTIONS / HTTP/1.1 > User-Agent: WebDAVFS/1.2.3 (01238000) Darwin/6.8 (Power Macintosh) > Accept: */* > Host: localhost:80 > Content-Length: 0 > > > 127.000.000.001.00080-127.000.000.001.53029: HTTP/1.1 200 OK > Date: Fri, 31 Oct 2003 22:50:13 GMT > Server: Apache/2.0.47 (Unix) DAV/2 > DAV: 1,2 > DAV: <http://apache.org/dav/propset/fs/1> > MS-Author-Via: DAV > Allow: > OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND,PROPPATCH,COPY,MOVE,LOCK,UNL > OCK > Content-Length: 0 > Content-Type: httpd/unix-directory > > is much more digestible and results in the disk being mounted. > > Now, the first thing to ask is: > > 1) is DAV: DAV:1 correct? I would expect "DAV: 1" to be the correct > header
Checking the spec at http://ftp.ics.uci.edu/pub/ietf/webdav/protocol/rfc2518.html#HEADER_DAV it seems that "DAV: 1" is correct. > 2) is our response correct? I think that, from a DAV perspective, "/" > is not a page but rather a folder.... even if, to be honest, > httpd/unix-directory really sucks as a content type, but anyway. Yes, mod_dav proved to be quite interoperable. "httpd/unix-directory" is what our "collection2propfind.xsl" currently delivers as well (as part of a multi-status response body). I think this could be changed. However if we want the davmap to be a widely interoperable WebDAV server, I think we should have something like a compatibility test suite - similar to Slide's TProcessor or litmus http://www.webdav.org/neon/litmus/ that could easily be run after each such change. As for the empty response body. It would be a matter of having a serializer supressing it. However I didn't come accross a WebDAV client not simply ignoring a response body. I assume changing the header to "DAV: 1" solved the problem with WEBDAVFS? Guido > > Expect more feedback on this since I'm going to investigate more and > more webdav capabilities as I prepare to attack doco.
