Re: ETags?

When I first considered ETags and bindings, I assumed that all bindings 
to the same resource MUST show the same ETag.  That came from my 
understanding of what the ETag is used for, which is shaped by the 
implementations I've been involved in and what they do (authoring, 
sharing).  Note that I'm not making the naive assumption that an ETag 
can be used to identify two bindings -- but I did make the assumption 
that a single ETag can be recorded in order to synchronize a set of 
bindings to a single resource.

Then I saw Brian's email, where he put forward an excellent argument 
for why every binding MUST show its own unique ETag.  I can entirely 
understand a server implementor reading these specs and making that 
decision.

So if I wrote a synchronizing client (which I am), and Brian wrote an 
authoring server (which he does), if we were guided only by the specs 
and our interpretations, we would probably have interoperability 
problems.  My client would probably be confused by synchronizing two 
URLs which it knew to be bindings to the same resource but which 
reported different ETags.

Thus, I support adding text to bindings, either limiting the ways that 
servers can implement ETags and bindings, or explaining to clients the 
wide range of possible implementations they might have to deal with.

Lisa

On Jan 18, 2005, at 5:32 PM, Roy T. Fielding wrote:

>
>>> 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.
>
> I suggest we give them a sharp object and let evolution take its 
> course.
>
> There is nothing in either specification that would lead to such an
> assumption and no evidence that implementers have made it (at least
> none that survived in the wild).
>
> ....Roy
>
>

Received on Wednesday, 19 January 2005 02:27:44 UTC