W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: Session-ID proposal

From: Dave Kristol <dmk@allegra.att.com>
Date: Mon, 21 Aug 95 10:27:03 EDT
Message-Id: <199508211428.AA009985291@hplb.hpl.hp.com>
To: dwm@shell.portal.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-talk@www10.w3.org
David Morris <dwm@shell.portal.com> wrote on Sun, 20 Aug 1995 17:38:17 -0700 (PDT):

  > I must have missed something ... if I build an application which needs 
  > session like control, I have a real hard time believing that I would
  > find any intermediate caching (as in proxy) acceptable. Providing  a
  > mechanism where any arbitrary user could retrieve information cached
  > from a session-id based connection seems like an unnecessary exposure
  > of semi-private information.

Yes, you missed some of the discussion on these mailing lists.  I agree
that pages that contain user-specific information, such as the current
contents of a shopping basket, are inherently uncachable.  But I
contend that it's possible to design a cache-friendly application where
most of the pages are cachable, if you accept that State-Info (my
proposal, http://www.research.att.com/~dmk/session.html) is passed
through intermediaries without becoming part of cache state.

The example I use is a shopping basket application.  A vendor shows you
a product description page that has, on the bottom, a link to "My
Current Shopping Basket".  The product description page is generic, if
you assume that the link is really to a CGI that eats the accompanying
State-Info and spits back a display of your current basket.  So the
product description itself can be cached.  Furthermore, because
State-Info should not be cached, the semi-private information is no
more exposed than it otherwise would be for passing through
  > On Mon, 14 Aug 1995, Jim Seidman wrote:
  > > [...] 
  > > Given these considerations, and the slowly increasing use of "Expires"
  > > headers, State-Info could be expensive indeed.

One of Jim's objections was to my (erroneous) assumption that caching
proxies routinely do GET I-M-S to the origin server, so sending
State-Info was cheap.  If S-I can't piggy-back with I-M-S, I agree S-I
adds expense.  And because Expires is being sent more often, proxies
send I-M-S less often.
  > Hence, I would contend State-Info will have little impact since
  > caching would/should be disabled in most contexts where State-Info
  > applies.
Perhaps.  There's still value in not shipping the entire document,

Dave Kristol
Received on Monday, 21 August 1995 07:29:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC