ETags, If-Match and database versions

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