rfc2227.txt

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

                   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.