Re: Summary of ETag related issues in RFC2518bis

Dan Brotsky wrote:
>>    The question then is how one would implement than on a 
>> server using a filesystem as the backing store, which is a 
>> *very* common case (Apache).  The information have from the 
>> filesystem doesn't seem to give us enough data without doing 
>> something like checksumming the file.  The performance 
>> implications of that solution are rather drastic.
> 
> First of all, there are many filesystems in the world that accurate to way more than 1 millisecond, so I don't think a general statement such as "the filesystem doesn't seem to give us enough data" is really applicable.

Depends on what the target platform is. Apache is built on top of APR, 
(Apache Portable Runtime) as I recall, and that API may not have a 
guarantee of a higher timer resolution. What would be your proposal to 
the Apache guys how to handle that?

> Second, even in filesystems with millisecond resolutions, all the filesystem has to do is support exclusive write-locking and you can build a compliant server.  The server must simply keep the file locked long enough to avoid the milllisecond window and then set the time back to the write time in order to ensure that any interference is noticeable.

You mean "second" resolution, right? Two problems here:

1) Doing that may not be acceptable for mass uploads, where millions of 
documents need to be uploaded (don't tell me this isn't a use case...).

2) Even then, it's not that simple. ETag and Last-Modified also have to 
be adjusted after COPY and notably MOVE (!).

But it seems that there's a simple way to fix this (for Apache): should 
a client require a strong ETag upon PUT, it could make that explicit in 
the request (new header?), so that the server can just special-case 
this, and do what's needed to ensure the ETag is stable. Wilfredo?

> I don't have any problem with a standard that can't be implemented in the simplest possible way against the weakest possible resources.  All we are saying is that, if you really have a filesystem that allows multiple writers to interfere with one another undetectably, then you can't build a compliant WebDAV server against that filesystem.  And that's just a fact: the server certainly can't guarantee anything without support from the filesystem.

I disagree with the statement that this kind of server is non-compliant. 
Are you saying that Apache/moddav is non-compliant?

>>    Absent a workable solution, we're going to be moving 
>> Apache into the non-compliant category if this is a 
>> MUST-level requirement.
> 
> I think there are many workable solutions over standard filesystems for this problem.

This discussion isn't new. As a matter of fact, it started at least two 
years ago. As of now, nothing in Apache/moddav has changed. I take that 
as indication that changing the server may not be as trivial as some 
people think.

So, Dan, can you make a concrete proposal how to change Apache/moddav?

 > ...


Best regards, Julian

Received on Tuesday, 20 December 2005 08:48:24 UTC