- From: Shel Kaphan <sjk@amazon.com>
- Date: Mon, 28 Aug 1995 12:28:53 -0700
- 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. --Shel
Received on Monday, 28 August 1995 12:34:03 UTC