Re: Session-ID proposal

Shel Kaphan <sjk@amazon.com> wrote:
  > 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.

I have assumed (erroneously?) that a caching proxy must send
conditional GETs to the origin server.  If so, there's already the cost
of a connection.  The State-Info (previously "Session-ID") can ride the
request almost for free.

Dave Kristol

Received on Thursday, 10 August 1995 17:54:17 UTC