HTTP 缓存、用户身份验证和 PHP
我正在用 PHP 开发一些软件，并且正在尝试使其有效地利用 HTTP 缓存。然而，我最近遇到的问题之一是登录后，登录之前访问的页面会被缓存，并且不会像登录一样运行。
如果 PHP 和 PHP 之间存在 HTTP 缓存，这尤其是一个问题。客户。如果我将缓存限制器设置为始终“公共”，则该页面可能将始终被缓存（即使通过代理缓存也是如此）。如果我将缓存限制器设置为在未登录时为“公共”，在登录时将其设置为“私有”中，我目前遇到的问题可能仍然会发生。如果我将缓存限制器设置为始终私有，则代理缓存根本不会受益，并且我当前遇到的问题可能仍然会发生。
这个问题的理想解决方案是什么？有没有办法让网络浏览器在用户登录后“重试”？对于代理缓存，我知道有一些方法可以根据传入的cookie进行缓存，所以我相信这可以解决部分问题。但从网络浏览器的角度来看这个问题又如何呢？
I'm working on some software in PHP and I'm in the process of trying to make it utilize HTTP caching effectively. However, one of the problems I've been having lately is after logging in, pages visited prior to logging in are cached and do not act as if logged in.
This is especially a problem if there were to be an HTTP cache between PHP and the client. If I set the cache limiter to always be 'public,' the page presumably will always be cached (even by a proxy cache.) If I set the cache limiter to be 'public' when not logged in, and 'private' when logged in, the problem I currently have would probably still occur. If I set the cache limiter to always be private, a proxy cache would not benefit at all, AND the problem I currently have would probably still occur.
What is the ideal solution to this problem? Is there a way to cause the web browser 'try again' after the user has logged in? For a proxy cache, I know there are ways to cache based on the incoming cookies, so I believe that may solve part of the problem. But what about the issue from the web browser point of view?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这里没有一个很好的解决方案，但您有几个选择：
不是，利用 AJAX 通过 JSON 请求登录状态
服务。
相同的页面并且不期望不同的结果。这是你的吗
用例？如果是，您可能已经使用 AJAX 来提供
实时更新，实施起来可能并不是一个巨大的飞跃
选项#1。
There isn't a great solution here but you have a couple options:
not, by utilizing AJAX to request the logged in state via a JSON
service.
same pages and not expecting different results. Is this your
use-case? If it is is, you're probably using AJAX already to provide
real-time updates and it's probably not a huge leap to implement
option #1.