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

A true sign of thinking too much about this,  I woke up this morning
with a couple ideas I need to write down before I forget them.

My interpretation (and I'm sure someone will correct me if I'm wrong)
is, as I've previously said, that GET and HEAD are the only two standard
HTTP methods that can be served from a cache.

(We must distinguish method requests that can be served from a cache from 
results (of any method) that can be cached -- two different subjects).

My impression is that no other standard methods besides GET and HEAD
can be served from a cache, but unless I missed it, the spec does not
appear to explicitly state this.

We have the "Cache-control: no-cache" request header to force
proxies to forward GET and HEAD requests.  


HTTP is supposed to be an extensible protocol, in the sense that new
methods can be added.  At the moment the only safe thing for proxies
to do is to forward any request for any new method, actually any
method other than GET and HEAD, and only to serve GETs and HEADs
that don't have Cache-control: no-cache (and that also meet certain other
criteria).

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.

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

	-------------------------------------------------
On a slightly different topic, Koen Holtman also recently responded recently:
  [ me: ]	
  >  Expiration dates are a very weird concept anyway.
  >We're mostly using them to signal that something is "pre-expired" and
  >so uncacheable, something best done with some other mechanism anyway.

  Well, we have Cache-Control now, which seems to be completely
  equivalent to Expires, so you can use that.

I bring this up since I believe there's an issue that was left
hanging.  I do not believe we have decided that Cache-control:
no-cache is exactly equivalent to Expires: yesterday.  The difference
is that Expires is expressly not supposed to affect history mechanisms
("document stacks"), whereas at least Netscape's implementation of
Cache-control: no-cache will affect them, according to Lou Montulli.
And Cache-control: private is certainly not equivalent to Expires:
<future-date>, since the only effective caching that can happen with
this directive is in the client.  

Can this please be resolved unambiguously?  I would like to see it
specified that Cache-control: no-cache either must or must not affect
history mechanisms as well as caches.  As we already have Expires:
yesterday to cause one effect, I suggest we use the directive for the
other effect.

In any case, I repeat that using Expires: yesterday for this type of
thing seems somewhat twisted to me. We're stuck with it at least for
backward compatibility, but the semantics it has acquired seems
overloaded.  Another directive would be better.

--Shel

Received on Monday, 4 September 1995 13:17:57 UTC