W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: Vary: Cookie

From: Jamie Lokier <jamie@shareable.org>
Date: Wed, 3 Jun 2009 19:01:43 +0100
To: Adrien de Croy <adrien@qbik.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20090603180143.GB12766@shareable.org>
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
Received on Wednesday, 3 June 2009 18:02:21 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC