Re: Possible optimization to State-Info proposal

Shel Kaphan <sjk@amazon.com> wrote:
  > Some combination of Koen Holtman and Dave Kristol conversed:
  > 	
  >  > >  > Caches in user agents should be careful to implement the caching
  >  > >  > semantics defined in the HTTP protocol, especially when handling
  >  > >  > requests or responses containing State-Info headers.
  >  > >I think it's safe for a user agent to cache responses that contain
  >  > >State-Info headers, though I haven't thought it through carefully.
  >  > 
  >  > It definately is not: the state-info response headers gotten on an URI can
  >  > change through time.  Imagine a POST-URI working as a toggle button.
  >  > 
  > 
  > Of course you shouldn't cache state-info headers, but you should
  > cache a cacheable resource even if it is sent with state-info headers.
  > It's best to make cacheability and transmittal of state-info
  > completely orthogonal.

That particular exchange concerned user-agent-side caches, not proxy
caches. 

I'm in favor of the KISS (keep it simple, stupid) approach.

I think much of the argument has been over what constitutes a
"cacheable resource."  And the answer has two dimensions:
philosophical and operational.  On the philosophical side, what
resources must, should, can, should not, can not, and must not be
cached?  On the operational side, what techniques are employed (e.g.,
headers) by the origin server to get the cache to exhibit the desired
behavior?

Further complicating the question is, what do existing caching proxies
do, and how would that behavior interact with State-Info?  How would
that behavior affect deployment of this new feature?  Ideally the
interaction with "old" cache would be benign:  things would either work
(unlikely) or break softly.

  > 
  > 	[ much discussion of idempotence, caching, etc. ]
  > 
  > I don't think we have to make a big deal about defining idempotence.

My only reason for fussing with the definition is to be sure we're talking
about the same things and using the same terms to do so.  I feared we were
using the same words to mean different things.

  > As I tried to say before, whether a resource can be cached, and hence
  > stop participating in a stateful dialog, is up to the origin server
  > designer/administrator.  If a returned resource is marked as cacheable (no
  > Pragma: no-cache, no Expires: <yesterday>), the resource is cacheable,
  > period.  State-info is never cacheable.
  > 
  > State-info can be sent with any response from an origin server,
  > but can never originate from an intermediate proxy.  It can also be
  > returned along with any request from a user agent.
  > 
  > I don't see why it needs to be any more complex than that.

That much sounds fine, and I agree.  The messiness arises when State-Info
passes through a caching proxy in one direction or the other.  (I know
that isn't news to you.)  The goal is to cache as much stuff as possible
and still perform correctly.
  > 
  > 	[ tuned caches ... ]
  > 
  > As for the idea that caches might decide to cache things they
  > shouldn't (overruling headers in responses), and then give error
  > responses to requests with state-info requests, I think that's really
  > a travesty.

I agree, but apparently it's something that must be dealt with, just
like error conditions in general.  Furthermore, we have to deal with
deployment and inter-operation with old caching proxies.

Summary:  I think I largely agree with you (Shel), but I also see that
there are complicating factors we can't really ignore.

Dave Kristol

Received on Monday, 28 August 1995 13:04:35 UTC