- From: Koen Holtman <koen@win.tue.nl>
- Date: Sat, 17 Feb 1996 22:52:57 +0100 (MET)
- To: sjk@amazon.com (Shel Kaphan)
- Cc: koen@win.tue.nl, http-caching@pa.dec.com, state@xent.w3.org
Shel Kaphan: >Koen Holtman writes: > > Expires will control this. [...] >Expires won't do the right thing if the origin server ever fails to >return a set-cookie header in a 304 response, because if there was a >set-cookie header cached from before, it would be returned to the >next requestor. Yes, you never have to fail to return a 304 with a Set-Cookie of course. [...] > > Expires: Thu, 01 Jan 1980 00:00:00 GMT > > Cache-control: no-cache="set-cookie"; max-age=100000 > > Set-Cookie: session-id=4314 >I think you need the expires even in 1.1, so that future >requests for this resource will be passed through to the origin, where >they can get a new cookie. Oops, you are right, I should have said max-age=0 above. I thought up the `Cache-Control always overrides Expires in 1.1, even if Expires gives a shorter lifetime' idea in the context of Vary headers and negotiable resources. A better example would be Expires: Thu, 01 Jan 1980 00:00:00 GMT Cache-control: max-age=100000 Vary: user-agent because a 1.0 proxy cache would not understand the Vary header, while a 1.1 cache would. >--Shel Koen.
Received on Saturday, 17 February 1996 22:11:16 UTC