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