W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: backward compatibility of non-cachable headers

From: Koen Holtman <koen@win.tue.nl>
Date: Sat, 17 Feb 1996 22:52:57 +0100 (MET)
Message-Id: <199602172152.VAA08033@wswiop05.win.tue.nl>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC