- From: Shel Kaphan <sjk@amazon.com>
- Date: Thu, 10 Aug 1995 14:14:31 -0700
- 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 UTC