HTTP Working Group Jeffrey Mogul, DECWRL
`Internet-Draft Paul J. Leach, Microsoft
`Expires: 10 October 1997 25 March 1997
`
` Simple Hit-Metering and Usage-Limiting for HTTP
`
` draft-ietf-http-hit-metering-02.txt
`
`STATUS OF THIS MEMO
`
` This document is an Internet-Draft. Internet-Drafts are
` working documents of the Internet Engineering Task Force
` (IETF), its areas, and its working groups. Note that other
` groups may also distribute working documents as
` Internet-Drafts.
`
` Internet-Drafts are draft documents valid for a maximum of
` six months and may be updated, replaced, or obsoleted by
` other documents at any time. It is inappropriate to use
` Internet-Drafts as reference material or to cite them other
` than as "work in progress."
`
` To learn the current status of any Internet-Draft, please
` check the "1id-abstracts.txt" listing contained in the
` Internet-Drafts Shadow Directories on ftp.is.co.za
` (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
` Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
` West Coast).
`
` Distribution of this document is unlimited. Please send
` comments to the HTTP working group at
` <http-wg@cuckoo.hpl.hp.com>. Discussions of the working
` group are archived at
` <URL:http://www.ics.uci.edu/pub/ietf/http/>. General
` discussions about HTTP and the applications which use HTTP
` should take place on the <www-talk@w3.org> mailing list.
`
`ABSTRACT
`
` This document proposes a simple extension to HTTP, using a
` new ‘‘Meter’’ header, which permits a limited form of
` demographic information (colloquially called
` ‘‘hit-counts’’) to be reported by caches to origin servers,
` in a more efficient manner than the ‘‘cache-busting’’
` techniques currently used. It also permits an origin
` server to control the number of times a cache uses a cached
` response, and outlines a technique that origin servers can
` use to capture referral information without
` ‘‘cache-busting.’’
`
`Mogul, Leach [Page 1]
`
`Google Inc.
`GOOG 1024
`IPR of U.S. Patent No. 6,286,045
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` TABLE OF CONTENTS
`
`1 Introduction 2
` 1.1 Goals, non-goals, and limitations 3
` 1.2 Brief summary of the design 4
` 1.3 Terminology 5
`2 Overview 5
` 2.1 Discussion 7
`3 Design concepts 7
` 3.1 Implementation of the "metering subtree" 8
` 3.2 Format of the Meter header 9
` 3.3 Negotiation of hit-metering and usage-limiting 10
` 3.4 Transmission of usage reports 13
` 3.5 When to send usage reports 14
` 3.6 Subdivision of usage-limits 16
`4 Analysis 17
` 4.1 Approximation accuracy for counting users 17
` 4.2 What about "Network Computers"? 18
` 4.3 Critical-path delay analysis 18
`5 Specification 19
` 5.1 Specification of Meter header and directives 19
` 5.2 Abbreviations for Meter directives 22
` 5.3 Counting rules 22
` 5.3.1 Counting rules for hit-metering 23
` 5.3.2 Counting rules for usage-limiting 23
` 5.3.3 Equivalent algorithms are allowed 24
` 5.4 Counting rules: interaction with Range requests 25
` 5.5 Implementation by non-caching proxies 26
` 5.6 Implementation by cooperating caches 26
`6 Examples 26
` 6.1 Example of a complete set of exchanges 26
` 6.2 Protecting against HTTP/1.0 proxies 28
` 6.3 More elaborate examples 29
`7 Interactions with content negotiation 29
` 7.1 Treatment of responses carrying a Vary header 30
` 7.2 Interaction with Transparent Content Negotiation 31
`8 A Note on Capturing Referrals 31
`9 Alternative proposals 32
`10 Security Considerations 32
`11 Acknowledgements 33
`12 References 33
`13 Authors’ addresses 34
`
`1 Introduction
`
` For a variety of reasons, content providers want to be able to
` collect information on the frequency with which their content is
` accessed. This desire leads to some of the "cache-busting" done by
` existing servers. ("Cache-busting" is the use by servers of
` techniques intended to prevent caching of responses; it is unknown
`
`Mogul, Leach [Page 2]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` exactly how common this is.) This kind of cache-busting is done not
` for the purpose of maintaining transparency or security properties,
` but simply to collect demographic information. Some cache-busting is
` also done to provide different advertising images to appear on the
` same page (i.e., each retrieval of the page sees a different ad).
`
` This proposal supports a model similar to that of publishers of
` hard-copy publications: such publishers (try to) report to their
` advertisers how many people read an issue of a publication at least
` once; they don’t (try to) report how many times a reader re-reads an
` issue. They do this by counting copies published, and then try to
` estimate, for their publication, on average how many people read a
` single copy at least once. The key point is that the results aren’t
` exact, but are still useful. Another model is that of coding
` inquiries in such a way that the advertiser can tell which
` publication produced the inquiry.
`
`1.1 Goals, non-goals, and limitations
` HTTP/1.1 already allows origin servers to prevent caching of
` responses, and evidence exists [8] that at least some of the time,
` this is being done for the sole purpose of collecting counts of the
` number of accesses of specific pages. Some of this evidence is
` inferred from the study of proxy traces; some is based on explicit
` statements of the intention of the operators of Web servers.
` Information collected this way might or might not be of actual use to
` the people who collect it; the fact is that they want to collect it,
` or already do so.
`
` The goal of this proposal is to provide an optional performance
` optimization for this use of HTTP/1.1.
`
` This specification is:
`
` - Optional: no server or proxy is required to implement it.
`
` - Proxy-centered: there is no involvement on the part of
` end-client implementations.
`
` - Solely a performance optimization: it provides no
` information or functionality that is not already available
` in HTTP/1.1. The intent is to improve performance overall,
` and reduce latency for almost all interactions; latency
` might be increased for a small fraction of HTTP
` interactions.
`
` - Best-efforts: it does not guarantee the accuracy of the
` reported information, although it does provide accurate
` results in the absence of persistent network failures or
` host crashes.
`
`Mogul, Leach [Page 3]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` - Neutral with respect to privacy: it reveals to servers no
` information about clients that is not already available
` through the existing features of HTTP/1.1.
`
` The goals of this specification do not include:
`
` - Solving the entire problem of efficiently obtaining
` extensive information about requests made via proxies.
`
` - Improving the protection of user privacy (although our
` proposal may reduce the transfer of user-specific
` information to servers, it does not prevent it).
`
` - Preventing or encouraging the use of log-exchange
` mechanisms.
`
` - Avoiding all forms of "cache-busting", or even all
` cache-busting done for gathering counts.
`
` This design has certain potential limitations:
`
` - If it is not deployed widely in both proxies and servers,
` it will provide little benefit.
`
` - It may, by partially solving the hit-counting problem,
` reduce the pressure to adopt more complete solutions, if
` any become available.
`
` - Even if widely deployed, it might not be widely used, and
` so might not significantly improve performance.
`
` These potential limitations might not be problems in actual practice.
`
`1.2 Brief summary of the design
` This section is included for people not wishing to read the entire
` document; it is not a specification for the proposed design, and
` over-simplifies many aspects of the design.
`
` The goal of this design is to eliminate the need for origin servers
` to use "cache-busting" techniques, when this is done just for the
` purpose of counting the number of users of a resource.
` (Cache-busting includes techniques such as setting immediate
` Expiration dates, or sending "Cache-control: private" in each
` response.)
`
` The design adds a new "Meter" header to HTTP; the header is always
` protected by the "Connection" header, and so is always hop-by-hop.
` This mechanism allows the construction of a "metering subtree", which
` is a connected subtree of proxies, rooted at an origin server. Only
` those proxies that explicitly volunteer to join in the metering
` subtree for a resource participate in hit-metering, but those proxies
`
`Mogul, Leach [Page 4]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` that do volunteer are required to make their best effort to provide
` accurate counts. When a hit-metered response is forwarded outside of
` the metering subtree, the forwarding proxy adds "Cache-control:
` proxy-maxage=0", so that other proxies (outside the metering subtree)
` are forced to forward all requests to a server in the metering
` subtree.
`
` ---------
` NOTE: the HTTP/1.1 specification does not currently define a
` "proxy-maxage" Cache-control directive. A separate proposal
` has been made, on various grounds, to add such a directive to
` the next revision of the HTTP/1.1 specification [6].
` ---------
`
` The Meter header carries zero or more directives, similar to the way
` that the Cache-control header carries directives. Proxies may use
` certain Meter directives to volunteer to do hit-metering for a
` resource. If a proxy does volunteer, the server may use certain
` directives to require that a response be hit-metered. Finally,
` proxies use a "count" Meter directive to report the accumulated hit
` counts.
`
` The Meter mechanism can also be used by a server to limit the number
` of uses that a cache may make of a cached response, before
` revalidating it.
`
` The full specification includes complete rules for counting "uses" of
` a response (e.g., non-conditional GETs) and "reuses" (conditional
` GETs). These rules ensure that the results are entirely consistent
` in all cases, except when systems or networks fail.
`
`1.3 Terminology
` This document uses terms defined and explained in the HTTP/1.1
` specification [3], including ‘‘origin server,’’ ‘‘resource,’’
` ‘‘hop-by-hop,’’ ‘‘unconditional GET,’’ and ‘‘conditional GET.’’ The
` reader is expected to be familiar with the HTTP/1.1 specification and
` its terminology.
`
`2 Overview
`
` The design described in this document introduces several new features
` to HTTP:
`
` - Hit-metering: allows an origin server to obtain reasonably
` accurate counts of the number of clients using a resource
` instance via a proxy cache, or a hierarchy of proxy caches.
`
` - Usage-limiting: allows an origin server to control the
` number of times a cached response may be used by a proxy
` cache, or a hierarchy of proxy caches, before revalidation
` with the origin server.
`Mogul, Leach [Page 5]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` These new non-mandatory features require minimal new protocol
` support, no change in protocol version, relatively little overhead in
` message headers. The design adds no additional network round-trips
` in any critical path that directly affects user-perceived latency
` (see section 4.3 for an analysis).
`
` The primary goal of hit-metering and usage-limiting is to obviate the
` need for an origin server to send "Cache-control: proxy-maxage=0"
` with responses for resources whose value is not likely to change
` immediately. In other words, in cases where the only reason for
` contacting the origin server on every request that might otherwise be
` satisfied by a proxy cache entry is to allow the server to collect
` demographic information or to control the number of times a cache
` entry is used, the extension proposed here will avoid a significant
` amount of unnecessary network traffic and latency.
`
` This design introduces one new ‘‘Meter’’ header, which is used both
` in HTTP request messages and HTTP response messages. The Meter
` header is used to transmit a number of directives and reports. In
` particular, all negotiation of the use of hit-metering and usage
` limits is done using this header. No other changes to the existing
` HTTP/1.1 specification [3] are proposed in this document.
`
` This design also introduces several new concepts:
`
` 1. The concepts of a "use" of a cache entry, which is when a
` proxy returns its entity-body in response to a conditional
` or non-conditional request, and the "reuse" of a cache
` entry, which is when a proxy returns a 304 (Not Modified)
` response to a conditional request which is satisfied by
` that cache entry.
`
` 2. The concept of a hit-metered resource, for which proxy
` caches make a best-effort attempt to report accurate
` counts of uses and/or reuses to the origin server.
`
` 3. The concept of a usage-limited resource, for which the
` origin server expects proxy caches to limit the number of
` uses and/or reuses.
`
` The new Meter directives and reports interact to allow proxy caches
` and servers to cooperate in the collection of demographic data. The
` goal is a best-efforts approximation of the true number of uses
` and/or reuses, not a guaranteed exact count.
`
` The new Meter directives also allow a server to bound the inaccuracy
` of a particular hit-count, by bounding the number of uses between
` reports. It can also, for example, bound the number of times the
` same ad is shown because of caching.
`
`Mogul, Leach [Page 6]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` Section 7.1 describes a way to use server-driven content negotiation
` (the Vary header) that allows an HTTP origin server to flexibly
` separate requests into categories and count requests by category.
` Implementation of such a categorized hit counting is likely to be a
` very small modification to most implementations of Vary; some
` implementations may not require any modification at all.
`
`2.1 Discussion
` Mapping this onto the publishing model, a proxy cache would increment
` the use-count for a cache entry once for each unconditional GET done
` for the entry, and once for each conditional GET that results in
` sending a copy of the entry to update a client’s invalid cached copy.
` Conditional GETs that result in 304 (Not Modified) are not included
` in the use-count, because they do not result in a new user seeing the
` page, but instead signify a repeat view by a user that had seen it
` before. However, 304 responses are counted in the reuse-count.
` HEADs are not counted at all, because their responses do not contain
` an entity-body.
`
` The Meter directives apply only to shared proxy caches, not to
` end-client (or other single-user) caches. Single user caches should
` not use Meter, because their hits will be automatically counted as a
` result of the unconditional GET with which they first fetch the page,
` from either the origin-server or from a proxy cache. Their
` subsequent conditional GETs do not result in a new user seeing the
` page.
`
` The mechanism specified here counts GETs; other methods either do not
` result in a page for the user to read, aren’t cached, or are
` "written-through" and so can be directly counted by the origin
` server. (If, in the future, a "cachable POST" came into existence,
` whereby the entity-body in the POST request was used to select a
` cached response, then such POSTs would have to be treated just like
` GETs.) The applicability of hit-metering to any new HTTP methods
` that might be defined in the future is currently unspecifiable.
`
` In the case of multiple caches along a path, a proxy cache does the
` obvious summation when it receives a use-count or reuse-count in a
` request from another cache.
`
`3 Design concepts
`
` In order to allow the introduction of hit-metering and usage-limiting
` without requiring a protocol revision, and to ensure a reasonably
` close approximation of accurate counts, the negotiation of metering
` and usage-limiting is done hop-by-hop, not end-to-end. If one
` considers the "tree" of proxies that receive, store, and forward a
` specific response, the intent of this design is that within some
` (possibly null) "metering subtree", rooted at the origin server, all
` proxies are using the hit-metering and/or usage-limiting requested by
` the origin server.
`Mogul, Leach [Page 7]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` Proxies at the leaves of this subtree will insert a "Cache-control:
` proxy-maxage=0" directive, which forces all other proxies (below this
` subtree) to check with a leaf of the metering subtree on every
` request. However, it does not prevent them from storing and using
` the response, if the revalidation succeeds.
`
` No proxy is required to implement hit-metering or usage-limiting.
` However, any proxy that transmits the Meter header in a request MUST
` implement every unconditional requirement of this specification,
` without exception or amendment.
`
` This is a conservative design, which may sometimes fail to take
` advantage of hit-metering support in proxies outside the metering
` subtree. However, it is likely that without the reliability offered
` by a conservative design, managers of origin servers with
` requirements for accurate approximations will not take advantage of
` any hit-metering proposal.
`
` The hit-metering/usage-limiting mechanism is designed to avoid any
` extra network round-trips in the critical path of any client request,
` and (as much as possible) to avoid excessively lengthening HTTP
` messages.
`
` The Meter header is used to transmit both negotiation information and
` numeric information.
`
` A formal specification for the Meter header appears in section 5; the
` following discussion uses an informal approach to improve clarity.
`
`3.1 Implementation of the "metering subtree"
` The "metering subtree" approach is implemented in a simple,
` straightforward way by defining the new "Meter" header as one that
` MUST always be protected by a Connection header in every request or
` response. I.e., if the Meter header is present in an HTTP message,
` that message:
`
` 1. MUST contain "Connection: meter", and MUST be handled
` according to the HTTP/1.1 specification of the Connection
` header.
`
` 2. MUST NOT be sent in response to a request from a client
` whose version number is less than HTTP/1.1.
`
` 3. MUST NOT be accepted from a client whose version number is
` less than HTTP/1.1.
`
` The reason for the latter two restrictions is to protect against
` proxies that might not properly implement the Connection header.
` Otherwise, a subtree that includes an HTTP/1.0 proxy might
` erroneously appear to be a metering subtree.
`
`Mogul, Leach [Page 8]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` ---------
` Note: It appears that for the Connection header mechanism to
` function correctly, a system receiving an HTTP/1.0 (or
` lower-version) message that includes a Connection header must
` act as if this header, and all of the headers it protects,
` ought to have been removed from the message by an intermediate
` proxy.
`
` Although RFC2068 does not specifically require this behavior,
` it appears to be implied. Otherwise, one could not depend on
` the stated property (section 14.10) that the protected options
` ‘‘MUST NOT be communicated by proxies over further
` connections.’’ This should probably be clarified in a
` subsequent draft of the HTTP/1.1 specification.
`
` This specification does not, in any way, propose a modification
` of the specification of the Connection header.
` ---------
`
` From the point of view of an origin server, the proxies in a metering
` subtree work together to obey usage limits and to maintain accurate
` usage counts. When an origin server specifies a usage limit, a proxy
` in the metering subtree may subdivide this limit among its children
` in the subtree as it sees fit. Similarly, when a proxy in the
` subtree receives a usage report, it ensures that the hits represented
` by this report are summed properly and reported to the origin server.
`
` When a proxy forwards a hit-metered or usage-limited response to a
` client (proxy or end-client) not in the metering subtree, it MUST
` omit the Meter header, and it MUST add "Cache-control:
` proxy-maxage=0" to the response.
`
`3.2 Format of the Meter header
` The Meter header is used to carry zero or more directives. Multiple
` Meter headers may occur in an HTTP message, but according to the
` rules in section 4.2 of the HTTP/1.1 specification [3], they may be
` combined into a single header (and should be so combined, to reduce
` overhead).
`
` For example, the following sequence of Meter headers
`
` Meter: max-uses=3
` Meter: max-reuses=10
` Meter: do-report
`
` may be expressed as
`
` Meter: max-uses=3, max-reuses=10, do-report
`
`Mogul, Leach [Page 9]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
`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-maxage=0".
` (An origin server wishing to prevent HTTP/1.0 proxies from improperly
` caching the response could also send both "Expires: <now>", to
` prevent such caching, and "Cache-control: max-age=NNNN", to allow
` newer proxies to cache the response).
`
` The purpose of the Meter header is to obviate the need for
` "Cache-control: proxy-maxage=0" within a metering subtree. Thus, any
` proxy may negotiate the use of hit-metering and/or usage-limiting
` with the next-hop server. If this server is the origin server, or is
` already part of a metering subtree (rooted at the origin server),
` then it may complete the negotiation, thereby extending the metering
` subtree to include the new proxy.
`
` To start the negotiation, a proxy sends its request with one of the
` following Meter directives:
`
` will-report-and-limit
` indicates that the proxy is willing and able to
` return usage reports and will obey any usage-limits.
`
` wont-report indicates that the proxy will obey usage-limits but
` will not send usage reports.
`
` wont-limit indicates that the proxy will not obey usage-limits
` but will send usage reports.
`
` A proxy willing to neither obey usage-limits nor send usage reports
` MUST NOT transmit a Meter header in the request.
`
` By definition, an empty Meter header:
`
` Meter:
`
` is equivalent to "Meter: will-report-and-limit", and so, by the
` definition of the Connection header (see section 14.10 of the
` HTTP/1.1 specification [3]), a request that contains
`
` Connection: Meter
`
` and no explicit Meter header is equivalent to a request that contains
`
` Connection: Meter
` Meter: will-report-and-limit
`
` This makes the default case more efficient.
`
`Mogul, Leach [Page 10]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` An origin server that is not interested in metering or usage-limiting
` the requested resource simply ignores the Meter header.
`
` If the server wants the proxy to do hit-metering and/or
` usage-limiting, its response should include one or more of the
` following Meter directives:
`
` For hit-metering:
`
` do-report specifies that the proxy MUST send usage reports to
` the server.
`
` dont-report specifies that the proxy SHOULD NOT send usage
` reports to the server.
`
` 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.
`
` ---------
` 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.
`
`Mogul, Leach [Page 11]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` 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.
`
` 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:
` proxy-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: proxy-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
`
`Mogul, Leach [Page 12]
`
`

`
`
`Internet-Draft Hit-Metering for HTTP 25 March 1997 11:50
`
` 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.)
`
` ---------
` For example, if proxy A receives a GET request from proxy B for
` URL X with "Connection: Meter", but proxy A’s cached response
` for URL does not include any Meter directives, then proxy A may
` ignore the metering offer from proxy B.
`
` However, if proxy A has previously told the origin server
` "Meter: wont-limit" (implying will-report), and the cached
` response contains "Meter: do-report", and proxy B’s request
` includes "Meter: wont-report", then proxy B’s offer is
` inconsistent with proxy A’s duty to the origin server.
` Therefore, in this case proxy A must add "Cache-control:
` proxy-maxage=0" when it returns the cached response to proxy B,
` and must not include a Meter header in this response.
` ---------
`
` If a server does not want to use the Meter mechanism, and will not
` want to use it any time soon, it may send this directive:
`
` wont-ask recommends that the proxy SHOULD NOT send any Meter
` directives to this server.
`
` The proxy SHOULD rem