Re: ETags, If-Match and database versions

If-None-Match and If-Match are for different purposes.

If-None-Match is for caching. i.e., it's "Please give me this resource, but
only if it doesn't match an etag that I've previously seen". And RFC-9110
section 13.1.2 <https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.2>
says:

> A recipient MUST use the weak comparison function when comparing entity
> tags for If-None-Match (Section 8.8.3.2
> <https://www.rfc-editor.org/rfc/rfc9110.html#entity.tag.comparison>),
> since weak entity tags can be used for cache validation even if there have
> been changes to the representation data.


If-Match is for optimistic locking. i.e., it's "Please update this resource
to this new version, but only if it matches an etag that I've previously
seen". And RFC-9110 section 13.1.1
<https://www.rfc-editor.org/rfc/rfc9110.html#name-if-match> says:

> An origin server MUST use the strong comparison function when comparing
> entity tags for If-Match (Section 8.8.3.2
> <https://www.rfc-editor.org/rfc/rfc9110.html#entity.tag.comparison>),
> since the client intends this precondition to prevent the method from being
> applied if there have been any changes to the representation data.


And this just feels backwards to me. It's effectively saying:

   - The representation of the data has changed since you last saw it, but
   since the underlying data itself hasn't changed then you can just keep
   using the old representation.
   - The representation of the data has changed since you last saw it, so
   you're not allowed to update it even if the actual data itself is unchanged.

And, maybe naively, it feels like it would make more sense to be:

   - The representation of the data has changed since you last saw it, so
   here's the data in the new representation.
   - The representation of the data has changed since you last saw it, but
   since the underlying data itself hasn't changed then we can safely update
   it.

And this, really, is the crux of my question - why isn't this the other way
around?

And maybe it should actually be down to the server to decide whether they
want to support the weak or strong comparison function for each of these
cases. After all, they're the only ones who definitively know what is and
isn't safe... The HTTP spec could make suggestions, but making it a MUST
instead of a SHOULD just feels a bit much to me.

Cheers