Using back button: IE and Safari not reading from

Question

I'd like to avoid a GET request when the user navigates away from a page and returns to it when using the broswer's back button. This works fine without any special treatment in Firefox and Chrome (recent versions).

However, Safari and IE both perform a GET request when using the back button to go back to a previous page.

I've fiddled around with headers controlling the caching behavior (Last-Modified, Expires, Cache-Control) without success. Any suggestions how one can stop IE and Safari from reloading the page when using the back button?

Here's is a typical request and response header, which are identical in IE and Safari when using the back button, reloading the page or entering the URL in the adress bar.

Request Headers

Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding:gzip, deflate
Accept-Language:en-US
Origin:http://165.88.162.245:8000
Referer:http://165.88.162.245:8000/login?next=/
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.21.1 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1

Response Headers

Content-Language:en
Content-Type:text/html; charset=utf-8
Date:Tue, 12 Jul 2011 11:35:31 GMT
Server:WSGIServer/0.1 Python/2.6.6
Set-Cookie:sessionid=0675e1246fe03946c54d2052e7adf0c9; Path=/
Vary:Accept-Language, Cookie

Answer 1

Which versions of IE specifically? What are the exact HTTP Response headers?

IE9 and earlier will not cache a page with a "no-cache" header. For IE10 and later, the cached response will be conditionally validated or pulled from the cache without validation in the case of back/forward navigation (See http://blogs.msdn.com/b/ieinternals/archive/2012/08/01/internet-explorer-10-network-performance-improvements-first-available-pre-resolve-pre-connect-caching.aspx)

IE9 fixed a number of issues in this area; please read http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx for more information.

Answer 2

The problem for IE was the Varyheader entry. In particular the Cookie entry which inhibits caching in IE. Thanks to the blog entry mentioned by Eric I was able to pin down the problem.

Unfortunately this does not solve the problem in Safari. Eventually I settled down to a different approach which seems much better. The reason the reload bothered me was that I used it to provide access to a session state that has been left by navigating away from the page. The solution is not to to rely on the client cache to provide this functionality, rather provide URLs which perform the task of reloading the session state independent of client caching.