Re: session-id redux

John Franks (
Thu, 27 Jul 1995 14:05:28 -0500

In article <>, 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