httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: mod_cache with Cache-Control no-cache= or private=
Date Wed, 13 Mar 2013 23:56:28 GMT
On Wed, Mar 13, 2013 at 9:28 PM, Tim Bannister <> 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
> 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

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

In all cases, IMHO, no cached Set-Cookie should aver played by a cache
with private/no-cache="Set-Cookie" associated with the resource.

View raw message