When we are developing new sites or testing changes in new ones that involve css after the new code is committed and someone goes to check the changes they always see a cached version of the old css. This is causing a lot of problems in testing because people never are sure if they have the latest css on screen (I know shift and clicking refresh clears this cache but I can't expect end users to know to do this). What are my possible solutions?
+2
A:
In your development environment, set the Expires header much lower. In your Production environment, set it higher, and then set it low about a week before you do your release.
Tom Ritter
2008-09-22 20:57:11
+3
A:
If you're serving your CSS from static files (or anything that the query string doesn't matter for), try varying that to ensure that the browser makes a fresh request, as it will think that it's pulling a completley different resource, so have for example:
"styles.css?token=1234" in the CSS reference in your markup and change the value of "token" on each CSS check-in
Rob
2008-09-22 20:58:19
I already use a static method to add css to pages so I added a timestamp of the build to the querystring works great thanks.
Greg
2008-09-22 21:48:08
+1
A:
Its not a great solution, but I've gotten around this before at the page level by adding a querystring to the end of the call to the CSS file:
<link href="/css/global.css?id=3939" type="text/css" rel="stylesheet" />
Then I'd randomize the id value so that it always loads a different value on page load. Then I'd take this code out before pushing to production. I suppose you could also pull the value from a config file, so that it only has to be loaded once per commit.
Michael
2008-09-22 21:01:06
A:
Similar (a bit more detail) answers given for the JavaScript version of this question, which has the same problem/solution
Paul Rowland
2009-03-18 22:05:15
A:
Looks like there is a bug with iis6 and static content, upgrade may be the best solution, if possibile.
Joao Pinto
2010-08-25 17:52:55