处理缓存和浏览器后退按钮的最佳方法是什么?
处理用户返回到在 ASP.NET 应用程序中缓存了项目的页面的最佳方法是什么? 有没有一种好方法来捕获后退按钮(事件?)并以这种方式处理缓存?
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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
您可以尝试使用 HttpResponse.Cache 属性如果这有帮助:
或者可以使用 HttpResponse.CacheControl,但它已被弃用,取而代之的是上面的 Cache 属性:
编辑:或者您真的可以 发疯并手动完成这一切:
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:
据我所知(或至少读过),最好不要尝试响应用户事件,而是思考“在页面中”。
构建您的应用程序,以便它不关心后退按钮是否为推.. 它只会处理它.. 从开发的角度来看,这可能意味着一些额外的工作,但总体而言将使应用程序更加健壮..
即,如果步骤 3 执行一些数据更改,则用户单击返回(到步骤 2)并再次单击“下一步”,然后应用程序检查是否已进行更改。或者理想情况下,在用户单击“确定”之前,它不会进行任何硬更改结束..这样,所有更改都会被存储,并且您可以根据之前每次加载时输入的值重新填充表单..
我希望这是有道理的:)
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 :)
RFC 2616 §13.13 说历史和缓存是不同的东西。 缓存绝对不能影响后退按钮。
如果 HTTP 标头的任何组合影响“后退”按钮,则这是浏览器中的一个错误……但有一个例外。
在 HTTPS 中,浏览器将
Cache-control: Must-revalidate
解释为使用后退按钮时刷新页面的请求(Mozilla 称之为“愚蠢的银行模式”)。 纯 HTTP 不支持此功能。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.处理这个问题的最佳方法可能是在 ASP.NET 页面(或者母版页,如果您使用的是母版页)中放置一个 no-cache 指令。 我认为没有办法直接在 ASP.NET 代码中处理这个问题(因为缓存决策是在客户端进行的)。
至于MVC,不知道如何实现这一点(假设它与基于Web Forms的ASP.NET不同); 我没用过。
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.
以下代码在 IE9+、FF21 和最新 Chrome 中适用于我:
您可以将其放置在 MasterPage 中的
Page_Load()
事件处理程序中,以便应用程序中的每个页面在以下情况下都需要往返服务器:按后退按钮。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.