Re: ADAMS1, point 31. (cachability of methods).

Henrik writes:
    There is a large group of extensions which your proposed change
    will impact:  the group of extensions describing under which terms
    a cached entry can be handed out based on payment, copyright,
    licensing, content filtering, added service, etc.

    If the cache knows about one of these mandatory extensions (using
    the M- prefix) then it should be able to serve the request without
    revalidating the response. Imagine if 80% of requests are M-
    prefixed with some widely used copyright extension then the forced
    revalidations are potentially seriously impacting cache performance
    without reason.

    True, caches that don't understand the extension will have to
    validate but on the other hand, if the extension is fully cachable
    by everyone then it hardly calls for messing with the method name
    but instead for an optional extension. There is no need to produce
    more than one GET method.

Henrik, please read section 14.9.6 (Cache Control Extensions).
It already handles the problem you are describing.  For example,
an extension can define the meaning of a new cache-control
directive (let's call it "henrik-mode"), and send:

	Cache-control: max-age=0, must-revalidate, henrik-mode=999

Any cache that doesn't understand your extension must ignore
"henrik-mode" and so will do the necessary revalidation.  If
the cache does understand your extension, 14.9.6 allows it
to use the "henrik-mode" directive to modify the behavior
of the other two ("modify" may mean "ignore").

    I do not believe we at this point can change whether we consider
    caching or the method to be the highest in the hierarchy.

I don't think at this point we should be proposing changes to
the HTTP/1.1 protocol without first reading the existing
specification :-)

-Jeff

Received on Monday, 16 November 1998 17:47:13 UTC