- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 25 Mar 97 11:52:05 PST
- To: http-wg@cuckoo.hpl.hp.com
Koen writes:
- Some exotic proxy arrangements could lead to there being a
`metering sub-graph' instead of a tree. Have you done the analysis
to find out if section 5.6 really covers all subcases?
It "covers all subcases" by passing the buck to the designers/implementors
of cooperative caches. It says "if you agree to meter, then you
have to ensure that the external behavior of your set of caches
is consistent with the intention of this specification." I left
it vague so that we don't overconstrain these designers/implementors.
But they always have the option of not participating in hit-metering.
- Section 3.3: `then the proxy MUST add "Cache-control:
proxy-maxage=0" to all responses it sends for the resource.'
You probably mean: `then the proxy MUST add "Cache-control:
proxy-maxage=0" to all responses for which metering or limiting was
requested.'
because you say earlier on that being metered is a property of a response,
not of a resource.
This paragraph wasn't very clear. "The resource" in that sentence
should have been something like "the current request". I rewrote
the paragraph more carefully:
A proxy that receives the Meter header in a request may ignore it
only to the extent that this is consistent with its own duty to the
next-hop server. If the received Meter request header is
inconsistent with that duty, or if no Meter request header is received
and the response from the next-hop server requests any form of
metering or limiting, then the proxy MUST add "Cache-control:
proxy-maxage=0" to any response it forwards for that request. (A
proxy SHOULD NOT add or change the Expires header or max-age
Cache-control directive.)
That's a much wordier rewrite of the paragraph, but I think it
leaves much less ambiguity.
- Section 4.1:
`The existing (HTTP/1.0) "cache-busting" mechanisms for counting
distinct users will certainly overestimate the number of users behind
a proxy, since it provides no reliable way to distinguish between a
user's initial request and subsequent repeat requests caused by
insufficient space in the end-client cache.'
Hit metering also `provides no reliable way to distinguish between
a user's initial request and subsequent repeat requests caused by
insufficient space in the end-client cache' if I'm correct (there
is no If-* header if the page dropped out of the cache), so
limiting this statement to "cache-busting" is a bit misleading.
Actually, this was a bug. The correct statement is:
The existing (HTTP/1.0) "cache-busting" mechanisms for counting
distinct users will certainly overestimate the number of users behind
a proxy, since it provides no reliable way to distinguish between a
user's initial request and subsequent repeat requests that might have
been conditional GETs, had not cache-busting been employed.
I.e., if you cache-bust in HTTP/1.0 (e.g., by setting Expires to
something ancient), then when a client sends a conditional GET
to a caching proxy, the proxy has to forward this to the origin server.
And when a client sends an unconditional GET to a caching proxy,
presumably a well-implemented proxy can turn this into a conditional
GET as well (before forwarding it to the origin server), so I see no
obvious way for the origin server to distinguish these two classes
of client events.
`The "Cache-control:
proxy-maxage=0" feature of HTTP/1.1 does allow the separation of
use-counts and reuse-counts, provided that no HTTP/1.0 proxy caches
intervene.'
How can they intervene? Do some 1.0 proxies stip off the
If-NoMatch headers when forwarding a request on a stale cache
entry, or are you talking about something else?
No, this simply means that if the origin server relies on proxy-maxage=0,
it will be ignored by any HTTP/1.0 proxy cache along the path, and so some
of the use counts could be lost.
-Jeff
Received on Tuesday, 25 March 1997 12:01:03 UTC