0

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.

ilivewithian
  • 19,476
  • 19
  • 103
  • 165

5 Answers5

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

JohnFx
  • 34,542
  • 18
  • 104
  • 162
2

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:

http://blog.httpwatch.com/2007/10/03/60-of-web-users-can%E2%80%99t-be-wrong-%E2%80%93-don%E2%80%99t-break-the-back-button/

HttpWatchSupport
  • 2,804
  • 1
  • 17
  • 16
1

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.

matt b
  • 138,234
  • 66
  • 282
  • 345
  • It's not a problem with editing old data, we can handle that easily. It's users getting confused that their changes aren't shown on the page. – ilivewithian Apr 08 '09 at 07:59
1

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?

Christopher Edwards
  • 6,589
  • 8
  • 43
  • 57
0

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.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794