Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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"

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:

Does that sound correct?

share|improve this question
up vote 4 down vote accepted

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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