RE: ETags and concurrency control

Pablo Castro wrote:
> Weak ETags: the HTTP spec is pretty explicit that 
> ETag/if-match headers require bit-by-bit equality of the 
> resource, and if the resource changes a single bit then the 
> ETag should be different. There is a concept of "weak ETags" 
> that can be equal if the resource is "semantically 
> equivalent", but the spec indicates that is only to be used 
> in GETs. So for the cases where a developer uses something 
> that's not a reliable timestamp as an ETag we end up 
> deviating somewhat from the spec. I'm sure that other folks 
> have ran into this before.

(from the blog post):
> You can also used a relaxed form of ETags where the entity
> might change but the ETag stay the same. It's not
> completely HTTP compliant and may confuse intermediate
> systems, but it may be your only option in some scenarios.

Nobody should implement optimistic concurrency in SQL without using a
version field (e.g. timestamp) or checking every single value in the row (or
at least the ones being updated). Otherwise, you don't have optimistic
concurrency; you have a giant mess. The same applies to ETags; if the server
doesn't vary the ETag when the resource (representation) changes, then you
will end up with a huge mess. 

You can use MD5, SHA-1, or SHA-2 hashing to keep the ETag at a reasonable
size. Many backup systems and distributed filesystems are using SHA-* hashes
for duplicate block detection. You should be able to find quite a few
whitepapers and research papers that detail the (minute) risks associated
with using these hashes for matching.

I can't think of a reason that weak ETag comparison should be forbidden for
non-safe HTTP requests (PUT or DELETE), as long as people are using matching
weak ETags only for "semantically equivalent" representations. Strong ETag
comparison should only be needed for range requests. Try bringing it up on
the HTTP Working Group mailing list (ietf-http-wg@w3.org) and see what they
have to say.

Regards,
Brian

Received on Monday, 28 April 2008 05:01:48 UTC