Cacheable extension methods (was: an idempotent idea)

Balint Nagy Endre writes:
 > Shel,
 > I keep thinking over your idea, and this is what I have figured out:
 > An extension method may require some x.y version of the protocol to
 > function properly.


The original idea again was to add a new request header,
Cache-control: serve-from-cache (I'm not too particular on what it's
called) that allows "extension methods" not in the official set of
HTTP methods to be served from a cache, just like GET or HEAD.

I think the only requirement on proxies is already satisfied: proxies
that do not understand the additional header must forward the request.
So, no new proxy functionality is *required*.  But proxies that
understand the new header can satisfy some requests out of their cache
that they might not otherwise be able to.  So I don't think version
number checking enters into it.  Old proxies that don't support the
new header don't break, and new ones that understand it don't change
the semantics, just performance.

 If a request arrives to an older server in its way 
 > to origin server, the old server MUST report failure (501 Not implemented).

No - it can just forward the request as it would do with POST, PUT, etc.

 > (in 1.0 version of the protocol we have no way to add extension methods
 > on the fly.)

The spec allows for extension methods. I interpret this to mean that agreeing
clients and servers can use private "extension" methods even though
they are not mentioned in the spec.  Supporting this better is the
reason for this header.

 This implies of course an other extension header, something
 > like
 > Server-Control: may-forward=<http-version>
 > and its variation
 > Server-Control: may-cache=<http-version>
 > may be the permissive cache controlling directive.

It's entirely possible I'm just missing your point, but,
repeating my earlier posts, the only additional header needed
is one that tells a proxy it may FETCH the result from its cache, and
does not change any behavior on STORING into caches.  You don't need
"may-forward" because proxies may always forward.  You don't need
"must-forward" because requests other than GET or HEAD must presently
always be forwarded.  You don't need "may-cache" because there is not
new required functionality on storing into caches, just on fetching --
you just need "may-serve-from-cache".  This is equivalent to "must
forward: NOT".

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

--Shel

Received on Sunday, 10 September 1995 21:12:26 UTC