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

Re: Possible optimization to State-Info proposal

From: Dave Kristol <dmk@allegra.att.com>
Date: Fri, 25 Aug 95 10:02:32 EDT
Message-Id: <199508251408.AA048259692@hplb.hpl.hp.com>
To: sjk@amazon.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Shel Kaphan <sjk@amazon.com> wrote:
  > I mentioned this before, obliquely in a response on another topic, but
  > if I'm right, what follows can significantly reduce the potential
  > performance problems with DMK's State-Info proposal.
  >                                             Key conclusion: An
  > idempotent request such as GET, which produces no side effects, cannot
  > affect the state of a stateful dialog.  Therefore, it seems
  > unnecessary for requests that can be satisfied out of a cache to pass
  > through any information to the next server.
  > This, of course, makes it even more imperative that caches not serve
  > cached documents they shouldn't.
  > With the recent addition to the proposal that clients stay in the
  > "have state-info" state when there is no state-info in the server's
  > (or cache's) response, this means that caches need not "reflect"
  > state-info either.

This idea sounds promising.  Let me expand a bit from an operational
standpoint.  Remember the recent change whereby a user agent retains
its State-Info if it receives no State-Info from a server.  If caching
proxies followed the rule that they cached only those documents for
which they received no State-Info from the origin server, and if origin
servers were careful to send State-Info only when it changed, I believe
caching proxies would be able to cache anything cachable (in the
State-Info context).

Upon getting a one, a caching proxy could satisfy a request for a
resource from the cache if there were a fresh one available, whether or
not the request contained a State-Info request header.  (That's a
change, and it would indeed enhance caching.)

The idea of an idempotent method could be expanded to imply that, not
only does the resource not change, but its State-Info does not change
either.  (I guess that's obvious if you bundle State-Info into a
larger concept of "the resource".)

Nice idea!  If the dust settles without major objections, I'll add this
to a state-info-01 I-D.  That will be a couple of weeks, after some

Dave Kristol
Received on Friday, 25 August 1995 07:09:39 UTC

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