- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 28 Dec 2024 09:26:31 +1100
- To: Graham Cox <graham@grahamcox.co.uk>
- Cc: ietf-http-wg@w3.org
There's a specific definition of the comparison function here: https://httpwg.org/specs/rfc9110.html#entity.tag.comparison To summarise, you can use weak ETags, but in this case you need to compare them as if they were strong. Cheers, > On 28 Dec 2024, at 2:14 am, Graham Cox <graham@grahamcox.co.uk> wrote: > > Hi there, > > I've been implementing optimistic locking in my REST API, and have run into some awkwardness with the way ETags work per RFC-9110. And I'm wondering if I'm missing something obvious... > > Firstly, we've got the entire concept of strong and weak ETags. In particular, RFC-9110 states: > > A "strong validator" is representation > > metadata that changes value whenever a > > change occurs to the representation data that > > would be observable in the content of a 200 > > (OK) response to GET. > > > In contrast, a "weak validator" is > > representation metadata that might not > > change for every change to the > > representation data. This weakness might be > > due to limitations in how the value is > > calculated (e.g., clock resolution), an inability > > to ensure uniqueness for all possible > > representations of the resource, or a desire of > > the resource owner to group representations > > by some self-determined set of equivalency > > rather than unique sequences of data. > https://datatracker.ietf.org/doc/html/rfc9110#section-8.8.1 > > So, I read that to mean that if you're using a strong etag then it should be generated based on the bytes-on-the-wire. Or, to put another way, if you're using the database stored version of the data then it should be a weak etag instead. In particular since a change in the formatting of the data - pretty printing, field order, etc - might have no impact on the meaning of the data but does change the bytes sent. > > Which is all pretty reasonable. And is easy to handle, which is nice. > > However, if we then get to the If-Match header then we see this: > > An origin server MUST use the strong > > comparison function when comparing entity > > tags for If-Match > > So, if we're using weak ETags then we "can't" use If-Match. > > Which, all combined, would seem to mean that we can't use If-Match for optimistic locking based on database stored versions. > > Is this right? Or am I missing something? > > Cheers -- Mark Nottingham https://www.mnot.net/
Received on Friday, 27 December 2024 22:26:39 UTC