rfc2227.txt

中、英文RFC文档大全打包下载完全版 .

   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