Re: Session-ID proposal
Dave Kristol ([email protected])
Thu, 10 Aug 95 17:48:43 EDT
Shel Kaphan <[email protected]> wrote:
> Dave Kristol writes:
> > [email protected] (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