Re: Non-persistent Cookie proposal

-- [ From: Bob Wyman * EMC.Ver #2.5.02 ] --

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.
> Responses which contain Set-Cookie headers must also never be cached, no
matter
> whether the request itself contained a Cookie header.

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

Because you state no rules in your proposal for maintaining the continuity
of a session (i.e. you don't address the "fragility" issues I raised
concerning Kristol's proposal and you don't mention Netscape-like "path"
data in your proposal.) I'll assume you mean to accept the rules that
Kristol proposed, including his recent, but as yet undocumented, statement
that he expects servers to "reflect" State-Info when received in requests
for URI's that don't require State-Info and his statement that he expects
State-Info to be able to carry State for more than one application at a time
.

    1. Assume that a browser has picked up, because of prior interactions
       with ServerA, a cookie or State-Info header that it must send in the
       next request to ServerA.
    2. Assume that the browser requests URI-1 from ServerA via Proxy-A. 
       URI-1 does not require any State-Info.
    3. Assume that a Proxy-A has a non-expired copy of URI-1 in cache.

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. The response to this request should include the State-Info "reflected"
back. Now, the question is, what should the cache do? Should it purge URI-1
from its cache since it has been "received" as part of a response that
contained State-Info? Should it update any internal information concerning
URI-1? NOTE: If you allow a scenario like this to purge items from cache,
you'll find that a reader who wanders around a site with some outstanding
State-Info can blast all sorts of things out of the cache unnecessarily.

Now, using only assumptions 1 and 2 above and with assumption 3 now reading:

    3. Assume that Proxy-A does not have a copy of URI-1 in cache.

What should the cache do when it gets a response to the browsers request for
URI-1? We know (although the cache doesn't) that URI-1 is perfectly safe to
cache since it doesn't have any need for State-Info, Cookies, etc. How do we
get the thing in cache? Or, do we simply hope this doesn't happen too often?

I think these problems are all solved by insisting that applications that
send data that shouldn't be cached use the "Pragma: no-cache" header and
relieve the cache writers from trying to intuit what the heck is going on.

Cache writers who want to be "very sure" can implement slightly more complex
strategies. For instance:
    1. If you have something in cache and you get a request with State-Info,
        forward the request using conditional get.
    2. If you get a response which includes State-Info, then, in the absence
of 
        Pragma's, Expires, etc. cache the object but remember that it had
        State-Info in the response. (don't cache the State-Info)
    3. If you get a request for a resource that has the "had State-Info"
        flag set, then do a conditional get with no State-Info to give
        the origin-server a chance to create a new session.
    4. If a "304 Not Modified" response is received and carries
        State-Info, remember that you had State-Info only if you didn't
        have the "had State-Info" flag set for the item before.
    5. If a "304 Not Modified" response without State-Info is 
        received for something that has the "had State-Info" flag set, 
        clear the flag.

		bob wyman

Received on Friday, 11 August 1995 18:34:32 UTC