httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bannister <>
Subject Re: mod_cache with Cache-Control no-cache= or private=
Date Wed, 13 Mar 2013 20:28:58 GMT
On 13 Mar 2013, at 17:41, Yann Ylavic <> wrote:
> On Wed, Mar 13, 2013 at 6:35 PM, Tom Evans <> wrote:
>> On Wed, Mar 13, 2013 at 5:27 PM, Yann Ylavic <> wrote:
>>> How would the origin invalidate a Set-Cookie, with an empty one ?
>>> Regards,
>>> Yann.
>> Set it again, with an in the past expiry date.
> Well, that's not exactly the same thing, the user may have a valid Cookie (which is not
the one cached) the origin wants to keep going on.
> I meant invalidating the cached cookie, not the one of the user.

Is this the situation you're worried about:

ClientA: GET /foo HTTP/1.1
ClientA: Host: …

ReverseProxy: GET /foo HTTP/1.1
ReverseProxy: Host: …

Origin: HTTP/1.1 200 OK
Origin: Date: …
Origin: Set-Cookie: data=AAAAAA
Origin: Cache-Control: private=Set-Cookie

ReverseProxy: HTTP/1.1 200 OK
ReverseProxy: Date: …
ReverseProxy: Set-Cookie: data=AAAAAA
ReverseProxy: Cache-Control: private=Set-Cookie

ClientB: GET /foo HTTP/1.1
ClientB: Host: …
ClientB: Cookie: data=BBBBBB

ReverseProxy: GET /foo HTTP/1.1
ReverseProxy: Host: …
ReverseProxy: Cookie: data=BBBBBBB

Origin: HTTP/1.1 304 Not Modified
Origin: Date: …
Origin: Cache-Control: private=Set-Cookie

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

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.

Tim Bannister –

View raw message