Avoiding 304 (not modified) responses

…衆ロ難τιáo~ 提交于 2019-12-05 01:56:08

The Expires: header your server sends out has nothing to do with future 304 responses. It provides only an estimate to clients/proxies for how long they can wait before considering a resource "stale." Clients aren't required to observe this header and are free to continue making new requests for the same resource if they wish. So, to answer your question in short:

No, you'll never be able to explicitly prevent users from making new requests for the same resource regardless of what headers you send.

The 304 response is the result of a matching If-Match or If-Modified-Since header in the client request. What's happening here is your server is sending out either/or/both of the following headers with its original response:

  • ETag
  • Last-Modified

Clients then send back the following headers with their requests to see if the resource has changed from their cached version:

  • If-Match (ETag)
  • If-Modified-Since (Last-Modified)

If either of these conditions is true then the server will send the 304 Not Modified response you've observed and the client will know it can safely serve up its cached version of the resource.

Compliance Note

RFC 2616 Section 14.21 actually prohibits compliant servers from sending Expires headers more than one year in the future, so you shouldn't be using "access plus 10 years" in the first place:

HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!