Chrome ignores the ETag header and just uses the in memory cache/disk cache

The server is telling chrome that the resource is good for the next 2 hours (7200 seconds). Presumably your second request was sooner than that.

You would be better served with max-age: 0 or perhaps max-age: 0, must-revalidate. Then while you'll never get a fully-cached operation (not even bothering to hit the server) you can still have the server send 304 Not Modified responses to tell the browser that it can use the cached entity (and update any metadata based on headers if applicable) so while you still have a request-response happening only around 300bytes will be sent rather than however many kilobytes or more the entity is.

This is an old post but this is how we solved it.

@Musterknabe Comment on your update 3:

The same thing happened with us, even after setting must-revalidate chrome was not reloading fresh resources. I found out that since resources were already present in clients/browser cache memory they were being served from memory cache and the new request(to get static resources) was not firing resulting. So response headers were not updated with must-revalidate

To fix this problem we used two steps:
1. Changed resource file names - To make sure new request will be fired
2. Added cache-control headers to static files(In startup.cs) - To take care of future static resource file changes. So that going forward we don't have to change the resource file names.

    public void Configure(IApplicationBuilder app)    {        app.UseStaticFiles(new StaticFileOptions        {            OnPrepareResponse = ctx =>            {                const int durationInSeconds = 0;                ctx.Context.Response.Headers[HeaderNames.CacheControl] =                    "must-revalidate,max-age=" + durationInSeconds;            }        });    }

Hope it helps.

For anyone else who might land here, note that Chrome does not cache anything if there are any SSL errors (such as if you're using a self-signed certificate).

Original post that clued me in: https://stackoverflow.com/a/55101722/9536265

Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=110649 (and it appears they will never fix it, which seems ridiculous since almost all developers will be developing in that very situation)

I have not been able to confirm with documentation, but the behavior appears to be the same with Edge Chromium. Firefox, on the other hand, will happily follow standard cache practices for sites using "Not secure" certificates such as those with imperfectly-matching site names or self-signed certificates. I have not tested Safari.