Re: backward compatibility of non-cachable headers

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