Re: ETags, If-Match and database versions

Graham,

Ah yes - I'm used to the more common caching use of ETags - browsers only
ever use INM that I'm aware of and they only return a single value
(whatever was passed in the ETag response header). Sorry for missing that.

FWIW, that RFC is INCREDIBLY hard to understand (IMO) and always has been.

My take is that it's *your* server and *your* content, so it's entirely up
to you what sort of ETag you send in a response header - weak or strong -
which will affect what comparison function is used by your web server if
your client uses an If-Match header.

For example, you COULD pass two semantically-the-same but technically
different representations of the data, e.g.

    {
        "title": "Some Article Title",
        "content": "Some Article Content"
    }

and

    {
        "content": "Some Article Content",
        "title": "Some Article Title"
    }

and give them both the same strong ETag (based on the database values used
to build those fields). Is it a 'good' idea to pervert the use of strong
vs. weak ETags? Probably not. But as long as you're able to validate
things, it doesn't really matter.

I guess what I'm saying is that all of the ETag/INM/IM processing is
entirely based on what you, the server, decide to mark your content as.

Rory

On Sun, Dec 29, 2024 at 7:33 AM Glenn Strauss <
gs-lists-ietf-http-wg@gluelogic.com> wrote:

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

-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt