HTTP 标头“Cache-Control: public”有什么风险?

发布于 2024-09-11 16:26:45 字数 546 浏览 3 评论 0原文

Cache-Control HTTP/1.1 标头可以指定 max-age 以及缓存内容是否可以是公共的或私有的,指示中间缓存是否可以缓存该内容。

例如,Ruby on Rails 的 expires_in() 默认使用 Cache-Control: private

将其公开有什么风险?如果它是公共的,哪些额外的地方可以缓存内容——例如,它会是代理服务器吗?

如果网站像 Amazon.com,但用户是匿名的,那么可能不存在太多隐私问题?如果用户登录了,会不会存在隐私问题,因为数据经过地方,数据是可见的。如果该位置想要“坏”,那么它确实不需要关心 Cache-Control: private

如果这是一个用户可以登录的网站,但该网站只搜索鱼油、维生素等保健品怎么办?在这种情况下,涉及的隐私就更少了,因为它不像亚马逊,那里有更多种类的产品,例如用户可以真正更关心隐私问题的书籍。

话虽如此,拥有 Cache-Control: public 的额外优势是什么?

The Cache-Control HTTP/1.1 header can specify max-age as well as whether the cache content can be public or private, indicating whether intermediate cache can cache the content.

For example, Ruby on Rails's expires_in() defaults to using Cache-Control: private

What is the risk of making it public? If it is public, which extra places can cache the content -- would it be a proxy server, for example?

What if the website is like Amazon.com, but the user is anonymous, then probably there is not much privacy issue? What if the user is logged in, could there be privacy issue, because the data passes through places and the data is visible. If that location wants to be "bad", it really doesn't need to care about the Cache-Control: private anyway.

What if it is a website where user can be logged in, but the website only search for health products like fish oil and vitamins, and so forth. In that case, there is even less privacy involved because it is unlike Amazon.com where there are a lot more variety of products such as books for which a user can really care more about privacy issue.

Having said that, what is the additional advantage of have Cache-Control: public?

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

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

发布评论

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

评论(2

夏至、离别 2024-09-18 16:26:45

Cache-Control: Public 的问题是响应可能会被缓存并显示给不同的用户。如果您有一个经过身份验证的应用程序显示私有数据,这就会出现问题。一般来说,您应该只对静态页面或无论哪个用户发出请求都返回相同数据的页面使用 public。

The problem with Cache-Control: Public is that the response may be cached and displayed to a different user. This is a problem if you have an authenticated application that is displaying private data. In general, you should only use public for static pages, or pages that return the same data no matter what user is making the request.

波浪屿的海角声 2024-09-18 16:26:45

我进一步找到了以下规范:

http://www.w3。 org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

公开

表示响应可能是
由任何缓存缓存,即使它会
通常是不可缓存或可缓存的
仅在非共享缓存内。 (看
还有授权,第 14.8 节,用于
其他详细信息。)

私人

表示全部或部分
响应消息的目的是
单用户且不得被缓存
共享缓存。这允许一个原点
服务器声明指定的
部分响应的目的是
只有一个用户并且不是有效的
响应其他用户的请求。
私有(非共享)缓存可以缓存
的回应。注意:此用法
单词 private 仅控制
响应可能会被缓存,但不能
确保消息的私密性
内容。

所以看起来更多的是“共享缓存”而不是中间缓存。

I further found the following spec:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

public

Indicates that the response MAY be
cached by any cache, even if it would
normally be non-cacheable or cacheable
only within a non- shared cache. (See
also Authorization, section 14.8, for
additional details.)

private

Indicates that all or part of the
response message is intended for a
single user and MUST NOT be cached by
a shared cache. This allows an origin
server to state that the specified
parts of the response are intended for
only one user and are not a valid
response for requests by other users.
A private (non-shared) cache MAY cache
the response. Note: This usage of the
word private only controls where the
response may be cached, and cannot
ensure the privacy of the message
content.

So it looks like it is more about "shared cache" instead of intermediate cache.

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