W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: Hit-metering: to Proposed Standard?

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Wed, 20 Nov 96 16:21:45 PST
Message-Id: <9611210021.AA00621@acetes.pa.dec.com>
To: Ingrid Melve <Ingrid.Melve@uninett.no>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1931
Ingrid seems to have found a (fixable) bug in our proposal:

    3.3 Negotiation of hit-metering and usage-limiting
       An origin server that wants to collect hit counts for a resource, by
       simply forcing all requests to bypass any proxy caches, would respond
       to requests on the resource with "Cache-control: proxy-revalidate".
    In reading the HTTP/1.1 spec, I had the understanding that
    must-revalidate and proxy-revalidate as defined in 14.9 only
    requires a cache to revalidate if the response is stale, not every
    time a request is made (unless there is an Authorization field).
    Please correct me if I am wrong.
    > draft-ietf-http-v11-spec-07.txt:
    > When the must-revalidate directive is present in a response received 
    > by a cache, that cache MUST NOT use the entry after it becomes stale 
    > to respond to a subsequent request without first revalidating it with 
    > the origin server.
    > [..]
    > The proxy-revalidate directive has the same meaning as the must- 
    > revalidate directive, except that it does not apply to non-shared 
    > user agent caches.

    If the proxy handing out a "Cache-control: proxy-revalidate" also
    is expected to modify staleness parameters like "Cache-control:
    max-age=0" this should be stated. 

Even though I wrote the words in the HTTP/1.1 specification for
"must-revalidate" and "proxy-revalidate", for some reason when I
was writing the hit-metering draft I forgot about this.  Yes, it
seems necessary for a proxy that is forwarding a response outside
of the metering subtree to generate
	Cache-control: proxy-revalidate,max-age=0
because this is exactly what the origin server would have had to
do to get the desired effect in the absence of the Meter mechanism.

This implies that if the received response said something like:
	Cache-control: max-age=3600
then the forwarded response would require a change in max-age:
	Cache-control: proxy-revalidate,max-age=0

    Are caches allowed to change max-age ??

I'm not sure that the HTTP/1.1 specification is explicit about

It's a shame that we didn't include a Cache-control directive
in HTTP/1.1 like "proxy-max-age" that only applies to proxies.
Or something like "proxy-always-revalidate" (with a shorter name)
that means the equivalent of "proxy-revalidate even if fresh".

Note that this is independent of the hit-metering issue: Ingrid
has pointed out a problem in HTTP/1.1 that would affect any origin
server wishing to see all of the unconditional GET requests but
not wishing to defeat end-client caching.

If we can solve that problem with HTTP/1.1, then the hit-metering
proposal doesn't need to ask proxies to rewrite max-age.

Received on Thursday, 21 November 1996 17:02:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:21 UTC