W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: ETags and concurrency control

From: Werner Baumann <werner.baumann@onlinehome.de>
Date: Fri, 02 May 2008 21:31:40 +0200
Message-ID: <481B6C1C.3020601@onlinehome.de>
CC: ietf-http-wg@w3.org

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 
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 
- 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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC