HTTP 304&缓存控制:无缓存

发布于 2024-12-27 16:14:46 字数 1062 浏览 1 评论 0原文

我看到对网络服务器的一些调用的以下响应:

初始调用:

HTTP/1.1 200 OK
Date: Mon, 16 Jan 2012 05:46:49 GMT
X-Powered-By: Servlet/2.5 JSP/2.1
Content-Type: text/plain
Content-Length: 78
Content-Encoding: gzip
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
X-PvInfo: [S10202.C6191.A6057.RA6008.G182D.U3FAE8760].[OT/plaintext.OG/documents]
Vary: Accept-Encoding
Set-Cookie: JSESSIONID=l9pLPT5J1tpgK19Fq2qlT0F15ryByWDLgVLz16ffWPm4qQp6nzzx!-518520380; path=/; HttpOnly
DST=rd319o00000000000000000000ffffac16018bo8200; path=/
Connection: close

后续调用:

HTTP/1.1 304 Not Modified
Date: Mon, 16 Jan 2012 05:48:43 GMT
Connection: close
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
Vary: Accept-Encoding

我不清楚的是,这两个调用都返回 Cache -Control: 给浏览器的 no-cache 指令。

但是,第二次调用还会返回 304 Not Modified

如果服务器被指示不缓存早期响应,那么服务器期望页面从哪里提供数据?

有趣的是,我确实看到浏览器中提供的响应,因此浏览器似乎已经缓存了响应,尽管有 no-cache 指令。为什么?

I'm seeing the below response from some calls to a webserver:

Initial call:

HTTP/1.1 200 OK
Date: Mon, 16 Jan 2012 05:46:49 GMT
X-Powered-By: Servlet/2.5 JSP/2.1
Content-Type: text/plain
Content-Length: 78
Content-Encoding: gzip
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
X-PvInfo: [S10202.C6191.A6057.RA6008.G182D.U3FAE8760].[OT/plaintext.OG/documents]
Vary: Accept-Encoding
Set-Cookie: JSESSIONID=l9pLPT5J1tpgK19Fq2qlT0F15ryByWDLgVLz16ffWPm4qQp6nzzx!-518520380; path=/; HttpOnly
DST=rd319o00000000000000000000ffffac16018bo8200; path=/
Connection: close

Subsequent calls:

HTTP/1.1 304 Not Modified
Date: Mon, 16 Jan 2012 05:48:43 GMT
Connection: close
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
Vary: Accept-Encoding

What I'm unclear about is that both calls return a Cache-Control: no-cache directive to the browser.

However, the second call also returns a 304 Not Modified.

Where does the server expect the page to serve the data from, given that it's been instructed not to cache the earlier response?

Interestingly, I do see the response served in the browser, so the browser appears to have cached the response, despite the no-cache directive. Why?

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

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

发布评论

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

评论(1

故事未完 2025-01-03 16:14:46

带有 Cache-Control: no-cache 的响应 并不意味着响应根本不能存储在客户端,而是意味着:

如果 no-cache 指令未指定字段名称,则
缓存不得使用响应来满足后续请求
没有成功地与源服务器重新验证。这
允许源服务器阻止缓存,甚至可以通过以下方式进行缓存:
已配置为返回对客户端请求的过时响应。

因此,客户端可以将响应存储在本地缓存中,但需要由源服务器重新验证响应。如果服务器表明存储在客户端缓存中的响应仍然有效(即 304 响应),则允许客户端使用存储的响应来满足请求。

A response with Cache-Control: no-cache does not mean that the response must not be stored at the client at all, instead it means:

If the no-cache directive does not specify a field-name, then a
cache MUST NOT use the response to satisfy a subsequent request
without successful revalidation with the origin server. This
allows an origin server to prevent caching even by caches that
have been configured to return stale responses to client requests.

So the client is allowed to store the response in the local cache but it needs to revalidate the response by the origin server. If the server says that the response stored in the client’s cache is still valid (i. e. 304 response), the client is allowed to use the stored response to satisfy the request.

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