W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Fwd: Re: PUT vs strong ETags]

From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
Date: Sat, 3 Dec 2005 15:11:56 -0800
Message-Id: <CD416928-1079-4F39-9433-30C207171DE5@wsanchez.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, WebDAV <w3c-dist-auth@w3.org>
To: Lisa Dusseault <lisa@osafoundation.org>

On Nov 29, 2005, at 1:43 PM, Lisa Dusseault wrote:

> On Nov 29, 2005, at 1:12 PM, Julian Reschke wrote:
>>
>> Wilfredo Sánchez Vega wrote:
>>>   Question for you.
>>>   Apache HTTPD emits a weak etag for a file resource if the  
>>> timestamp on the file is the same as the current time (one second  
>>> accuracy) and a strong etag otherwise.
>>>   The reason for that logic, as I understand it, is that because  
>>> the etag generation depends on the timestamp and that the file  
>>> may change multiple times within a one-second period, an etag  
>>> generated from a timestamp matching the current time isn't reliable.
>>
>> Finally a good explanation.
>
> Do other people consider this behavior to be incorrect according to  
> the spec?  (I'm assuming the explanation is correct and it aligns  
> with what I've seen).  But it seems that within-second changes do  
> not guarantee "semantic equivalence" as required by HTTP.
>
> Lisa

   My best read of the spec leads me to believe that this is not  
correct as per the spec.

   A more correct solution may be to append something to the strong  
ETag if it is in the same timespan as now instead of using a weak  
ETag in that case.

   However, this doesn't address the problem of correctly changing  
the ETag if multiple changes occur within a subsecond timespan.  But  
then, neither does the weak ETag trick.

   If people agree that Apache HTTPd is incorrect here, I'll be happy  
to implement, lobby for and commit an appropriate change for future  
versions.

	-wsv
Received on Sunday, 4 December 2005 02:19:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT