You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/11/01 00:11:39 UTC
Fooling around with cocoon davmap
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
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.
Expect more feedback on this since I'm going to investigate more and
more webdav capabilities as I prepare to attack doco.
--
Stefano.
Re: Fooling around with cocoon davmap
Posted by Martin Holz <ho...@fiz-chemie.de>.
Stefano Mazzocchi <st...@apache.org> writes:
>
> Today, for example, I found out that Cadaver and DAVExplorer don't
> talk DeltaV to Slide... :-(((( and I can't get Catacomb or Subversion
> to build on merlino. I'm sooo depressed. :-(
Both do DeltaV for me. I am using current slide server from CVS with linear
versioning, cadaver 0.21.0 and DAVExplorer 0.90. IIRC DeltaV is disabled in
some versions of cadaver due to problems.
Martin
P.S : Is www.webdav.org down.
Re: Fooling around with cocoon davmap
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Nov 2, 2003, at 01:28 Europe/Rome, Gianugo Rabellino wrote:
> Stefano Mazzocchi wrote:
>
>> Yes, it did.
>> BTW, do you know if Cadaver can talk simple DeltaV with subversion?
>
> Unfortunately, I'm afraid not.
I'll try (if I can manage to build subversion on merlino) and report
back
> They both implement a subset of the spec. Have you tried DAVExplorer
> (http://www.ics.uci.edu/~webdav/), BTW?
yes, I have this as well, but the problem is that I don't have a
subversion running locally.
--
Stefano.
Re: Fooling around with cocoon davmap
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
>
> Yes, it did.
>
> BTW, do you know if Cadaver can talk simple DeltaV with subversion?
Unfortunately, I'm afraid not. They both implement a subset of the spec.
Have you tried DAVExplorer (http://www.ics.uci.edu/~webdav/), BTW?
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: Fooling around with cocoon davmap
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Nov 1, 2003, at 11:53 Europe/Rome, Guido Casper wrote:
>> 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.
ah, ok, but being compliant to the spec doesn't really help if your app
doesn't work :-( as IE shows us almost every other second.
>> 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).
cool
> 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.
I would be in favor of this, but might not be enough.
Today, for example, I found out that Cadaver and DAVExplorer don't talk
DeltaV to Slide... :-(((( and I can't get Catacomb or Subversion to
build on merlino. I'm sooo depressed. :-(
The bleeding edge hurts. painfully.
> 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?
Yes, it did.
BTW, do you know if Cadaver can talk simple DeltaV with subversion?
--
Stefano.
Re: Fooling around with cocoon davmap
Posted by Guido Casper <gc...@s-und-n.de>.
Stefano Mazzocchi <st...@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.