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

Re: Possible optimization to State-Info proposal

From: Shel Kaphan <sjk@amazon.com>
Date: Mon, 28 Aug 1995 11:43:23 -0700
Message-Id: <199508281843.LAA02299@bert.amazon.com>
To: Dave Kristol <dmk@allegra.att.com>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Dave Kristol writes:

 > If you're going to introduce dependencies on State-Info specifically,
 > you could just as well introduce the requirement that responses that
 > contain State-Info not be cached.

I claim that any response that originates from an origin server can
legitimately contain a state-info header, and that it's best not to
complicate that.

Suppose that a POST returns the same resource that a later GET
*could* return. The POST's returned resource gets cached, even though the POST
itself could not have been served from a cache.  The POST's response can
legitimately contain state-info.   So, there is no correlation between
responses that can contain state-info and those that can be cached.
Leave cacheability to the already too numerous headers that control that.

  Why the need for extra headers?
 > Is there ever a reason to cache a response that contains State-Info?
 > In this case, the caching server would respond with 501 when it saw
 > State-Info.
 > Dave Kristol

There may not be a *need* for it that we can imagine right now, but
there's also no need for restrictions against it.  An origin server
may legitimately and aggressively try to start sessions whenever it can,
including times when it is delivering cacheable, shared resources.

--Shel Kaphan
Received on Monday, 28 August 1995 11:48:22 UTC

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