On Sat, 25 Aug 2007 13:06:10 +0200
Werner Baumann <werner.baumann@...> wrote:
> Unforunately the implementation of conditional requests is badly
> broken in Apache/mod_dav. This is bad.
> But it is worse:
> This bug in Apache/mod_dav was first reported 2003-01-30
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=16593) and then
> again 2005-12-24
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=38034). It is not
> yet fixed. On 2007-07-26 I sent a patch to fix this bug: No response.
> So Apache/mod_dav seems to be unmaintained. This is really
> frustrating. Especially as I like free software and microsoft's IIS
> gets it right. If you know anybody involved in the development of
> Apache, please talk to them about this problem.
I'll bug people on the httpd-dev mailing list. These bugs are
violations of HTTP/1.1 which is something I would hope they would take
> HEAD requests:
> davfs2 tries to work around this problem using HEAD requests to check
> for changes on the server before uploading or requesting a lock for a
> new file. This works most of the time, but is ugly and not really
> secure, as there may be race conditions with two requests instead of
> Locked Null resources:
> Whether we use conditional requests or HEAD to check for changes on
> the server, the client must know whether the file already exists on
> the server or not.
> When a client locks a not-yet-existing file, it must know, whether
> the server creates a new empty file (new style) or a locked null
> resource (old style). This is quite easy: when the server creates a
> new file, it MUST respond with 201 CREATED.
> The combination Apache/subversion, you use, seems to violate the spec
> in creating a new file and responding with 200. This makes dealing
> with the lost update problem almost impossible. The only sensible
> behaviour for a client would be "don't care". But davfs2 wants to
> care about. Although this might not be a problem for subversion (as
> it creates a new version and does not delete anything), it is a big
> problem for all clients, that are not specialized on just one buggy
> Please, report this as a bug to the maintainer of the server software.
I believe the MUST requirement for a 201 response is new with RFC 4918
which specifies lockempty resources. So I think if the server is
creating locknull resources, they can legitimately return a response of
200. Of course, in this case, subversion is returning 200 for a
lockempty resource; hence, this is definitely a bug. I will report
it to the subversion developers.
There is still the problem, however, that davfs expects a 404 response
to its HEAD request after performing a LOCK. Although a server MUST
return a 201 when using lockempty resources, it would be nice if davfs
could handle a 200 response to a HEAD request on a lockempty resource
and not silently fail. Should I report this as a bug on davfs's bug
> Missing MOVEs:
> davfs2 delays uploading of files that are closed by the user for some
> seconds (exact time depends on the load) for two reasons:
> - many applications use temporary files, that will be deleted
> immediately after closing. Delaying the uploads avoids unnecessary
> - davfs2 is single threaded. Delaying large uploads improves (most
> time) the response time of davfs2 to calls from the application.
> So, if you create a new file A and rename it into B: when file A is
> not yet uploaded, davfs2 will just unlock A, and create and upload
> file B.
> Note: Some people think this feature is a bug. I intend to make it a
> configuration option. But this will not be in the near future.
In this particular situation, I have no problem with this. I could see
other people having a problem when you start to mix in BIND and DeltaV
functionality where a MOVE would retain DAV:resource-id and/or version
Thanks for your help!