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 that way?
相关问题
- Carriage Return (ASCII chr 13) is missing from tex
- How to store image outside of the website's ro
- 'System.Threading.ThreadAbortException' in
- Request.PathInfo issues and XSS attacks
- How to dynamically load partial view Via jquery aj
相关文章
- asp.net HiddenField控件扩展问题
- asp.net HiddenField控件扩展问题
- Asp.Net网站无法写入错误日志,测试站点可以,正是站点不行
- asp.net mvc 重定向到vue hash字符串丢失
- FormsAuthenticationTicket expires too soon
- “Dynamic operations can only be performed in homog
- What is the best way to create a lock from a web a
- Add to htmlAttributes for custom ActionLink helper
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.
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 :)
The following code worked for me in IE9+, FF21 and Latest Chrome:
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.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.You can try using the HttpResponse.Cache property if that would help:
Or could could block caching of the page altogether with HttpResponse.CacheControl, but its been deprecated in favor of the Cache property above:
Edit: OR you could really go nuts and do it all by hand: