Issue with CDN strong caching without Cache-Control or Expires headers

Question

We're using Azure CDN to serve images, and I'm trying to understand why images are being strong-cached by web browsers even though there is no Cache-Control or Expires headers in the image response.

For example, the following response headers are returned for an image from Azure CDN:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Content-MD5: KuQCJm6GQyEjejWwmRgRwQ==
Content-Type: image/jpeg
Date: Tue, 21 Nov 2017 00:15:57 GMT
Etag: 0x8D523228F0F4C42
Last-Modified: Sat, 04 Nov 2017 01:22:47 GMT
Server: ECAcc (meb/A744)
X-Cache: HIT
x-ms-blob-type: BlockBlob
x-ms-lease-status: unlocked
x-ms-request-id: 00822b7c-001e-0045-4194-61d246000000
x-ms-version: 2009-09-19
Content-Length: 5143

<<image data>>

As you can see there is an Etag header returned, but no Cache-Control or Expires headers.

When tracing the network traffic (using Fiddler) from the browser (Chrome), we are NOT seeing any subsequent requests for these images.

My understanding of Etags is that subsequent requests for this image should be sent back to the server (weak caching), and then the server can return a 304 not modified response if the file has not changed.

Can anyone shed any light on this?

Brad Barnett Brad Barnett · Accepted Answer · 2017-11-21T04:41:13

I think you need the header cache-control: must-revalidate to get the browser to check the source and have 304 mot modified returned if there is no change.

This is not optimal in terms of caching though.

You are better to invalidate the js with QS changes ("v=??") or set a short expires / max-age header (60 / 120 seconds, or whatever you can handle in terms of deployment, 5 minutes???).

Having an expires header combined with etags should still mean the browser receives a 304 not modified from the server after expiration.

Issue with CDN strong caching without Cache-Control or Expires headers

1 Answers