什么决定了 HTTP 缓存的请求等效性？

Question

I feel like this has to be easy to Google, but I can't find it: from the perspective of an HTTP cache, what determines if two requests are equivalent?

I imagine one ingredient is that that their URLs need to be identical; for example, rearranging (but not changing) query string parameters seems to cause a cache miss. Presumably they need to have the same Accept header. What else determines if a request can be served from cache?

Answer 1

This is mostly described in this RFC: https://tools.ietf.org/html/rfc7234#section-4

Summary:

• The method
• The full uri
• Caching-related headers in response influence whether something got stored.
• Any request headers that appeared in the list of the Vary response header.

It also matters whether you are caching for a specific user (for example a browser), or many users (for example a proxy).

Answer 2

There are all the conditional requests for cache control like If-match, If-unmodified-since, If-none-match and If-modified-since . For example If-modified-since works this way: suppose you have already requested a page and now you want to reload it. If the header is present then a new page will be sent back from the server ONLY if it was modified since the date indicated as a value for If-modified-since, otherwise 304(not-modified) status will be returned. Accept and Accept-* instead are necessary for Content-Negotiation, like in which language the page should be returned.

More on conditional requests here: https://tools.ietf.org/html/rfc7232#page-13

Answer 3

I also struggled with this. Changing my google search to use "http cache key" generated better results. Using the URL seems to be the most common. Query strings are also generally included.

https://support.cloudflare.com/hc/en-us/articles/115004290387-Using-Custom-Cache-Keys describes what the default is for cloudflare and a discussion on the impact of using different keys.

Another parameter that could be useful is to identifying the type of assets that you want to cache. Or leave it open (no filtering)

"Authorization" header is specifically mentioned in the HTTP spec ( https://tools.ietf.org/html/rfc7234 ) and needs to be handled.

Upon further reading, I noticed the section on "Secondary keys" in the standard ( https://tools.ietf.org/html/rfc7234#section-4.1 ) and the use of "Vary" header in a response. Headers presented in the "Vary" response header have to match in both the original and the new request for the cache to declare it as a match.

And as for the primary key, standard says "The primary cache key consists of the request method and target URI." in https://tools.ietf.org/html/rfc7234#section-2