On Wed, Mar 13, 2013 at 9:28 PM, Tim Bannister <is...@jellybaby.net> wrote: > Is this the situation you're worried about: > > ClientA: GET /foo HTTP/1.1 > ReverseProxy: GET /foo HTTP/1.1 > Origin: HTTP/1.1 200 OK > Origin: Set-Cookie: data=AAAAAA > Origin: Cache-Control: private=Set-Cookie > ReverseProxy: Set-Cookie: data=AAAAAA > ReverseProxy: Cache-Control: private=Set-Cookie > > ClientB: GET /foo HTTP/1.1 > ClientB: Cookie: data=BBBBBB > ReverseProxy: GET /foo HTTP/1.1 > ReverseProxy: Cookie: data=BBBBBBB > Origin: HTTP/1.1 304 Not Modified
Yes, about what happens now, the ReverseProxy (mod_cache) must not "Set-Cookie: data=AAAAAA" to ClientB. > This should just work. The final reply from the cacheing reverse proxy should > look like this: > ReverseProxy: HTTP/1.1 304 Not Modified > ReverseProxy: Date: … This actually does not work, mod_cache will serve the cached Set-Cookie. The CacheIgnoreHeaders directive only can prevent this (not controlled by the origin). The final reply to ClientB, whose request is not conditional, can also be : ReverseProxy: HTTP/1.1 200 OK ReverseProxy: Cache-Control: private=Set-Cookie ReverseProxy: <cached body> That's the main goal I guess (limit backend hits for large things). > and the Set-Cookie: header from the stored request would not be used (in > fact, the proxy may have elected not to store it). The origin doesn't have to > mention that header in the 304 response. In mod_cache the "no-store" of a particular header is harder to patch than the "no-cache" (ie. do not serve without revalidation), but indeed the former would be more efficient, no need to "sanitize" each served response. For the "private=", the rfc does not say more than its BNF... If private has the same semantic as without the =, the header should not be stored (the "Cache-Control: private" response is not stored by mod_cache). In all cases, IMHO, no cached Set-Cookie should aver played by a cache with private/no-cache="Set-Cookie" associated with the resource.
