timeout=NNN sets a metering timeout of NNN minutes, from the time
that this response was originated, for the reporting
of a hit-count. If the proxy has a non-zero hit
count for this response when the timeout expires, it
MUST send a report to the server at or before that
time. Implies "do-report".
By definition, an empty Meter header in a response, or any Meter
header that does not contain "dont-report", means "Meter: do-report";
this makes a common case more efficient.
RFC 2227 Hit-Metering and Usage-Limiting October 1997
Note: an origin server using the metering timeout mechanism to
bound the collection period over which hit-counts are obtained
should adjust the timeout values in the responses it sends so that
all responses generated within that period reach their metering
timeouts at or before the end of that period.
If the origin server simply sends a constant metering timeout T
with each response for a resource, the reports that it receives
will reflect activity over a period whose duration is between T
and N*T (in the worst case), where N is the maximum depth of the
metering subtree.
For usage-limiting
max-uses=NNN sets an upper limit of NNN "uses" of the response,
not counting its immediate forwarding to the
requesting end-client, for all proxies in the
following subtree taken together.
max-reuses=NNN sets an upper limit of NNN "reuses" of the response
for all proxies in the following subtree taken
together.
When a proxy has exhausted its allocation of "uses" or "reuses" for a
cache entry, it MUST revalidate the cache entry (using a conditional
request) before returning it in a response. (The proxy SHOULD use
this revalidation message to send a usage report, if one was
requested and it is time to send it. See sections 3.4 and 3.5.)
These Meter response-directives apply only to the specific response
that they are attached to.
Note that the limit on "uses" set by the max-uses directive does
not include the use of the response to satisfy the end-client
request that caused the proxy's request to the server. This
counting rule supports the notion of a cache-initiated prefetch: a
cache may issue a prefetch request, receive a max-uses=0 response,
store that response, and then return that response (without
revalidation) when a client makes an actual request for the
resource. However, each such response may be used at most once in
this way, so the origin server maintains precise control over the
number of actual uses.
A server MUST NOT send a Meter header that would require a proxy to
do something that it has not yet offered to do. A proxy receiving a
Meter response-directive asking the proxy to do something it did not
volunteer to do SHOULD ignore that directive.
RFC 2227 Hit-Metering and Usage-Limiting October 1997
A proxy receiving a Meter header in a response MUST either obey it,
or it MUST revalidate the corresponding cache entry on every access.
(I.e., if it chooses not to obey the Meter header in a response, it
MUST act as if the response included "Cache-control: s-maxage=0".)
Note: a proxy that has not sent the Meter header in a request for
the given resource, and which has therefore not volunteered to
honor Meter directives in a response, is not required to honor
them. If, in this situation, the server does send a Meter header
in a response, this is a protocol error. However, based on the
robustness principle, the proxy may choose to interpret the Meter
header as an implicit request to include "Cache-control: s-
maxage=0" when it forwards the response, since this preserves the
apparent intention of the server.
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: s-
maxage=0" to any response it forwards for that request. (A proxy
=7= |