rfc2227.txt

RFC 的详细文档！

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