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 12:28:53 -0700
Message-Id: <199508281928.MAA02671@bert.amazon.com>
To: Koen Holtman <koen@win.tue.nl>
Cc: Dave Kristol <dmk@allegra.att.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

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. 

	[ much discussion of idempotence, caching, etc. ]

I don't think we have to make a big deal about defining idempotence.
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.

	[ 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.

Received on Monday, 28 August 1995 12:34:03 UTC

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