Re: ETags?

On Jan 18, 2005, at 4:52 PM, Julian Reschke wrote:
> Brian Korver wrote:
>> The BIND spec doesn't mention ETags at all, but buried in section
>> 3.11 of RFC 2616 is the following text:
>>    An entity tag MUST be unique across all versions of all entities
>>    associated with a particular resource. A given entity tag value MAY
>>    be used for entities obtained by requests on different URIs. The 
>> use
>>    of the same entity tag value in conjunction with entities obtained 
>> by
>>    requests on different URIs does not imply the equivalence of those
>>    entities.
>> which (at least to me) seems counter-intuitive in the face of multiple
>> bindings -- I would have guessed that the ETag would remain constant.
>
> I think all this says is that if you get the same Etag for "/a" and 
> "/b", you can't assume that it's the same entity.

Right, that's what I believe it says too, but I think that may be
counter-intuitive for some implementers -- who may in fact miss
this text in 3.11 and to implement expecting that they can assume
it's the same entity.



>
>> Any chance we could squeeze some text into the draft, similar to that
>> dealing with locking?  Something approximately like:
>>   Entity Tags and Bindings
>>   It might be thought that ETags would be associated with resources,
>>   not URIs, and as such two different URIs with identical ETags
>>   would imply that the URIs are bindings to the same resource.
>>   This is not the case, however.  Section 3.11 of [RFC2616]
>>   states that ETags are on URIs, not resources.
>
> I agree with the conclusion, but I think the motivation for saying 
> this is a bit weak. Could you please re-read 3.11 and consider my 
> explanation  above?
>
> That being said here's something for RFC2518bis to clarify: RFC2616's 
> definition of ETag semantics doesn't work well with namespace 
> operations. In practice, within the same URL namespace ETags will only 
> work well when they are indeed unique not only for all versions for a 
> single URI, but for the whole namespace (otherwise a server will have 
> to do post-processing after MOVE operations to ensure that ETag 
> semantics are preserved, possibly assigning new ETags just because a 
> namespace operation occured).
>
> Best regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
-brian
briank@xythos.com

Received on Wednesday, 19 January 2005 01:18:30 UTC