summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2227.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2227.txt')
-rw-r--r--doc/rfc/rfc2227.txt2075
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc2227.txt b/doc/rfc/rfc2227.txt
new file mode 100644
index 0000000..d823ae5
--- /dev/null
+++ b/doc/rfc/rfc2227.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Network Working Group J. Mogul
+Request for Comments: 2227 DECWRL
+Category: Standards Track P. Leach
+ Microsoft
+ October 1997
+
+
+ Simple Hit-Metering and Usage-Limiting for HTTP
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+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."
+
+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 8
+ 3.1 Implementation of the "metering subtree" 8
+ 3.2 Format of the Meter header 10
+ 3.3 Negotiation of hit-metering and usage-limiting 10
+ 3.4 Transmission of usage reports 14
+ 3.5 When to send usage reports 15
+ 3.6 Subdivision of usage-limits 16
+
+
+
+
+Mogul & Leach Standards Track [Page 1]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ 4 Analysis 17
+ 4.1 Approximation accuracy for counting users 18
+ 4.2 What about "Network Computers"? 19
+ 4.3 Critical-path delay analysis 19
+ 5 Specification 20
+ 5.1 Specification of Meter header and directives 20
+ 5.2 Abbreviations for Meter directives 23
+ 5.3 Counting rules 24
+ 5.3.1 Counting rules for hit-metering 24
+ 5.3.2 Counting rules for usage-limiting 25
+ 5.3.3 Equivalent algorithms are allowed 26
+ 5.4 Counting rules: interaction with Range requests 27
+ 5.5 Implementation by non-caching proxies 27
+ 5.6 Implementation by cooperating caches 28
+ 6 Examples 28
+ 6.1 Example of a complete set of exchanges 28
+ 6.2 Protecting against HTTP/1.0 proxies 30
+ 6.3 More elaborate examples 30
+ 7 Interactions with content negotiation 31
+ 7.1 Treatment of responses carrying a Vary header 31
+ 7.2 Interaction with Transparent Content Negotiation 32
+ 8 A Note on Capturing Referrals 32
+ 9 Alternative proposals 33
+ 10 Security Considerations 34
+ 11 Acknowledgments 35
+ 12 References 35
+ 13 Authors' Addresses 36
+ 14 Full Copyright Statement 37
+
+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
+ 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
+
+
+
+Mogul & Leach Standards Track [Page 2]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ 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 [9] 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.
+
+ - 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.
+
+
+
+
+Mogul & Leach Standards Track [Page 3]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ - 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
+ 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: s-
+ maxage=0", so that other proxies (outside the metering subtree) are
+ forced to forward all requests to a server in the metering subtree.
+
+
+
+
+Mogul & Leach Standards Track [Page 4]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ NOTE: the HTTP/1.1 specification does not currently define a "s-
+ maxage" Cache-control directive. The HTTP working group has
+ decided to add such a directive to the next revision of the
+ HTTP/1.1 specification [7].
+
+ 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 [4], 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.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", SHOULD NOT",
+ "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
+ interpreted as described in RFC 2119 [1].
+
+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 Standards Track [Page 5]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ 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: s-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 [4] 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.
+
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 6]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 7]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+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.
+
+ Proxies at the leaves of this subtree will insert a "Cache-control:
+ s-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:
+
+
+
+Mogul & Leach Standards Track [Page 8]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ 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.
+
+ 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: s-maxage=0" to
+ the response.
+
+
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 9]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+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 [4], 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
+
+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: s-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: s-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.
+
+
+
+Mogul & Leach Standards Track [Page 10]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ 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 [4]), 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.
+
+ 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.
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 11]
+
+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.
+
+
+
+
+Mogul & Leach Standards Track [Page 12]
+
+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
+ 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: s-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.
+
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 13]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ The proxy SHOULD remember this fact for up to 24 hours. This avoids
+ virtually all unnecessary overheads for servers that do not wish to
+ use or support the Meter header. (This directive also implies
+ "dont-report".)
+
+3.4 Transmission of usage reports
+
+ To transmit a usage report, a proxy sends the following Meter header
+ in a request on the appropriate resource:
+
+ Meter: count=NNN/MMM
+
+ The first integer indicates the count of uses of the cache entry
+ since the last report; the second integer indicates the count of
+ reuses of the entry (see section 5.3 for rules on counting uses and
+ reuses). The transmission of a "count" directive in a request with
+ no other Meter directive is also defined as an implicit transmission
+ of a "will-report-and-limit" directive, to optimize the common case.
+ (A proxy not willing to honor usage-limits would send "Meter:
+ count=NNN/MMM, wont-limit" for its reports.)
+
+ Note that when a proxy forwards a client's request and receives a
+ response, the response that the proxy sends immediately to the
+ requesting client is not counted as a "use". I.e., the reported
+ count is the number of times the cache entry was used, and not the
+ number of times that the response was used.
+
+ A proxy SHOULD NOT transmit "Meter: count=0/0", since this conveys no
+ useful information.
+
+ Usage reports MUST always be transmitted as part of a conditional
+ request (such as a GET or HEAD), since the information in the
+ conditional header (e.g., If-Modified-Since or If-None-Match) is
+ required for the origin server to know which instance of a resource
+ is being counted. Proxys forwarding usage reports up the metering
+ subtree MUST NOT change the contents of the conditional header, since
+ otherwise this would result in incorrect counting.
+
+ A usage report MUST NOT be transmitted as part of a forwarded request
+ that includes multiple entity tags in an If-None-Match or If-Match
+ header.
+
+ Note: a proxy that offers its willingness to do hit-metering
+ (report usage) must count both uses and reuses. It is not
+ possible to negotiate the reporting of one but not the other.
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 14]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+3.5 When to send usage reports
+
+ A proxy that has offered to send usage reports to its parent in the
+ metering subtree MUST send a usage report in each of these
+ situations:
+
+ 1. When it forwards a conditional GET on the resource
+ instance on behalf of one of its clients (if the GET is
+ conditional on at most one entity-tag).
+
+ 2. When it forwards a conditional HEAD on the resource
+ instance on behalf of one of its clients.
+
+ 3. When it must generate a conditional GET to satisfy a
+ client request because the max-uses limit has been
+ exceeded.
+
+ 4. Upon expiration of a metering timeout associated with a
+ cache entry that has a non-zero hit-count.
+
+ 5. When it removes the corresponding non-zero hit-count entry
+ from its storage for any reason including:
+
+ - the proxy needs the storage space for another
+ hit-count entry.
+
+ - the proxy is not able to store more than one response
+ per resource, and a request forwarded on behalf of a
+ client has resulted in the receipt of a new response
+ (one with a different entity-tag or last-modified
+ time).
+
+ Note that a cache might continue to store hit-count information
+ even after having deleted the body of the response, so it is
+ not necessary to report the hit-count when deleting the body;
+ it is only necessary to report it if the proxy is about to
+ "forget" a non-zero value.
+
+ (Section 5.3 explains how hit-counts become zero or non-zero.)
+
+ If the usage report is being sent because the proxy is about to
+ remove the hit-count entry from its storage, or because of an expired
+ metering timeout:
+
+ - The proxy MUST send the report as part of a conditional
+ HEAD request on the resource instance.
+
+
+
+
+
+Mogul & Leach Standards Track [Page 15]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ - The proxy is not required to retry the HEAD request if it
+ fails (this is a best-efforts design). To improve
+ accuracy, however, the proxy SHOULD retry failed HEAD
+ requests, subject to resource constraints.
+
+ - The proxy is not required to serialize any other operation
+ on the completion of this request.
+
+ Note: proxy implementors are strongly encouraged to batch several
+ HEAD-based reports to the same server, when possible, over a
+ single persistent connection, to reduce network overhead as much
+ as possible. This may involve a non-naive algorithm for
+ scheduling the deletion of hit-count entries.
+
+ If the usage count is sent because of an arriving request that also
+ carries a "count" directive, the proxy MUST combine its own (possibly
+ zero) use and reuse counts with the arriving counts, and then attempt
+ to forward the request.
+
+ However, the proxy is not required to forward an arriving request
+ with a "count" directive, provided that:
+
+ - it can reply to the request using a cached response, in
+ compliance with other requirements of the HTTP
+ specification.
+
+ - such a response does not exceed a max-uses limit.
+
+ - it is not required to forward the request because of an
+ expired metering timeout.
+
+ If an arriving request carries a "count" directive, and the proxy no
+ longer has a cache entry for the resource, the proxy MUST forward the
+ "count" directive. (This is, in any case, what a proxy without a
+ suitable cache entry would normally do for any valid request it
+ receives.)
+
+3.6 Subdivision of usage-limits
+
+ 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.
+
+ For example, consider the situation with two proxies P1 and P2, each
+ of which uses proxy P3 as a way to reach origin server S. Imagine
+ that S sends P3 a response with
+
+
+
+
+
+Mogul & Leach Standards Track [Page 16]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ Meter: max-uses=10
+
+ The proxies use that response to satisfy the current requesting end-
+ client. The max-uses directive in this example allows the
+ combination of P1, P2, and P3 together to satisfy 10 additional end-
+ client uses (unconditional GETs) for the resource.
+
+ This specification does not constrain how P3 divides up that
+ allocation among itself and the other proxies. For example, P3 could
+ retain all of max-use allocation for itself. In that case, it would
+ forward the response to P1 and/or P2 with
+
+ Meter: max-uses=0
+
+ P3 might also divide the allocation equally among P1 and P2,
+ retaining none for itself (which may be the right choice if P3 has
+ few or no other clients). In this case, it could send
+
+ Meter: max-uses=5
+
+ to the proxy (P1 or P2) that made the initial request, and then
+ record in some internal data structure that it "owes" the other proxy
+ the rest of the allocation.
+
+ Note that this freedom to choose the max-uses value applies to the
+ origin server, as well. There is no requirement that an origin
+ server send the same max-uses value to all caches. For example, it
+ might make sense to send "max-uses=2" the first time one hears from a
+ cache, and then double the value (up to some maximum limit) each time
+ one gets a "use-count" from that cache. The idea is that the faster
+ a cache is using up its max-use quota, the more likely it will be to
+ report a use-count value before removing the cache entry. Also, high
+ and frequent use-counts imply a corresponding high efficiency benefit
+ from allowing caching.
+
+ Again, the details of such heuristics would be outside the scope of
+ this specification.
+
+4 Analysis
+
+ This section includes informal analyses of several aspects of hit-
+ metering:
+
+ 1. the accuracy of results when applied to counting users
+ (section 4.1).
+
+ 2. the problem of counting users whose browsers do not
+ include caches, such as Network Computers (section 4.2).
+
+
+
+Mogul & Leach Standards Track [Page 17]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ 3. delays imposed on "critical paths" for HTTP operations
+ (section 4.3).
+
+4.1 Approximation accuracy for counting users
+
+ For many (but not all) service operators, the single most important
+ aspect of the request stream is the number of distinct users who have
+ retrieved a particular entity within a given period (e.g., during a
+ given day). The hit-metering mechanism is designed to provide an
+ origin server with an approximation of the number of users that
+ reference a given resource. The intent of the design is that the
+ precision of this approximation is consistent with the goals of
+ simplicity and optional implementation.
+
+ Almost all Web users use client software that maintains local caches,
+ and the state of the art of local-caching technology is quite
+ effective. (Section 4.2 discusses the case where end-client caches
+ are small or non-existent.) Therefore, assuming an effective and
+ persistent end-client cache, each individual user who retrieves an
+ entity does exactly one GET request that results in a 200 or 203
+ response, or a 206 response that includes the first byte of the
+ entity. If a proxy cache maintains and reports an accurate use-count
+ of such retrievals, then its reported use-count will closely
+ approximate the number of distinct users who have retrieved the
+ entity.
+
+ There are some circumstances under which this approximation can break
+ down. For example, if an entity stays in a proxy cache for much
+ longer than it persists in the typical client cache, and users often
+ re-reference the entity, then this scheme will tend to over-count the
+ number of users. Or, if the cache-management policy implemented in
+ typical client caches is biased against retaining certain kinds of
+ frequently re-referenced entities (such as very large images), the
+ use-counts reported will tend to overestimate the user-counts for
+ such entities.
+
+ Browser log analysis has shown that when a user revisits a resource,
+ this is almost always done very soon after the previous visit, almost
+ always with fewer than eight intervening references [11]. Although
+ this result might not apply universally, it implies that almost all
+ reuses will hit in the end-client cache, and will not be seen as
+ unconditional GETs by a proxy cache.
+
+ 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. The
+
+
+
+Mogul & Leach Standards Track [Page 18]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ "Cache-control: s-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.
+
+ Note that if there is doubt about the validity of the results of
+ hit-metering a given set of resources, the server can employ cache-
+ busting techniques for short periods, to establish a baseline for
+ validating the hit-metering results. Various approaches to this
+ problem are discussed in a paper by James Pitkow [9].
+
+4.2 What about "Network Computers"?
+
+ The analysis in section 4.1 assumed that "almost all Web users" have
+ client caches. If the Network Computers (NC) model becomes popular,
+ however, then this assumption may be faulty: most proposed NCs have
+ no disk storage, and relatively little RAM. Many Personal Digital
+ Assistants (PDAs), which sometimes have network access, have similar
+ constraints. Such client systems may do little or no caching of HTTP
+ responses. This means that a single user might well generate many
+ unconditional GETs that yield the same response from a proxy cache.
+
+ First note that the hit-metering design in this document, even with
+ such clients, provides an approximation no worse than available with
+ unmodified HTTP/1.1: the counts that a proxy would return to an
+ origin server would represent exactly the number of requests that the
+ proxy would forward to the server, if the server simply specifies
+ "Cache-control: s-maxage=0".
+
+ However, it may be possible to improve the accuracy of these hit-
+ counts by use of some heuristics at the proxy. For example, the
+ proxy might note the IP address of the client, and count only one GET
+ per client address per response. This is not perfect: for example,
+ it fails to distinguish between NCs and certain other kinds of hosts.
+ The proxy might also use the heuristic that only those clients that
+ never send a conditional GET should be treated this way, although we
+ are not at all certain that NCs will never send conditional GETs.
+
+ Since the solution to this problem appears to require heuristics
+ based on the actual behavior of NCs (or perhaps a new HTTP protocol
+ feature that allows unambiguous detection of cacheless clients), it
+ appears to be premature to specify a solution.
+
+4.3 Critical-path delay analysis
+
+ In systems (such as the Web) where latency is at issue, there is
+ usually a tree of steps which depend on one another, in such a way
+ that the final result cannot be accomplished until all of its
+ predecessors have been. Since the tree structure admits some
+
+
+
+Mogul & Leach Standards Track [Page 19]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ parallelism, it is not necessary to add up the timings for each step
+ to discover the latency for the entire process. But any single path
+ through this dependency tree cannot be parallelized, and the longest
+ such path is the one whose length (in units of seconds) determines
+ the overall latency. This is the "critical path", because no matter
+ how much shorter one makes any other path, that cannot change the
+ overall latency for the final result.
+
+ If one views the final result, for a Web request, as rendering a page
+ at a browser, or otherwise acting on the result of a request, clearly
+ some network round trips (e.g., exchanging TCP SYN packets if the
+ connection doesn't already exist) are on the critical path. This
+ hit-metering design does add some round-trips for reporting non-zero
+ counts when a cache entry is removed, but, by design, these are off
+ any critical path: they may be done in parallel with any other
+ operation, and require only "best efforts", so a proxy does not have
+ to serialize other operations with their success or failure.
+
+ Clearly, anything that changes network utilization (either increasing
+ or decreasing it) can indirectly affect user-perceived latency. Our
+ expectation is that hit-metering, on average, will reduce loading and
+ so even its indirect effects should not add network round-trips in
+ any critical path. But there might be a few specific instances where
+ the added non-critical-path operations (specifically, usage reports
+ upon cache-entry removal) delay an operation on a critical path.
+ This is an unavoidable problem in datagram networks.
+
+5 Specification
+
+5.1 Specification of Meter header and directives
+
+ The Meter general-header field is used to:
+
+ - Negotiate the use of hit-metering and usage-limiting among
+ origin servers and proxy caches.
+
+ - Report use counts and reuse counts.
+
+ Implementation of the Meter header is optional for both proxies and
+ origin servers. However, any proxy that transmits the Meter header
+ in a request MUST implement every requirement of this specification,
+ without exception or amendment.
+
+ The Meter header MUST always be protected by a Connection header. A
+ proxy that does not implement the Meter header MUST NOT pass it
+ through to another system (see section 5.5 for how a non-caching
+ proxy may comply with this specification). If a Meter header is
+
+
+
+
+Mogul & Leach Standards Track [Page 20]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ received in a message whose version is less than HTTP/1.1, it MUST be
+ ignored (because it has clearly flowed through a proxy that does not
+ implement Meter).
+
+ A proxy that has received a response with a version less than
+ HTTP/1.1, and therefore from a server (or another proxy) that does
+ not implement the Meter header, SHOULD NOT send Meter request
+ directives to that server, because these would simply waste
+ bandwidth. This recommendation does not apply if the proxy is
+ currently hit-metering or usage-limiting any responses from that
+ server. If the proxy receives a HTTP/1.1 or higher response from
+ such a server, it should cease its suppression of the Meter
+ directives.
+
+ All proxies sending the Meter header MUST adhere to the "metering
+ subtree" design described in section 3.
+
+ Meter = "Meter" ":" 0#meter-directive
+
+ meter-directive = meter-request-directive
+ | meter-response-directive
+ | meter-report-directive
+
+ meter-request-directive =
+ "will-report-and-limit"
+ | "wont-report"
+ | "wont-limit"
+
+ meter-report-directive =
+ | "count" "=" 1*DIGIT "/" 1*DIGIT
+
+ meter-response-directive =
+ "max-uses" "=" 1*DIGIT
+ | "max-reuses" "=" 1*DIGIT
+ | "do-report"
+ | "dont-report"
+ | "timeout" "=" 1*DIGIT
+ | "wont-ask"
+
+ A meter-request-directive or meter-report-directive may only appear
+ in an HTTP request message. A meter-response-directive may only
+ appear in an HTTP response directive.
+
+ An empty Meter header in a request means "Meter: will-report-and-
+ limit". An empty Meter header in a response, or any other response
+ including one or more Meter headers without the "dont-report" or
+ "wont-ask" directive, implies "Meter: do-report".
+
+
+
+
+Mogul & Leach Standards Track [Page 21]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ The meaning of the meter-request-directives are as follows:
+
+ 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 neither to obey usage-limits nor to send usage
+ reports MUST NOT transmit a Meter header in the request.
+
+ The meaning of the meter-report-directives are as follows:
+
+ count "=" 1*DIGIT "/" 1*DIGIT
+ Both digit strings encode decimal integers. The
+ first integer indicates the count of uses of the
+ cache entry since the last report; the second integer
+ indicates the count of reuses of the entry.
+
+ Section 5.3 specifies the counting rules.
+
+ The meaning of the meter-response-directives are as follows:
+
+ max-uses "=" 1*DIGIT
+ sets an upper limit on the number of "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 "=" 1*DIGIT
+ sets an upper limit on the number of "reuses" of the
+ response for all proxies in the following subtree
+ taken together.
+
+ 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 "=" 1*DIGIT
+ sets a metering timeout of the specified number of
+ minutes (not seconds) after the origination of this
+ response (as indicated by its "Date" header). If the
+
+
+
+Mogul & Leach Standards Track [Page 22]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ 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. Timeouts should be
+ implemented with an accuracy of plus or minus one
+ minute. Implies "do-report".
+
+ wont-ask specifies that the proxy SHOULD NOT send any Meter
+ headers to the server. The proxy should forget this
+ advice after a period of no more than 24 hours.
+
+ Section 5.3 specifies the counting rules, and in particular specifies
+ a somewhat non-obvious interpretation of the max-uses value.
+
+5.2 Abbreviations for Meter directives
+
+ To allow for the most efficient possible encoding of Meter headers,
+ we define abbreviated forms of all Meter directives. These are
+ exactly semantically equivalent to their non-abbreviated
+ counterparts. All systems implementing the Meter header MUST
+ implement both the abbreviated and non-abbreviated forms.
+ Implementations SHOULD use the abbreviated forms in normal use.
+
+ The abbreviated forms of Meter directive are shown below, with the
+ corresponding non-abbreviated literals in the comments:
+
+ Abb-Meter = "Meter" ":" 0#abb-meter-directive
+
+ abb-meter-directive = abb-meter-request-directive
+ | abb-meter-response-directive
+ | abb-meter-report-directive
+
+ abb-meter-request-directive =
+ "w" ; "will-report-and-limit"
+ | "x" ; "wont-report"
+ | "y" ; "wont-limit"
+
+ abb-meter-report-directive =
+ | "c" "=" 1*DIGIT "/" 1*DIGIT ; "count"
+
+ abb-meter-response-directive =
+ "u" "=" 1*DIGIT ; "max-uses"
+ | "r" "=" 1*DIGIT ; "max-reuses"
+ | "d" ; "do-report"
+ | "e" ; "dont-report"
+ | "t" "=" 1*DIGIT ; "timeout"
+ | "n" ; "wont-ask"
+
+
+
+
+
+Mogul & Leach Standards Track [Page 23]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ Note: although the Abb-Meter BNF rule is defined separately from
+ the Meter rule, one may freely mix abbreviated and non-abbreviated
+ Meter directives in the same header.
+
+5.3 Counting rules
+
+ Note: please remember that hit-counts and usage-counts are
+ associated with individual responses, not with resources. A cache
+ entry that, over its lifetime, holds more than one response is
+ also not a "response", in this particular sense.
+
+ Let R be a cached response, and V be the value of the Request-URI and
+ selecting request-headers (if any, see section 14.43 of the HTTP/1.1
+ specification [4]) that would select R if contained in a request. We
+ define a "use" of R as occurring when the proxy returns its stored
+ copy of R in a response with any of the following status codes: a 200
+ (OK) status; a 203 (Non-Authoritative Information) status; or a 206
+ (Partial Content) status when the response contains byte #0 of the
+ entity (see section 5.4 for a discussion of Range requests).
+
+ Note: when a proxy forwards a client's request and receives a
+ response, the response that the proxy sends immediately to the
+ requesting client is not counted as a "use". I.e., the reported
+ count is the number of times the cache entry was used, and not the
+ number of times that the response was used.
+
+ We define a "reuse" of R as as occurring when the proxy responds to a
+ request selecting R with a 304 (Not Modified) status, unless that
+ request is a Range request that does not specify byte #0 of the
+ entity.
+
+5.3.1 Counting rules for hit-metering
+
+ A proxy participating in hit-metering for a cache response R
+ maintains two counters, CU and CR, associated with R. When a proxy
+ first stores R in its cache, it sets both CU and CR to 0 (zero).
+ When a subsequent client request results in a "use" of R, the proxy
+ increments CU. When a subsequent client request results in a "reuse"
+ of R, the proxy increments CR. When a subsequent client request
+ selecting R (i.e., including V) includes a "count" Meter directive,
+ the proxy increments CU and CR using the corresponding values in the
+ directive.
+
+ When the proxy sends a request selecting R (i.e., including V) to the
+ inbound server, it includes a "count" Meter directive with the
+ current CU and CR as the parameter values. If this request was
+ caused by the proxy's receipt of a request from a client, upon
+ receipt of the server's response, the proxy sets CU and CR to the
+
+
+
+Mogul & Leach Standards Track [Page 24]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ number of uses and reuses, respectively, that may have occurred while
+ the request was in progress. (These numbers are likely, but not
+ certain, to be zero.) If the proxy's request was a final HEAD-based
+ report, it need no longer maintain the CU and CR values, but it may
+ also set them to the number of intervening uses and reuses and retain
+ them.
+
+5.3.2 Counting rules for usage-limiting
+
+ A proxy participating in usage-limiting for a response R maintains
+ either or both of two counters TU and TR, as appropriate, for that
+ resource. TU and TR are incremented in just the same way as CU and
+ CR, respectively. However, TU is zeroed only upon receipt of a
+ "max-uses" Meter directive for that response (including the initial
+ receipt). Similarly, TR is zeroed only upon receipt of a "max-
+ reuses" Meter directive for that response.
+
+ A proxy participating in usage-limiting for a response R also stores
+ values MU and/or MR associated with R. When it receives a response
+ including only a max-uses value, it sets MU to that value and MR to
+ infinity. When it receives a response including only a max-reuses
+ value, it sets MR to that value and MU to infinity. When it receives
+ a response including both max-reuses and max-reuses values, it sets
+ MU and MR to those values, respectively. When it receives a
+ subsequent response including neither max-reuses nor max-reuses
+ values, it sets both MU and MR to infinity.
+
+ If a proxy participating in usage-limiting for a response R receives
+ a request that would cause a "use" of R, and TU >= MU, it MUST
+ forward the request to the server. If it receives a request that
+ would cause a "reuse" of R, and TR >= MR, it MUST forward the request
+ to the server. If (in either case) the proxy has already forwarded a
+ previous request to the server and is waiting for the response, it
+ should delay further handling of the new request until the response
+ arrives (or times out); it SHOULD NOT have two revalidation requests
+ pending at once that select the same response, unless these are Range
+ requests selecting different subranges.
+
+ There is a special case of this rule for the "max-uses" directive: if
+ the proxy receives a response with "max-uses=0" and does not forward
+ it to a requesting client, the proxy should set a flag PF associated
+ with R. If R is true, then when a request arrives while if TU >= MU,
+ if the PF flag is set, then the request need not be forwarded to the
+ server (provided that this is not required by other caching rules).
+ However, the PF flag MUST be cleared on any use of the response.
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 25]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ Note: the "PF" flag is so named because this feature is useful
+ only for caches that could issue a "prefetch" request before an
+ actual client request for the response. A proxy not implementing
+ prefetching need not implement the PF flag.
+
+5.3.3 Equivalent algorithms are allowed
+
+ Any other algorithm that exhibits the same external behavior (i.e.,
+ generates exactly the same requests from the proxy to the server) as
+ the one in this section is explicitly allowed.
+
+ Note: in most cases, TU will be equal to CU, and TR will be
+ equal to CR. The only two cases where they could differ are:
+
+ 1. The proxy issues a non-conditional request for the
+ resource using V, while TU and/or TR are non-zero, and
+ the server's response includes a new "max-uses" and/or
+ "max-reuses" directive (thus zeroing TU and/or TR, but
+ not CU and CR).
+
+ 2. The proxy issues a conditional request reporting the
+ hit-counts (and thus zeroing CU and CR, but not TU or
+ TR), but the server's response does not include a new
+ "max-uses" and/or "max-reuses" directive.
+
+ To solve the first case, the proxy has several implementation
+ options
+
+ - Always store TU and TR separately from CU and CR.
+
+ - Create "shadow" copies of TU and TR when this situation
+ arises (analogous to "copy on write").
+
+ - Generate a HEAD-based usage report when the
+ non-conditional request is sent (or when the
+ "max-uses=0" is received), causing CU and CR to be
+ zeroed (analogous in some ways to a "memory barrier"
+ instruction).
+
+ In the second case, the server implicitly has removed the
+ usage-limit(s) on the response (by setting MU and/or MR to
+ infinity), and so the fact that, say, TU is different from CU
+ is not significant.
+
+ Note: It may also be possible to eliminate the PF flag by
+ sending extra HEAD-based usage-report requests, but we
+ recommend against this; it is better to allocate an extra bit
+ per entry than to transmit extra requests.
+
+
+
+Mogul & Leach Standards Track [Page 26]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+5.4 Counting rules: interaction with Range requests
+
+
+ HTTP/1.1 allows a client to request sub-ranges of a resource. A
+ client might end up issuing several requests with the net effect of
+ receiving one copy of the resource. For uniformity of the results
+ seen by origin servers, proxies need to observe a rule for counting
+ these references, although it is not clear that one rule generates
+ accurate results in every case.
+
+ The rule established in this specification is that proxies count as a
+ "use" or "reuse" only those Range requests that result in the return
+ of byte #0 of the resource. The rationale for this rule is that in
+ almost every case, an end-client will retrieve the beginning of any
+ resource that it references at all, and that it will seldom retrieve
+ any portion more than once. Therefore, this rule appears to meet the
+ goal of a "best-efforts" approximation.
+
+5.5 Implementation by non-caching proxies
+
+ A non-caching proxy may participate in the metering subtree; this is
+ strongly recommended.
+
+ A non-caching proxy (HTTP/1.1 or higher) that participates in the
+ metering subtree SHOULD forward Meter headers on both requests and
+ responses, with the appropriate Connection headers.
+
+ If a non-caching proxy forwards Meter headers, it MUST comply with
+ these restrictions:
+
+ 1. If the proxy forwards Meter headers in responses, such a
+ response MUST NOT be returned to any request except the
+ one that elicited it.
+
+ 2. Once a non-caching proxy starts forwarding Meter headers,
+ it should not arbitrarily stop forwarding them (or else
+ reports may be lost).
+
+ A proxy that caches some responses and not others, for whatever
+ reason, may choose to implement the Meter header as a caching proxy
+ for the responses that it caches, and as a non-caching proxy for the
+ responses that it does not cache, as long as its external behavior
+ with respect to any particularly response is fully consistent with
+ this specification.
+
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 27]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+5.6 Implementation by cooperating caches
+
+ Several HTTP cache implementations, most notably the Harvest/Squid
+ cache [2], create cooperative arrangements between several caches.
+ If such caches use a protocol other than HTTP to communicate between
+ themselves, such as the Internet Cache Protocol (ICP) [12], and if
+ they implement the Meter header, then they MUST act to ensure that
+ their cooperation does not violate the intention of this
+ specification.
+
+ In particular, if one member of a group of cooperating caches agrees
+ with a server to hit-meter a particular response, and then passes
+ this response via a non-HTTP protocol to a second cache in the group,
+ the caches MUST ensure that the server which requested the metering
+ receives reports that appropriately account for any uses or resues
+ made by the second cache. Similarly, if the first cache agreed to
+ usage-limit the response, the total number of uses by the group of
+ caches MUST be limited to the agreed-upon number.
+
+6 Examples
+
+6.1 Example of a complete set of exchanges
+
+ This example shows how the protocol is intended to be used most of
+ the time: for hit-metering without usage-limiting. Entity bodies are
+ omitted.
+
+ A client sends request to a proxy:
+
+ GET http://foo.com/bar.html HTTP/1.1
+
+ The proxy forwards request to the origin server:
+
+ GET /bar.html HTTP/1.1
+ Host: foo.com
+ Connection: Meter
+
+ thus offering (implicitly) "will-report-and-limit".
+
+ The server responds to the proxy:
+
+ HTTP/1.1 200 OK
+ Date: Fri, 06 Dec 1996 18:44:29 GMT
+ Cache-control: max-age=3600
+ Connection: meter
+ Etag: "abcde"
+
+
+
+
+
+Mogul & Leach Standards Track [Page 28]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ thus (implicitly) requiring "do-report" (but not requiring
+ usage-limiting).
+
+ The proxy responds to the client:
+
+ HTTP/1.1 200 OK
+ Date: Fri, 06 Dec 1996 18:44:29 GMT
+ Etag: "abcde"
+ Cache-control: max-age=3600, proxy-mustcheck
+ Age: 1
+
+ Since the proxy does not know if its client is an end-system, or a
+ proxy that doesn't do metering, it adds the "proxy-mustcheck"
+ directive.
+
+ Another client soon asks for the resource:
+
+ GET http://foo.com/bar.html HTTP/1.1
+
+ and the proxy sends the same response as it sent to the other client,
+ except (perhaps) for the Age value.
+
+ After an hour has passed, a third client asks for the response:
+
+ GET http://foo.com/bar.html HTTP/1.1
+
+ But now the response's max-age has been exceeded, so the proxy
+ revalidates the response with the origin server:
+
+ GET /bar.html HTTP/1.1
+ If-None-Match: "abcde"
+ Host: foo.com
+ Connection: Meter
+ Meter: count=1/0
+
+ thus simultaneously fulfilling its duties to validate the response
+ and to report the one "use" that wasn't forwarded.
+
+ The origin server responds:
+
+ HTTP/1.1 304 Not Modified
+ Date: Fri, 06 Dec 1996 19:44:29 GMT
+ Cache-control: max-age=3600
+ Etag: "abcde"
+
+ so the proxy can use the original response to reply to the new
+ client; the proxy also zeros the use-count it associates with that
+ response.
+
+
+
+Mogul & Leach Standards Track [Page 29]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ Another client soon asks for the resource:
+
+ GET http://foo.com/bar.html HTTP/1.1
+
+ and the proxy sends the appropriate response.
+
+ After another few hours, the proxy decides to remove the cache entry.
+ When it does so, it sends to the origin server:
+
+ HEAD /bar.html HTTP/1.1
+ If-None-Match: "abcde"
+ Host: foo.com
+ Connection: Meter
+ Meter: count=1/0
+
+ reporting that one more use of the response was satisfied from the
+ cache.
+
+6.2 Protecting against HTTP/1.0 proxies
+
+ An origin server that does not want HTTP/1.0 caches to store the
+ response at all, and is willing to have HTTP/1.0 end-system clients
+ generate excess GETs (which will be forwarded by HTTP/1.0 proxies)
+ could send this for its reply:
+
+ HTTP/1.1 200 OK
+ Cache-control: max-age=3600
+ Connection: meter
+ Etag: "abcde"
+ Expires: Sun, 06 Nov 1994 08:49:37 GMT
+
+ HTTP/1.0 caches will see the ancient Expires header, but HTTP/1.1
+ caches will see the max-age directive and will ignore Expires.
+
+ Note: although most major HTTP/1.0 proxy implementations observe
+ the Expires header, it is possible that some are in use that do
+ not. Use of the Expires header to prevent caching by HTTP/1.0
+ proxies might not be entirely reliable.
+
+6.3 More elaborate examples
+
+ Here is a request from a proxy that is willing to hit-meter but is
+ not willing to usage-limit:
+
+ GET /bar.html HTTP/1.1
+ Host: foo.com
+ Connection: Meter
+ Meter: wont-limit
+
+
+
+Mogul & Leach Standards Track [Page 30]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ Here is a response from an origin server that does not want hit
+ counting, but does want "uses" limited to 3, and "reuses" limited to
+ 6:
+
+ HTTP/1.1 200 OK
+ Cache-control: max-age=3600
+ Connection: meter
+ Etag: "abcde"
+ Expires: Sun, 06 Nov 1994 08:49:37 GMT
+ Meter: max-uses=3, max-reuses=6, dont-report
+
+ Here is the same example with abbreviated Meter directive names:
+
+ HTTP/1.1 200 OK
+ Cache-control: max-age=3600
+ Connection: meter
+ Etag: "abcde"
+ Expires: Sun, 06 Nov 1994 08:49:37 GMT
+ Meter:u=3,r=6,e
+
+7 Interactions with content negotiation
+
+ This section describes two aspects of the interaction between hit-
+ metering and "content-negotiated" resources:
+
+ 1. treatment of responses carrying a Vary header (section
+ 7.1).
+
+ 2. treatment of responses that use the proposed Transparent
+ Content Negotiation mechanism (section 7.2).
+
+7.1 Treatment of responses carrying a Vary header
+
+ Separate counts should be kept for each combination of the headers
+ named in the Vary header for the Request-URI (what [4] calls "the
+ selecting request-headers"), even if they map to the same entity-tag.
+ This rule has the effect of counting hits on each variant, if there
+ are multiple variants of a page available.
+
+ Note: This interaction between Vary and the hit-counting
+ directives allows the origin server a lot of flexibility in
+ specifying how hits should be counted. In essence, the origin
+ server uses the Vary mechanism to divide the requests for a
+ resource into arbitrary categories, based on the request- headers.
+ (We will call these categories "request-patterns".) Since a proxy
+ keeps its hit-counts for each request-pattern, rather than for
+ each resource, the origin server can obtain separate statistics
+ for many aspects of an HTTP request.
+
+
+
+Mogul & Leach Standards Track [Page 31]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ For example, if a page varied based on the value of the User-Agent
+ header in the requests, then hit counts would be kept for each
+ different flavor of browser. But it is in fact more general than
+ that; because multiple header combinations can map to the same
+ variant, it also enables the origin server to count the number of
+ times (e.g.) the Swahili version of a page was requested, even though
+ it is only available in English.
+
+ If a proxy does not support the Vary mechanism, then [4] says that it
+ MUST NOT cache any response that carries a Vary header, and hence
+ need not implement any aspect of this hit-counting or usage-limiting
+ design for varying resources.
+
+ Note: this also implies that if a proxy supports the Vary
+ mechanism but is not willing to maintain independent hit-counts
+ for each variant response in its cache, then it must follow at
+ least one of these rules:
+
+ 1. It must not use the Meter header in a request to offer
+ to hit-meter or usage-limit responses.
+
+ 2. If it does offer to hit-meter or usage-limit responses,
+ and then receives a response that includes both a Vary
+ header and a Meter header with a directive that it
+ cannot satisfy, then the proxy must not cache the
+ response.
+
+ In other words, a proxy is allowed to partially implement the
+ Vary mechanism with respect to hit-metering, as long as this has
+ no externally visible effect on its ability to comply with the
+ Meter specification.
+
+ This approach works for counting almost any aspect of the request
+ stream, without embedding any specific list of countable aspects in
+ the specification or proxy implementation.
+
+7.2 Interaction with Transparent Content Negotiation
+
+ [A description of the interaction between this design and the
+ proposed Transparent Content Negotiation (TCN) design [6] will be
+ made available in a later document.]
+
+8 A Note on Capturing Referrals
+
+ It is alleged that some advertisers want to pay content providers,
+ not by the "hit", but by the "nibble" -- the number of people who
+ actually click on the ad to get more information.
+
+
+
+
+Mogul & Leach Standards Track [Page 32]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ Now, HTTP already has a mechanism for doing this: the "Referer"
+ header. However, perhaps it ought to be disabled for privacy reasons
+ -- according the HTTP/1.1 spec:
+
+ "Because the source of the link may be private information or may
+ reveal an otherwise private information source, it is strongly
+ recommended that the user be able to select whether or not the
+ Referer field is sent."
+
+ However, in the case of ads, the source of the link actually wants to
+ let the referred-to page know where the reference came from.
+
+ This does not require the addition of any extra mechanism, but rather
+ can use schemes that embed the referrer in the URI in a manner
+ similar to this:
+
+ http://www.blah.com/ad-reference?from=site1
+
+ Such a URI should point to a resource (perhaps a CGI script) which
+ returns a 302 redirect to the real page
+
+ http://www.blah.com/ad-reference.html
+
+ Proxies which do not cache 302s will cause one hit on the redirection
+ page per use, but the real page will get cached. Proxies which do
+ cache 302s and report hits on the cached 302s will behave optimally.
+
+ This approach has the advantage that it works whether or not the
+ end-client has disabled the use of Referer. Combined with the rest
+ of the hit-metering proposal in this design, this approach allows,
+ for example, an advertiser to know how often a reference to an
+ advertisement was made from a particular page.
+
+9 Alternative proposals
+
+ There might be a number of other ways of gathering demographic and
+ usage information; other mechanisms might respond to a different set
+ of needs than this proposal does. This proposal certainly does not
+ preclude the proposal or deployment of other such mechanisms, and
+ many of them may be complementary to and compatible with the
+ mechanism proposed here.
+
+ There has been some speculation that statistical sampling methods
+ might be used to gather reasonably accurate data. One such proposal
+ is to manipulate cache expiration times so that selected resources
+ are uncachable for carefully chosen periods, allowing servers to
+ accurately count accesses during those periods. The hit-metering
+ mechanism proposed here is entirely complementary to that approach,
+
+
+
+Mogul & Leach Standards Track [Page 33]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ since it could be used to reduce the cost of gathering those counts.
+ James Pitkow has written a paper comparing an earlier draft of this
+ hit-metering proposal with sampling approaches [9].
+
+ Phillip Hallam-Baker has proposed using a log-exchange protocol [5],
+ by which a server could request a proxy's logs by making an HTTP
+ request to the proxy. This proposal asserts that it is "believed to
+ operate correctly in configurations involving multiple proxies", but
+ it is not clear that this is true if an outer proxy is used as a
+ (one-way) firewall. The proposal also leaves a number of open
+ issues, such as how an origin server can be sure that all of the
+ proxies in the request subtree actually support log-exchange. It is
+ also not clear how this proposal couples a proxy's support of log-
+ exchange to a server's permission to cache a response.
+
+ For general background on the topic of Web measurement standards, see
+ the discussion by Thomas P. Novak and Donna L. Hoffman [8]. Also see
+ the "Privacy and Demographics Overview" page maintained by by the
+ World Wide Web Consortium [10], which includes a pointer to some
+ tentative proposals for gathering consumer demographics (not just
+ counting references) [3].
+
+10 Security Considerations
+
+ Which outbound clients should a server (proxy or origin) trust to
+ report hit counts? A malicious proxy could easily report a large
+ number of hits on some page, and thus perhaps cause a large payment
+ to a content provider from an advertiser. To help avoid this
+ possibility, a proxy may choose to only relay usage counts received
+ from its outbound proxies to its inbound servers when the proxies
+ have authenticated themselves using Proxy-Authorization and/or they
+ are on a list of approved proxies.
+
+ It is not possible to enforce usage limits if a proxy is willing to
+ cheat (i.e., it offers to limit usage but then ignores a server's
+ Meter directive).
+
+ Regarding privacy: it appears that the design in this document does
+ not reveal any more information about individual users than would
+ already be revealed by implementation of the existing HTTP/1.1
+ support for "Cache-control: max-age=0, proxy-revalidate" or "Cache-
+ control: s-maxage=0". It may, in fact, help to conceal certain
+ aspects of the organizational structure on the outbound side of a
+ proxy. In any case, the conflict between user requirements for
+ anonymity and origin server requirements for demographic information
+ cannot be resolved by purely technical means.
+
+
+
+
+
+Mogul & Leach Standards Track [Page 34]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+11 Acknowledgments
+
+ We gratefully acknowledge the constructive comments received from
+ Anselm Baird-Smith, Ted Hardie, Koen Holtman (who suggested the
+ technique described in section 8), Dave Kristol, Ari Luotonen,
+ Patrick R. McManus, Ingrid Melve, and James Pitkow.
+
+12 References
+
+ 1. Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ 2. Anwat Chankhunthod, Peter B. Danzig, Chuck Neerdaels, Michael
+ F. Schwartz, and Kurt J. Worrell. A Hierarchical Internet Object
+ Cache. Proc. 1996 USENIX Technical Conf., San Diego, January,
+ 1996, pp. 153-163.
+
+ 3. Daniel W. Connolly. Proposals for Gathering Consumer
+ Demographics.
+ http://www.w3.org/pub/WWW/Demographics/Proposals.html.
+
+ 4. Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
+ Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1," RFC 2068,
+ January, 1997.
+
+ 5. Phillip M. Hallam-Baker. Notification for Proxy Caches. W3C
+ Working Draft WD-proxy-960221, World Wide Web Consortium,
+ February, 1996. http://www.w3.org/pub/WWW/TR/WD-proxy.html.
+
+ 6. Holtman, K., and A. Mutz, "Transparent Content Negotiation in
+ HTTP", Work in Progress.
+
+ 7. Mogul, J., "Forcing HTTP/1.1 proxies to revalidate responses",
+ Work in Progress.
+
+ 8. Thomas P. Novak and Donna L. Hoffman. New Metrics for New Media:
+ Toward the Development of Web Measurement Standards. This is a
+ draft paper, currently available at http://
+ www2000.ogsm.vanderbilt.edu/novak/web.standards/webstand.html.
+ Cited by permission of the author; do not quote or cite without
+ permission.
+
+ 9. James Pitkow. In search of reliable usage data on the WWW.
+ Proc. Sixth International World Wide Web Conference, Santa Clara,
+ CA, April, 1997.
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 35]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+ 10. Joseph Reagle, Rohit Khare, Dan Connolly, and Tim Berners-Lee.
+ Privacy and Demographics Overview.
+ http://www.w3.org/pub/WWW/Demographics/.
+
+ 11. Linda Tauscher and Saul Greenberg. Revisitation Patterns in
+ World Wide Web Navigation. Research Report 96/587/07, Department
+ of Computer Science, University of Calgary, March, 1996.
+ http://www.cpsc.ucalgary.ca/projects/grouplab/
+ papers/96WebReuse/TechReport96.html.
+
+ 12. Wessels, D., and K. Claffy "Internet Cache Protocol (ICP),
+ version 2", RFC 2186, September 1997.
+
+13 Authors' Addresses
+
+ Jeffrey C. Mogul
+ Western Research Laboratory
+ Digital Equipment Corporation
+ 250 University Avenue
+ Palo Alto, California, 94305, U.S.A.
+
+ EMail: mogul@wrl.dec.com
+ Phone: 1 415 617 3304 (email preferred)
+
+
+ Paul J. Leach
+ Microsoft
+ 1 Microsoft Way
+ Redmond, Washington, 98052, U.S.A.
+
+ EMail: paulle@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 36]
+
+RFC 2227 Hit-Metering and Usage-Limiting October 1997
+
+
+14 Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implmentation may be prepared, copied, published
+ andand distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mogul & Leach Standards Track [Page 37]
+