0

Background: there are good reasons to want to disable Last-Modified and ETag headers for some website assets: to prevent browsers sending conditional requests (either using If-Modified-Since or If-None-Match, respectively). This is good because conditional requests are just a waste of a round trip for assets that have a version number or digest in the URL – i.e. when you've made a commitment that the URL will always serve the same content body forever. In this case it's often better to force a browser to go straight to its local cache on repeat visits.


My question: I want to host a static website with S3 and CloudFront. It will be fairly low-traffic, and I want it to be fast. But there's no obvious way to prevent these headers coming through to the client – you can't disable them on S3, nor configure CloudFront to strip them out.

Options I've considered:

  • put a proxy between S3 and CloudFront (on e.g. EC2) with the sole job of stripping out these headers
    • but for me this goes against the whole point of having a static site; I want to minimise moving parts
  • use a different CDN that allows you to strip headers (e.g. could do this with Fastly's VCL configuration)
    • but I really like CloudFront's zero minimum monthly spend, it makes it very cheap for a low-traffic site.

Is there anything else I could try?

1

...when you've made a commitment that the URL will always serve the same content body forever. In this case it's often better to force a browser to go straight to its local cache on repeat visits.

A browser (or other cache) will not visit the origin until it believes the content has expired. In your case, you would want to instead send the appropriate Cache-Control or Expires headers to indicate the longest possible cache time. That's the only way to create the commitment about the stability of the URL. Removing ETag and Last-Modified will increase the data being sent, not reduce. This is because without those headers, the browser and origin will be forced to refresh the entire content, rather than simply perform a light revalidation.

In the case of using a CDN, what you may instead be looking for is one that let's you override the Cache-Control and Expires headers that are delivered to the end user to indicate that they should cache the content indefinitely, even if the CDN needs to revalidate it. So it is in your interest if the CDN is able to re-validate the content based on the ETag and Last-Modified headers, regardless of what you advertise to the end client.

  • "A browser (or other cache) will not visit the origin until it believes the content has expired." I'm 95% sure this is incorrect. I know it sounds weird, but in my experience, adding ETag headers switches a lot of browsers into a mode where they revalidate even if their cached copy is still 'fresh' according to its max-age. I'm going to run a test now to check if this is still true. – callum Jul 22 '16 at 16:28
  • OK so there is a difference, but not by as big a margin as I thought. I made a node app that served a page with two script tags, and the scripts were served one with an ETag and one without, both with far-future max-age, and I requested the html page in a bunch of different ways from different browsers. In total the ETagged script was requested a few more times than the other one, but not by a big proportion, so I guess I'll stop worrying about it. I think it made a bigger difference with the browsers of a few years ago. – callum Jul 22 '16 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.