Squid 配置以确保 HTTP 标头与缓存内容的标头匹配

发布于 2024-10-01 05:41:07 字数 749 浏览 10 评论 0原文

我们有这样的云设置:

User Request -> Perlbal (SSL unwrapping) -> Squid (Caching) -> Apache -> HTTP Response

我们在某些页面上支持 SSL,而在其他页面上不支持。 perlbal 层之外的所有内容仅处理通过未加密的 HTTP 的请求,因为 perlbal 解包了 SSL,但它确实添加了一个 X-Forwarded-Proto 标头,以便应用程序知道是否使用了 SSL。

如果请求通过 HTTP 到达应用程序 (Apache),则当该特定页面需要 SSL 时,它会重定向到 HTTPS。

当对安全资源的请求到达我们的应用程序时,如果应用程序发送Cache-Control: public,squid 会正确缓存该内容。问题是,如果用户在缓存后尝试访问该资源的 HTTP 版本,squid 将其作为缓存 HIT 处理并通过 HTTP 返回缓存的资源,而实际上我们需要将其视为缓存 MISS,因为 X -Forwarded-Proto 与原始请求不匹配。

这是怎么做到的?我们的应用程序发送:

Vary: X-Forwarded-Proto,Accept-Encoding

我很难找到任何关于此的文章/文档,并且这个 Vary 标头似乎是其他人建议的,但它不起作用。无论 X-Forwarded-Proto 标头指示 SSL 或其他方式,Squid 都会提供缓存内容。

We have a cloud setup like this:

User Request -> Perlbal (SSL unwrapping) -> Squid (Caching) -> Apache -> HTTP Response

We support SSL on some pages, and not on others. Everything beyond the perlbal layer only process requests over unencrypted HTTP since perlbal unwraps the SSL, but it does add an X-Forwarded-Proto header so that the application knows if SSL was used or not.

If a request hits the application (Apache) over HTTP, when that particular page requires SSL it redirects to HTTPS.

When a request for a secure resource reaches our application, and if the application sends Cache-Control: public, squid caches that content correctly. The problem is that if the user then tries to access the HTTP version of that resource once it's cached, squid processes it as a cache HIT and returns the cached resource over HTTP, when in fact we need it to consider it a cache MISS because X-Forwarded-Proto does not match the original request.

How is this done? Our application sends:

Vary: X-Forwarded-Proto,Accept-Encoding

I'm having a hard time finding any articles/documentation on this and this Vary header seems to be what other people suggest, but it is not working. Squid serves the cached content regardless of the X-Forwarded-Proto header indicating SSL or otherwise.

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

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

发布评论

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

评论(1

趁微风不噪 2024-10-08 05:41:07

天啊。

由于历史原因,我们在 .htaccess 中添加了此内容:

BrowserMatch "MSIE" brokenvary=1
BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
BrowserMatch "Opera" !brokenvary
SetEnvIf brokenvary 1 force-no-vary

三种猜测一旦 IE 6 用户访问我们的网站,squid 缓存会发生什么情况。更改标头已删除。缓存策略被破坏。

螺丝IE。删除这个是一个很好的举措。现在一切正常。

OMFG.

We had this in our .htaccess for historical reasons:

BrowserMatch "MSIE" brokenvary=1
BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
BrowserMatch "Opera" !brokenvary
SetEnvIf brokenvary 1 force-no-vary

Three guesses what happens to the squid cache once an IE 6 user visits our site. Vary header removed. Caching strategy broken.

Screw IE. Removing this was a good move. Everything working now.

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