Network Working Group J. Mogul
Request for Comments: 2227 DECWRL
Category: Standards Track P. Leach
Microsoft
October 1997
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
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
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."
本文档建议对HTTP进行一个简单的扩展，使用一个新的“Meter”头，它允许缓存以比当前使用的“缓存破坏”技术更有效的方式向源服务器报告有限形式的人口统计信息（俗称“命中数”）。它还允许源服务器控制缓存使用缓存响应的次数，并概述了源服务器可用于捕获引用信息而无需“缓存破坏”的技术
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
1引言2 1.1目标、非目标和限制3 1.2设计概述4 1.3术语5 2概述5 2.1讨论7 3设计概念8 3.1“计量子树”的实施8 3.2仪表标题格式10 3.3命中计量和使用限制的协商10 3.4使用报告的传输14 3.5何时发送使用报告15 3.6使用限制的细分16
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
4分析17 4.1计算用户的近似精度18 4.2“网络计算机”呢？19 4.3关键路径延迟分析19 5规范20 5.1仪表头规范和指令20 5.2仪表指令的缩写23 5.3计数规则24 5.3.1命中计数的计数规则24 5.3.2使用限制的计数规则25 5.3.3允许使用等效算法26 5.4计数规则：与范围的交互请求27 5.5通过非缓存代理实现27 5.6通过协作缓存实现28 6示例28 6.1完整交换集的示例28 6.2针对HTTP/1.0代理的保护30 6.3更详细的示例30 7与内容协商的交互31 7.1处理带有不同标头的响应31 7.2交互透明内容协商32 8关于获取转介的说明32 9备选方案33 10安全考虑34 11确认35 12参考35 13作者地址36 14完整版权声明37
1 Introduction
1导言
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
该提案支持一种类似于纸质出版物出版商的模式：此类出版商（试图）向广告商报告有多少人至少阅读一期出版物；他们不会（试图）报告读者重读一期文章的次数。他们通过计算出版的拷贝数来实现这一点，然后试图估计，对于他们的出版物，平均有多少人阅读了一本书
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.
单个副本至少一次。关键是结果并不精确，但仍然有用。另一种模式是对查询进行编码，这样广告客户就可以知道是哪种出版物产生了查询。
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.
HTTP/1.1已经允许源服务器阻止缓存响应，并且有证据表明[9]至少在某些时候，这样做的唯一目的是收集特定页面的访问次数。其中一些证据是从代理痕迹的研究中推断出来的；有些是基于网络服务器运营商意图的明确声明。以这种方式收集的信息可能对收集信息的人有实际用途，也可能没有实际用途；事实上，他们想收集，或者已经收集了。
The goal of this proposal is to provide an optional performance optimization for this use of HTTP/1.1.
本提案的目标是为这种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.
- 仅仅是性能优化：它不提供HTTP/1.1中没有的信息或功能。其目的是提高整体性能，并减少几乎所有交互的延迟；对于一小部分HTTP交互，延迟可能会增加。
- 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.
- 在隐私方面中立：它不会向服务器透露关于客户端的任何信息，而这些信息是通过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.
- 解决了通过代理有效获取有关请求的广泛信息的整个问题。
- 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.
这些潜在的限制在实际操作中可能不是问题。
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.
该设计向HTTP添加了一个新的“Meter”头；头始终受“连接”头的保护，因此总是逐跳保护。此机制允许构建“计量子树”，它是代理的连接子树，根在源服务器上。只有那些明确自愿加入资源的计量子树的代理才能参与命中计量，但是那些自愿加入的代理需要尽最大努力提供准确的计数。当在计量子树外部转发命中计量响应时，转发代理添加“缓存控制：s-maxage=0”，以便强制其他代理（计量子树外部）将所有请求转发到计量子树中的服务器。
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].
注意：HTTP/1.1规范目前没有定义“s-maxage”缓存控制指令。HTTP工作组已决定将该指令添加到HTTP/1.1规范的下一版本中[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.
仪表标头携带零个或多个指令，类似于缓存控制标头携带指令的方式。代理可以使用某些仪表指令自愿为资源执行命中计量。如果代理确实是自愿的，服务器可能会使用某些指令来要求按命中率计量响应。最后，代理使用“count”Meter指令来报告累积的命中计数。
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.
在重新验证缓存响应之前，服务器还可以使用Meter机制来限制缓存对缓存响应的使用次数。
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.
完整规范包括计算响应的“使用”（例如，非条件GET）和“重用”（条件GET）的完整规则。这些规则确保结果在所有情况下都是完全一致的，除非系统或网络出现故障。
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.
本文档使用HTTP/1.1规范[4]中定义和解释的术语，包括“源服务器”、“资源”、“逐跳”、“无条件获取”和“条件获取”。读者应熟悉HTTP/1.1规范及其术语。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”、“可能”和“可选”应按照RFC 2119[1]中的说明进行解释。
2 Overview
2概述
The design described in this document introduces several new features to HTTP:
本文档中描述的设计为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.
- 使用限制：允许源服务器在与源服务器重新验证之前，控制代理缓存或代理缓存层次结构使用缓存响应的次数。
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).
这些新的非强制性功能需要最少的新协议支持，协议版本没有变化，消息头的开销相对较小。该设计不会在任何直接影响用户感知延迟的关键路径中增加额外的网络往返（有关分析，请参阅第4.3节）。
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.
命中计数和使用限制的主要目标是避免源服务器需要发送“Cache control:s-maxage=0”以及对其值不可能立即更改的资源的响应。换句话说，在代理缓存项可能满足的每个请求上联系源服务器的唯一原因是允许服务器收集人口统计信息或控制缓存项的使用次数的情况下，这里建议的扩展将避免大量不必要的网络流量和延迟。
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.
该设计引入了一个新的“Meter”报头，用于HTTP请求消息和HTTP响应消息。仪表表头用于传输大量指令和报告。特别是，所有关于命中计量和使用限制的协商都是使用此标头完成的。本文件中未提出对现有HTTP/1.1规范[4]的其他更改。
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.
1. 缓存项的“使用”概念，即代理返回其实体实体以响应条件或非条件请求，以及缓存项的“重用”概念，即代理返回304（未修改）响应以满足该缓存项的条件请求。
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.
2. 按命中率计费的资源的概念，对于该资源，代理缓存尽最大努力向源服务器报告使用和/或重用的准确计数。
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.
3. 使用受限资源的概念，对于该资源，源服务器期望代理缓存限制使用和/或重用的数量。
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.
新的仪表指令和报告相互作用，允许代理缓存和服务器在收集人口统计数据时进行协作。目标是尽最大努力近似真实的使用和/或重用次数，而不是保证精确的计数。
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.
新的Meter指令还允许服务器通过限制报告之间的使用次数来限制特定命中计数的不精确性。例如，它还可以绑定由于缓存而显示相同广告的次数。
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.
第7.1节描述了一种使用服务器驱动的内容协商（Vary头）的方法，该方法允许HTTP源服务器灵活地将请求划分为多个类别，并按类别对请求进行计数。这种分类命中计数的实现可能是对Vary的大多数实现的一个非常小的修改；有些实现可能根本不需要任何修改。
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.
将此映射到发布模型上，代理缓存将为缓存项的每个无条件GET增加一次使用计数，并为每个条件GET增加一次使用计数，这将导致发送项的副本以更新客户端的无效缓存副本。304中的结果（未修改）的条件获取不包括在使用计数中，因为它们不会导致新用户看到该页面，而是表示以前看到过该页面的用户重复查看。然而，304个响应被计入重用计数中。人头根本不算在内，因为他们的回答不包含实体体。
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.
Meter指令仅适用于共享代理缓存，而不适用于终端客户端（或其他单用户）缓存。单用户缓存不应使用Meter，因为它们的命中率将自动计算为它们第一次从源服务器或代理缓存获取页面时使用的无条件GET的结果。它们随后的条件get不会导致新用户看到该页面。
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.
此处指定的机制计数；其他方法要么不生成供用户读取的页面，要么不缓存，要么“写入”，因此可以由源服务器直接计数。（如果将来出现了一个“可缓存的POST”，即POST请求中的实体体被用于选择缓存响应，那么这些POST将不得不像GET一样处理。）命中计量对将来可能定义的任何新HTTP方法的适用性目前无法确定。
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.
在路径上有多个缓存的情况下，当代理缓存从另一个缓存接收到请求中的使用计数或重用计数时，代理缓存会进行明显的求和。
3 Design concepts
3设计概念
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.
此子树叶上的代理将插入一个“Cache control:s-maxage=0”指令，该指令强制所有其他代理（在此子树下）在每次请求时使用计量子树的叶进行检查。但是，如果重新验证成功，则不会阻止它们存储和使用响应。
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.
命中计量/使用限制机制旨在避免任何客户端请求的关键路径中出现任何额外的网络往返，并（尽可能）避免过度延长HTTP消息。
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.
仪表表头的正式规范见第5节；以下讨论使用非正式方法来提高清晰度。
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:
“计量子树”方法以一种简单、直接的方式实现，方法是将新的“计量”头定义为在每个请求或响应中必须始终受到连接头保护的头。即，如果HTTP消息中存在仪表头，则该消息：
1. MUST contain "Connection: meter", and MUST be handled according to the HTTP/1.1 specification of the Connection header.
1. 必须包含“Connection:meter”，并且必须根据连接头的HTTP/1.1规范进行处理。
2. MUST NOT be sent in response to a request from a client whose version number is less than HTTP/1.1.
2. 不得在响应来自版本号小于HTTP/1.1的客户端的请求时发送。
3. MUST NOT be accepted from a client whose version number is less than HTTP/1.1.
3. 不能从版本号小于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.
后两个限制的原因是为了防止代理可能无法正确实现连接头。否则，包含HTTP/1.0代理的子树可能会错误地显示为计量子树。
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.
注意：要使连接头机制正常工作，接收包含连接头的HTTP/1.0（或更低版本）消息的系统必须将此头及其保护的所有头从消息中通过中间代理删除。
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.
尽管RFC2068没有明确要求这种行为，但它似乎是隐含的。否则，就不能依赖于声明的属性（第14.10节），即受保护的选项“不得由代理通过进一步的连接进行通信”。这可能应该在HTTP/1.1规范的后续草案中予以澄清。
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.
当代理将按命中计数或使用限制的响应转发给不在计数子树中的客户端（代理或最终客户端）时，它必须省略计数头，并且必须在响应中添加“缓存控制：s-maxage=0”。
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).
仪表表头用于携带零个或多个指令。HTTP消息中可能会出现多个仪表头，但根据HTTP/1.1规范[4]第4.2节中的规则，它们可以组合成一个单独的头（并且应该这样组合，以减少开销）。
For example, the following sequence of Meter headers
例如，下面的仪表标题序列
Meter: max-uses=3
Meter: max-reuses=10
Meter: do-report
Meter: max-uses=3
Meter: max-reuses=10
Meter: do-report
may be expressed as
可表示为
Meter: max-uses=3, max-reuses=10, do-report
Meter: max-uses=3, max-reuses=10, do-report
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).
如果源服务器希望通过简单地强制所有请求绕过任何代理缓存来收集资源的命中计数，则会使用“缓存控制：s-maxage=0”响应资源上的请求。（希望防止HTTP/1.0代理不正确地缓存响应的源服务器还可以发送“Expires:<now>”以防止此类缓存，以及“Cache control:max age=NNNN”以允许较新的代理缓存响应）。
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.
计量头的目的是避免在计量子树中需要“缓存控制：s-maxage=0”。因此，任何代理都可以与下一跳服务器协商命中计量和/或使用限制的使用。如果此服务器是源服务器，或者已经是计量子树的一部分（根于源服务器），则它可以完成协商，从而扩展计量子树以包括新代理。
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.
will report and limit表示代理愿意并且能够返回使用情况报告，并且将遵守任何使用限制。
wont-report indicates that the proxy will obey usage-limits but will not send usage reports.
wont report表示代理将遵守使用限制，但不会发送使用情况报告。
wont-limit indicates that the proxy will not obey usage-limits but will send usage reports.
wont limit表示代理将不遵守使用限制，但将发送使用情况报告。
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
相当于“Meter:will report and limit”，因此，根据连接头的定义（参见HTTP/1.1规范[4]第14.10节），包含
Connection: Meter
连接：仪表
and no explicit Meter header is equivalent to a request that contains
并且没有显式的Meter头相当于包含
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.
do report指定代理必须向服务器发送使用情况报告。
dont-report specifies that the proxy SHOULD NOT send usage reports to the server.
dont report指定代理不应向服务器发送使用情况报告。
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".
timeout=NNN为报告命中计数设置计量超时NNN分钟，从发起此响应的时间算起。如果代理在超时过期时对此响应具有非零命中计数，则它必须在该时间或之前向服务器发送报告。暗示“做报告”。
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.
根据定义，响应中的空仪表标题或不包含“Don report”的任何仪表标题表示“Meter:do report”；这使得普通案例更有效。
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.
如果源服务器只是在资源的每个响应中发送一个恒定的计量超时T，那么它收到的报告将反映持续时间在T和N*T之间（在最坏的情况下）的一段时间内的活动，其中N是计量子树的最大深度。
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 uses=NNN为以下子树中的所有代理设置响应的NNN“uses”上限，不计算其立即转发到请求端客户端的次数。
max-reuses=NNN sets an upper limit of NNN "reuses" of the response for all proxies in the following subtree taken together.
max reuses=NNN为以下子树中的所有代理设置响应的NNN“reuses”上限。
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.)
当代理已耗尽其对缓存项的“使用”或“重用”分配时，它必须在响应中返回缓存项之前重新验证缓存项（使用条件请求）。（如果请求了使用情况报告，则代理应使用此重新验证消息发送使用情况报告，并且是时候发送了。请参见第3.4节和第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.
请注意，max uses指令设置的“uses”限制不包括使用响应来满足导致代理向服务器发出请求的最终客户端请求。此计数规则支持缓存启动预取的概念：缓存可以发出预取请求，接收max uses=0响应，存储该响应，然后在客户端对资源发出实际请求时返回该响应（无需重新验证）。但是，每个这样的响应最多可以以这种方式使用一次，因此源服务器对实际使用的数量保持精确控制。
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.
服务器不得发送需要代理来执行其尚未提供的操作的仪表头。一个代理收到一个仪表响应指令，要求代理做它不愿意做的事情，应该忽略该指令。
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".)
在响应中接收仪表头的代理必须服从它，或者必须在每次访问时重新验证相应的缓存项。（即，如果它选择不遵守响应中的仪表标题，则其行为必须与响应包含“缓存控制：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.
注意：在给定资源的请求中没有发送仪表头，因此在响应中没有自愿遵守仪表指令的代理不需要遵守这些指令。在这种情况下，如果服务器在响应中确实发送了仪表头，则这是一个协议错误。然而，基于健壮性原则，代理可能会选择在转发响应时将仪表头解释为包含“缓存控制：s-maxage=0”的隐式请求，因为这保留了服务器的明显意图。
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.)
在请求中接收仪表头的代理可以忽略仪表头，但忽略的程度必须与它对下一跳服务器的职责一致。如果收到的仪表请求标头与该职责不一致，或者如果没有收到仪表请求标头，并且来自下一跳服务器的响应请求任何形式的计量或限制，则代理必须将“缓存控制：s-maxage=0”添加到它为该请求转发的任何响应中。（代理不应添加或更改Expires标头或max age Cache control指令。）
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.
例如，如果代理A从代理B接收到一个GET请求，请求URL X带有“Connection:Meter”，但代理A对URL的缓存响应不包括任何Meter指令，那么代理A可能会忽略代理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.
但是，如果代理A之前告诉源服务器“Meter:wont limit”（意味着将报告），并且缓存的响应包含“Meter:do report”，代理B的请求包含“Meter:wont report”，那么代理B的报价与代理A对源服务器的义务不一致。因此，在这种情况下，当代理A向代理B返回缓存响应时，必须添加“缓存控制：s-maxage=0”，并且在该响应中不得包含仪表头。
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.
wont ask建议代理不向该服务器发送任何仪表指令。
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".)
代理应该记住这个事实长达24小时。对于不希望使用或不支持仪表表头的服务器，这实际上避免了所有不必要的开销。（本指令还暗示“不报告”。）
To transmit a usage report, a proxy sends the following Meter header in a request on the appropriate resource:
要传输使用情况报告，代理在相应资源的请求中发送以下仪表标头：
Meter: count=NNN/MMM
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.)
第一个整数表示自上次报告以来缓存项的使用次数；第二个整数表示条目的重用次数（有关使用次数和重用次数的计数规则，请参见第5.3节）。在没有其他仪表指令的请求中传输“count”指令也被定义为隐式传输“will report and limit”指令，以优化常见情况。（不愿意遵守使用限制的代理将为其报告发送“Meter:count=NNN/MMM，wont limit”。）
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.
代理不应传输“Meter:count=0/0”，因为这不会传递任何有用的信息。
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.
使用情况报告必须始终作为条件请求（如GET或HEAD）的一部分传输，因为原始服务器需要条件标头中的信息（例如，如果自修改或如果不匹配）才能知道正在统计资源的哪个实例。在计量子树上的Proxys转发使用情况报告不得更改条件标头的内容，否则将导致不正确的计数。
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.
使用情况报告不得作为转发请求的一部分传输，该转发请求在If None Match或If Match标头中包含多个实体标记。
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.
注意：一个愿意进行命中计量（报告使用）的代理必须计算使用和重用。不可能就其中一个而不是另一个的报告进行谈判。
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).
1. 当它代表一个客户端转发资源实例上的条件GET时（如果GET最多有一个实体标记作为条件）。
2. When it forwards a conditional HEAD on the resource instance on behalf of one of its clients.
2. 当它代表一个客户端转发资源实例上的条件头时。
3. When it must generate a conditional GET to satisfy a client request because the max-uses limit has been exceeded.
3. 它必须生成条件GET以满足客户端请求，因为已超过最大使用限制。
4. Upon expiration of a metering timeout associated with a cache entry that has a non-zero hit-count.
4. 与具有非零命中计数的缓存项关联的计量超时到期时。
5. When it removes the corresponding non-zero hit-count entry from its storage for any reason including:
5. 当它出于任何原因从其存储器中删除相应的非零命中计数项时，包括：
- 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.)
（第5.3节解释了命中计数如何变为零或非零。）
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.
- 代理必须将报告作为资源实例上的条件HEAD请求的一部分发送。
- 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.
- 如果HEAD请求失败，则不需要代理重试该请求（这是一种尽力而为的设计）。但是，为了提高准确性，代理应根据资源限制重试失败的HEAD请求。
- 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.
如果由于也带有“count”指令的到达请求而发送使用计数，则代理必须将其自身（可能为零）的使用和重用计数与到达计数相结合，然后尝试转发请求。
However, the proxy is not required to forward an arriving request with a "count" directive, provided that:
但是，代理不需要转发带有“count”指令的到达请求，前提是：
- it can reply to the request using a cached response, in compliance with other requirements of the HTTP specification.
- 它可以根据HTTP规范的其他要求，使用缓存响应来响应请求。
- 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.)
如果到达的请求带有“count”指令，并且代理不再具有资源的缓存项，则代理必须转发“count”指令。（在任何情况下，对于收到的任何有效请求，没有合适缓存项的代理通常都会这样做。）
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
例如，考虑两个代理P1和P2的情况，每个代理使用代理P3作为到达源服务器的方式。
Meter: max-uses=10
仪表：最大使用=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.
代理使用该响应来满足当前请求的终端客户端。本例中的max uses指令允许P1、P2和P3组合在一起，以满足资源的10个额外终端客户端使用（无条件GET）。
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
本规范不限制P3如何在自身和其他代理之间分配该分配。例如，P3可以为自己保留所有最大使用分配。在这种情况下，它将使用
Meter: max-uses=0
仪表：最大使用=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
P3还可以在P1和P2之间平均分配分配，不为自己保留任何分配（如果P3很少或没有其他客户端，这可能是正确的选择）。在这种情况下，它可以发送
Meter: max-uses=5
仪表：最大使用量=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.
发送给发出初始请求的代理（P1或P2），然后在一些内部数据结构中记录它“欠”另一个代理剩余的分配。
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.
请注意，选择max uses值的自由也适用于源服务器。不要求源服务器向所有缓存发送相同的max uses值。例如，第一次从缓存中听到消息时发送“max uses=2”，然后每次从该缓存中获取“use count”时将该值加倍（达到某个最大限制）可能是有意义的。其思想是，缓存使用其最大使用配额的速度越快，就越有可能在删除缓存项之前报告使用计数值。此外，高和频繁使用计数意味着允许缓存带来了相应的高效率好处。
Again, the details of such heuristics would be outside the scope of this specification.
同样，此类启发法的细节将超出本规范的范围。
4 Analysis
4分析
This section includes informal analyses of several aspects of hit-metering:
本节包括对命中计量几个方面的非正式分析：
1. the accuracy of results when applied to counting users (section 4.1).
1. 计算用户时结果的准确性（第4.1节）。
2. the problem of counting users whose browsers do not include caches, such as Network Computers (section 4.2).
2. 计算浏览器不包含缓存的用户的问题，如网络计算机（第4.2节）。
3. delays imposed on "critical paths" for HTTP operations (section 4.3).
3. 对HTTP操作的“关键路径”施加的延迟（第4.3节）。
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.
几乎所有的Web用户都使用维护本地缓存的客户端软件，而本地缓存技术的最先进水平是相当有效的。（第4.2节讨论了终端客户端缓存很小或不存在的情况。）因此，假设有一个有效且持久的终端客户端缓存，检索实体的每个用户只执行一个GET请求，该请求会导致200或203响应，或包含实体第一个字节的206响应。如果代理缓存维护并报告此类检索的准确使用计数，则其报告的使用计数将接近已检索实体的不同用户数。
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.
浏览器日志分析表明，当用户重新访问资源时，几乎总是在上次访问之后很快完成，几乎总是使用少于八个中间引用[11]。虽然这个结果可能不会普遍适用，但它意味着几乎所有的重用都会在最终客户机缓存中命中，并且不会被代理缓存视为无条件的GET。
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
现有（HTTP/1.0）“缓存破坏”机制用于计算不同用户的数量，这肯定会高估代理背后的用户数量，因为如果没有使用缓存破坏，它无法提供可靠的方法来区分用户的初始请求和可能是条件GET的后续重复请求。这个
"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.
HTTP/1.1的“缓存控制：s-maxage=0”功能允许分离使用计数和重用计数，前提是没有HTTP/1.0代理缓存介入。
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].
请注意，如果对给定资源集的命中计数结果的有效性有疑问，服务器可以在短时间内采用缓存破坏技术，以建立用于验证命中计数结果的基线。James Pitkow[9]在一篇论文中讨论了解决这个问题的各种方法。
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.
第4.1节中的分析假设“几乎所有Web用户”都有客户端缓存。然而，如果网络计算机（NC）模型变得流行，那么这种假设可能是错误的：大多数提出的网络计算机没有磁盘存储，RAM相对较少。许多个人数字助理（PDA）有时可以访问网络，但也有类似的限制。这样的客户机系统可能很少或根本不缓存HTTP响应。这意味着单个用户可能会生成许多无条件get，这些get从代理缓存中产生相同的响应。
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".
首先请注意，本文档中的命中计数设计，即使使用此类客户端，提供的近似值也不比未修改的HTTP/1.1差：如果服务器仅指定，则代理返回到源服务器的计数将准确表示代理转发到服务器的请求数“缓存控制：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.
然而，可以通过在代理服务器上使用一些启发式方法来提高这些命中计数的准确性。例如，代理可能会记录客户机的IP地址，并且每个响应中每个客户机地址只计算一个GET。这并不完美：例如，它无法区分NCs和某些其他类型的主机。代理还可以使用启发式方法，即只有那些从不发送条件GET的客户端才应该这样处理，尽管我们根本不确定NCs是否永远不会发送条件GET。
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.
由于此问题的解决方案似乎需要基于NCs的实际行为的启发式（或者可能是允许明确检测无缓存客户端的新HTTP协议功能），因此指定解决方案似乎为时过早。
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
在存在延迟问题的系统（如Web）中，通常会有一个相互依赖的步骤树，这样，在所有之前的步骤都完成之前，无法完成最终结果。因为树结构允许一些
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.
如果将Web请求的最终结果视为在浏览器上呈现页面，或以其他方式对请求的结果进行操作，则某些网络往返（例如，如果连接不存在，则交换TCP SYN数据包）显然位于关键路径上。这种命中计数设计确实在删除缓存项时添加了一些用于报告非零计数的往返，但是，根据设计，这些往返都脱离了任何关键路径：它们可以与任何其他操作并行完成，并且只需要“尽最大努力”，因此代理不必序列化其他操作的成功或失败。
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规格
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
仪表头必须始终由连接头保护。未实现计量头的代理不得将其传递给其他系统（非缓存代理如何符合本规范，请参见第5.5节）。如果仪表标题为
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).
在版本低于HTTP/1.1的消息中接收，必须忽略该消息（因为它显然已通过未实现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.
如果代理收到的响应版本低于HTTP/1.1，因此来自未实现计量头的服务器（或其他代理），则不应向该服务器发送计量请求指令，因为这只会浪费带宽。如果代理当前命中计数或使用限制来自该服务器的任何响应，则此建议不适用。如果代理从这样的服务器接收到HTTP/1.1或更高版本的响应，它应该停止对Meter指令的抑制。
All proxies sending the Meter header MUST adhere to the "metering subtree" design described in section 3.
发送仪表表头的所有代理必须遵守第3节中所述的“计量子树”设计。
Meter = "Meter" ":" 0#meter-directive
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-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"
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.
仪表请求指令或仪表报告指令只能出现在HTTP请求消息中。仪表响应指令只能出现在HTTP响应指令中。
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".
请求中的空仪表标题表示“仪表：将报告和限制”。响应中的空仪表标题，或任何其他响应，包括一个或多个不带“Don report”或“wont ask”指令的仪表标题，意味着“Meter:do report”。
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.
will report and limit表示代理愿意并且能够返回使用情况报告，并且将遵守任何使用限制。
wont-report indicates that the proxy will obey usage-limits but will not send usage reports.
wont report表示代理将遵守使用限制，但不会发送使用情况报告。
wont-limit indicates that the proxy will not obey usage-limits but will send usage reports.
wont limit表示代理将不遵守使用限制，但将发送使用情况报告。
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.
计数“=”1*位“/”1*位两个数字字符串都对十进制整数进行编码。第一个整数表示自上次报告以来缓存项的使用次数；第二个整数表示条目的重用次数。
Section 5.3 specifies the counting rules.
第5.3节规定了计数规则。
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 uses“=”1*位设置响应“使用”次数的上限，不包括以下子树中所有代理的立即转发到请求端客户端的次数。
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.
max reuses“=”1*位设置了以下子树中所有代理响应的“reuses”数量上限。
do-report specifies that the proxy MUST send usage reports to the server.
do report指定代理必须向服务器发送使用情况报告。
dont-report specifies that the proxy SHOULD NOT send usage reports to the server.
dont report指定代理不应向服务器发送使用情况报告。
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
timeout“=”1*位设置发出此响应后指定分钟数（而非秒数）的计量超时（由其“日期”标题指示）。如果
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.
wont ask指定代理不应向服务器发送任何仪表头。代理人应在不超过24小时后忘记此通知。
Section 5.3 specifies the counting rules, and in particular specifies a somewhat non-obvious interpretation of the max-uses value.
第5.3节规定了计数规则，特别是规定了对max uses值的不明显解释。
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 = "Meter" ":" 0#abb-meter-directive
abb-meter-directive = abb-meter-request-directive | abb-meter-response-directive | abb-meter-report-directive
abb仪表指令=abb仪表请求指令| abb仪表响应指令| abb仪表报告指令
abb-meter-request-directive = "w" ; "will-report-and-limit" | "x" ; "wont-report" | "y" ; "wont-limit"
abb仪表请求指令=“w”；“将报告并限制”|“x”；“不会报告”|“y”；“不会限制”
abb-meter-report-directive =
| "c" "=" 1*DIGIT "/" 1*DIGIT ; "count"
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"
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"
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.
注：尽管Abb Meter BNF规则与Meter规则分开定义，但可以在同一标题中自由混合使用缩写和非缩写的Meter指令。
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).
设R为缓存响应，V为请求URI的值，并选择请求头（如果有，请参阅HTTP/1.1规范[4]第14.43节），如果请求中包含R，则选择请求头。我们将R的“使用”定义为当代理在响应中返回其存储的R副本时，使用以下任何状态代码：200（OK）状态；203（非权威信息）状态；或者当响应包含实体的字节#0时的206（部分内容）状态（有关范围请求的讨论，请参见第5.4节）。
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.
我们将R的“重用”定义为当代理以304（未修改）状态响应选择R的请求时发生，除非该请求是未指定实体字节0的范围请求。
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.
参与缓存响应R的命中计数的代理维护两个与R相关的计数器CU和CR。当代理首先在其缓存中存储R时，它将CU和CR都设置为0（零）。当后续客户端请求导致“使用”R时，代理将增加CU。当后续客户端请求导致R的“重用”时，代理增加CR。当选择R（即，包括V）的后续客户端请求包括“计数”仪表指令时，代理使用指令中的相应值增加CU和CR。
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
当代理向入站服务器发送选择R（即，包括V）的请求时，它包括一个“计数”仪表指令，当前CU和CR为参数值。如果此请求是由代理收到来自客户端的请求引起的，则在收到服务器的响应后，代理会将CU和CR设置为
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.
在请求进行过程中可能分别发生的使用和重用次数。（这些数字可能为零，但不确定为零。）如果代理请求是最终的基于总分的报告，则不再需要维护CU和CR值，但也可以将其设置为干预使用和再使用的数量，并保留它们。
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.
参与响应R的使用限制的代理为该资源维护两个计数器TU和TR中的一个或两个（视情况而定）。TU和TR分别以与CU和CR相同的方式递增。但是，只有在收到响应的“max uses”仪表指令（包括初始接收）时，TU才会归零。类似地，TR仅在收到该响应的“max reuses”仪表指令时才归零。
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.
参与响应R的使用限制的代理还存储与R相关联的值MU和/或MR。当它接收到仅包括max uses值的响应时，它将MU设置为该值，将MR设置为无穷大。当它接收到只包含max reuses值的响应时，它将MR设置为该值，将MU设置为无穷大。当它接收到一个包含max reuses和max reuses值的响应时，它分别将MU和MR设置为这些值。当它接收到既不包含max reuses也不包含max reuses值的后续响应时，它将MU和MR都设置为无穷大。
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.
如果参与响应R的使用限制的代理收到将导致“使用”R的请求，并且TU>=MU，则它必须将该请求转发给服务器。如果它接收到一个会导致R“重用”的请求，并且TR>=MR，它必须将该请求转发给服务器。如果（在任何一种情况下）代理已经将以前的请求转发给服务器并正在等待响应，则它应该延迟对新请求的进一步处理，直到响应到达（或超时）；它不应该同时有两个选择相同响应的挂起的重新验证请求，除非这些是选择不同子范围的范围请求。
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.
对于“max uses”指令，此规则有一个特例：如果代理收到一个“max uses=0”的响应，并且没有将其转发给请求客户端，则代理应设置一个与R关联的标志PF。如果R为真，则当请求到达时，如果TU>=MU，则如果设置了PF标志，然后，不需要将请求转发到服务器（前提是其他缓存规则不需要这样做）。但是，在使用响应时必须清除PF标志。
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.
注意：“PF”标志之所以如此命名，是因为此功能仅适用于可能在响应的实际客户端请求之前发出“预回迁”请求的缓存。未实现预取的代理不需要实现PF标志。
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:
注：在大多数情况下，TU等于CU，TR等于CR。只有两种情况不同：
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).
1. 代理使用V向资源发出无条件请求，而TU和/或TR为非零，服务器的响应包括新的“max uses”和/或“max reuses”指令（从而将TU和/或TR归零，而不是CU和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.
2. 代理发出一个有条件的请求，报告命中计数（从而将CU和CR归零，但不将TU或TR归零），但服务器的响应不包括新的“max uses”和/或“max reuses”指令。
To solve the first case, the proxy has several implementation options
为了解决第一种情况，代理有几个实现选项
- Always store TU and TR separately from CU and CR.
- 始终将TU和TR与CU和CR分开存放。
- Create "shadow" copies of TU and TR when this situation arises (analogous to "copy on write").
- 出现这种情况时，创建TU和TR的“影子”副本（类似于“写时复制”）。
- 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).
- 在发送无条件请求时（或在接收到“max uses=0”时），生成基于磁头的使用情况报告，导致CU和CR归零（在某些方面类似于“内存屏障”指令）。
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.
在第二种情况下，服务器隐式地删除了响应的使用限制（通过将MU和/或MR设置为无穷大），因此，假设TU与CU不同的事实并不重要。
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.
注意：也可以通过发送额外的基于头部的使用情况报告请求来消除PF标志，但我们建议不要这样做；与传输额外请求相比，为每个条目分配额外的位更好。
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.
HTTP/1.1允许客户端请求资源的子范围。客户端可能会发出多个请求，最终收到一份资源副本。对于源服务器看到的结果的一致性，代理需要遵守计算这些引用的规则，尽管不清楚在每种情况下是否有一条规则生成准确的结果。
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.
本规范中建立的规则是，代理仅将导致返回资源字节0的范围请求计算为“使用”或“重用”。此规则的基本原理是，在几乎所有情况下，最终客户机都将检索其引用的任何资源的开头，并且很少检索任何部分超过一次。因此，该规则似乎符合“最大努力”近似值的目标。
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.
参与计量子树的非缓存代理（HTTP/1.1或更高版本）应在请求和响应上转发带有适当连接头的计量头。
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.
1. 如果代理在响应中转发仪表头，则不得将此类响应返回给任何请求，引发该响应的请求除外。
2. Once a non-caching proxy starts forwarding Meter headers, it should not arbitrarily stop forwarding them (or else reports may be lost).
2. 一旦非缓存代理开始转发仪表头，它就不应该随意停止转发仪表头（否则报告可能会丢失）。
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.
缓存某些响应而非其他响应的代理，无论出于何种原因，都可以选择将仪表头作为缓存响应的缓存代理，以及作为未缓存响应的非缓存代理，只要其关于任何特定响应的外部行为完全符合本规范。
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.
几个HTTP缓存实现，最著名的是Harvest/Squid缓存[2]，在几个缓存之间创建协作安排。如果此类缓存使用HTTP以外的协议在它们之间进行通信，如互联网缓存协议（ICP）[12]，并且如果它们实现了电表报头，则它们必须采取行动以确保它们的合作不会违反本规范的意图。
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.
特别是，如果一组协作缓存中的一个成员同意服务器命中特定响应，然后通过非HTTP协议将该响应传递给该组中的第二个缓存，缓存必须确保请求计量的服务器接收到适当说明第二个缓存的任何使用或结果的报告。类似地，如果第一个缓存同意使用限制响应，则缓存组的总使用次数必须限制为商定的数量。
6 Examples
6个例子
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
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
GET/bar.html HTTP/1.1主机：foo.com连接：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"
HTTP/1.1 200 OK
Date: Fri, 06 Dec 1996 18:44:29 GMT
Cache-control: max-age=3600
Connection: meter
Etag: "abcde"
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
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.
由于代理不知道其客户端是终端系统还是不进行计量的代理，因此它添加了“proxy mustcheck”指令。
Another client soon asks for the resource:
另一个客户端很快会请求资源：
GET http://foo.com/bar.html HTTP/1.1
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
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
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"
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.
因此代理可以使用原始响应回复新客户端；代理还将其与该响应关联的使用计数归零。
Another client soon asks for the resource:
另一个客户端很快会请求资源：
GET http://foo.com/bar.html HTTP/1.1
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
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.
报告已从缓存中再次使用响应。
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.0缓存存储响应，并且愿意让HTTP/1.0终端系统客户端生成多余的GET（这些GET将由HTTP/1.0代理转发），则可以发送此GET作为其答复：
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.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.
HTTP/1.0缓存将看到古老的Expires头，但HTTP/1.1缓存将看到max age指令并忽略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.
注意：尽管大多数主要的HTTP/1.0代理实现都遵守Expires头，但也可能有一些在使用中不遵守。使用Expires头阻止HTTP/1.0代理缓存可能并不完全可靠。
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
GET/bar.html HTTP/1.1主机：foo.com连接：米米：不会限制
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:
以下是来自源服务器的响应，它不希望命中计数，但希望“使用”限制为3，而“重用”限制为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
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:
以下是相同的示例，带有缩写的Meter指令名称：
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
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
7与内容协商的交互
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).
1. 处理带有不同标题的响应（第7.1节）。
2. treatment of responses that use the proposed Transparent Content Negotiation mechanism (section 7.2).
2. 对使用提议的透明内容协商机制的响应的处理（第7.2节）。
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.
对于请求URI的Vary头中指定的头的每个组合（即[4]所称的“选择请求头”），即使它们映射到相同的实体标记，也应保留单独的计数。如果一个页面有多个变体可用，则此规则可以计算每个变体的点击次数。
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.
注意：Vary和hit counting指令之间的这种交互允许源服务器在指定如何计算点击数方面具有很大的灵活性。本质上，源服务器使用Vary机制根据请求头将资源请求划分为任意类别。（我们将这些类别称为“请求模式”。）由于代理保留每个请求模式的命中计数，而不是每个资源的命中计数，因此源服务器可以获得HTTP请求许多方面的单独统计数据。
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.
如果代理不支持Vary机制，那么[4]表示它不能缓存任何带有Vary头的响应，因此不需要针对不同的资源实现这种命中计数或使用限制设计的任何方面。
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:
注意：这还意味着，如果代理支持Vary机制，但不愿意在其缓存中为每个变量响应维护独立的命中计数，那么它必须至少遵循以下规则之一：
1. It must not use the Meter header in a request to offer to hit-meter or usage-limit responses.
1. 它不得在请求中使用仪表标题，以提供命中仪表或使用限制响应。
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.
2. 如果它确实提供命中计量器或使用限制响应，然后接收到一个响应，该响应既包括Vary头，也包括一个带有它无法满足的指令的计量器头，那么代理不能缓存该响应。
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.
这种方法适用于计算请求流的几乎任何方面，而无需在规范或代理实现中嵌入任何特定的可计算方面列表。
[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.]
[本设计与拟议的透明内容协商（TCN）设计[6]之间的交互说明将在以后的文件中提供。]
8 A Note on Capturing Referrals
8关于获取转介的说明
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.
据称，一些广告商想向内容提供商付费，不是通过“点击”，而是通过“蚕食”——即实际点击广告以获取更多信息的人数。
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:
现在，HTTP已经有了这样一种机制：“Referer”头。然而，也许出于隐私原因应该禁用它——根据HTTP/1.1规范：
"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."
“由于链接的来源可能是私人信息，也可能透露其他私人信息来源，因此强烈建议用户能够选择是否发送Referer字段。”
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:
这不需要添加任何额外的机制，而是可以使用以类似以下方式将引用方嵌入URI的方案：
http://www.blah.com/ad-reference?from=site1
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
这样的URI应该指向一个资源（可能是一个CGI脚本），它返回一个302重定向到真实页面
http://www.blah.com/ad-reference.html
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.
不缓存302的代理每次使用都会在重定向页面上命中一次，但实际页面将被缓存。缓存302并在缓存的302上报告命中的代理将以最佳方式运行。
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.
这种方法的优点是，无论最终客户端是否禁用了Referer的使用，它都可以工作。结合本设计中的点击量计量建议的其余部分，这种方法允许，例如，广告客户知道从特定页面引用广告的频率。
9 Alternative proposals
9备选提案
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,
有人猜测，统计抽样方法可能用于收集合理准确的数据。一个这样的建议是操纵缓存过期时间，以便选定的资源在精心选择的时间段内不可缓存，从而允许服务器在这些时间段内准确计算访问次数。此处提出的命中计量机制完全是对该方法的补充，
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].
因为它可以用来降低收集这些计数的成本。James Pitkow已经写了一篇论文，比较了这个命中计量方案的早期草案与抽样方法[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.
Phillip Hallam Baker建议使用日志交换协议[5]，通过该协议，服务器可以通过向代理发出HTTP请求来请求代理的日志。该提案声称“相信它在涉及多个代理的配置中可以正确运行”，但如果将外部代理用作（单向）防火墙，则不清楚这是否正确。该提案还留下了一些悬而未决的问题，例如，源服务器如何确保请求子树中的所有代理实际上都支持日志交换。还不清楚此方案如何将代理对日志交换的支持与服务器缓存响应的权限相结合。
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].
有关Web测量标准主题的一般背景，请参见Thomas P.Novak和Donna L.Hoffman[8]的讨论。另请参见万维网联盟维护的“隐私和人口统计概述”页面[10]，其中包括一些收集消费者人口统计数据的初步建议（不仅仅是统计参考文献）[3]。
10 Security Considerations
10安全考虑
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).
如果代理愿意欺骗，则不可能强制执行使用限制（即，它提供限制使用，但随后忽略服务器的Meter指令）。
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.
关于隐私：本文档中的设计似乎没有透露任何关于个人用户的更多信息，而现有HTTP/1.1支持“缓存控制：最大年龄=0，代理重新验证”或“缓存控制：s-maxage=0”的实现已经透露了这些信息。事实上，它可能有助于在代理的出站端隐藏组织结构的某些方面。在任何情况下，用户对匿名性的要求与原始服务器对人口统计信息的要求之间的冲突都不能通过纯粹的技术手段解决。
11 Acknowledgments
11致谢
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.
我们衷心感谢安塞尔姆·贝尔德·史密斯、特德·哈迪、科恩·霍特曼（他提出了第8节所述的技术）、戴夫·克里斯托、阿里·洛托宁、帕特里克·R·麦克马纳斯、英格丽德·梅尔夫和詹姆斯·皮特科提出的建设性意见。
12 References
12参考文献
1. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
1. Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
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.
2. 安瓦特·昌亨托德、彼得·丹泽、查克·尼尔代尔斯、迈克尔·F·施瓦茨和库尔特·J·沃雷尔。分层Internet对象缓存。过程。1996年USENIX技术会议，圣地亚哥，1996年1月，第153-163页。
3. Daniel W. Connolly. Proposals for Gathering Consumer Demographics. http://www.w3.org/pub/WWW/Demographics/Proposals.html.
3. 丹尼尔·W·康诺利。收集消费者人口统计数据的建议。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.
4. 菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，尼尔森，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
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.
5. 菲利普·M·哈勒姆·贝克。代理缓存通知。W3C工作草案WD-proxy-960221，万维网联盟，1996年2月。http://www.w3.org/pub/WWW/TR/WD-proxy.html.
6. Holtman, K., and A. Mutz, "Transparent Content Negotiation in HTTP", Work in Progress.
6. Holtman，K.和A.Mutz，“HTTP中的透明内容协商”，正在进行中。
7. Mogul, J., "Forcing HTTP/1.1 proxies to revalidate responses", Work in Progress.
7. Mogul，J.，“强制HTTP/1.1代理重新验证响应”，正在进行中。
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.
8. 托马斯·P·诺瓦克和唐娜·L·霍夫曼。新媒体的新指标：走向网络测量标准的发展。这是一份文件草稿，目前可在http://www2000.ogsm.vanderbilt.edu/novak/web.standards/webstand.html上查阅。经作者许可引用；未经允许不得引用或引用。
9. James Pitkow. In search of reliable usage data on the WWW. Proc. Sixth International World Wide Web Conference, Santa Clara, CA, April, 1997.
9. 詹姆斯·皮特科。在WWW.Proc上搜索可靠的使用数据。第六届国际万维网会议，加利福尼亚州圣克拉拉，1997年4月。
10. Joseph Reagle, Rohit Khare, Dan Connolly, and Tim Berners-Lee. Privacy and Demographics Overview. http://www.w3.org/pub/WWW/Demographics/.
10. Joseph Reagle、Rohit Khare、Dan Connolly和Tim Berners Lee。隐私和人口统计概述。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.
11. 琳达·陶谢尔和索尔·格林伯格。万维网导航中的重访模式。1996年3月，卡尔加里大学计算机科学系96/587／07年度研究报告。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.
12. Wessels，D.和K.Claffy，“互联网缓存协议（ICP），版本2”，RFC2186，1997年9月。
13 Authors' Addresses
13作者地址
Jeffrey C. Mogul Western Research Laboratory Digital Equipment Corporation 250 University Avenue Palo Alto, California, 94305, U.S.A.
美国加利福尼亚州帕洛阿尔托大学大道250号Jeffrey C.Mogul西部研究实验室数字设备公司，邮编94305。
EMail: mogul@wrl.dec.com
Phone: 1 415 617 3304 (email preferred)
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.
Paul J.Leach微软1号微软路雷德蒙德，华盛顿，98052，美国。
EMail: paulle@microsoft.com
EMail: paulle@microsoft.com
14 Full Copyright Statement
14完整版权声明
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。