RE: Summary of ETag related issues in RFC2518bis

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

I gave one below.

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

No, I meant millisecond.  Perhaps you are sugggesting that APR only supports 1-second resolution?  Why would that be?  I know of no filesystems with that kind of resolution.

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

Sure it's a use case.  But you don't explain why it's not acceptable.

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

It's exactly that simple.  Because COPY and MOVE don't suffer the non-interference problem (on the target, that is), because the target doesn't exist for someone to have open.

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

I have no opinion about this.  If I were working on Apache I never would have been returning weak etags in the first place.  I would be putting together the timestamp and filesize returned by the fs and using that as the etag in the first place.  If someone complained that they ran into a case where some other process wrote the file at exactly the same millisecond and exactly the same size and I reported the same etag when in fact they claimed the content was different, then I would say "whoops, sorry, that's a bug, and it's a never-fix bug because the use cases where it's a problem so rare and so hard to fix (see pain-in-the-rear solution above) that it's not worth fixing.  If you want to make that bug go away use a real filesystem with microsecond resolution for your server."

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

No, I take that as an indication that everyone agrees that this bug is only there conceptually and that it never actually occurs in the field.  I know for a fact that the Adobe client implementations just ignored the weak marking on the etag and that's why they were interoperable with Apache.

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

Yes: stop returning weak etags.  See above.

    dan

Received on Wednesday, 21 December 2005 06:03:55 UTC