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

[EMAIL PROTECTED] /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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature



Reply via email to