Re: ETags and concurrency control

Julian Reschke wrote:
> I'd say that it's the server's choice to generate these kinds of ETags. 
> Nut if it does, and they aren't reliable enough for a write operation, 
> it could still reject the request... My understanding was that we want 
> *allow* servers to support weak etags on write operations, not require.
> 
Take the case of Apache-style weak etags (based on insufficient time 
resolution).
If the server cannot know whether the the entity changed since the etag 
was generated, it will always have to reject the request. Allowing weak 
etags in these requests will only result in an additional round trip.
If the server can know whether the entity changed since the etag was 
generated, there is no need for the etag to be weak, it *is* strong.

Things are quite different, when you think of weak etags meaning not 
byte-by-byte, but semantically equal. But there is the whole mess. These 
are two completely different and unrelated concepts.
- insecure (or unreliable): there is a small chance, that the entity 
changed without changing the etag, and the change may be completely 
arbitrary.
- semantically equivalent, though not byte-by-byte equal.

As long as you try to get this two concepts into one definition of weak 
etag, it will stay a confusing mess.

Werner

Received on Friday, 2 May 2008 19:32:26 UTC