RE: Summary of ETag related issues in RFC2518bis

>    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.

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.

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.

> 
>    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.

    dan

> 
> 	-wsv
> 
> 
> On Dec 19, 2005, at 6:16 PM, Jim Whitehead wrote:
> 
> > If I'm a client that has an exclusive write lock, then if I PUT to 
> > that resource, the stored entity should not be modified by anyone 
> > other than the server. In this case, which is the most 
> common one for 
> > DAV-based editing, it's still very useful for the client to receive 
> > the final etag value in the response to PUT. Why? It saves 
> the client 
> > from having to poll an uncertain number of times before it receives 
> > the final, stable etag value.
> >
> > I still feel that R2 is required.
> 
> 
>

Received on Tuesday, 20 December 2005 05:14:48 UTC