Subject: Vary: Cookie

From: Adrien de Croy <[email-masked]>
Date: Wed, 03 Jun 2009 13:06:08 +1200

Hi

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.

thanks.

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Jun 2009 15:09:02 +1000

In theory, set-cookie can be stored by a shared cache, assuming the  
response is otherwise cacheable; it doesn't have any special status in  
this regard. Likewise, the cookie request header doesn't affect  
requests unless Vary says so.

In practice, some (but not all) shared caches will treat requests or  
responses with cookies differently (although it's less prevalent on  
cookies, since so many sites  tend to spray them everywhere...).

This is documented to some degree in the cookie RFCs, but as has been  
noted before, we don't have any accurate specification of cookies as  
they're deployed today.

Cheers,

On 03/06/2009, at 11:06 AM, Adrien de Croy wrote:

>
> Hi
>
> I'm seeing quite a few responses from some servers with a Vary:  
> Cookie header.
>
> thought cookies weren't to be stored by shared caches, which makes  
> it then impossible to match on a cookie in a subsequent request.
>
> 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.
>
> thanks.
>
> Adrien
>
>
> -- 

--
Mark Nottingham     http://www.mnot.net/

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 3 Jun 2009 18:55:36 +0100

> cookies, since so many sites  tend to spray them everywhere...).

It would be quite messy, if a server sent a page with Set-Cookie, then
later another page with a _later_ Set-Cookie which replaces the
earlier cookie, then a long time later the cache serves the _original_
Set-Cookie with a cookie which has long ago expired, causing the later
cookie to be lost.

On the other hand, using request's Cookie for caching seems reasonable
to me, if the server does not consider the response private to just
one client.

Even though a cookie value is (usually) tied to a single client, a
_response_ might be the same for many different client cookie values,
but still restricted to a subset of client cookie values.

For example, it may be the server has the same response for all people
in a certain group, each with different cookies, and a different
response for all people in another group, also each with different
cookies.

If a server requires a response to be private to just one client, it
can use "Cache-Control: private".

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 3 Jun 2009 19:01:43 +0100

Adrien de Croy wrote:
> deal with this?  

> To date I've been treating the presence of a Cookie 

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