Re: ETags, If-Match and database versions

On Sun, Dec 29, 2024 at 02:39:11PM +0000, Graham Cox wrote:
> 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.

If-Match specifies behavior of If-Match.

If-Match does not specify behavior for specific Content-Type.

*Iff* your JSON is semantically the same, you can choose to issue a
Strong ETag for the data in the database.  That's on you; your call for
your server.  *Iff* you know how caching intermediaries and clients will
operate on that Strong ETag, such as for your optimistic locking, and
that behavior is your intended behavior, you may go forth and issue a
Strong ETag.

These protocols are intended to provide deterministic and expected
interoperable behavior between clients, intermediaries, and servers.

If you use Strong ETags on your database data, do you achieve the
behavior you desire using Strong ETags?  Do your questions derive from
an actual real-world problem?  Please describe how.  Are you merely
afraid that the HTTP response is not byte-for-byte identical even though
you know the JSON is semantically equivalent and based on identical data
in the underlying database, and that underlying data is the scope you
want to identify with the Strong ETag, and you do not see issues with
client and intermediaries use of the specific representation of the
database data returned in the HTTP response?

If your (postive and negative scenario) testing demonstrates your
intended behavior using Strong ETags on your database data, feel free
to use Strong ETags on your database data.

Cheers, Glenn

Received on Sunday, 29 December 2024 15:29:53 UTC