Sunday, April 22, 2007

a new fix for the msie caching bug

ran into trouble with my ajax html client running in msie (7 in this case). it *refused* to refresh the pages it just edited! in other words, xmlhttprequest was not used to get the new data - msie served the data from a local cache instead!!!!!

i've sen this before and the most common fix is to add random data to the end of the URL to convince msie that this is a new url:


it works, but is messy. i dug around for a while and turned up a posting on the msdn site that talked about this issue in some detail. the key point, msie honors a custom cache control header extension that allows web servers to control this odd behavior:

Cache-Control: post-check=[sec],pre-check=[sec]

both values are in seconds.

the deal is this:

when ie completes an http get request, it places the results in a local cache. then next time is is about to make the same request, these two values come into play. if the copy in the local cache is younger than the pre-check value, msie will deliver the data from the local cache. *also*, if the copy in the local cache is *older* than the post-check value, msie will (in the background) get a copy of the new resource from the server and save it do disk. that way the *next* time the page is requested, it will be newer, but it will still come from the local cache.

convoluted, but efficient.

so i added the following cache-control header to all my output:

CacheControl: post-check=1,precheck=2

the good news is that this worked like a champ. no messing with the url means i can better support third-party caching servers and still get msie to behave properly.

there are a handful of details to setting this up properly, so it's worth checking out the page at msdn.

No comments: