HTTP 304 Not Modified 响应是否应该包含缓存控制标头?

发布于 2024-08-07 17:15:58 字数 1536 浏览 9 评论 0原文

我试图理解这一点,并搜索了类似的问题,但我仍然没有 100% 理解它应该如何工作。

我在请求图像资源时得到以下响应:

Response Headers
    Server  Apache-Coyote/1.1
    Date    Mon, 19 Oct 2009 09:04:04 GMT
    Expires Mon, 19 Oct 2009 09:06:05 GMT
    Cache-Control   public, max-age=120
    Etag    image_a70703fb393a60b6da346c112715a0abd54a3236
    Content-Disposition inline;filename="binary-216-420"
    Content-Type    image/jpg;charset=UTF-8
    Content-Length  4719

所需的行为是客户端应将其缓存 120 秒,然后再次从服务器请求它。在 120 秒内,没有向服务器发送任何请求。

然后,120 秒后,发送请求并收到 304 响应:

Response Headers
    Server  Apache-Coyote/1.1
    Date    Mon, 19 Oct 2009 09:06:13 GMT

Request Headers
    Host    localhost:8080
    User-Agent  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
    Accept  image/png,image/*;q=0.8,*/*;q=0.5
    Accept-Language en-us,no;q=0.8,sq;q=0.7,en;q=0.5,sv;q=0.3,nn;q=0.2
    Accept-Encoding gzip,deflate
    Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive  300
    Connection  keep-alive
    Referer http://localhost:8080/cms/site/0/en/home
    Cookie  JSESSIONID=768ABBE1A3BFABE3B535900233330650; versionsCssDisplayState=block; iceInfo=iceOn:false,activePortletKey:,icePagePanelX:1722,icePagePanelY:3
    If-None-Match   image_a70703fb393a60b6da346c112715a0abd54a3236

到目前为止,一切顺利。但是,在下一个请求(120 秒内)时,我会认为该资源应该缓存 120 新秒。另一方面,我在浏览器(Firefox)中看到的是,从此时起它始终请求资源并接收 304 响应。

我是否应该在 304 响应中附加缓存控制标头?从我在规范中读到的内容来看,似乎应该省略缓存控制设置,并且缓存应该自动将其缓存 120 秒?

I've tried to understand this, and searched SO for similar questions, but I still don't have a 100% understanding on how this is supposed to work.

I get this response on a request for an image resource:

Response Headers
    Server  Apache-Coyote/1.1
    Date    Mon, 19 Oct 2009 09:04:04 GMT
    Expires Mon, 19 Oct 2009 09:06:05 GMT
    Cache-Control   public, max-age=120
    Etag    image_a70703fb393a60b6da346c112715a0abd54a3236
    Content-Disposition inline;filename="binary-216-420"
    Content-Type    image/jpg;charset=UTF-8
    Content-Length  4719

The desired behavior is that the client should cache this for 120 seconds, then request it from the server again. Within the 120 seconds, no request is sent to the server.

Then, after 120 seconds, a request is sent and a 304 response is received:

Response Headers
    Server  Apache-Coyote/1.1
    Date    Mon, 19 Oct 2009 09:06:13 GMT

Request Headers
    Host    localhost:8080
    User-Agent  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
    Accept  image/png,image/*;q=0.8,*/*;q=0.5
    Accept-Language en-us,no;q=0.8,sq;q=0.7,en;q=0.5,sv;q=0.3,nn;q=0.2
    Accept-Encoding gzip,deflate
    Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive  300
    Connection  keep-alive
    Referer http://localhost:8080/cms/site/0/en/home
    Cookie  JSESSIONID=768ABBE1A3BFABE3B535900233330650; versionsCssDisplayState=block; iceInfo=iceOn:false,activePortletKey:,icePagePanelX:1722,icePagePanelY:3
    If-None-Match   image_a70703fb393a60b6da346c112715a0abd54a3236

So far, all well. But then, on the next request (whithin 120 seconds) i would have thought that the resource should be cached for 120 new seconds. What i see in the browser (Firefox) on the other hand, is that it from this point on always request the resource and receives the 304-response.

Am I supposed to attach the cache-control headers in the 304-response? From what i can read in the spec, it seems like the cache-control settings should be omitted, and that the cache should cache it for 120 new seconds automatically?

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

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

发布评论

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

