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