Re: an idempotent idea (think it twice - see what happens)

Shel Kaphan writes:
> Balint Nagy Endre writes:
>  > Shel Kaphan writes:
> 	...
>  > > We have the "Cache-control: no-cache" request header to force
>  > > proxies to forward GET and HEAD requests.  
>  > Oops. In http/1.0 we have Pragma: no-cache!
>  > This can force 1.0 proxies to re-request the URL again.
>  > I like the "Cache-control: no-cache" better, but in requests I want not
>  > override the 1.0 protocol, and we shall use cache-control only as a
>  > response header!
>  > > 
> 
> I intended this suggestion for http 1.1, but certainly if it
> were to be retrofitted, the same comments would apply to the related pragmas.
> Cache-control replaces the related pragmas for both requests and responses.
> Some programs might, of course, be smart enough to know which http version
> they're talking to and do the right thing.
Current draft-v11-00a has both pragma no-cache and cache-control (as *general*
headers), leaving us confused until Roy issues the next revision.
>  > > What if someone someday invents an extension method for HTTP that
>  > > could be served from a cache?  (Well, it *could* happen...)
>  > > For that case, there would need to be a directive informing proxies
>  > > that even though the request is not GET or HEAD, it is OK to serve the
>  > > result from a cache.  In that case, perhaps it would be a good idea to
>  > > put in another Cache-control directive that explicitly allows requests
>  > > to be served from a cache.
>  > Great idea!
>  > For 1.0 version we can't add this of course, but it would be nice to
>  > have it starting from 1.1. But here we are talking about (entities in)
>  > responses!
> 
> I don't understand what you were getting at with your last sentence.
Yeah, it's really confusing here. (I wrote this really late night/early
morning.)
The permissive form of Cache-Control (may be may-cache?)
will state, that the method in the request may be cach(e?)able,
and has no relation to the entity-body. For 1.0 we have an implicit
may-cache on GET (and HEAD) methods, speaking in terms of a fictive
1.x version of the protocol, having this directive.
(A similar, implicit 'Cache-control: private' is in effect on a response,
if a request contains an Authorisation field.)
> 
>  > > I was thinking of "Cache-control: cacheable", but that has two serious
>  > > problems:  people don't agree on how to spell "cacheable" :), and the
>  > > very word would probably confuse some implementors and they would
>  > > decide it meant something on responses.  So, maybe 
>  > > "Cache-control: serve-from-cache".
>  > maybe Cache-control: cache?
> 
> That would still seem to suggest that something should happen when
> storing into caches, and not just for fetching from them, as intended.
Of course, the "may-cache" will enable storing (depending on other headers).
> 		...
>  > But the Expires: <yesterday> doesn't mean, that the entity-body in the
>  > response isn't cacheable, as John Franks <john@math.nwu.edu> on 16th Aug wrote: 
>  > "There are also reasons that a request not to cache should be orthogonal to
>  > the Expires: header." (And I haven't see any arguments, disproving
>  > this statement.)
>  > 
> 
> I really don't get this.  Expires: <yesterday> might not make it
> illegal to store something into a cache, but it would make it illegal
> to fetch it from the cache later.  So it would be pointless to store it,
> except insofar as a history list usea the same storage substrate as a
> cache does.
... would make it illegal to fetch it from the cache *without contacting the
origin server* later. But the response to the conditonal GET or HEAD may say:
"the entity-body not changed", and it is fully legitimate to serve the
cached entity to the client. Storing the response may be pointless of
course, but only if the first test gets back a new entity-body.
The performance gain may be neglectable, if the entity-body in question
is small.
> 
>  > The "Expires" header affects cache fetch actions,
>  > while the "Cache-control" header affects cache store actions!
>  > 
> Cache-control (or the Pragmas) affect both fetching and storing.
Only if Cache-Control is used in requests, but my (not explicitly said)
assumption was:
Pragma no-cache is for requests, Cache-Control is for responses.
Now I write down this as a proposal:
Let the 1.0 Pragma no-cache to be remain effective in requests,
(which is a bit unfortunate in wording, but backward compatible),
and the new Cache-Control header to be defined as effective only in responses.
(with this wordingin effect, the client may suggest: "the response is
private" using Cache-Contol: private, and the server may honor
that suggestion by copying it into the response.)

An alternative to this may be:
Pragma: no-cache as a request header and
Cache-Control: private|no-cache|... as a response header.
In this case, responses containing Pragma: no-cache and requests
containing Cache-Control would be signs of non-compliant implementations.

If the WG adopts one of these, cache-control will have no effect on fetches
from the cache: we will have nothing to fetch, if there is no
stored data. Rarely, while processing a response, a cached entity may be
invalidated (removed) when the response contains restrictive cache-control.

(Now I feel the second alternative being better, but I'm not sure.
My original concept is the first alternative.)

This responds to Jeffrey Moguls "Still trying to make sense of HTTP
caching model" too.

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Tuesday, 5 September 1995 20:21:42 UTC