W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1995

Re: Session-ID proposal

From: Shel Kaphan <sjk@amazon.com>
Date: Thu, 10 Aug 1995 14:14:31 -0700
Message-Id: <199508102114.OAA08832@bert.amazon.com>
To: dmk@allegra.att.com (Dave Kristol)
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-talk@www10.w3.org
Dave Kristol writes:
 > koen@win.tue.nl (Koen Holtman) wrote (on www-talk):
 >   > Dave Kristol:
 >   > [....]
 >   > >	http://www.research.att.com/~dmk/session.html
 >   > 
 >   > This proposal is not clear enough about caching. Specifically:
 >   > 
 >   >   is the session-id header in the request part of the cache key for the
 >   >   entity in the response?
 > No.  In section 2.3 I said:
 >     Similarly, a caching proxy must pass back to the requestor any
 >     Session-ID response header it receives, but it must not cache that
 >     header as part of its cache state.
 >   > 
 >   > If it is, this means that almost no meaningful caching is possible for
 >   > services using session-id, even if 99% if the entities in the session
 >   > (inline pictures, product description pages) do not depend on the session
 >   > state.
 > Yes, exactly.

However, please note that the "side channel" of state information that
flows both directions and bypasses proxy and user-agent caches, even
if the resources themselves are cached, is not cheap.  Setting up and
tearing down the TCP connections is a nontrivial fraction of the cost
of retrieving a small resource (but I admit: I don't have numbers) --
especially html files, as opposed to large graphics or audio media files.
And those media files are typically cacheable anyhow.  Even on systems
where URLs contain session-IDs, the URLs for the media files usually
need not, and so they're cacheable.

--Shel
Received on Thursday, 10 August 1995 17:17:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:18 GMT