2

A very common solution is to do the following:

<ifModule mod_headers.c>
    FileETag None
    Header unset ETag
    Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
    Header set Pragma "no-cache"
    Header set Expires "Thu, 01 Jan 1970 00:00:01 GMT"
</ifModule>

I do want them to be cached, but I also want them to be invalidated when we redeploy. I'm thinking that I need to re-enable the ETag and then when we re-upload files "touch" them so the timestamps will all read the current time and they'll get a different ETag.

I'm somewhat going by what I'm reading from this answer:

https://stackoverflow.com/questions/499966/etag-vs-header-expires

Does that sound correct?

Community
  • 1

1 Answers1

3

Etag is a good idea, but your expires header thwarts it. Why not just set your expires header to a sane value? Too many people set the expires to crazy dates, which for a properly configured client will make the client not even send a request to the server.

First, set your expires to something sane like request date + 1 week (whatever your expected release cycle is). Then clients that properly follow the specifications for expires headers will check back after that much time. Its much simpler and more reliable than trying to cache bust everything every deploy.

EDIT: I assumed the example you gave was your config. I don't mean it to sound harsh but I see people doing silly stuff with caching all the time.

Kyle
  • 1,589
  • 9
  • 14