Re: session-id redux

In article <9507271719.AA13484@www10.w3.org>, Rick Troth writes:
> 
>         What we're talking about now is putting state info into the
> URL instead of in the HTTP headers like this
> 
>                 http://serverhost/path/path/path;state;blah;blah
> 
>         such that the server can set PATH_INFO to  "state;blah;blah"
> for the fronting CGI script to utilize.

This and all the other schemes which put state or session-id in URLs
can destroy proxies.  All you need is one hot item and every cache
will consist of hundreds of copies of that item which differ only in
the session-id embedded in their URL.  The same problem occurs if
session-id is used as part of the cache key.

Can you imagine what would happen if Netscape released a new browser
via HTTP and Cookies were used as part of the cache key?  Every
proxy-cache and local cache in the world would be full of copies of
one browser.

For this reason I think it is crucial that session-id never be cached
by proxies!

The one good new idea I have seen on this thread is the suggestion of
Dave Kristol for dealing with this.  Namely, if an object has a
session-id attached, the proxy should cache the object with the
notation that it needs a session-id (but not keep the session-id).
Then when another request comes for the object the proxy must send an
if-modified-since to the server and include the clients session-id.  A
304 from the server means send the cached version with the returned 
session-id.  A new version of the object from the server means that
maybe the session id had state so send the new version (use it to
replace the cached version too).


-- 

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Thursday, 27 July 1995 15:07:17 UTC