On 13 Mar 2013, at 17:41, Yann Ylavic <ylavic....@gmail.com> wrote: > On Wed, Mar 13, 2013 at 6:35 PM, Tom Evans <tevans...@googlemail.com> wrote: >> On Wed, Mar 13, 2013 at 5:27 PM, Yann Ylavic <ylavic....@gmail.com> 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 – is...@jellybaby.net