评论(3

清风挽心 2024-08-14 17:15:58

RFC7232 更新 RFC2616 说:

生成 304 响应的服务器必须生成以下任何一个
以下标头字段将在 200(OK)中发送
对同一请求的响应:Cache-Control、Content-Location、Date、
ETag、过期和变化。

RFC7232 updates RFC2616 to say:

The server generating a 304 response MUST generate any of the
following header fields that would have been sent in a 200 (OK)
response to the same request: Cache-Control, Content-Location, Date,
ETag, Expires, and Vary.

酒儿 2024-08-14 17:15:58

理论上,您不必发送 304 的 Cache-Control ——接收者应该继续使用从原始 200 收到的缓存指令。但是,正如您所发现的,在实践中,如果您不这样做继续发送 Cache-Control,浏览器将忽略您最初发送的缓存指令,并恢复到它们自己的默认启发式。

因此,在实践中,您应该在 304 中包含与 200 中相同的 Cache-Control。规范仅要求您在 304 与之前发送的内容不同时发送它(请参阅 10.3.5 304 未修改) - 但它肯定不会禁止您当相同时重复它。

并专门回应其他答案(结构)中的错误观点:

  1. 确实希望中间缓存缓存响应(即更新资源的缓存条目)。它们将适当地响应来自客户端的 200 或 304 请求,具体取决于客户端是否包含条件标头(例如 If-Modified-Since)。

  2. 120 秒的 ttl由 304 刷新(因此同一客户端至少在 120 秒内不应再次请求同一资源)。而客户端,只要他们仍然缓存了内容,就会继续对资源发出条件请求,您可以继续使用 304 进行响应。

In theory you shouldn't have to send Cache-Control for a 304 -- the recipient should just continue to use the cache directives that it received from the original 200. However, as you've found, in practice if you don't keep sending Cache-Control, browsers will ignore the cache directives that you sent originally, and revert to their own default heuristics.

So in practice, you should include the same Cache-Control with a 304 that you would with a 200. The spec only mandates that you send it for a 304 if it's different than what you sent previously (see 10.3.5 304 Not Modified) -- but it certainly doesn't forbid you from repeating it when it's the same.

And to respond specifically to the wrong-headed points from the other answer (Structure's):

  1. You do want intermediary caches to cache the response (that is, update their cache entry for the resource). They will respond appropriately to requests from clients with a 200 or a 304, depending on whether the client included a conditional header like If-Modified-Since.

  2. The 120-second ttl will be refreshed by the 304 (so the same client shouldn't make another request for the same resource for at least another 120 seconds). And clients, as long as they've still got the content cached, will continue to make conditional requests for the resource, which you can continue to respond to with a 304.

秋凉 2024-08-14 17:15:58

如果我理解正确的话,那么浏览器实际上缓存了 120 秒,并且您的服务器正在响应 304 Not Modified 到后续的 If-Modified-Since 请求。当最终用户访问相同的 URL 时,就会发生此“IMS”请求。此时浏览器可以发送 If-Modified-Since 请求。浏览器想知道它是否显示过时的内容。这看起来很正常。

收到此请求后,您的服务器应回复 200 OK、304 Not Modified(或 4XX,如果需要)。

我认为您不应该将服务器设置为发送带有 304 响应的 Cache-Control 标头,原因有两个:
1. 您不希望任何中间缓存来缓存 304 响应(它们有可能)
2. 120秒的TTL不会被304响应刷新。浏览器将在 200 OK 响应后保留该对象 120 秒。 120 秒后,浏览器应该发送 GET 请求,而不是 If-Modified-Since,因此您的服务器将使用文件的字节进行响应,而不仅仅是 304 响应。

请注意,浏览器不会在 120 秒后自动再次请求该文件,除非最终用户通过页面加载或直接在地址栏中输入 URL 专门请求该文件(或者除非您有一个自定义应用程序以某种方式控制该功能)。

编辑了第一段,以便读起来更好一点(希望如此)

If I understand correctly then the browser is in fact caching for 120 seconds and your server is responding 304 Not Modified to subsequent If-Modified-Since requests. This "IMS" request occurs when the end-user accesses the same URL. At that time the browser can send an If-Modified-Since request. The browser wants to know if it is displaying stale content. This seems normal.

Upon receiving this request your server should reply 200 OK, 304 Not Modified (or a 4XX, if necessary).

I do not believe you should set your server to send a Cache-Control header with the 304 response for two reasons:
1. You do not want any intermediary caches to cache that 304 response (there is a possibility that they could)
2. The 120 second TTL will not be refreshed by the 304 response. The browser will retain the object for 120 seconds from the 200 OK response. After 120 seconds the browser should send a GET request, not an If-Modified-Since, so your server will respond with the bytes of the file and not just a 304 response.

Note that the browser will not request the file again automatically after 120 seconds unless the end-user specifically requests it via a page load or directly inputting the URL into their address bar (or unless you have a custom application that controls that functionality somehow).

Edited the first paragraph to read a bit better(hopefully)

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