rfc2227.txt

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

                   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