- From: Shel Kaphan <sjk@amazon.com>
- Date: Mon, 28 Aug 1995 11:43:23 -0700
- 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