Re: ETags, If-Match and database versions

There is, and it defines the "strong comparison function" as:
> Strong comparison:two entity tags are equivalent> if both are not weak
and their opaque-tags match> character-by-character.
It's also got a table to make it clear that the strong comparison function
only works if both sides of the comparison are strong etags...
I.e., by that wording you're not able to use the strong comparison function
- as required by the If-Match header - on weak etags.
Or is there somewhere else that overrides this for this scenario?
Cheers


On Fri, 27 Dec 2024, 22:26 Mark Nottingham, <mnot@mnot.net> wrote:

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