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

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.

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


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

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


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

Your other points about the meaning of expires when no entity is
present are interesting -- but I have nothing to add right now.

--Shel

Received on Tuesday, 5 September 1995 11:02:17 UTC