谷歌浏览器缓存问题

发布于 2024-11-05 03:35:54 字数 814 浏览 0 评论 0原文

我之前问过这个问题但没有得到答案,所以我添加更多信息。 我使用 spring 3 mvc 和 spring security 进行身份验证/授权构建了一个对 js 要求较高的在线服务。 HTTPS 是任何交互的必要条件,因此所有请求都启用 HTTPS。服务器设置由 Apache2 服务器后面的单个 Tomcat 7 应用程序服务器(将来可能会添加更多)组成,该服务器充当 mod_proxy、mod_cache 和 mod_deflate 的反向代理。为所有可缓存资源(js、css、图像)设置缓存标头:

Cache-Control:max-age=604800, must-revalidate, public

上述标头在 Firefox 和 IE 浏览器(至少我分别测试过的版本 3+ 和 8+)中均具有所需的结果,即两个浏览器相应地缓存 .js 和 .css 文件,除非用户刷新页面,这样浏览器就会在请求标头中附加 Cache-Control:max-age=0 并获得 304 回复,或者强制使用 Cache-Control:no-cache 进行刷新,以便重新获取资源。 另一方面,Google Chrome 的行为有所不同,尽管它会缓存文件,但会通过将 jsessionid 附加到用于在缓存中存储文件的键来将文件绑定到分配给用户的特定会话。这会导致每次用户登录/退出或关闭浏览器时从服务器重新获取文件(Spring security 有一个临时 sessionid 和一个不同的“记住我”)。当用户访问登录屏幕以及登录后重定向到主站点时,用于登录屏幕和主站点的主 css 甚至会被提取两次(因为现在 chrome 忽略了缓存中的文件,该文件没有sessionid 绑定到它)。

I have asked this question before and got no answer so i am adding more info.
I have built an online service that's a bit heavy on js using spring 3 mvc and spring security for authentication / authorization. HTTPS is a requirement for any interaction so this is on for all requests. The server setup consists of a single Tomcat 7 app server (may add more in the future) behind an Apache2 server that acts as a reverse proxy with mod_proxy, mod_cache and mod_deflate. The cache headers are set for all cacheable resources (js,css,images) to:

Cache-Control:max-age=604800, must-revalidate, public

The above header has the desired outcome in both Firefox and IE browsers (at least versions 3+ and 8+ respectively that i have tested on) i.e. both browsers cache the .js and .css files accordingly unless the user refreshes the page so the browser will append to the request header a Cache-Control:max-age=0 and will get a 304 reply, or forces a refresh with Cache-Control:no-cache so it will refetch the resource.
On the other hand, Google Chrome behaves differently, although it caches the files it binds them to the specific session that is assigned to the user by appending the jsessionid to the key that is used for storing the files in cache. This results in the files being re-fetched from the server each time the user logs in/out or closes the browser (Spring security has a temporal sessionid and a different remember me one). The main css that is used for the login screen as well as the main site is even fetched twice when the user visits the login screen and when he is redirected to the main site after login (since now chrome ingores the file in cache which has no sessionid bound to it).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

各空 2024-11-12 03:35:54

我最近再次遇到这个问题,我终于弄清楚了 Chrome 拒绝缓存静态资源的原因,即使标头完全正常。
它与会话无关,相反,如果您从 HTTPS URL 请求资源并且服务器使用您尚未在受信任的证书存储中导入的自签名证书,则它不会缓存任何内容。我有

I came across this problem again lately and i finally figured out the reason that Chrome was refusing to cache the static resources even though the headers were perfectly fine.
It had nothing to do with the session, instead it will not cache any content if your requesting resources from an HTTPS URL and the server uses a self signed certificate which you haven't imported in your trusted certificates store. I had

意犹 2024-11-12 03:35:54

是否标记no-transform 到底有什么帮助吗?

Cache-Control:max-age=604800, must-revalidate, public, no-transform

Does tagging no-transform on the end help any?

Cache-Control:max-age=604800, must-revalidate, public, no-transform
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文