What is the meaning of the HTTP header Vary:*
Asked Answered
A

1

12

As far as I know, the HTTP Header Vary specifies a comma separated list of HTTP headers that need to be considered by caches together with the URL when deciding if a request is a cache hit or miss.

If that header is omitted, means that only the URL will be considered.

But what happen when the header is Vary:* ?

RFC 2616 14.4

A Vary field value of *** signals that unspecified parameters not limited to the request-headers (e.g., the network address of the client), play a role in the selection of the response representation. The * value MUST NOT be generated by a proxy server; it may only be generated by an origin server.

RFC 2616 13.6

A Vary header field-value of * always fails to match and subsequent requests on that resource can only be properly interpreted by the origin server.

Does it means that all requests with this header are going to be a cache miss?

I find out that ASP.NET is returning that HTTP header if you use their OutputCacheAttribute, and you have to disable explicitly that behaviour if you don't want the header, or you want to specify custom headers, so I (want to) believe it is unlikely.

Which is the practical meaning of Vary:* ?

Thanks.

Adventuresome answered 29/9, 2011 at 15:48 Comment(0)
S
8

Vary:* tells caches that the response has been chosen based on aspects beyond the usual aspects of HTTP content negotiation (e.g. Accept, Accept-Language, Accept-Charset).

Effectively this tells the cache not to cache the response. That is the meaning of "subsequent requests on that resource can only be properly interpreted by the origin server". The cache must forward these requests to the origin server.

Edit: Vary is orthogonal to caching. Consider this:

GET /foo HTTP/1.1

200 Ok Cache-Control: maxage=60 Content-Location: /foo.html Vary: *

Vary:* tells caches that the response cannot be cached for requests to /foo. But because of the Content-Location header, caches can still store the response for requests to /foo.html.

Scarabaeoid answered 1/10, 2011 at 15:53 Comment(5)
I still don't see the point of that header. Why should I use it rather than no-cache or no-store? Why in the world would asp.net send this header together with cache instructions?Adventuresome
Vary is not just for caches. It documents the content negotiation selection process. removing Vary and making the response not-public cacheable would hide the fact that negotiation took place. This would hide the fact that the request URI identifies a negotiated resource, which might be of interest to some intermediary or client.Scarabaeoid
Humm... it does make sense now. OutputCacheAttribute is just a wrapper for the ASP.NET WebForms cache API. ASP.NET WebForms is based on POST calls (postbacks), so the response always vary by parameters in the POST, that are outside of the HTTP headers and the URL. That is the reason. Thanks a million, you saved me a headache :DAdventuresome
I have started a new question related with Vary, could you tell me if what I said makes sense? thanks : #7635966Adventuresome
If Vary:* is passed without Content-Location, which wasn't a part of the original question, what happens - does the cache always miss? This answer doesn't quite answer the original question here.Werra

© 2022 - 2024 — McMap. All rights reserved.