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