Re: Vary: Cookie

Adrien de Croy wrote:
> I'm seeing quite a few responses from some servers with a Vary: Cookie 
> header.
> 
> this makes me wonder if this is desired / supported behaviour.  I 
> thought cookies weren't to be stored by shared caches, which makes it 
> then impossible to match on a cookie in a subsequent request.
> 
> Actually the whole aspect of caching + cookies isn't covered in 
> RFC2616.  Is there another RFC I should be reading to figure out how to 
> deal with this?  

> To date I've been treating the presence of a Cookie 
> header similarly to the presence of an authorization tag wrt caching, 
> since cookies are (AFAIK) mainly used to establish an association 
> between a specific client and the server, and thence the implications 
> are that responses are at least private to that client.

As I explain with an example in the other mail, even though cookies
are usually private to one client, a response might be common to many
different clients, even though it depends on the cookie value.

"Vary: Cookie" would be appropriate for that, forcing the cache to
query the origin server with If-None-Match.

If you don't retain "Cookie" headers in the shared cache, it's not a
disaster, it will simply fail to match any of the stored responses (so
there is no point storing them).

I can see problems caused by caching Set-Cookie response headers, but
in the absence of any special rule for them, origin servers can simply
declare those responses uncacheable if a cache sending old Set-Cookie
headers would cause problems.

Vary is quite smart, really.  As long as caches implement it right, it
does not require caches to have special rules for special headers.

-- Jamie