Re: session-id redux

John Franks (john@math.nwu.edu)
Thu, 27 Jul 1995 14:05:28 -0500

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