I have an app which is very database and user intensive. The users are very keen on the browser history buttons for navigation.
Is there a way that I can absolutely guarantee that the page will reload if a user picks something out of their browser history?
What I regularly see is that a copy of the page will be shown from the browsers cache, rather than being reloaded.
I’ve tried:
this.Response.Cache.SetNoStore() this.Response.Cache.SetNoServerCaching() this.Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache)
And
this.Response.Cache.SetExpires(DateTime.Now.AddSeconds ( -1 ) );
None of these seems to help, sometimes the browser will load the old cached version anyway.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
You need two statements to prevent caching:
Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache); // For IE
Response.Cache.SetNoStore(); // For Firefox
For more detail see:
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
Also, make sure that you always follow a POST with a redirect so that the back button works correctly:
Method 2
If you are using the 3.5 framework you can use the History server control to manager what goes into the browser history.
Here is a video and some blog articles with tips on using it:
Video: How Do I Use the ASP.NET history control?
Back Button Support for ASP.NET Update Panels
ASP.NET: Managing Browser History with AJAX and UpdatePanels
Tip/Trick: Enabling Back/Forward-Button Support for ASP.NET AJAX UpdatePanel
Update: As noted int he comments, you are using the 2.0 version of the framework. Here is a link explaining how to use this control on .NET 2.0 :
Using ASP.NET 3.5 History Control with ASP.NET 2.0
Method 3
What’s the danger of seeing old data? If it is a fear that user’s will interact with or attempt to change “old” data, then when the user makes a submission, shouldn’t the server-side code be capable of handling requests to act on “old data” or data that is no longer valid?
It would be probably be far easier to prevent “accidental” updates of data that users shouldn’t be able to interact with on the server-side, as opposed to preventing any client ever from having a copy of a page stored in their browser history or cache. You aren’t really ever going to be able to perfectly present the latter.
In other words, you are better off making sure that these types of bugs don’t enter your application where you have control – the server-side code – than you are hoping that every single browser that interacts with your site respects your cache headings, that every single browser follows the HTTP/HTML standards, etc.
Method 4
Are you sure the browser cache is the issue?
Response.Cache.SetCacheability(HttpCacheability.NoCache)
Should work. Have you tried different browsers or are all browsers affected?
Method 5
I wouldn’t worry so much about the cache.
The problem in ASP.Net is that postback events and ViewState mean the server may not render the same url in the same way twice. Instead, it takes the current “state” of the app into account. So when the user hits the back button, because viewstate and other postback data is not available going in this direction they may not see the page in the same way they were expecting.
To keep the back button working you need to turn off ViewState and handle all server events with a Response.Redirect to a new URL.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0