Why isn't the browser respecting the Cache-Control header?

Question

I've got an image on S3, that has a Cache-Control header set to public, max-age=3600. So, downstream systems (proxy, browser, etc) should cache it for 1 hour.

I can see the browser returns 304 (not modified) after subsequent requests.

I've then gone and updated that image on S3 (the resource isn't versioned..the URL hasn't changed, just the _content), but the browser went and got the new version. (e.g HTTP 200).

Here's the chrome network traffic:

Requests:

1. 200 (ok)
2. 304 (not modified)

~ image changed behind the scenes ~

3. 200 (ok)
4. 304 (not modified)

Here's the response header:

How is this possible? Am i not setting the correct header?

Two things are confusing me:

1. The response should still be 304 (not modified)? How did the browser know to go and get the image? max-age hasn't been reached?
2. Shouldn't chrome show "from disk cache" or whatever? (and not actually go to the server?)

My guess is - i'm not setting the right cache-control header or something. So can someone please shed some light on this behaviour, and let me know what i need to do to cache resources for 1 hour :)

Thanks!

Answer 1

There is ETag specified in the response.

The ETag is explained as such in the spec

An entity-tag can be more reliable for validation than a modification date in situations where it is inconvenient to store modification
dates, where the one-second resolution of HTTP date values is not
sufficient, or where modification dates are not consistently
maintained.

so browsers prefer it over the date-based expiration.

Hence, your browser makes a request every time, and unless the content has changed - http 304 is returned. Otherwise - it's http 200.

If you only want time-based expiration - remove ETag.

References:

• https://tools.ietf.org/html/rfc7232#section-2.3