RE: Summary of ETag related issues in RFC2518bis

On Tue, 20 Dec 2005, Dan Brotsky wrote:

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

Well, the issue started with Apache using weak ETags, then strong ones. 
Note that the ETag is an opaque string, the way it is computed is up to 
the server. If a server want to use the md5 sum as the ETag, it is 
entirely possible, the choice to use the timestamp and length is part of 
Apache's design. Try to use "ContentDigest on" on big files and you will 
understand why.

My server knows how to handle x != GET(PUT(x)) for subsequent revision 
(well because cvs knows), it handles itself the issue, without any need 
from the client to know what's really going on behind the scene.

The discussion boils down to:
After a PUT, is it safe to continue to edit the resource without doing 
a reload?
And the server should give the answer. 205 if it is not safe, 204 
otherwise, with the ETag that someone will get in a subsequent GET.

> Yes: stop returning weak etags.  See above.

"on PUT". Agreed.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Wednesday, 21 December 2005 10:06:06 UTC