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

Re: Vary: Cookie

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 3 Jun 2009 15:09:02 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <BEBC04CB-47FE-4CF9-ABC9-2D5A21FD75FD@mnot.net>
To: Adrien de Croy <adrien@qbik.com>
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.


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.
> 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

Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 3 June 2009 05:09:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:49 UTC