cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <gcas...@s-und-n.de>
Subject Re: Fooling around with cocoon davmap
Date Sat, 01 Nov 2003 10:53:02 GMT
Stefano Mazzocchi <stefano@apache.org> 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.


Mime
View raw message