- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 20 Nov 96 16:21:45 PST
- To: Ingrid Melve <Ingrid.Melve@uninett.no>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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 this. 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. -Jeff
Received on Thursday, 21 November 1996 17:02:09 UTC