[Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis

[Julian Reschke]

Lisa Dusseault wrote:
> 
> On Dec 22, 2005, at 7:51 AM, Mike Shaver wrote:
> 
>> On 12/21/05, Helge Hess <helge.hess at opengroupware.org> wrote:
>>
>>> Usually the etag will just be a content revision number (most likely
>>> matching the revision field of iCalendar, SEQUENCE) and is rather
>>> cheap to deliver.
>>> I'm not sure why you suggest that the etag must be computed, I know
>>> of no server which does this (I know that Apache can be optionally
>>> configured to compute a hash, but no one does it in RL ...).
>>
>> Is support for weak entity tags widespread?  I certainly believe from
>> my reading of the HTTP RFC
>> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11) that a
>> strong entity tag has to represent the specific set of octets, not
>> just semantic equivalence.
> 
> To my knowledge, the only server that uses weak ETags is 
> Apache/mod_dav.  It's not a good example of how to use weak etags, 

Incorrect. IIS 5.1 shows similar behavior (you get the weak ETag not 
upon PUT, but on a subsequent GET).

> because it doesn't do any semantic equivalence checking before deciding 
> whether to create a new ETag.  Instead, it assigns a weak ETag based on 
> the timestamp when an entity is stored.  Since the timestamp doesn't 
> always have enough granularity to be able to mark two changes within a 
> short time period, when the short time period expires the server 
> converts the weak ETag to a strong Etag (simply by stripping the w/).

Apache simply has decided that multiple updates within one second *are* 
semantically equivalent. They also ensure that after that time window 
has elapsed any HTTP client that uses ETags will get the "final" state 
of the content. At least from an HTTP caching p.o.v. this is completely ok.

> In theory, a client reading HTTP would have to treat this strong ETag as 
> representing a new entity -- the spec is very clear on clients not 
> trying to interpret ETags -- and always do a GET as soon as it noticed 
> the "new" ETag.  In practice, a few clients treat the Apache server 
> specially and have custom logic for this case.

I don't understand this part. An Etag is an opaque string, but what has 
this to do with server implementations, or whether the ETag is strong or 
not?

> Thus this practice fails in two ways:
>  - There are many times when the client is forced to GET the content 
> again even when it hasn't changed
>  - There are some times when the content changes twice before the weak 
> ETag is converted to the strong ETag and the client doesn't catch the 
> second change

So why does this matter? If the client stops polling within that window, 
it will have one of many versions sent in that time window. If it 
continues polling, it will eventually get the final state.

> ...

Best regards, Julian