Re: Non-persistent Cookie proposal

Bob Wyman:
>koen@win.tue.nl wrote:

>> By default, a cache, no matter whether it is in a browser or in a
>> proxy, must never cache responses to requests with Cookie headers
>> in them.

>This rule is unnecessarily harsh and doesn't seem to provide any real
>benefit given that alternatives exist.

This rule is only the default: the default can, and should, be
overridden (by sending an Expires header, see Section 6.) when
appropriate (i.e. for product description pages that do not depend on
session state).  One could even imagine servers doing this overriding
automatically then the response is not generated by a cgi-script.

For the benefits provided by having this rule, see my recent reply to
Dave Kristol in this thread.

>Because you state no rules in your proposal for maintaining the continuity
>of a session

I do, see Section 3: cookie headers will keep being sent in requests
for _every_ url on that server, with a `forget cookie' timeout set at
30 minutes after the last request for an URI on that server.

I don't want to require servers to reflect cookies back to clients:
reflecting a cookie back is a redundant operation.

>When the browser requests URI-1, it will send the State-Info to Proxy-A
>which should then forward that State-Info on to Server-A using a conditional
>Get.

Not in my proposal.  If an Expires: <date> header was present in the
previous response for URI-1 from Server-A to Proxy-A, Proxy-A is
allowed to use normal Expires semantics.  Normal semantics is: at any
time before <date>, Proxy-A is allowed to serve requests for URI-1,
done from any browser, by sending the URI-1 reply gotten from Server-A
from its cache memory, without *ever* contacting Server-A again (to do
a conditional Get).

>                bob wyman

Koen.

Received on Saturday, 12 August 1995 09:23:23 UTC