What's the best way to deal with cache and the browser back button?

Question

What\'s the best way to handle a user going back to a page that had cached items in an asp.net app? Is there a good way to capture the back button (event?) and handle the cache

Answer 1

The following code worked for me in IE9+, FF21 and Latest Chrome:

Response.Cache.SetCacheability(HttpCacheability.NoCache | HttpCacheability.Private);
Response.Cache.AppendCacheExtension("must-revalidate");
Response.Cache.AppendCacheExtension("max-age=0");
Response.Cache.SetNoStore();

You can place this in Page_Load() event handler in the MasterPage so that every page in your app requires a round-trip to the server when pressing the back button.

Answer 2

RFC 2616 §13.13 says that History and Cache are different things. There should be absolutely no way for cache to affect Back button.

If any combination of HTTP headers affects Back button, it's a bug in the browser …with one exception.

In HTTPS browsers interpret Cache-control: must-revalidate as request to refresh pages when Back button is used (Mozilla calls it "silly bank mode"). This isn't supported in plain HTTP.

Answer 3

As far as I know (or at least have read) is its best to try not to work in response to user events, but rather think "in the page"..

Architect your application so it doesn't care if the back button is pushed.. It will just deal with it.. This may mean a little extra work from a development point of view, but overall will make the application a lot more robust..

I.e if step 3 performs some data chages, then the user clicks back (to step 2) and clicks next again, then the application checks to see if the changes have been made.. Or ideally, it doesnt make any hard changes until the user clicks "OK" at the end.. This way, all the changes are stored and you can repopulate the form based on previously entered values on load, each and every time..

I hope that makes sense :)

Answer 4

You can try using the HttpResponse.Cache property if that would help:

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetValidUntilExpires(false);
Response.Cache.VaryByParams["Category"] = true;

if (Response.Cache.VaryByParams["Category"])
{
   //...
}

Or could could block caching of the page altogether with HttpResponse.CacheControl, but its been deprecated in favor of the Cache property above:

Response.CacheControl = "No-Cache";

Edit: OR you could really go nuts and do it all by hand:

Response.ClearHeaders();
Response.AppendHeader("Cache-Control", "no-cache"); //HTTP 1.1
Response.AppendHeader("Cache-Control", "private"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "no-store"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "must-revalidate"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "max-stale=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "post-check=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "pre-check=0"); // HTTP 1.1 
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.1 
Response.AppendHeader("Keep-Alive", "timeout=3, max=993"); // HTTP 1.1 
Response.AppendHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT"); // HTTP 1.1 

Answer 5

The best way to deal with it is to probably put a no-cache directive in your ASP.NET pages (or a master page if you're using one). I don't think there's a way to deal with this directly in your ASP.NET code (since the cache decision is happening on the client).

As for MVC, don't know how you would accomplish that (assuming it's different from Web Forms-based ASP.NET); I haven't used it.