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

I don't have a firm read on whether the Apache HTTPd behavior is non- 
compliant. However, I strongly feel that its current behavior is very  
bad for clients.

What clients really need is for the ETag to not change unless the  
content changes.

So, if an ETag starts out weak, it should stay weak. If it starts  
strong, it should stay strong. The weak->strong transition is a  
problem. I don't think clients care particularly about weak vs strong  
etags. In fact, if the server does some amount of background  
processing on the content, but returns a semantically equivalent  
representation then the server should be using weak etags  
consistently, AFAIK. For example, if a CalDAV server receives an  
event, bursts it out into its database, then reconstructs a slightly  
different XML representation that is semantically equivalent, it  
should only be using weak etags in this case to represent the fact  
that there are minor tweaks to the representation of the resource.

- Jim


On Dec 3, 2005, at 3:11 PM, Wilfredo Sánchez Vega wrote:

>
> 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 Thursday, 8 December 2005 01:49:43 UTC