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

Balint Nagy Endre writes:
 > You forgot to mention previously, that your proposed
 > "Cache-Control: serve-from-cache" will be a request header.

Sorry.

 > I like the fresh idea of introducing a permissive cache-control directive.
 > (Now we have only restrictive ones.)
 > But to have to fetch something from the cache, we shall first something
 > to store. Both clients and servers must implement the new method to be
 > working. From this viewpoint it is indifferent, client or server stuffs
 > in the permissive cache-control. If you want to employ permissive
 > cache-control to tell caches, that an entity-body contained in a PUT-like
 > request can be cached, then it makes sense.
 > 
 > I had only GET-like methods in mind, when I read your proposal.
 > (This is my mistake, of course.)

I had only GET-like methods in mind too.

I think I understand what you mean here, but I think this would be
hard to do as you suggest.  The reason it has to be a request header
is that the purpose is to make it possible for a cache to serve a
document for a method that is like GET and HEAD, but not on the
official list of methods that can be served out of caches.  You are of
course right that both the end user agent and origin server must know
about a new method for anything good to happen, but the caches in
between don't need to know anything about the new method, and can't be
assumed to know.  So the request header provides a way for a cache to
decide for itself that a method is like GET, in the sense that it is
possible to return a result from the cache without going to the origin
server.

If this were done in a response header, more information would have to
be propagated.  The cache would have to be told what methods it could
respond to without going to the origin server.  It would be much
messier that way.

--Shel

Received on Wednesday, 6 September 1995 15:14:48 UTC