Re: Interoperability between webdavfs and Apache Slide

[Chris Sharp <cs...@mac.com>]

This is not a problem with webdav_fs but with an incompatibility  
introduced in Slide - I believe in preparation for ACL support some  
time ago. Try setting lockdiscoveryIncludesPrincipalURL to false in the  
web.xml.

Chris.
On Nov 27, 2003, at 1:56 PM, Stefano Mazzocchi wrote:

> Dear Jim,
>
> first of all, sorry for this unsolicited email. I found your name  
> associated with posts on webdavfs and from the CVS commmits on the  
> source code I believe that you are still involved in the maintanance  
> of the webdavfs code, if not, I apologize and I will be thankful if  
> you could indicate me the best person to contact or the appropriate  
> mailing list where these matters are discussed.
>
> I'm writing to you because I'm involved in the Apache Slide project.  
> For more information on Slide, please see
>
>  http://jakarta.apache.org/slide/
>
> Slide is not widely known, but, at the moment, Slide is probably the  
> most complete open source implementation of the WebDAV protocol stack,  
> including WebDAV level 1 and 2, DeltaV, DASL and ACL.
>
> As a (proud!) mac user, it is a must that Slide does not only pass our  
> dry tests, but works, in real life, with tools and Darwin's webdavfs  
> is very likely to be a winning showcase for the project and very  
> useful for my personal needs.
>
> Unfortunately, it doesn't work. :-(
>
> Pier and I spent a good few hours this afternoon to understand where  
> the problem resides and I think we found out that the problem seems to  
> be located on webdavfs side.
>
> It seems that it forgets to send back the "opaquelocktoken" that he  
> acquired with LOCK when doing the subsequent PUT, receives a 423  
> LOCKED back and believes that the file is busy.
>
> This behbavior is not exhibited in mod_dav even if the HTTP traces are  
> surprisingly similar.
>
> To test this, we did the following:
>
>  0) used MacosX 10.3.1, webdavfs sends
>  "WebDAVFS/1.2.5 (01258000) Darwin/7.0.0 (Power Macintosh)"
>     as User-Agent: HTTP header.
>
>  1) mod_dav (from HTTPD 2.1-dev of a few weeks ago)
>      ---> installed at http://127.0.0.1/dav/
>
>  2) Slide 2.0.1 (from CVS of today)
>      ---> installed at http://127.0.0.1:8080/slide/
>     [running on Apache Tomcat 4.1.29]
>
>  3) we mounted both WebDAV folders as disks, here is my 'mount' output
>
> [stefano@Merlino] /Volumes $ mount
> /dev/disk0s5 on / (local, journaled)
> devfs on /dev (local)
> fdesc on /dev (union)
> <volfs> on /.vol
> automount -nsl [304] on /Network (automounted)
> automount -fstab [310] on /automount/Servers (automounted)
> automount -static [310] on /automount/static (automounted)
> localhost:8080/slide/files/ on /Volumes/files (nodev, noexec, nosuid,  
> mounted by stefano)
> localhost/dav/ on /Volumes/dav (nodev, noexec, nosuid, mounted by  
> stefano)
>
> [note: 'slide/files' is the webdav writable folder for slide]
>
>  4) we executed the command
>
>   echo "blah" > /Volumes/files/blah
>
> and
>
>   echo "blah" > /Volumes/dav/blah
>
> in order to minimize the impact of the IO libraries on top of webdavfs  
> and write directly to the FS layer.
>
> Here are the resulting access logs:
>
> ----- mod_dav  
> ----------------------------------------------------------------
>
> "PROPFIND /dav/blah HTTP/1.1" 207 439
> "LOCK /dav/blah HTTP/1.1" 200 449
> "GET /dav/blah HTTP/1.1" 200 -
> "PUT /dav/blah HTTP/1.1" 204 -
> "PROPFIND /dav/blah HTTP/1.1" 207 372
> "UNLOCK /dav/blah HTTP/1.1" 204 -
>
> ---- slide  
> ----------------------------------------------------------------------
>
> "PROPFIND /slide/files/ HTTP/1.1" 207 1780
> "PROPFIND /slide/history/ HTTP/1.1" 207 1784
> "LOCK /slide/files/blah HTTP/1.1" 200 1710
> "PUT /slide/files/blah HTTP/1.1" 423 814
>
> as you can see, the 423 signals termination, resulting in a  
> zero-length file being written on disk (in Finder, the "file is busy"  
> output comes out).
>
> In order to understand why this happens, the two PUT operations are  
> different:
>
> --- mod_dav  
> ---------------------------------------------------------------------
>
> PUT /dav/blah HTTP/1.1
> User-Agent: WebDAVFS/1.2.5 (01258000) Darwin/7.0.0 (Power Macintosh)
> Accept: */*
> Host: localhost:80
> Content-Length: 5
> If:(<opaquelocktoken:7942c777-21cd-0310-9222-8d4da0aeb12e>)
>
> --- slide  
> ----------------------------------------------------------------------- 
> -
>
> PUT /slide/files/blah HTTP/1.1
> User-Agent: WebDAVFS/1.2.5 (01258000) Darwin/7.0.0 (Power Macintosh)
> Accept: */*
> Host: localhost:8080
> Content-Length: 5
>
> as you can see, the lock token is missing, thus Slide correctly  
> responds that the resource is locked.
>
> In order to understand why this happens, we believe that we need to  
> take a look at the request/response for the LOCK method:
>
> --- mod_dav  
> ---------------------------------------------------------------------
>
> LOCK /dav/blah HTTP/1.1
> User-Agent: WebDAVFS/1.2.5 (01258000) Darwin/7.0.0 (Power Macintosh)
> Accept: */*
> Host: localhost:80
> Depth: 0
> Timeout: Second-600
> Content-Type: text/xml; charset="utf-8"
> Content-Length: 213
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:lockinfo xmlns:D="DAV:">
> <D:lockscope><D:exclusive/></D:lockscope>
> <D:locktype><D:write/></D:locktype>
> <D:owner> <D:href>default-owner</D:href> </D:owner>
> </D:lockinfo>
>
> HTTP/1.1 200 OK
> Date: Thu, 27 Nov 2003 21:29:16 GMT
> Server: Apache/2.1.0-dev (Unix) DAV/2 SVN/0.32.1 Catacomb/0.9.0
> Lock-Token: <opaquelocktoken:7942c777-21cd-0310-9222-8d4da0aeb12e>
> Vary: User-Agent
> Content-Length: 449
> Content-Type: text/xml; charset="utf-8"
>
> <?xml version="1.0" encoding="utf-8"?>
> <D:prop xmlns:D="DAV:">
> <D:lockdiscovery>
> <D:activelock>
> <D:locktype><D:write/></D:locktype>
> <D:lockscope><D:exclusive/></D:lockscope>
> <D:depth>0</D:depth>
> <ns0:owner xmlns:ns0="DAV:"> <ns0:href>default-owner</ns0:href>  
> </ns0:owner><D:timeout>Second-600</D:timeout>
> <D:locktoken>
> <D:href>opaquelocktoken:7942c777-21cd-0310-9222-8d4da0aeb12e</D:href>
> </D:locktoken>
> </D:activelock>
>
> </D:lockdiscovery>
> </D:prop>
>
> --- slide  
> ---------------------------------------------------------------------
>
> LOCK /slide/files/blah HTTP/1.1
> User-Agent: WebDAVFS/1.2.5 (01258000) Darwin/7.0.0 (Power Macintosh)
> Accept: */*
> Host: localhost:8080
> Depth: 0
> Timeout: Second-600
> Content-Type: text/xml; charset="utf-8"
> Content-Length: 213
>
> <?xml version="1.0" encoding="utf-8" ?>
> <D:lockinfo xmlns:D="DAV:">
> <D:lockscope><D:exclusive/></D:lockscope>
> <D:locktype><D:write/></D:locktype>
> <D:owner> <D:href>default-owner</D:href> </D:owner>
> </D:lockinfo>
>
> HTTP/1.1 200 OK
> Content-Type: text/xml; charset="UTF-8"
> Date: Thu, 27 Nov 2003 21:30:36 GMT
> Server: Apache Tomcat/4.1.29 (HTTP/1.1 Connector)
> Transfer-Encoding: chunked
> Lock-Token: <opaquelocktoken:1661058a8b79d22df83c0eaf45479506>
>
>
> 127.000.000.001.08080-127.000.000.001.57489: 13
> <?xml version="1.0"
> 11
>  encoding="UTF-8"
> 2
> ?>
> 2
>
>
> 1
> <
> 6
> D:prop
> 6
>  xmlns
> 1
> :
> 1
> D
> 2
> ="
> 4
> DAV:
> 1
> "
> 1
> >
> 2
>
>
> 4
>
> 1
> <
> f
> D:lockdiscovery
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 1
> <
> c
> D:activelock
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 1
> <
> a
> D:locktype
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 4
>
> 1
> <
> 7
> D:write
> 3
>  />
> 2
>
>
> 4
>
> 4
>
> 4
>
> 2
> </
> a
> D:locktype
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 1
> <
> b
> D:lockscope
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 4
>
> 1
> <
> b
> D:exclusive
> 3
>  />
> 2
>
>
> 4
>
> 4
>
> 4
>
> 2
> </
> b
> D:lockscope
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 1
> <
> 7
> D:depth
> 1
> >
> 1
> 0
> 2
> </
> 7
> D:depth
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 1
> <
> 7
> D:owner
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 4
>
> 1
> <
> 6
> D:href
> 1
> >
> d
> default-owner
> 2
> </
> 6
> D:href
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 2
> </
> 7
> D:owner
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 1
> <
> 9
> D:timeout
> 1
> >
> d
> Second-604799
> 2
> </
> 9
> D:timeout
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 1
> <
> b
> D:locktoken
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 4
>
> 1
> <
> 6
> D:href
> 1
> >
> 30
> opaquelocktoken:1661058a8b79d22df83c0eaf45479506
> 2
> </
> 6
> D:href
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 2
> </
> b
> D:locktoken
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 1
> <
> f
> D:principal-URL
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 4
>
> 1
> <
> 6
> D:href
> 1
> >
> 16
> /slide/unauthenticated
> 2
> </
> 6
> D:href
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 4
>
> 2
> </
> f
> D:principal-URL
> 1
> >
> 2
>
>
> 4
>
> 4
>
> 2
> </
> c
> D:activelock
> 1
> >
> 2
>
>
> 4
>
> 2
> </
> f
> D:lockdiscovery
> 1
> >
> 2
>
>
> 2
> </
> 6
> D:prop
> 1
> >
> 2
>
>
> 2
>
> ----------------------------------------------------------------------- 
> ------------
>
> besides the laughably granular chunking that the Tomcat HTTP/1.1  
> implementation in 4.1.x, the content appears correct. The only major  
> difference is that the token has the format of
>
>    mod_dav -> 7942c777-21cd-0310-9222-8d4da0aeb12e
>
> while
>
>    slide -> 1661058a8b79d22df83c0eaf45479506
>
> but the two formats, are, IMO, both compliant UUIDs.
>
> We went into the webdavfs code and we realized that in the file http.c  
> in function http_put() the following lines
>
> 	if ((arg != (void *) - 1) && (putinfo->locktoken))
> 	{
> 		addstr(iov, n, "If:(<");
> 		addstr(iov, n, putinfo->locktoken);
> 		addstr(iov, n, ">)\r\n");
> 	}
>
> indicate that if the putinfo_locktoken failed to be acquired in the  
> previous response parsing, it's simply omitted.
>
> I personally believe this is not exactly the safest thing to do as  
> failing to acquire a lock should indicate an error and not being  
> silently ignored.
>
> Anyway, looking into the file webdav_parse.c in the function  
> parse_lock_create(), we were not able to understand what is going  
> wrong.
>
> NOTE: I don't get any 'webdav-related' messages or parsing errors in  
> the console output.
>
> And this is why I'm asking you: do you have any idea of what's going  
> on? did you have similar experiences with other DAV servers?
>
> NOTE: if you need it, I can give you my prepackaged installation of  
> tomcat+slide for you to try on your machine.
>
> Thanks much in advance and keep in mind that we'll be very welcome to  
> continue supporting webdavfs interoperability with Slide.
>
> Ciao.
>
> --
> Stefano.


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Interoperability between webdavfs and Apache Slide

[Stefano Mazzocchi <st...@apache.org>]

On 1 Dec 2003, at 18:18, Chris Sharp wrote:

> This is not a problem with webdav_fs but with an incompatibility 
> introduced in Slide - I believe in preparation for ACL support some 
> time ago. Try setting lockdiscoveryIncludesPrincipalURL to false in 
> the web.xml.

No, Chris, it is a bug in webdav_fs and Jim confirmed this (he 
experienced the same bug with WindowsCE webdav server implementation 
and already fixed it).

it is true that if the lock discovery doesn't include the principal 
URL, webdav_fs works, but this is a workaround on their bug (which is 
already fixed in their internal codebase, but hasn't been released 
yet).

But I suggest that we ship Slide with lockdiscoveryIncludesPrincipalURL 
turned off so that we don't have those problems with the entire macosx 
installation out there that hasn't been patched (or hasn't migrated to 
panther).

--
Stefano.