Re: ETags, If-Match and database versions

When describing week etags vs. strong etags to people who don't understand
them (a nearly daily task for me!), I find it easiest to use the example of
an webpage which may be served from one or more specific applications. The
page looks (and interacts) exactly the same, but looking at the HTML shows
different comments in the source.

So two copies of the page served from different applications might
'effectively' be the same (same look-and-feel, same functionality), but
byte-for-byte they are actually slightly different.

This is a case where two different objects could be given the same weak
etag when stored in a server or CDN cache - when a client browser requests
an updated copy of an object which is stale in the client's cache, it
doesn't matter whether it gets copy A or copy B - it's a web page. Whether
the HTML comments in the page say one thing or another is immaterial.

On Sat, Dec 28, 2024, 6:34 AM Michael Sweet <msweet@msweet.org> wrote:

> Graham,
>
> > On Dec 28, 2024, at 7:08 AM, Graham Cox <graham@grahamcox.co.uk> wrote:
> > ...
> > I've also seen the suggestion to append a server version to the etag to
> avoid this, but there are significantly more reasons to change the server
> version that *wouldn't* change the JSON representation. And doing that
> would then mean every time the server version changes then all the etags
> would change, which would mean that caching and optimistic locking breaks -
> often needlessly...
>
> Don't make it the actual server software version, make it an encoding
> version number that changes only when the generated content changes - that
> is something you can create a unit test for (and thus be alerted when you
> need to change the number) and that could also handle potential DB schema
> changes, i.e., if you add a field/column but not remove/rename things.
>
> ________________________
> Michael Sweet
>
>
>