HTTP Working Group Jeffrey Mogul, DECWRL
`Internet-Draft Paul J. Leach, Microsoft
`Expires: 22 July 1997 21 January 1997
`
` Simple Hit-Metering for HTTP
` Preliminary Draft
`
` draft-ietf-http-hit-metering-00.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 draft proposes a simple extension to HTTP, using a new
` ``Meter'' header, to permit 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 1016
`IPR of U.S. Patent No. 6,014,698
`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` TABLE OF CONTENTS
`
`1 Introduction 2
` 1.1 Goals, non-goals, and limitations 3
` 1.2 Brief summary of the design 4
`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 What about "Network Computers"? 18
` 4.2 Why max-uses is not a Cache-control directive 19
`5 Specification 19
` 5.1 Specification of Meter header and directives 19
` 5.2 Abbreviations for Meter directives 21
` 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 25
`6 Expressing or approximating the "proxy-mustcheck" directive 26
`7 Examples 27
` 7.1 Example of a complete set of exchanges 27
` 7.2 Protecting against HTTP/1.0 proxies 29
` 7.3 More elaborate examples 29
`8 Interactions with varying resources 30
`9 A Note on Capturing Referrals 31
`10 Security Considerations 32
`11 Revision history 32
` 11.1 draft-mogul-http-hit-metering-01.txt 32
` 11.2 draft-mogul-http-hit-metering-00.txt 33
`12 Acknowledgements 33
`13 References 33
`14 Authors' addresses 33
`
`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 (exactly how much is unknown). This kind of
` cache-busting is done not for the purpose of maintaining transparency
` or security properties, but simply to collect demographic
` information. It has also been pointed out that some cache-busting is
`
`Mogul, Leach [Page 2]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` also done to provide different advertising images to appear on the
` same page (i.e., each retrieval of the page sees a different ad).
`
` One model that this proposal tries to support is one reasonably
` 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 we have evidence 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. We take no
` position on whether the information collected this way is of use to
` the people who collect it; the fact is that they want to collect it,
` or already do so.
`
` Our goal in this proposal is to provide an optional performance
` optimization for this use of HTTP/1.1.
`
` Our proposal 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. Our intention is to improve performance
` overall, and reduce latency for almost all interactions; we
` do not purport to reduce latency for every single HTTP
` interaction.
`
` - 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.
`
` - 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.
`
`Mogul, Leach [Page 3]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` To the extent that any part of this specification conflicts with
` these criteria, we would consider that to be a bug, and will
` undertake to resolve this when it is brought to our attention.
`
` Our goals 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.
`
` We recognize certain potential limitations of our design:
`
` - 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 (hypothetical) more complete
` solutions.
`
` - Even if widely deployed, it might not be widely used, and
` so might not significantly improve performance.
`
` We do not believe that these potential limitations are problems in
` reality.
`
`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.
`
` Our goal 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.)
`
` We add 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 us to construct 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 that do
`
`Mogul, Leach [Page 4]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` 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-mustcheck", 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 define a
` "proxy-mustcheck" Cache-control directive. We use this name as
` a placeholder for a directive meaning "proxies must revalidate
` this response even if fresh," which is not currently defined in
` HTTP/1.1. In section 6 we describe several alternatives for
` expressing or approximating this placeholder; see also [2].
` ---------
`
` 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.
`
`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.
`
` These new non-mandatory features require minimal new protocol
` support, no change in protocol version, relatively little overhead in
` message headers, and no additional network round-trips in any
` critical path.
`Mogul, Leach [Page 5]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` The primary goal of hit-metering and usage-limiting is to obviate the
` need for an origin server to send "Cache-control: proxy-mustcheck"
` 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 [1] 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.
`
` We also identify 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 (see section
` 8). 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.
`
`Mogul, Leach [Page 6]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
`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.
`
` ---------
` Note: this means that the reuse-count does not include reuses
` done locally to the end-client. While there are some reasons
` to want to collect such information, especially for research
` into user behavior patterns, we believe that the reasons
` against doing so (network overheads, additional client
` complexity, and possible privacy issues) are stronger.
` However, we encourage further discussion of this issue.
` ---------
`
` 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.)
`
` 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
`
`Mogul, Leach [Page 7]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` (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.
`
` Proxies at the leaves of this subtree will insert a "Cache-control:
` proxy-mustcheck" 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 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, we believe that without a conservative design,
` managers of origin servers with requirements for accurate information
` 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.
`
`Mogul, Leach [Page 8]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` Otherwise, a subtree that includes an HTTP/1.0 proxy might
` erroneously appear to be a metering subtree.
`
` ---------
` Note: We believe that in order 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 the current draft of the HTTP/1.1 specification does
` not specifically require this behavior, we believe that it is
` 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.'' We
` suggest that this be clarified in a subsequent draft of the
` HTTP/1.1 specification.
`
` We do 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-mustcheck" to the response.
`
` ---------
` Design question: alternatively, we could specify that the
` origin server is responsible for adding "Cache-control:
` proxy-mustcheck" to the response, and that a proxy in the
` metering subtree should ignore this directive, unless it has
` exhausted one of the usage limits. This would get the proxies
` out of the business of adding headers to responses, but it
` would increase the number of bytes in the response from the
` origin server.
` ---------
`
`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 [1], they may be
`
`Mogul, Leach [Page 9]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` 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
`
`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-mustcheck".
` (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-mustcheck" 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
`
`Mogul, Leach [Page 10]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` definition of the Connection header (see section 14.10 of the
` HTTP/1.1 specification [1]), 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.
`
` These request directives ("will-report", "will-limit", and
` "will-report-and-limit" in both its explicit and implicit forms)
` apply to all subsequent requests made on the given transport
` connection.
`
` ---------
` Note: one way for a server to implement the ``connection-long''
` nature of these three directives is to associate two flag bits
` with each transport connection from a client, which are
` initially cleared when the connection is established. Receipt
` of the "will-report" or "will-limit" directive sets the
` corresponding flag bit; receipt of the "will-report-and-limit"
` or of an empty Meter request header sets both bits.
` ---------
`
` 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.
`
` 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.
`
` 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.
`Mogul, Leach [Page 11]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` 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 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-mustcheck".)
`
` ---------
` Note: a proxy that has not sent the Meter header in a request
` during the given transport connection, 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-mustcheck" 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 header is inconsistent, or no
` Meter header is received and the next-hop server has requested any
` metering or limiting, then the proxy MUST add "Cache-control:
`
`Mogul, Leach [Page 12]
`

`
`

`
`Internet-Draft Hit-Metering for HTTP (DRAFT) 21 January 1997 12:06
`
` proxy-mustcheck" to all responses it sends for the resource. (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-mustcheck" 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 remember this fact for up to 24 hours. This avoids
` virtually all un