Network Working Group J. Mogul
Request for Comments: 3229 Compaq WRL
Category: Standards Track B. Krishnamurthy
F. Douglis
AT&T
A. Feldmann
Univ. of Saarbruecken
Y. Goland
A. van Hoff
Marimba
D. Hellerstein
ERS/USDA
January 2002
Network Working Group J. Mogul
Request for Comments: 3229 Compaq WRL
Category: Standards Track B. Krishnamurthy
F. Douglis
AT&T
A. Feldmann
Univ. of Saarbruecken
Y. Goland
A. van Hoff
Marimba
D. Hellerstein
ERS/USDA
January 2002
Delta encoding in 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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1.
本文档描述了如何支持增量编码作为HTTP/1.1的兼容扩展。
Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."
许多HTTP（超文本传输协议）请求都会导致检索稍微修改过的资源实例，而客户端已经为这些实例提供了缓存项。研究表明，此类修改更新非常频繁，并且修改通常比实际实体小得多。在这种情况下，如果HTTP能够传输更改的最小描述，而不是资源的整个新实例，那么它将更有效地利用网络带宽。这称为“增量编码”
Table of Contents
目录
1 Introduction.................................................... 3
1.1 Related research and proposals........................... 4
2 Goals........................................................... 5
3 Terminology..................................................... 6
4 The HTTP message-generation sequence............................ 8
4.1 Relationship between deltas and ranges................... 11
5 Basic mechanisms................................................ 13
5.1 Background: an overview of HTTP cache validation......... 13
5.2 Requesting the transmission of deltas.................... 14
5.3 Choice of delta algorithm and format..................... 16
5.4 Identification of delta-encoded responses................ 16
5.5 Guaranteeing cache safety................................ 17
5.6 Transmission of delta-encoded responses.................. 18
5.7 Examples of requests combining Range and delta encoding.. 19
6 Encoding algorithms and formats................................. 22
7 Management of base instances.................................... 23
7.1 Multiple entity tags in the If-None-Match header......... 24
7.2 Hints for managing the client cache...................... 25
8 Deltas and intermediate caches.................................. 27
9 Digests for data integrity...................................... 28
10 Specification.................................................. 28
10.1 Protocol parameter specifications....................... 28
10.2 IANA Considerations..................................... 30
10.3 Basic requirements for delta-encoded responses.......... 30
10.4 Status code specifications.............................. 30
10.4.1 226 IM Used...................................... 31
10.5 Header specifications................................... 31
10.5.1 Delta-Base....................................... 31
10.5.2 IM............................................... 32
10.5.3 A-IM............................................. 33
10.6 Caching rules for 226 responses......................... 35
10.7 Rules for deltas in the presence of content-codings..... 36
10.7.1 Rules for generating deltas in the presence of
content-codings.................................. 37
10.7.2 Rules for applying deltas in the presence of
content-codings.................................. 37
10.7.3 Examples for using A-IM, IM, and content-codings. 38
10.8 New Cache-Control directives............................ 40
10.8.1 Retain directive................................. 40
10.8.2 IM directive..................................... 40
10.9 Use of compression with delta encoding.................. 41
10.10 Delta encoding and multipart/byteranges................ 42
11 Quantifying the protocol overhead.............................. 42
12 Security Considerations........................................ 44
13 Acknowledgements............................................... 44
14 Intellectual Property Rights................................... 44
1 Introduction.................................................... 3
1.1 Related research and proposals........................... 4
2 Goals........................................................... 5
3 Terminology..................................................... 6
4 The HTTP message-generation sequence............................ 8
4.1 Relationship between deltas and ranges................... 11
5 Basic mechanisms................................................ 13
5.1 Background: an overview of HTTP cache validation......... 13
5.2 Requesting the transmission of deltas.................... 14
5.3 Choice of delta algorithm and format..................... 16
5.4 Identification of delta-encoded responses................ 16
5.5 Guaranteeing cache safety................................ 17
5.6 Transmission of delta-encoded responses.................. 18
5.7 Examples of requests combining Range and delta encoding.. 19
6 Encoding algorithms and formats................................. 22
7 Management of base instances.................................... 23
7.1 Multiple entity tags in the If-None-Match header......... 24
7.2 Hints for managing the client cache...................... 25
8 Deltas and intermediate caches.................................. 27
9 Digests for data integrity...................................... 28
10 Specification.................................................. 28
10.1 Protocol parameter specifications....................... 28
10.2 IANA Considerations..................................... 30
10.3 Basic requirements for delta-encoded responses.......... 30
10.4 Status code specifications.............................. 30
10.4.1 226 IM Used...................................... 31
10.5 Header specifications................................... 31
10.5.1 Delta-Base....................................... 31
10.5.2 IM............................................... 32
10.5.3 A-IM............................................. 33
10.6 Caching rules for 226 responses......................... 35
10.7 Rules for deltas in the presence of content-codings..... 36
10.7.1 Rules for generating deltas in the presence of
content-codings.................................. 37
10.7.2 Rules for applying deltas in the presence of
content-codings.................................. 37
10.7.3 Examples for using A-IM, IM, and content-codings. 38
10.8 New Cache-Control directives............................ 40
10.8.1 Retain directive................................. 40
10.8.2 IM directive..................................... 40
10.9 Use of compression with delta encoding.................. 41
10.10 Delta encoding and multipart/byteranges................ 42
11 Quantifying the protocol overhead.............................. 42
12 Security Considerations........................................ 44
13 Acknowledgements............................................... 44
14 Intellectual Property Rights................................... 44
15 References..................................................... 44
16 Authors' addresses............................................. 47
17 Full Copyright Statement....................................... 49
15 References..................................................... 44
16 Authors' addresses............................................. 47
17 Full Copyright Statement....................................... 49
1 Introduction
1导言
The World Wide Web is a distributed system, and so often benefits from caching to reduce retrieval delays. Retrieval of a Web resource (such as a document, image, icon, or applet) over the Internet or other wide-area networks usually takes enough time that the delay is over the human threshold of perception. Often, that delay is measured in seconds. Caching can often eliminate or significantly reduce retrieval delays.
万维网是一个分布式系统，因此常常受益于缓存以减少检索延迟。通过Internet或其他广域网检索Web资源（如文档、图像、图标或小程序）通常需要足够的时间，延迟超过人类的感知阈值。通常，延迟以秒为单位。缓存通常可以消除或显著减少检索延迟。
Many Web resources change over time, so a practical caching approach must include a coherency mechanism, to avoid presenting stale information to the user. Originally, the Hypertext Transfer Protocol (HTTP) provided little support for caching, but under operational pressures, it quickly evolved to support a simple mechanism for maintaining cache coherency.
许多Web资源会随着时间的推移而变化，因此实际的缓存方法必须包括一致性机制，以避免向用户呈现过时的信息。最初，超文本传输协议（HTTP）对缓存提供的支持很少，但在操作压力下，它迅速发展为支持维护缓存一致性的简单机制。
In HTTP/1.0 [2], the server may supply a "last-modified" timestamp with a response. If a client stores this response in a cache entry, and then later wishes to re-use the response, it may transmit a request message with an "If-modified-since" field containing that timestamp; this is known as a conditional retrieval. Upon receiving a conditional request, the server may either reply with a full response, or, if the resource has not changed, it may send an abbreviated reply, indicating that the client's cache entry is still valid. HTTP/1.0 also includes a means for the server to indicate, via an "Expires" timestamp, that a response will be valid until that time; if so, a client may use a cached copy of the response until that time, without first validating it using a conditional retrieval.
在HTTP/1.0[2]中，服务器可以提供带有响应的“上次修改”时间戳。如果客户机将该响应存储在高速缓存条目中，然后希望重新使用该响应，则它可以发送带有包含该时间戳的“If modified since”字段的请求消息；这称为条件检索。在接收到条件请求后，服务器可以使用完整响应进行回复，或者，如果资源没有更改，它可以发送一个简短的回复，指示客户端的缓存项仍然有效。HTTP/1.0还包括服务器通过“Expires”时间戳指示响应在该时间之前有效的方法；如果是这样，客户端可以使用响应的缓存副本，直到那时为止，而不必首先使用条件检索对其进行验证。
HTTP/1.1 [10] adds many new features to improve cache coherency and performance. However, it preserves the all-or-none model for responses to conditional retrievals: either the server indicates that the resource value has not changed at all, or it must transmit the entire current value.
HTTP/1.1[10]添加了许多新功能以提高缓存一致性和性能。但是，对于条件检索的响应，它保留了all或none模型：要么服务器指示资源值根本没有更改，要么它必须传输整个当前值。
Common sense suggests (and traces confirm), however, that even when a Web resource does change, the new instance is often substantially similar to the old one. If the difference, or "delta", between the two instances could be sent to the client instead of the entire new instance, a client holding a cached copy of the old instance could apply the delta to construct the new version. In a world of finite bandwidth, the reduction in response size and delay could be significant.
然而，常识表明（并证实），即使Web资源发生了变化，新实例通常与旧实例基本相似。如果两个实例之间的差异或“增量”可以发送到客户端而不是整个新实例，则持有旧实例缓存副本的客户端可以应用增量来构建新版本。在带宽有限的世界中，响应大小和延迟的减少可能是显著的。
One can think of deltas as a way to squeeze as much benefit as possible from client and proxy caches. Rather than treating an entire response as the "cache line", with deltas we can treat arbitrary pieces of a cached response as the replaceable unit, and avoid transferring pieces that have not changed.
人们可以将delta看作是从客户机和代理缓存中尽可能多地获取好处的一种方法。与将整个响应视为“缓存线”不同，使用delta，我们可以将缓存响应的任意部分视为可替换单元，并避免传输未更改的部分。
This document proposes a set of compatible extensions to HTTP/1.1 that allow clients and servers to use delta encoding with minimal overhead.
本文档提出了一组兼容的HTTP/1.1扩展，允许客户端和服务器以最小的开销使用增量编码。
We assume that the reader is familiar with the HTTP/1.1 specification.
我们假设读者熟悉HTTP/1.1规范。
The idea of delta encoding to reduce communication or storage costs is not new. For example, the MPEG-1 video compression standard transmits occasional still-image frames, but most of the frames sent are encoded (to oversimplify) as changes from an adjacent frame. The SCCS and RCS [27] systems for software version control represent intermediate versions as deltas; SCCS starts with an original version and encodes subsequent ones with forward deltas, whereas RCS encodes previous versions as reverse deltas from their successors. Jacobson's technique for compressing IP and TCP headers over slow links [17] uses a clever, highly specialized form of delta encoding.
用增量编码来降低通信或存储成本的想法并不新鲜。例如，MPEG-1视频压缩标准偶尔传输静止图像帧，但发送的大多数帧都是根据相邻帧的变化进行编码（过于简化）。用于软件版本控制的SCCS和RCS[27]系统将中间版本表示为增量；SCCS从原始版本开始，用正向增量编码后续版本，而RCS将先前版本编码为后续版本的反向增量。Jacobson在慢速链路上压缩IP和TCP报头的技术[17]使用了一种巧妙、高度专业化的增量编码形式。
In spite of this history, it appears to have taken several years before anyone thought of applying delta encoding to HTTP, perhaps because the development of HTTP caching has been somewhat haphazard. The first published suggestion for delta encoding appears to have been by Williams et al. in a paper about HTTP cache removal policies [30], but these authors did not elaborate on their design until later [29].
尽管有这样的历史，但似乎要过几年才有人想到将增量编码应用于HTTP，这可能是因为HTTP缓存的开发有点随意。关于增量编码的第一个公开建议似乎是由Williams等人在一篇关于HTTP缓存删除策略的论文[30]中提出的，但这些作者直到后来才详细阐述他们的设计[29]。
The WebExpress project [15] appears to be the first published description of an implementation of delta encoding for HTTP (which they call "differencing"). WebExpress is aimed specifically at wireless environments, and includes a number of orthogonal optimizations. Also, the WebExpress design does not propose changing the HTTP protocol itself, but rather uses a pair of interposed proxies to convert the HTTP message stream into an optimized form. The results reported for WebExpress differencing are impressive, but are limited to a few selected benchmarks.
WebExpress项目[15]似乎是对HTTP增量编码（他们称之为“差异化”）实现的首次公开描述。WebExpress专门针对无线环境，包括许多正交优化。此外，WebExpress设计不建议更改HTTP协议本身，而是使用一对插入式代理将HTTP消息流转换为优化形式。WebExpress差异分析报告的结果令人印象深刻，但仅限于一些选定的基准测试。
Banga et al. [1] describe the use of optimistic deltas, in which a layer of interposed proxies on either end of a slow link collaborate to reduce latency. If the client-side proxy has a cached copy of a resource, the server-side proxy can simply send a delta (or a 304
Banga等人[1]描述了乐观增量的使用，在这种情况下，慢速链路两端的一层插入代理协作以减少延迟。如果客户端代理具有资源的缓存副本，则服务器端代理可以简单地发送增量（或增量）
[Not Modified] response). If only the server-side proxy has a cached copy, it may optimistically send its (possibly stale) copy to the client-side proxy, followed (if necessary) by a delta once the server-side proxy has validated its own cache entry with the origin server. The use of optimistic deltas, unlike delta encoding, actually increases the number of bytes sent over the network, in an attempt to improve latency by anticipating a "Not Modified" response from the origin server. The optimistic delta paper, like the WebExpress paper, did not propose a change to the HTTP protocol itself, and reported results only for a small set of selected URLs.
[未修改]响应）。如果只有服务器端代理具有缓存副本，则它可以乐观地将其（可能过时的）副本发送到客户端代理，在服务器端代理与源服务器验证其自己的缓存条目后（如有必要）发送增量。与增量编码不同，乐观增量的使用实际上增加了通过网络发送的字节数，试图通过预期来自源服务器的“未修改”响应来改善延迟。乐观的delta文件，像WebExpress文件一样，没有建议对HTTP协议本身进行更改，只报告了一小部分选定url的结果。
Mogul et al. [23] collected lengthy traces, at two different sites, of the full contents of HTTP messages, to quantify the potential benefits of delta-encoded responses. They showed that delta encoding can provide remarkable improvements in response-size and response-delay for an important subset of HTTP content types. They proposed a set of HTTP extensions, but without the level of detail required for a specification. Douglis et al. [8] used the same sets of full-content traces to quantify the rate at which resources change in the Web.
Mogul等人[23]在两个不同的站点收集了HTTP消息完整内容的长跟踪，以量化增量编码响应的潜在好处。他们表明，增量编码可以显著改善HTTP内容类型的一个重要子集的响应大小和响应延迟。他们提出了一组HTTP扩展，但没有规范所需的详细级别。Douglis等人[8]使用相同的完整内容跟踪集来量化网络中资源变化的速率。
The HTTP Distribution and Replication Protocol (DRP), proposed to W3C by Marimba, Netscape, Sun, Novell, and At Home, aims to provide a collection of new features for HTTP, to support "the efficient replication of data over HTTP" [13]. One aspect of the DRP proposal is the use of "differential downloading," which is essentially a form of delta encoding. The original DRP proposal uses a different approach than is described here, but a forthcoming revision of DRP will be revised to conform to the proposal in this document.
HTTP分发和复制协议（DRP）由Marimba、Netscape、Sun、Novell和Home向W3C提出，旨在为HTTP提供一系列新功能，以支持“通过HTTP高效复制数据”[13]。DRP方案的一个方面是使用“差异下载”，这本质上是一种增量编码形式。原始DRP提案使用了与本文所述不同的方法，但即将修订的DRP将进行修订，以符合本文件中的提案。
Tridgell and Mackerras [28] describe the "rsync" algorithm, which accomplishes something similar to delta encoding. In rsync, the client breaks a cache entry into a series of fixed-sized blocks, computes a digest value for each block, and sends the series of digest values to the server as part of its request. The origin server does the same block-based computation, and returns only those blocks whose digest values differ. We believe that it might be possible to support rsync using the "instance manipulation" framework described later in this document, but this has not been worked out in any detail.
Tridgell和Mackerras[28]描述了“rsync”算法，它实现了类似于增量编码的功能。在rsync中，客户机将缓存条目分解为一系列固定大小的块，计算每个块的摘要值，并将摘要值系列作为其请求的一部分发送给服务器。原始服务器执行相同的基于块的计算，并仅返回其摘要值不同的块。我们相信，使用本文后面描述的“实例操作”框架支持rsync是可能的，但这还没有得到详细的解决。
2 Goals
2个目标
The goals of this proposal are:
本提案的目标是：
1. Reduce the mean size of HTTP responses, thereby improving latency and network utilization.
1. 减少HTTP响应的平均大小，从而提高延迟和网络利用率。
2. Avoid any extra network round trips.
2. 避免任何额外的网络往返。
3. Minimize the amount of per-request and per-response overheads.
3. 最小化每个请求和每个响应的开销。
4. Support a variety of encoding algorithms and formats.
4. 支持多种编码算法和格式。
5. Interoperate with HTTP/1.0 and HTTP/1.1.
5. 与HTTP/1.0和HTTP/1.1进行互操作。
6. Be fully optional for clients, proxies, and servers.
6. 对于客户端、代理和服务器，完全可选。
7. Allow moderately simple implementations.
7. 允许适度简单的实现。
The goals do not include:
目标不包括：
- Reducing the number of HTTP requests sent to an origin server.
- 减少发送到源服务器的HTTP请求数。
- Reducing the size of every HTTP message.
- 减少每个HTTP消息的大小。
- Increasing the cache-hit ratio of HTTP caches.
- 增加HTTP缓存的缓存命中率。
- Allowing excessively simplistic implementations of delta encoding.
- 允许过度简化增量编码的实现。
- Delta encoding of request messages, or of responses to methods other than GET.
- 请求消息或对GET以外的方法的响应的增量编码。
Nothing in this specification specifically precludes the use of a delta encoding for the body of a PUT request. However, no mechanism currently exists for the client to discover if the server can interpret such messages, and so we do not attempt to specify how they might be used.
本规范中没有任何内容明确禁止对PUT请求主体使用增量编码。但是，目前还没有机制让客户端发现服务器是否可以解释这些消息，因此我们不尝试指定如何使用它们。
3 Terminology
3术语
HTTP/1.1 [10] defines the following terms:
HTTP/1.1[10]定义了以下术语：
resource A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways.
资源可以通过URI识别的网络数据对象或服务，如第3.2节所定义。资源可能有多种表示形式（例如，多种语言、数据格式、大小、分辨率）或以其他方式变化。
entity The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in section 7.
实体作为请求或响应的有效负载传输的信息。实体由实体标题字段形式的元信息和实体正文形式的内容组成，如第7节所述。
variant A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `variant.' Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.
变体资源在任何给定时刻可能有一个或多个与其关联的表示。这些表示中的每一种都被称为“变体”。使用“变体”一词并不一定意味着资源要接受内容协商。
The dictionary definition for "entity" is "something that has separate and distinct existence and objective or conceptual reality" [21]. Unfortunately, the definition for "entity" in HTTP/1.1 is similar to that used in MIME [12], based on a false analogy between MIME and HTTP.
字典对“实体”的定义是“具有独立和不同存在以及客观或概念现实的事物”[21]。不幸的是，基于MIME和HTTP之间的错误类比，HTTP/1.1中“实体”的定义与MIME[12]中使用的定义类似。
In MIME, electronic mail messages do have distinct and separate existences. MIME defines "entity" as something that "refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity."
在MIME中，电子邮件确实有不同的存在。MIME将“实体”定义为“专门指MIME定义的消息头字段和内容或多部分实体主体中的一个部分。”
In HTTP, however, a response message to a GET does not have a distinct and separate existence. Rather, it reflects the current state of a resource (or a variant, subject to a set of constraints). The HTTP/1.1 specification has no term to describe "the value that would be returned in response to a GET request at the current time for the selected variant of the specified resource." This leads to awkward wordings in the HTTP/1.1 specification in places where this concept is necessary.
然而，在HTTP中，对GET的响应消息并没有独立的存在。相反，它反映了资源（或变体，受一组约束）的当前状态。HTTP/1.1规范没有术语来描述“在当前时间为指定资源的所选变体响应GET请求时将返回的值”。这导致HTTP/1.1规范在需要此概念的地方使用了笨拙的措辞。
To express this concept, we define a new term, for use in this document:
为了表达这一概念，我们定义了一个新术语，用于本文件：
instance The entity that would be returned in a status-200 response to a GET request, at the current time, for the selected variant of the specified resource, with the application of zero or more content-codings, but without the application of any instance manipulations (see below) or transfer-codings.
实例当前，对于指定资源的选定变体，将在status-200响应GET请求时返回的实体，应用零个或多个内容编码，但不应用任何实例操作（见下文）或传输编码。
It is convenient to think of an entity tag, in HTTP/1.1, as being associated with an instance, rather than an entity. That is, for a given resource, two different response messages might include the same entity tag, but two different instances of the resource should never be associated with the same (strong) entity tag.
在HTTP/1.1中，可以方便地将实体标记视为与实例关联，而不是实体。也就是说，对于给定的资源，两个不同的响应消息可能包含相同的实体标记，但是资源的两个不同实例永远不应该与相同的（强）实体标记相关联。
We will informally use the term "delta," in this document, to mean an HTTP response encoded as the difference between two instances.
在本文中，我们将非正式地使用术语“delta”来表示编码为两个实例之间差异的HTTP响应。
More formally, delta encodings are members of a potentially larger class of transformations on instances, leading to this new term:
更正式地说，增量编码是实例上可能更大的转换类的成员，这导致了这个新术语：
instance manipulation An operation on one or more instances which may result in an instance being conveyed from server to client in parts, or in more than one response message. For example, a range selection or a delta encoding. Instance manipulations are end-to-end, and often involve the use of a cache at the client.
实例操作对一个或多个实例的操作，可能导致实例部分地从服务器传输到客户端，或在多个响应消息中传输。例如，范围选择或增量编码。实例操作是端到端的，通常涉及在客户端使用缓存。
For reasons that will become clear later on, it is convenient to think about subrange selection as a form of instance manipulation. In some contexts, compression might also be treated as an instance manipulation, rather than as a content-coding or transfer-coding.
出于稍后将变得清晰的原因，可以方便地将子范围选择视为实例操作的一种形式。在某些上下文中，压缩也可能被视为实例操作，而不是内容编码或传输编码。
4 The HTTP message-generation sequence
4 HTTP消息生成序列
HTTP/1.1 supports a number of different transformations on the body of a value:
HTTP/1.1支持在值体上进行多种不同的转换：
Content-coding According to the specification, "Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only decoded by the recipient." Content-codings are normally end-to-end transformations; i.e., once applied at the sender, they are not removed except at the ultimate recipient. An intermediate server may apply a content-coding, in appropriate circumstances.
根据规范进行内容编码，“内容编码值表示已经或可以应用于实体的编码转换。内容编码主要用于压缩或以其他方式有效转换文档，而不会丢失其底层媒体类型的标识，也不会丢失信息。通常，实体以编码形式存储，直接传输，仅由接收方解码。“内容编码通常是端到端的转换；即，一旦在发送方应用，它们不会被删除，除非在最终接收方。在适当的情况下，中间服务器可以应用内容编码。
Transfer-coding According to the specification, "Transfer coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer coding is a property of the message, not of the original entity." Transfer-codings are explicitly hop-by-hop transformations (although, as an optimization, an intermediate proxy may store the transfer-coded version of a message if this behavior is not inconsistent with its externally visible function.)
传输编码根据规范，“传输编码值用于指示已经、可以或可能需要应用于实体的编码转换，以确保“安全传输”“通过网络。这与内容编码不同，因为传输编码是消息的属性，而不是原始实体的属性。“传输编码是显式逐跳转换（不过，作为优化，如果中间代理的行为与其外部可见功能不一致，则中间代理可以存储消息的传输编码版本。）
Ranges An HTTP client, using the Range header, may request that the server return one or more subranges of the instance, rather than the entire instance value. HTTP/1.1 only supports byte-ranges, although there is some possibility that future extensions will allow for other kinds of range-specifiers (such as chapters of a document).
范围使用范围标头的HTTP客户端可能会请求服务器返回实例的一个或多个子范围，而不是整个实例值。HTTP/1.1只支持字节范围，尽管将来的扩展可能会允许使用其他类型的范围说明符（例如文档的章节）。
A client signals its willingness to receive a content-coding by sending an "Accept-Encoding" header, listing the set of content-codings that it understands. It may optionally include information about which content-codings it prefers. If a server uses any non-identity content-coding(s), it includes a "Content-Encoding" header field in the response, listing these content-codings in their order of application.
客户机通过发送一个“接受编码”头来表示其愿意接收内容编码，该头列出了它能够理解的一组内容编码。它可以选择性地包括关于它喜欢的内容编码的信息。如果服务器使用任何非身份内容编码，则在响应中会包含一个“content Encoding”（内容编码）头字段，按应用顺序列出这些内容编码。
RFC 2068 [9] did not include an analogous mechanism for negotiating the use of transfer-codings, although it does include an analogous "Transfer-Encoding" header for marking the response. A new "TE" header has since been added to HTTP/1.1 [10], analogous to the "Accept-Encoding" header.
RFC 2068[9]没有包括协商使用转移编码的类似机制，尽管它确实包括用于标记响应的类似“转移编码”标题。此后，HTTP/1.1[10]中添加了一个新的“TE”头，类似于“接受编码”头。
In this document, we add new, optional message headers to support the use of instance manipulations. A client signals its willingness to receive an instance-manipulation by sending an "A-IM" header (short for "Accept-Instance-Manipulation", which is far too long to spell out), analogous to the "Accept-Encoding" header. Similarly, a server lists the set of instance-manipulations it has applied using an "IM" header.
在本文档中，我们添加了新的可选消息头，以支持实例操作的使用。客户端通过发送一个类似于“接受编码”头的“A-IM”头（缩写为“接受实例操作”，太长了，无法拼写）来表示其愿意接收实例操作。类似地，服务器使用“IM”头列出它应用的实例操作集。
One must understand the relationship between these transformations in order to see how delta encoding applies to HTTP responses.
为了了解增量编码如何应用于HTTP响应，必须理解这些转换之间的关系。
Conceptually, the various transformations are applied in the following sequence:
从概念上讲，各种转换按以下顺序应用：
1. Upon receiving a GET request, the server uses the URI in the request to identify the requested resource.
1. 在收到GET请求时，服务器使用请求中的URI来标识请求的资源。
2. Optionally, it uses information from the request (and perhaps additional information) to select a variant of that resource.
2. 或者，它使用来自请求的信息（可能还有其他信息）来选择该资源的变体。
3. At this point, the server may apply a non-identity content-coding to the instance, or one might have been inherent in its generation. This also results in a Content-Encoding header.
3. 此时，服务器可能会对实例应用非标识内容编码，或者在其生成过程中可能已经应用了非标识内容编码。这也会产生一个内容编码头。
4. The result of the first three steps, at the time when the request is processed, is an instance. The instance includes a body (possibly empty) and possibly some instance headers. The entity tag, if any, is assigned at this point. That is, an entity tag is associated with an instance, NOT an entity.
4. 在处理请求时，前三个步骤的结果是一个实例。实例包括一个主体（可能为空）和一些实例头。此时将指定实体标记（如果有）。也就是说，实体标记与实例关联，而不是实体。
5. The server may then apply an instance-manipulation. For example, if the request included a Range header, the server may optionally produce a range response, consisting of the original set of headers, a Content-Range header, and the appropriate range(s) from the (possibly encoded) body. Delta encodings are instance-manipulations, and are computed at this stage.
5. 然后，服务器可以应用实例操作。例如，如果请求包括范围报头，则服务器可以选择性地生成范围响应，包括原始报头集、内容范围报头和来自（可能编码的）正文的适当范围。增量编码是实例操作，在此阶段进行计算。
6. The result of the fifth step becomes the entity, consisting of entity headers and an entity body.
6. 第五步的结果成为实体，由实体头和实体体组成。
7. The server may then apply a non-identity transfer-coding; on-the-fly compression could be done in this step. If so, a Transfer-Encoding header is added to the message.
7. 然后，服务器可以应用非身份传输编码；在这一步中可以进行动态压缩。如果是，则会向消息中添加传输编码标头。
8. The results of the seventh step is the message, consisting of a message body (the transfer-coded version of the entity body), the entity headers, and additional response and general headers.
8. 第七步的结果是消息，由消息体（实体体的传输编码版本）、实体头以及附加响应和常规头组成。
Note: Section 14.13 of the HTTP/1.1 specification [10] says "The Content-Length entity-header field indicates the size of the entity-body." In other words, Content-Length measures the length of an entity, not of an instance or of a variant. For example, if the message is a delta encoding, Content-Length gives the length of the delta encoding, not the length of the current instance.
注：HTTP/1.1规范[10]第14.13节说“内容长度实体头字段表示实体体的大小”。换句话说，内容长度度量实体的长度，而不是实例或变体的长度。例如，如果消息是增量编码，则Content Length给出的是增量编码的长度，而不是当前实例的长度。
Diagrammatically, the sequence is:
从图表上看，顺序是：
datatype operation leading to next datatype
======== ==================================
resource
| choose acceptable variant, if needed
v
variant
| apply content-coding, if any
v
datatype operation leading to next datatype
======== ==================================
resource
| choose acceptable variant, if needed
v
variant
| apply content-coding, if any
v
| compute/assign entity tag
v
instance
| apply instance manipulation, if any
v (delta encoding, range selection, etc.)
entity-body
| apply transfer-coding, if any
v
message-body
| compute/assign entity tag
v
instance
| apply instance manipulation, if any
v (delta encoding, range selection, etc.)
entity-body
| apply transfer-coding, if any
v
message-body
This formalization of the HTTP message generation sequence has not previously been described. However, it is clear that Range selection needs to be done after the entity tag has been assigned and after any content-coding has been applied, and before any transfer-coding is applied. Therefore, this formalization is fully consistent with previous practice and specification.
HTTP消息生成序列的这种形式化以前没有描述过。但是，很明显，范围选择需要在分配实体标记之后、应用任何内容编码之后以及应用任何传输编码之前进行。因此，这种形式化与以前的实践和规范完全一致。
If both Ranges and delta encodings are forms of instance manipulation, which should be applied first? This depends on how the Range is being used.
如果范围和增量编码都是实例操作的形式，那么应该首先应用哪一种？这取决于范围的使用方式。
Ranges are used for two main purposes, at the discretion of the requesting client:
范围用于两个主要目的，由请求客户自行决定：
1. to complete a partial response after a premature termination of a message transmission.
1. 在消息传输提前终止后完成部分响应。
2. to obtain just selected sections of an instance.
2. 仅获取实例的选定部分。
In the first use of Range, it would have to be applied after any delta encoding, since the intended use is to recover an intact copy of the delta-encoded instance. In the second use of Range, it would have to be applied before any delta encoding, because otherwise the
在第一次使用Range时，它必须在任何增量编码之后应用，因为预期用途是恢复增量编码实例的完整副本。在第二次使用范围时，必须在任何增量编码之前应用它，因为否则
offsets specified in the Range request would be meaningless (the client generally cannot know how a server's delta encoding maps instance byte offsets to entity byte offsets).
范围请求中指定的偏移量没有意义（客户端通常无法知道服务器的增量编码如何将实例字节偏移量映射到实体字节偏移量）。
Therefore, we need a mechanism to allow the client to specify the order in which two or more instance-manipulations should be applied. This is easily provided as part of the specification of the "A-IM" header (see section 10.5.3), where we require that the server apply instance-manipulations in the order that they are listed in the "A-IM" header. We also include a "range" literal in the set of registered instance-manipulations, to allow the client to specify (by its ordering with respect to other instance-manipulations) whether range selection is done before or after delta encoding.
因此，我们需要一种机制来允许客户端指定应用两个或多个实例操作的顺序。这很容易作为“A-IM”标头规范的一部分提供（参见第10.5.3节），其中我们要求服务器按照实例操作在“A-IM”标头中列出的顺序应用实例操作。我们还在注册的实例操作集中包含一个“range”文本，以允许客户机（通过其相对于其他实例操作的顺序）指定范围选择是在增量编码之前还是之后进行的。
We also need a mechanism for the server to indicate in which order two or more instance-manipulations have been applied; this is part of the specification of the "IM" header (see section 10.5.2), where we follow the same practice used for the "Content-Encoding" header: the "IM" header lists the instance-manipulations in the order that were applied (including, perhaps, the special "range" literal).
我们还需要一种机制，让服务器指示应用两个或多个实例操作的顺序；这是“IM”头规范的一部分（参见第10.5.2节），我们遵循“内容编码”头使用的相同实践：“IM”头按照应用的顺序列出实例操作（可能包括特殊的“范围”文字）。
A similar issue arises when Ranges are combined with compression. If the client is using a Range to complete a partial response after a premature termination of a compressed message, then the Range would have to be applied after the compression. This is feasible in unmodified HTTP/1.1, because the compression can be done as a content-coding. However, if the client is using a Range to obtain selected sections of an instance, it would normally be able to specify offsets only in terms of the uncompressed variant. If the selected portion was large enough to warrant compression, the client could request a compressed transfer-coding, but this is a hop-by-hop transformation and is not the most efficient approach (especially if an HTTP/1.0 proxy is in the path).
当范围与压缩相结合时，也会出现类似的问题。如果客户端在压缩消息提前终止后使用范围来完成部分响应，则必须在压缩后应用该范围。这在未修改的HTTP/1.1中是可行的，因为压缩可以作为内容编码来完成。但是，如果客户机使用范围来获取实例的选定部分，它通常只能根据未压缩变量指定偏移量。如果所选部分足够大，足以保证压缩，客户端可以请求压缩传输编码，但这是逐跳转换，不是最有效的方法（尤其是在路径中有HTTP/1.0代理的情况下）。
We can resolve this issue by supporting the use of compression as an instance-manipulation (as well as as a content-coding or transfer-coding), and by using the new mechanism that allows the client to specify that the compression instance-manipulation is done after the Range instance-manipulation.
我们可以通过支持将压缩用作实例操作（以及内容编码或传输编码），并通过使用允许客户端指定压缩实例操作在范围实例操作之后完成的新机制来解决此问题。
This also allows the client to control whether compression is done before or after delta encoding, since some simple differencing algorithms (such as the UNIX "diff" command) require post-compression of their output to yield the best results.
这还允许客户机控制压缩是在增量编码之前还是之后进行，因为一些简单的差分算法（如UNIX“diff”命令）需要对其输出进行后压缩以产生最佳结果。
5 Basic mechanisms
5基本机制
In this section, we explain the concepts behind delta encoding. This is not meant as a formal specification of the proposed extensions; see section 10 for that.
在本节中，我们将解释增量编码背后的概念。这并不是建议扩展的正式规范；见第10节。
When a client has a response in its cache, and wishes to ensure that this cache entry is current, HTTP/1.1 allows the client to do a "conditional GET", using one of two forms of "cache validators." In the traditional form, available in both HTTP/1.0 and in HTTP/1.1, the client may use the "If-Modified-Since" request-header to present to the server the "Last-Modified" timestamp (if any) that the server provided with the response. If the server's timestamp for the resource has not changed, it may send a response with a status code of 304 (Not Modified), which does not transmit the body of the resource. If the timestamp has changed, the server would normally send a response with a status code of 200 (OK), which carries a complete copy of the resource, and a new Last-Modified timestamp.
当客户机在其缓存中有响应，并且希望确保该缓存项是最新的时，HTTP/1.1允许客户机使用两种形式的“缓存验证器”之一执行“条件获取”。在传统形式中，HTTP/1.0和HTTP/1.1中都提供，客户机可以使用“If Modified-Since”请求标头向服务器提供服务器随响应提供的“上次修改”时间戳（如果有）。如果服务器的资源时间戳没有改变，它可以发送状态代码为304（未修改）的响应，该响应不传输资源主体。如果时间戳已更改，服务器通常会发送一个状态代码为200（OK）的响应，其中包含资源的完整副本和一个新的上次修改的时间戳。
This timestamp-based approach is prone to error because of the lack of timestamp resolution: if a resource changes twice during one second, the change might not be detectable. Therefore, HTTP/1.1 also allows the server to provide an entity tag with a response. An entity tag is an opaque string, constructed by the server according to its own needs; the protocol specification imposes a bare minimum of requirements on entity tags. (In particular, a "strong" entity tag must change if the value of the resource changes.) In this case, the client may validate its cache entry by sending its conditional request using the "If-None-Match" request-header, presenting the entity tag associated with the cached response. (The protocol defines several other ways to transmit entity tags, such as the "If-Range" header, used for short-circuiting an otherwise necessary round trip.) If the presented entity tag matches the server's current tag for the resource, the server should send a 304 (Not Modified) response. Otherwise, the server should send a 200 (OK) response, along with a complete copy of the resource.
由于缺乏时间戳解析，这种基于时间戳的方法容易出错：如果资源在一秒钟内更改两次，那么更改可能无法检测到。因此，HTTP/1.1还允许服务器提供带有响应的实体标记。实体标记是一个不透明的字符串，由服务器根据自己的需要构造；协议规范对实体标记施加了最低限度的要求。（特别是，如果资源的值改变，“强”实体标记必须改变。）在这种情况下，客户端可以通过使用“如果不匹配”请求头发送其条件请求来验证其缓存项，并显示与缓存响应关联的实体标记。（协议定义了几种传输实体标记的其他方式，例如用于短路其他必要往返的“If Range”头。）如果呈现的实体标记与服务器的资源当前标记匹配，服务器应发送304（未修改）响应。否则，服务器应发送200（确定）响应以及资源的完整副本。
In the existing HTTP protocol (HTTP/1.0 or HTTP/1.1), a client sending a conditional request can expect either of two responses:
在现有的HTTP协议（HTTP/1.0或HTTP/1.1）中，发送条件请求的客户端可以预期以下两种响应之一：
- status = 200 (OK), with a full copy of the resource, because the server's copy of the resource is presumably different from the client's cached copy.
- status=200（确定），具有资源的完整副本，因为服务器的资源副本可能与客户端的缓存副本不同。
- status = 304 (Not Modified), with no body, because the server's copy of the resource is presumably the same as the client's cached copy.
- status=304（未修改），没有正文，因为服务器的资源副本可能与客户端的缓存副本相同。
Informally, one could think of these as "deltas" of 100% and 0% of the resource, respectively. Note that these deltas are relative to a specific cached response. That is, a client cannot request a delta without specifying, somehow, which two instances of a resource are being differenced. The "new" instance is implicitly the current instance that the server would return for an unconditional request, and the "old" instance is the one that is currently in the client's cache. The cache validator (last-modified time or entity tag) is what is used to communicate to the server the identity of the old instance.
非正式地说，我们可以把它们分别看作是100%和0%资源的“三角洲”。请注意，这些增量与特定的缓存响应相关。也就是说，客户机无法在不指定资源的哪两个实例不同的情况下请求增量。“新”实例隐式地表示服务器将为无条件请求返回的当前实例，“旧”实例是当前在客户端缓存中的实例。缓存验证器（上次修改的时间或实体标记）用于向服务器传递旧实例的标识。
In order to support the transmission of actual deltas, an extension to HTTP/1.1 needs to provide these features:
为了支持实际增量的传输，HTTP/1.1的扩展需要提供以下功能：
1. A way to mark a request as conditional.
1. 将请求标记为有条件的方法。
2. A way to specify the old instance, to which the delta will be applied by the client.
2. 一种指定旧实例的方法，客户端将对其应用增量。
3. A way to indicate that the client is able to apply one or more specific forms of delta encoding.
3. 一种指示客户端能够应用一种或多种特定形式的增量编码的方法。
4. A way to mark a response as being delta-encoded in a particular format.
4. 将响应标记为以特定格式进行增量编码的一种方法。
The first two features are already provided by HTTP/1.1: the presence of a conditional request-header (such as "If-Modified-Since" or "If-None-Match") marks a request as conditional, and the value of that header uniquely specifies the old instance (ignoring the problem of last-modified timestamp granularity).
HTTP/1.1已经提供了前两个特性：存在条件请求头（例如“If Modified Since”或“If None Match”）将请求标记为条件请求，并且该头的值唯一地指定了旧实例（忽略上次修改的时间戳粒度问题）。
We defer discussion of the fourth feature, until section 5.6.
我们将第四个特性的讨论推迟到第5.6节。
The third feature, a way for the client to indicate that it is able to apply deltas (aside from the trivial 0% and 100% deltas), can be accomplished by transmitting a list of acceptable delta-encoding formats in a request-header field; specifically, the "A-IM" header. The presence of this list in a conditional request indicates that the client is able to apply delta-encoded cache updates.
第三个特性是客户端指示其能够应用增量（除了微不足道的0%和100%增量之外）的一种方式，可以通过在请求头字段中传输可接受的增量编码格式列表来实现；特别是“A-IM”标题。条件请求中存在此列表表示客户端能够应用增量编码的缓存更新。
For example, a client might send this request:
例如，客户端可能会发送此请求：
GET /foo.html HTTP/1.1 Host: bar.example.net If-None-Match: "123xyz" A-IM: vcdiff, diffe, gzip
GET/foo.html HTTP/1.1 Host:bar.example.net如果没有匹配：“123xyz”A-IM:vcdiff、dife、gzip
The meaning of this request is that:
本请求的含义是：
- The client wants to obtain the current value of /foo.html.
- 客户端希望获得/foo.html的当前值。
- It already has a cached response (instance) for that resource, whose entity tag is "123xyz".
- 它已经有了该资源的缓存响应（实例），其实体标记为“123xyz”。
- It is willing to accept delta-encoded updates using either of two formats, "diffe" (i.e., output from the UNIX "diff -e" command), and "vcdiff". (Encoding algorithms and formats, such as "vcdiff", are described in section 6.)
- 它愿意接受使用两种格式中的一种进行增量编码的更新，“diffe”（即从UNIX“diff-e”命令输出）和“vcdiff”。（第6节介绍了编码算法和格式，如“vcdiff”。）
- It is willing to accept responses that have been compressed using "gzip," whether or not these are delta-encoded. (It might be useful to compress the output of "diff -e".) However, based on the mandatory ordering constraint specified in section 10.5.3, if both delta encoding and compression are applied, then this "A-IM" request header specifies that compression should be done last.
- 它愿意接受使用“gzip”压缩的响应，不管这些响应是否是增量编码的。（压缩“diff-e”的输出可能很有用。）但是，根据第10.5.3节中规定的强制排序约束，如果同时应用了增量编码和压缩，则此“A-IM”请求头指定压缩应最后进行。
If, in this example, the server's current entity tag for the resource is still "123xyz", then it should simply return a 304 (Not Modified) response, as would a traditional server.
在本例中，如果服务器当前的资源实体标记仍然是“123xyz”，那么它应该像传统服务器一样返回304（未修改）响应。
If the entity tag has changed, presumably but not necessarily because of a modification of the resource, the server could instead compute the delta between the instance whose entity tag was "123xyz" and the current instance.
如果实体标记发生了更改，可能是因为修改了资源，但不一定是因为修改了资源，那么服务器可以计算实体标记为“123xyz”的实例与当前实例之间的增量。
We defer discussion of what the server needs to store, in order to compute deltas, until section 7.
为了计算增量，我们将服务器需要存储什么的讨论推迟到第7节。
We note that if a client indicates it is willing to accept deltas, but the server does not support this form of instance-manipulation, the server will simply ignore this aspect of the request. (HTTP always allows an implementation to ignore a header that is not required by a specification that the implementation complies with, and the specification of "A-IM" allows the server to ignore an instance-manipulation it does not understand.) So if a server either does not implement the A-IM header at all, or does not implement any
我们注意到，如果客户机表示愿意接受增量，但服务器不支持这种形式的实例操作，那么服务器将忽略请求的这一方面。（HTTP总是允许实现忽略实现所遵循的规范不需要的头，“a-IM”规范允许服务器忽略它不理解的实例操作。）因此，如果服务器根本没有实现a-IM头，或者没有实现任何
of the instance manipulations listed in the A-IM header, it acts as if the client had not requested a delta-encoded response: the server generates a status-200 response.
在A-IM头中列出的实例操作中，它的行为就好像客户端没有请求增量编码的响应：服务器生成status-200响应。
The server is not required to transmit a delta-encoded response. For example, the result might be larger than the current size of the resource. The server might not be able to compute a delta for this type of resource (e.g., a compressed binary format); the server might not have sufficient CPU cycles for the delta computation; the server might not support any of the delta formats supported by the client; or, the network bandwidth might be high enough that the delay involved in computing the delta is not worth the delay avoided by sending a smaller response.
服务器无需传输增量编码响应。例如，结果可能大于资源的当前大小。服务器可能无法计算此类资源的增量（例如，压缩二进制格式）；服务器可能没有足够的CPU周期进行增量计算；服务器可能不支持客户端支持的任何增量格式；或者，网络带宽可能足够高，以至于计算增量所涉及的延迟不值得通过发送较小的响应来避免延迟。
However, if the server does want to compute a delta, and the set of encodings it supports has more than one encoding in common with the set offered by the client, which encoding should it use? This is mostly at the option of the server, although the client can express preferences using "Quality Values" (or "qvalues") in the "A-IM" header. The HTTP/1.1 specification [10] describes qvalues in more detail. (Clients may prefer one delta encoding format over another that generates a smaller encoding, if the decoding costs for the first format are lower and the client is resource-constrained.)
但是，如果服务器确实想要计算增量，并且它支持的编码集与客户端提供的编码集有多个相同的编码，那么它应该使用哪种编码？这主要由服务器选择，尽管客户端可以使用“A-IM”头中的“质量值”（或“qvalues”）来表示首选项。HTTP/1.1规范[10]更详细地描述了qvalues。（如果第一种格式的解码成本较低且客户端资源受限，则客户端可能更喜欢一种增量编码格式，而不是生成较小编码的另一种格式。）
Server implementations have a number of possible approaches. For example, if CPU cycles are plentiful and network bandwidth is scarce, the server might compute each of the possible encodings and then send the smallest result. Or the server might use heuristics to choose an encoding format, based on things such as the content-type of the resource, the current size of the resource, and the expected amount of change between instances of the resource.
服务器实现有许多可能的方法。例如，如果CPU周期充足而网络带宽不足，服务器可能会计算每个可能的编码，然后发送最小的结果。或者，服务器可以使用启发式方法根据资源的内容类型、资源的当前大小以及资源实例之间的预期更改量等情况选择编码格式。
Note that it might pay to cache the deltas internally to the server, if a resource is typically requested by several different delta-capable clients between modifications. In this case, the cost of computing a delta may be amortized over many responses, and so the server might use a more expensive computation.
请注意，如果资源通常在修改之间由几个不同的具有增量功能的客户端请求，那么在服务器内部缓存增量可能会有好处。在这种情况下，计算增量的成本可能会分摊到许多响应中，因此服务器可能会使用更昂贵的计算。
A response using delta encoding must be identified as such. This is done using the "IM" response-header, specified in section 10.5.2.
必须识别使用增量编码的响应。这是使用第10.5.2节规定的“IM”响应标题完成的。
However, a simplistic application of this approach would cause serious problems if a delta-encoded response flows through an intermediate (proxy) cache that is not cognizant of the delta
但是，如果增量编码的响应流经不知道增量的中间（代理）缓存，则这种方法的简单应用将导致严重问题
mechanism. Because the Internet still includes a significant number of HTTP/1.0 caches, which might never be entirely replaced, and because the HTTP specifications insist that message recipients ignore any header field that they do not understand, a non-delta-capable proxy cache that receives a delta-encoded response might store that response, and might later return it to a non-delta-capable client that has made a request for the same resource. This naive client would believe that it has received a valid copy of the entire resource, with predictably unpleasant results.
机械装置由于Internet仍然包含大量HTTP/1.0缓存，这些缓存可能永远不会被完全替换，并且由于HTTP规范坚持邮件收件人忽略他们不理解的任何头字段，因此接收增量编码响应的不支持增量的代理缓存可能会存储该响应，并可能稍后将其返回给对同一资源发出请求的不支持增量的客户端。这个天真的客户机会认为它已经收到了整个资源的有效副本，结果令人不快。
To solve this problem, we propose that delta-encoded responses (actually, all instance-manipulated responses) be identified as such using a new HTTP status code. For specificity in the discussion that follows, we will use the (currently unassigned) code of 226, with a reason phrase of "IM Used". (We see no benefit in spelling out the words "Instance Manipulation Used," since this requires the transmission of unnecessary bytes, and this Reason-phrase should not normally be seen by human users.) There is some precedent for this approach: the HTTP/1.1 specification introduces the 206 (Partial Content) status code, for the transmission of sub-ranges of a resource. Existing proxies apparently forward responses with unknown status codes, and do not attempt to cache them.
为了解决这个问题，我们建议使用一个新的HTTP状态代码来识别增量编码的响应（实际上，所有实例操作的响应）。为了在下面的讨论中说明具体情况，我们将使用（目前未指定）代码226，其中的原因短语为“IM Used”。（我们认为拼写“使用实例操纵”一词没有任何好处，因为这需要传输不必要的字节，而这个原因短语通常不应该被人类用户看到。）这种方法有一些先例：HTTP/1.1规范引入了206（部分内容）状态码，用于传输资源的子范围。现有代理显然转发具有未知状态代码的响应，并且不尝试缓存它们。
An alternative to using a new status code would be to use the "Expires" header to prevent HTTP/1.0 caches from storing the response, then use "Cache-Control: max-age" (defined in HTTP/1.1) to allow more modern caches to store delta-encoded responses. This adds many bytes to the response headers, and so would reduce the effectiveness of delta encoding. It is also not entirely clear that this approach suppresses all caching by all HTTP/1.0 proxies.
使用新状态代码的替代方法是使用“Expires”头阻止HTTP/1.0缓存存储响应，然后使用“Cache Control:max age”（在HTTP/1.1中定义）允许更现代的缓存存储增量编码的响应。这会向响应头添加许多字节，因此会降低增量编码的有效性。还不完全清楚这种方法是否会抑制所有HTTP/1.0代理的所有缓存。
We were reluctant to define an additional status code as part of the support for delta encoding. However, we see no other efficient way to remain compatible with the deployed base of HTTP/1.0 cache implementations.
我们不愿意定义额外的状态代码作为增量编码支持的一部分。然而，我们看不到其他有效的方法来保持与部署的HTTP/1.0缓存实现的兼容。
Although we are not aware of any HTTP/1.1 proxy implementations that would attempt to cache a response with an unknown 2xx status code, the HTTP/1.1 specification does allow this behavior if the response carries an Expires or Cache-Control header field that explicitly allows caching. This would present a problem when a 226 (IM Used) response carries such headers.
尽管我们不知道有任何HTTP/1.1代理实现会尝试缓存具有未知2xx状态代码的响应，但如果响应包含明确允许缓存的Expires或cache Control header字段，HTTP/1.1规范确实允许此行为。当226（IM已使用）响应带有此类头时，这将出现问题。
The solution in that case is to exploit the Cache Control Extensions mechanism from the HTTP/1.1 specification. We define a new cache-directive, "im", which indicates that the "no-store" cache-directive may be ignored by implementations that conform to the specification for the IM and A-IM headers.
这种情况下的解决方案是利用HTTP/1.1规范中的缓存控制扩展机制。我们定义了一个新的缓存指令“im”，它表示符合im和a-im头规范的实现可能会忽略“no-store”缓存指令。
For example, this response:
例如，此响应：
HTTP/1.1 226 IM Used
ETag: "489uhw"
IM: vcdiff
Date: Tue, 25 Nov 1997 18:30:05 GMT
Cache-Control: no-store, im, max-age=30
HTTP/1.1 226 IM Used
ETag: "489uhw"
IM: vcdiff
Date: Tue, 25 Nov 1997 18:30:05 GMT
Cache-Control: no-store, im, max-age=30
...
...
"MUST NOT" be stored by a cache that complies with the HTTP/1.1 specification (which states that the max-age cache-directive "implies that the response is cacheable [...] unless some other, more restrictive cache directive is also present."). However, a cache that does comply with the specification for the im cache-directive (i.e., a cache that complies with the specification for the A-IM and IM header fields, and the 226 status code) ignores the no-store directive, and therefore sees the max-age directive as allowing caching.
“不得”由符合HTTP/1.1规范的缓存存储（该规范规定，最大年龄缓存指令“意味着响应是可缓存的[…]，除非还存在其他更严格的缓存指令。”）。但是，符合im cache指令规范的缓存（即，符合a-im和im头字段规范以及226状态代码的缓存）忽略no store指令，因此将max age指令视为允许缓存。
We are not entirely sure that all HTTP/1.1 caches obey the rule that the max-age directive is overridden by the no-store directive. If operational testing reveals this to be a problem, more elaborate solutions are possible.
我们不能完全确定所有HTTP/1.1缓存是否都遵守max age指令被no store指令覆盖的规则。如果运行测试表明这是一个问题，则可能有更详细的解决方案。
Warning to origin server implementors: it does not suffice to send
对源服务器实现者的警告：仅发送
Vary: If-None-Match, A-IM
变化：如果没有匹配，A-IM
in status-226 responses. We have discovered at least one scenario where this does not prevent a proxy cache that does not implement IM and A-IM from incorrectly "validating" a cached 226 response.
在状态-226的答复中。我们发现，至少有一种情况下，这不会阻止未实现IM和a-IM的代理缓存错误地“验证”缓存的226响应。
A delta-encoded response differs from a standard response in four ways:
增量编码响应在四个方面不同于标准响应：
1. It carries a status code of 226 (IM Used).
1. 它的状态代码为226（IM已使用）。
2. It carries an "IM" response-header field, indicating which delta encoding is used in this response.
2. 它带有一个“IM”响应头字段，指示此响应中使用的增量编码。
3. Its message-body is a delta encoding of the current instance, rather than a full copy of the instance.
3. 它的消息体是当前实例的增量编码，而不是实例的完整副本。
4. It might carry several other new headers, as described later in this document.
4. 它可能会携带其他几个新的标题，如本文档后面所述。
For example, a response to the request given in section 5.2 might look like:
例如，对第5.2节中给出的请求的响应可能如下所示：
HTTP/1.1 226 IM Used
ETag: "489uhw"
IM: vcdiff
Date: Tue, 25 Nov 1997 18:30:05 GMT
HTTP/1.1 226 IM Used
ETag: "489uhw"
IM: vcdiff
Date: Tue, 25 Nov 1997 18:30:05 GMT
...
...
(We do not show the actual contents of the response body, since this is a binary format.)
（我们不显示响应正文的实际内容，因为这是一种二进制格式。）
Note: the Etag header in a 226 response with a delta encoding provides the entity tag of the current instance of the resource variant. It is not meaningful to associate an entity tag with the delta value, which is not an instance.
注意：226响应中带有增量编码的Etag头提供了资源变量当前实例的实体标记。将实体标记与不是实例的增量值关联没有意义。
In the example used in section 5.2, the client sends:
在第5.2节中使用的示例中，客户机发送：
GET /foo.html HTTP/1.1 Host: bar.example.net If-None-Match: "123xyz" A-IM: vcdiff, diffe, gzip
GET/foo.html HTTP/1.1 Host:bar.example.net如果没有匹配：“123xyz”A-IM:vcdiff、dife、gzip
and the server either responds with a 304 (Not Modified) response, or with the appropriate delta encoding.
服务器要么响应304（未修改）响应，要么响应适当的增量编码。
Here are a few more examples, to clarify how the client request should be interpreted.
这里还有几个例子，以澄清应该如何解释客户机请求。
If the client sends
如果客户端发送
GET /foo.html HTTP/1.1
Host: bar.example.net
If-None-Match: "123xyz"
A-IM: vcdiff, diffe, gzip, range
Range: bytes=0-99
GET /foo.html HTTP/1.1
Host: bar.example.net
If-None-Match: "123xyz"
A-IM: vcdiff, diffe, gzip, range
Range: bytes=0-99
then the meaning is the same as in the example above, except that after the delta encoding (and compression, if any) is computed, the server then returns only the first 100 bytes of the output of the delta encoding. (If it is shorter than 100 bytes, the entire delta encoding is returned.) Because the "range" token appears last in the "A-IM" header, this tells the origin server to apply any range selection after the other instance-manipulations.
然后，其含义与上述示例中的含义相同，只是在计算了增量编码（以及压缩，如果有的话）之后，服务器只返回增量编码输出的前100个字节。（如果小于100字节，则返回整个增量编码。）因为“range”标记最后出现在“A-IM”头中，这会告诉源服务器在其他实例操作之后应用任何范围选择。
The interaction between the If-Range mechanism and delta encoding is somewhat complex. (If-Range means, informally, "if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity.") Here is an example that should clarify the use of this combination.
中频范围机制和增量编码之间的相互作用有些复杂。（如果范围非正式地表示，“如果实体未更改，请将我缺少的部分发送给我；否则，请将整个新实体发送给我。”）下面是一个示例，应该说明此组合的用法。
Suppose that the client wants to have the complete current instance of http://bar.example.net/foo.html. It already has a (complete) cache entry for this URI, with entity tag "A", so it issues this request:
假设客户机希望具有的完整当前实例http://bar.example.net/foo.html. 它已经有了这个URI的（完整的）缓存项，带有实体标记“a”，所以它发出这个请求：
GET /foo.html HTTP/1.1 host: bar.example.net If-None-Match: "A" A-IM: vcdiff
GET/foo.html HTTP/1.1 host:bar.example.net如果没有匹配：“A”A-IM:vcdiff
Suppose that the server's current instance has entity tag "B", and that the server also has retained a copy of the instance with entity tag "A". Then, the server could compute the difference between "B" and "A", and respond with:
假设服务器的当前实例具有实体标记“B”，并且服务器还保留了具有实体标记“a”的实例副本。然后，服务器可以计算“B”和“A”之间的差异，并响应：
HTTP/1.1 226 IM Used
Etag: "B"
IM: vcdiff
Date: Tue, 25 Nov 1997 18:30:05 GMT
Content-Length: 1000
HTTP/1.1 226 IM Used
Etag: "B"
IM: vcdiff
Date: Tue, 25 Nov 1997 18:30:05 GMT
Content-Length: 1000
...
...
but the network connection is terminated after the client has received exactly 900 bytes of the message body for the delta-encoded content.
但是，在客户端接收到增量编码内容的消息正文的900字节后，网络连接将终止。
The client wants to retrieve the remaining 100 bytes of the delta encoding that was being sent in the interrupted response. It therefore should send:
客户端希望检索在中断响应中发送的增量编码的剩余100字节。因此，它应发送：
GET /foo.html HTTP/1.1
host: bar.example.net
If-None-Match: "A"
If-Range: "B"
A-IM: vcdiff,range
Range: bytes=900-
GET /foo.html HTTP/1.1
host: bar.example.net
If-None-Match: "A"
If-Range: "B"
A-IM: vcdiff,range
Range: bytes=900-
This rather elaborate request has a well-defined meaning, which depends on the current entity tag Tcur of the instance when the server receives the request:
这个相当复杂的请求具有定义良好的含义，这取决于服务器接收请求时实例的当前实体标记Tcur：
Tcur = "A" (i.e., for some reason, the instance has reverted to the value already in the client's cache). The server should return a 304 (Not Modified) response, as required by the HTTP/1.1 specification for "If-None-Match".
Tcur=“A”（即，由于某种原因，实例已恢复为客户端缓存中已存在的值）。服务器应该返回304（未修改）响应，这是HTTP/1.1规范“If None Match”所要求的。
Tcur = "B" (i.e., the instance has not changed again). The HTTP/1.1 specification for "If-None-Match", in this case, is that the header field is ignored (by a server that does not understand delta encoding). Therefore, this is equivalent to the client's previous request, except that the Range selection is applied after the vcdiff instance manipulation (if both are to be applied). So the (delta-aware) server again computes the delta between the "A" instance and the "B" instance (or uses a cached computation of the delta), then applies the Range selection, and returns a 226 (IM Used) response, with an message-body containing bytes 900 to 999 of the result of the vcdiff encoding, with an "IM:vcdiff,range" response header.
Tcur=“B”（即实例没有再次更改）。在本例中，“If None Match”的HTTP/1.1规范是忽略标头字段（由不理解增量编码的服务器忽略）。因此，这相当于客户机以前的请求，只是范围选择是在vcdiff实例操作之后应用的（如果两者都要应用的话）。因此（增量感知）服务器再次计算“A”实例和“B”实例之间的增量（或使用增量的缓存计算），然后应用范围选择，并返回226（IM Used）响应，消息体包含vcdiff编码结果的900到999字节，以及“IM:vcdiff，Range”响应头。
Tcur = "C" (i.e., the instance has changed again). In this case, the HTTP/1.1 specification for "If-None-Match" again means that this is equivalent to an unconditional request for the current instance. The specification for "If-Range" requires the server to return the entire current instance. However, a delta-aware server can construct the delta between the "A" instance described by the "If-None-Match" field and the current ("C") instance, and return a 226 (IM Used) response, with an "IM:vcdiff" response header.
Tcur=“C”（即实例再次更改）。在这种情况下，“If None Match”的HTTP/1.1规范再次意味着这相当于对当前实例的无条件请求。“If Range”的规范要求服务器返回整个当前实例。然而，增量感知服务器可以在“If None Match”字段描述的“a”实例和当前（“C”）实例之间构造增量，并返回带有“IM:vcdiff”响应头的226（IM Used）响应。
If the client's request had not included the "If-None-Match: "A"" header field, the server could not have computed a delta, since it would not have known which entire instance was already available to
如果客户机的请求没有包含“If None Match:”A“”头字段，则服务器无法计算增量，因为它不知道哪个整个实例已可用于
the client. If the request had not included the "If-Range: "B"" header field, the server could not have distinguished between the latter two cases (Tcur = "B" or Tcur = "C") and would not have been able to apply the Range selection to the result of delta encoding.
客户。如果请求中没有包含“If Range:”B”头字段，服务器就无法区分后两种情况（Tcur=“B”或Tcur=“C”），也无法将范围选择应用于增量编码的结果。
On the other hand, suppose that the client has a cache entry for the "A" instance of http://bar.example.net/foo.html, and it has already received the first 900 bytes of a new instance "B" (perhaps as the result of an aborted transfer). Now the client wants to receive the entire current instance, so it could send this request:
另一方面，假设客户机为的“a”实例有一个缓存项http://bar.example.net/foo.html，并且它已经接收到新实例“B”的前900字节（可能是传输中止的结果）。现在，客户端希望接收整个当前实例，因此可以发送此请求：
GET /foo.html HTTP/1.1
host: bar.example.net
If-None-Match: "A"
If-Range: "B"
A-IM: range,vcdiff
Range: bytes=900-
GET /foo.html HTTP/1.1
host: bar.example.net
If-None-Match: "A"
If-Range: "B"
A-IM: range,vcdiff
Range: bytes=900-
In this example, as in the previous example, if Tcur = "A" then the server should send 304 (Not Modified), and if Tcur = "C", then the server should send the entire new instance, either as a 200 response or as a delta encoding against instance "A".
在此示例中，与前一示例一样，如果Tcur=“A”，则服务器应发送304（未修改），如果Tcur=“C”，则服务器应发送整个新实例，作为200响应或针对实例“A”的增量编码。
However, if Tcur = "B", in this case the server should first select the specified range (bytes 900 through the end) from both instances "A" and "B", then compute the delta encoding between these ranges (using vcdiff), and then transmit the result using a 226 (IM Used) response with an "IM:range,vcdiff" response header.
但是，如果Tcur=“B”，在这种情况下，服务器应首先从实例“A”和“B”中选择指定的范围（字节900到结尾），然后计算这些范围之间的增量编码（使用vcdiff），然后使用226（使用IM）响应和“IM:range，vcdiff”响应头传输结果。
6 Encoding algorithms and formats
6编码算法和格式
A number of delta encoding algorithms and formats have been described in the literature:
文献中描述了许多增量编码算法和格式：
diff -e The UNIX "diff" program is ubiquitously available, and is relatively fast for both encoding and decoding (decoding is actually done using the "ed" program). However, the size of the resulting deltas is relatively large. This algorithm can only be used on text-format files.
diff-e UNIX“diff”程序无处不在，编码和解码速度都相对较快（解码实际上是使用“ed”程序完成的）。但是，生成的三角洲的大小相对较大。此算法只能用于文本格式文件。
diff -e | gzip Running the output of "diff" through a compression algorithm such as "gzip" [5] (or, perhaps better, "deflate" [7, 6]) yields a more compact encoding, but the costs of encoding and decoding are much higher than for "diff" by itself. This algorithm can only be used on text-format files.
diff-e | gzip通过诸如“gzip”[5]（或者更好的是，“deflate”[7,6]）之类的压缩算法运行“diff”的输出，可以产生更紧凑的编码，但是编码和解码的成本远远高于“diff”本身。此算法只能用于文本格式文件。
vcdiff (vdelta) The algorithm that generates the "vcdiff" format [19, 20] inherently compresses its output, and generally produces smaller results than the combination of "diff" and "gzip". The algorithm also runs much faster, and can be applied to binary-format input. The "vcdiff" format is based on previous work on an algorithm named "vdelta." (Note that the "vcdiff" format can be used either for delta encoding or as a compressed format, so two different instance-manipulation values would have to be registered in order to distinguish these two uses, should its use as a compressed format be adopted.) The most recent published study suggests that "vdelta" is the best overall delta algorithm [16].
vcdiff（vdelta）生成“vcdiff”格式的算法[19,20]固有地压缩其输出，并且通常产生比“diff”和“gzip”组合更小的结果。该算法运行速度更快，可以应用于二进制格式的输入。“vcdiff”格式是基于以前对名为“vdelta”的算法所做的工作。（注意，“vcdiff”格式既可以用于增量编码，也可以用作压缩格式，因此，如果将其用作压缩格式，则必须注册两个不同的实例操作值，以区分这两种用途。）最近发表的研究表明，“vdelta”是最好的整体增量算法[16]。
gdiff The gdiff format [14] was specified as a generic, algorithm-independent format for expressing deltas. Because it is more generic it is easy to implement, but it may not be the most compact encoding format.
gdiff gdiff格式[14]被指定为一种通用的、与算法无关的格式，用于表示增量。因为它更通用，所以很容易实现，但它可能不是最紧凑的编码格式。
Our proposal does not recommend any specific algorithm or format, but rather encourages client and server implementors to choose the most appropriate one(s). However, to avoid the possibility of excessively long "A-IM" headers, we suggest that, after some period of experimentation, it might be reasonable to specify a "recommended" set of delta formats for general-purpose HTTP implementations.
我们的建议不推荐任何特定的算法或格式，而是鼓励客户机和服务器实现者选择最合适的算法或格式。然而，为了避免“A-IM”头过长的可能性，我们建议在经过一段时间的实验后，为通用HTTP实现指定一组“推荐的”增量格式可能是合理的。
We suspect that it should be possible to devise a delta encoding algorithm appropriate for use on typical image encodings, such as GIF and JPEG. Although experiments with vdelta have not shown much potential [23], this may simply be because these experiments used vdelta directly on the already-compressed forms of these encodings. However, it might be necessary to devise a delta encoding algorithm that is aware of the two-dimensional nature of images. We have some expectation that this is possible, since MPEG compression relies on computing deltas between successive frames of a video stream.
我们怀疑应该可以设计一种适合于典型图像编码（如GIF和JPEG）的增量编码算法。尽管使用vdelta的实验没有显示出太多的潜力[23]，这可能仅仅是因为这些实验直接在这些编码的已压缩形式上使用vdelta。然而，可能有必要设计一种了解图像二维性质的增量编码算法。我们期望这是可能的，因为MPEG压缩依赖于计算视频流连续帧之间的增量。
7 Management of base instances
7基本实例的管理
If the time between modifications of a resource is less than the typical eviction time for responses in client caches, this means that the "old instance" indicated in a client's conditional request might not refer to the most recent prior instance. This raises the question of how many old instances of a resource should be maintained by the server, if any. We call these old instances "base instances."
如果修改资源之间的时间间隔小于客户端缓存中响应的典型逐出时间，这意味着客户端条件请求中指示的“旧实例”可能不会引用最新的先前实例。这就提出了一个问题，即服务器应该维护多少旧的资源实例（如果有的话）。我们称这些旧实例为“基本实例”
There are many possible options for server implementors. For example:
服务器实现者有许多可能的选择。例如：
- The server might not store any old instances, and so would never respond with a delta.
- 服务器可能不存储任何旧实例，因此永远不会使用增量进行响应。
- The server might only store the most recent prior instance; requests attempting to validate this instance could be answered with a delta, but requests attempting to validate older instances would be answered with a full copy of the resource.
- 服务器可能只存储最新的先前实例；尝试验证此实例的请求可以用增量来回答，但尝试验证旧实例的请求将用资源的完整副本来回答。
- The server might store all prior instances, allowing it to provide a delta response for any client request.
- 服务器可能存储所有以前的实例，从而允许它为任何客户端请求提供增量响应。
- The server might store only a subset of the prior instances. The use of a Least Recently Used (LRU) algorithm to determine this kind of subset has proved effective in some similar circumstances, such as cache replacement.
- 服务器可能只存储先前实例的一个子集。在一些类似的情况下，如缓存替换，使用最近最少使用（LRU）算法来确定这类子集已被证明是有效的。
The server might not have to store prior instances explicitly. It might, instead, store just the deltas between specific base instances and subsequent instances (or the inverse deltas between base instances and prior instances). This approach might be integrated with a cache of computed deltas.
服务器可能不必显式存储以前的实例。相反，它可能只存储特定基础实例和后续实例之间的增量（或基础实例和先前实例之间的反向增量）。此方法可能与计算增量缓存集成。
None of these approaches necessarily requires additional protocol support. However, if a server administrator wants to store only a subset of the prior instances, but would like the server to be able to respond using deltas as often as possible, then the client needs some additional information. Otherwise, the client's "If-None-Match" header might specify a base instance not stored at the server, even though an appropriate base instance is held in the client's cache.
这些方法都不一定需要额外的协议支持。但是，如果服务器管理员希望只存储先前实例的子集，但希望服务器能够尽可能经常地使用增量进行响应，那么客户端需要一些附加信息。否则，客户机的“If None Match”头可能会指定一个未存储在服务器上的基本实例，即使相应的基本实例保存在客户机的缓存中。
We identify two additional protocol changes to help solve this problem.
我们确定了另外两个协议更改以帮助解决此问题。
Although the examples we have given so far show only one entity tag in an "If-None-Match" header, the HTTP/1.1 specification allows the header to carry more than one entity-tag. This feature was included in HTTP/1.1 to support efficient caching of multiple variants of a resource, but it is not restricted to that use.
尽管到目前为止我们给出的示例只显示了“If None Match”标头中的一个实体标记，但HTTP/1.1规范允许标头携带多个实体标记。HTTP/1.1中包含此功能是为了支持资源的多个变体的高效缓存，但并不限于此用途。
Suppose that a client has kept more than one instance of a resource in its cache. That is, not only does it keep the most recent instance, but it also holds onto copies of one or more prior, invalid instances. (Alternatively, it might retain sufficient delta or
假设客户机在其缓存中保留了一个以上的资源实例。也就是说，它不仅保留最近的实例，而且还保留一个或多个以前的无效实例的副本。（或者，它可以保留足够的增量或
inverse-delta information to reconstruct older instances.) In this case, it could use its conditional request to tell the server about all of the instances it could apply a delta to. For example, the client might send:
在这种情况下，它可以使用其条件请求告诉服务器它可以应用增量的所有实例。例如，客户端可能会发送：
GET /foo.html HTTP/1.1 host: bar.example.net If-None-Match: "123xyz", "337pey", "489uhw" A-IM: vcdiff
GET/foo.html HTTP/1.1 host:bar.example.net如果没有匹配：“123xyz”、“337pey”、“489uhw”A-IM:vcdiff
to indicate that it has three instances of this resource in its cache. If the server is able to generate a delta from any of these prior instances, it can select the appropriate base instance, compute the delta, and return the result to the client.
以指示其缓存中有此资源的三个实例。如果服务器能够从之前的任何实例生成增量，那么它可以选择适当的基本实例，计算增量，并将结果返回给客户端。
In this case, however, the server must also tell the client which base instance to use, and so we need to define a response header, named "Delta-Base", for this purpose. For example, the server might reply:
然而，在这种情况下，服务器还必须告诉客户端要使用哪个基本实例，因此我们需要为此定义一个名为“Delta base”的响应头。例如，服务器可能会答复：
HTTP/1.1 226 IM Used
ETag: "1acl059"
IM: vcdiff
Delta-Base: "337pey"
Date: Tue, 25 Nov 1997 18:30:05 GMT
HTTP/1.1 226 IM Used
ETag: "1acl059"
IM: vcdiff
Delta-Base: "337pey"
Date: Tue, 25 Nov 1997 18:30:05 GMT
This response tells the client to apply the delta to the cached response with entity tag "337pey", and to associate the entity tag "1acl059" with the result.
此响应告诉客户端将增量应用于实体标记为“337pey”的缓存响应，并将实体标记“1acl059”与结果关联。
Of course, if the server has retained more than one of the prior instances identified by the client, this could complicate the problem of choosing the optimal delta to return, since now the server has a choice not only of the delta format, but also of the base instance to use.
当然，如果服务器保留了客户端标识的多个先前实例，这可能会使选择要返回的最佳增量的问题复杂化，因为现在服务器不仅可以选择增量格式，还可以选择要使用的基本实例。
Support for multiple entity tags in choosing the base instance implies that a client might benefit from storing multiple old instances of a resource in its cache. A client with finite space would not want to keep all old instances, so it must manage its cache for maximal effectiveness by saving those instances most likely to be useful for future deltas. Although this could be accomplished using information purely local to the client (e.g., an LRU algorithm), certain "hint" information from the server could improve the client's ability to manage its cache. The use of hints for improving Web cache performance has been described previously [4, 22].
在选择基本实例时支持多个实体标记意味着客户机可能会受益于在其缓存中存储资源的多个旧实例。具有有限空间的客户机不希望保留所有旧实例，因此它必须通过保存最有可能用于未来增量的实例来管理其缓存，以获得最大的效率。虽然这可以通过使用客户机本地信息（例如，LRU算法）来实现，但来自服务器的某些“提示”信息可以提高客户机管理其缓存的能力。前面已经描述了如何使用提示来提高Web缓存性能[4,22]。
If the server intends to retain certain instances and not others, it can label the responses that transmit the retained instances. This would help the client manage its cache, since it would not have to retain all prior instances on the possibility that only some of them might be useful later. The label is a hint to the client, not a promise that the server will indefinitely retain an instance.
如果服务器打算保留某些实例而不是其他实例，它可以标记传输保留实例的响应。这将有助于客户机管理其缓存，因为它不必保留所有以前的实例，因为以后可能只有其中一些实例有用。标签是对客户端的提示，而不是服务器将无限期保留实例的承诺。
We propose adding a new directive to the existing "Cache-Control" header for this purpose, named "retain". For example, in response to an unconditional request, the server might send:
为此，我们建议在现有的“Cache-Control”头中添加一个名为“retain”的新指令。例如，为了响应无条件请求，服务器可能会发送：
HTTP/1.1 200 OK
ETag: "337pey"
Date: Tue, 25 Nov 1997 18:30:05 GMT
Cache-Control: retain
HTTP/1.1 200 OK
ETag: "337pey"
Date: Tue, 25 Nov 1997 18:30:05 GMT
Cache-Control: retain
to suggest that a delta-capable client should retain this instance. The "retain" directive could also appear in a delta response, referring to the current instance:
建议具有增量功能的客户端保留此实例。“retain”指令也可能出现在delta响应中，指的是当前实例：
HTTP/1.1 226 IM Used
ETag: "1acl059"
Date: Tue, 25 Nov 1997 18:30:05 GMT
Cache-Control: retain
IM: vcdiff
Delta-Base: "337pey"
HTTP/1.1 226 IM Used
ETag: "1acl059"
Date: Tue, 25 Nov 1997 18:30:05 GMT
Cache-Control: retain
IM: vcdiff
Delta-Base: "337pey"
The "retain" directive includes an optional timeout parameter, which the server can use if it expects to delete an old base instance at a particular time. For example,
“retain”指令包含一个可选的超时参数，如果服务器希望在特定时间删除旧的基本实例，则可以使用该参数。例如
HTTP/1.1 200 OK
ETag: "337pey"
Date: Tue, 25 Nov 1997 18:30:05 GMT
Cache-Control: retain=3600
HTTP/1.1 200 OK
ETag: "337pey"
Date: Tue, 25 Nov 1997 18:30:05 GMT
Cache-Control: retain=3600
means that the server intends to retain this base instance for one hour.
表示服务器打算将此基本实例保留一小时。
Another situation where a server can provide a hint to a client is where the server supports the delta mechanism in general, but does not intend to provide delta-encoded responses for a particular resource. By sending a "retain=0" directive, it indicates that the client should not waste request-header bytes attempting to obtain a delta-encoded response using this base instance (and, by implication, for this resource). It also indicates that the client ought not waste cache space on this instance after it has become stale. To
服务器可以向客户端提供提示的另一种情况是，服务器通常支持增量机制，但不打算为特定资源提供增量编码的响应。通过发送一个“retain=0”指令，它表明客户端不应该浪费请求头字节，以尝试使用此基本实例（并暗示此资源）获取增量编码响应。它还指出，在该实例过时之后，客户端不应该在该实例上浪费缓存空间。到
avoid wasting response-header bytes, a server ought not send "retain=0", except in reply to a request that attempts to obtain a delta-encoded response.
为了避免浪费响应头字节，服务器不应该发送“retain=0”，除非是为了响应试图获取增量编码响应的请求。
Note that the "retain" directive is orthogonal to the "max-age" directive. The "max-age" directive indicates how long a cache entry remains fresh (i.e.,can be used without contacting the origin server for revalidation); the "retain" directive is of interest to a client AFTER the cache entry has become stale.
请注意，“retain”指令与“max age”指令正交。“max age”指令指示缓存项保持新鲜的时间（即，无需联系原始服务器重新验证即可使用）；缓存项过时后，客户机会对“retain”指令感兴趣。
In practice, the "Cache-Control" response-header field might already be present, so the cost (in bytes) of sending this directive might be smaller than these examples implies.
实际上，“Cache Control”响应头字段可能已经存在，因此发送此指令的成本（以字节为单位）可能比这些示例所暗示的要小。
8 Deltas and intermediate caches
8个三角洲和中间缓存
Although we have designed the delta-encoded responses so that they will not be stored by naive proxy caches, if a proxy does understand the delta mechanism, it might be beneficial for it to participate in sending and receiving deltas.
尽管我们设计了增量编码的响应，以便它们不会被原始代理缓存存储，但如果代理确实了解增量机制，那么它参与发送和接收增量可能是有益的。
A proxy could participate in several independent ways:
代理可以通过几种独立的方式参与：
- In addition to forwarding a delta-encoded response, the proxy might store it, and then use it to reply to a subsequent request with a compatible "If-None-Match" field (i.e., one that is either a superset of the corresponding field of the request that first elicited the response, or one that includes the "Delta-Base" value in the cached response), and with a compatible "IM" response-header field (one that includes the actual delta-encoding format used in the response.) Of course, such uses are subject to all of the other HTTP rules concerning the validity of cache entries.
- 除了转发增量编码的响应外，代理还可以存储该响应，然后使用它以兼容的“If None Match”（如果不匹配）字段（即，第一次引发响应的请求的对应字段的超集，或者在缓存的响应中包含“delta Base”值的字段）响应后续请求，并且使用兼容的“IM”响应头字段（其中包括响应中使用的实际增量编码格式）。当然，此类使用受所有其他有关缓存项有效性的HTTP规则的约束。
- In addition to forwarding a delta-encoded response, the proxy might apply the delta to the appropriate entry in its own cache, which could then be used for later responses (even from non-delta-capable clients).
- 除了转发增量编码的响应外，代理还可以将增量应用于其自身缓存中的相应条目，该条目随后可用于后续响应（甚至来自不支持增量的客户端）。
- When the proxy receives a conditional request from a delta-capable client, and the proxy has a complete copy of an up-to-date ("fresh," in HTTP/1.1 terminology) response in its cache, it could generate a delta locally and return it to the requesting client.
- 当代理从支持增量的客户端接收到有条件的请求，并且代理在其缓存中有一个最新（“刷新”，在HTTP/1.1术语中）响应的完整副本时，它可以在本地生成增量并将其返回给请求客户端。
- When the proxy receives a request from a non-delta-capable client, it might convert this into a delta request before forwarding it to the server, and then (after applying a
- 当代理收到来自不支持增量的客户端的请求时，它可能会在将其转发到服务器之前将其转换为增量请求，然后（在应用
resulting delta response to one of its own cache entries) it would return a full-body response to the client (or a response with status code 206 or 304, as appropriate).
它将向客户端返回一个完整的主体响应（或状态代码为206或304的响应，视情况而定）。
All of these optional techniques increase proxy software complexity, and might increase proxy storage or CPU requirements. However, if applied carefully, they should help to reduce the latencies seen by end users, and load on the network. Generally, CPU speed and disk costs are improving faster than network latencies, so we expect to see increasing value available from complex proxy implementations.
所有这些可选技术都会增加代理软件的复杂性，并可能增加代理存储或CPU需求。但是，如果仔细应用，它们将有助于减少最终用户看到的延迟和网络负载。一般来说，CPU速度和磁盘成本的提高速度快于网络延迟，因此我们希望看到复杂代理实现的可用价值不断增加。
9 Digests for data integrity
9数据完整性摘要
When a recipient reassembles a complete HTTP response from several individual messages, it might be necessary to check the integrity of the complete response. For example, the client's cache might be corrupt, or the implementation of delta encoding (either at client or server) might have a bug.
当接收者从几个单独的消息重新组装完整的HTTP响应时，可能需要检查完整响应的完整性。例如，客户机的缓存可能已损坏，或者增量编码的实现（在客户机或服务器上）可能存在错误。
HTTP/1.1 includes mechanisms for ensuring the integrity of individual messages. A message may include a "Content-MD5" response header, which provides an MD5 message digest of the body of the message (but not the headers). The Digest Authentication mechanism [11] provides a similar message-digest function, except that it includes certain header fields. Neither of these mechanisms makes any provision for covering a set of data transmitted over several messages, as would be the case for the result of applying a delta-encoded response (or, for that matter, a Range response).
HTTP/1.1包括确保单个消息完整性的机制。消息可能包括“Content-MD5”响应头，它提供消息体（但不包括头）的MD5消息摘要。摘要身份验证机制[11]提供了类似的消息摘要功能，只是它包括某些头字段。这两种机制都没有为覆盖通过多个消息传输的一组数据做出任何规定，应用增量编码响应（或者，就此而言，范围响应）的结果就是如此。
Data integrity for reassembled messages requires the introduction of a new message header. Such a mechanism is proposed in a separate document [24]. One might still want to use the Digest Authentication mechanism, or something stronger, to protect delta messages against tampering.
重新组装的消息的数据完整性要求引入新的消息头。此类机制在另一份文件[24]中提出。您可能仍然希望使用摘要身份验证机制或更强大的机制来保护增量消息免受篡改。
10 Specification
10规格
In this specification, the key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described in RFC 2119 [3].
在本规范中，关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照RFC 2119[3]中的描述进行解释。
This specification defines a new HTTP parameter type, an instance-manipulation:
本规范定义了一种新的HTTP参数类型，即实例操作：
instance-manipulation = token [imparams]
实例操作=令牌[imparams]
imparams = ";" imparam-name [ "=" ( token | quoted-string ) ]
imparam-name = token
imparams = ";" imparam-name [ "=" ( token | quoted-string ) ]
imparam-name = token
Note that the imparam-name MUST NOT be "q", to avoid ambiguity with the use of qvalues (see [10]).
请注意，imparam名称不得为“q”，以避免使用qvalues时出现歧义（请参见[10]）。
The set of instance-manipulation values is initially:
实例操纵值集最初为：
- vcdiff A delta using the "vcdiff" encoding format [19, 20].
- vcdiff使用“vcdiff”编码格式的增量[19,20]。
- diffe The output of the UNIX "diff -e" command [26].
- 区分UNIX“diff-e”命令的输出[26]。
- gdiff The GDIFF encoding format [14].
- gdiff gdiff编码格式[14]。
- gzip Same definition as the HTTP "gzip" content-coding.
- gzip与HTTP“gzip”内容编码的定义相同。
- deflate Same definition as the HTTP "deflate" content-coding.
- deflate与HTTP“deflate”内容编码的定义相同。
- range A token indicating that the result is partial content, as the result of a range selection.
- 范围作为范围选择的结果，指示结果为部分内容的标记。
- identity A token used only in the A-IM header (not in the IM header), to indicate whether or not the identity instance-manipulation is acceptable.
- 标识仅在A-IM头（不在IM头）中使用的令牌，用于指示标识实例操作是否可接受。
For convenience in the rest of this specification, we define a subset of instance-manipulation values as delta-coding values:
为了方便本规范的其余部分，我们将实例操作值的子集定义为增量编码值：
delta-coding = "vcdiff" | "diffe" | "gdiff" | token
delta-coding = "vcdiff" | "diffe" | "gdiff" | token
Future instance-manipulation values might also be included in this list.
未来的实例操作值也可能包含在此列表中。
The Internet Assigned Numbers Authority (IANA) administers the name space for instance-manipulation values. Values and their meaning must be documented in an RFC or other peer-reviewed, permanent, and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. Subject to these constraints, name assignments are First Come, First Served (see RFC 2434 [25]).
Internet分配号码管理局（IANA）管理实例操作值的名称空间。值及其含义必须记录在RFC或其他同行评审的、永久的、随时可用的参考文件中，并提供足够的详细信息，以便独立实现之间的互操作性成为可能。根据这些限制条件，名称分配是先到先得（见RFC 2434[25]）。
This specification also inserts a new value in the IANA HTTP Status Code Registry (see RFC 2817 [18]). See section 10.4.1 for the specification of this code.
本规范还将在IANA HTTP状态码注册表中插入一个新值（请参阅RFC 2817[18]）。本规范的规范见第10.4.1节。
A server MAY send a delta-encoded response if all of these conditions are true:
如果所有这些条件均为真，服务器可能会发送增量编码响应：
1. The server would be able to send a 200 (OK) response for the request.
1. 服务器将能够为请求发送200（OK）响应。
2. The client's request includes an A-IM header field listing at least one delta-coding.
2. 客户机的请求包括列出至少一个增量编码的A-IM头字段。
3. The client's request includes an If-None-Match header field listing at least one valid entity tag for an instance of the Request-URI (a "base instance").
3. 客户机的请求包括一个If None Match头字段，其中列出了请求URI实例（“基本实例”）的至少一个有效实体标记。
A delta-encoded response:
增量编码响应：
- MUST carry a status code of 226 (IM Used).
- 必须携带状态代码226（IM已使用）。
- MUST include an IM header field listing, at least, the delta-coding employed.
- 必须包括一个IM头字段，至少列出所使用的增量编码。
- MAY include a Delta-Base header field listing the entity tag of the base-instance.
- 可以包括列出基本实例的实体标记的增量基本头字段。
The following new status code is defined for HTTP.
为HTTP定义了以下新的状态代码。
The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. The actual current instance might not be available except by combining this response with other previous or future responses, as appropriate for the specific instance-manipulation(s). If so, the headers of the resulting instance are the result of combining the headers from the status-226 response and the other instances, following the rules in section 13.5.3 of the HTTP/1.1 specification [10].
服务器已完成资源的GET请求，响应表示应用于当前实例的一个或多个实例操作的结果。实际的当前实例可能不可用，除非将此响应与其他以前或将来的响应相结合（视具体实例操作而定）。如果是这样，结果实例的头是根据HTTP/1.1规范[10]第13.5.3节中的规则，将status-226响应的头和其他实例的头组合起来的结果。
The request MUST have included an A-IM header field listing at least one instance-manipulation. The response MUST include an Etag header field giving the entity tag of the current instance.
该请求必须包含一个A-IM头字段，其中列出了至少一个实例操作。响应必须包括一个Etag头字段，该字段给出当前实例的实体标记。
A response received with a status code of 226 MAY be stored by a cache and used in reply to a subsequent request, subject to the HTTP expiration mechanism and any Cache-Control headers, and to the requirements in section 10.6.
根据HTTP过期机制和任何缓存控制头以及第10.6节的要求，状态代码为226的响应可由缓存存储并用于响应后续请求。
A response received with a status code of 226 MAY be used by a cache, in conjunction with a cache entry for the base instance, to create a cache entry for the current instance.
接收到的状态代码为226的响应可由高速缓存与基本实例的高速缓存条目一起使用，以创建当前实例的高速缓存条目。
The following headers are defined, for use as entity-headers. (Due to the terminological confusion discussed in section 3, some entity-headers are more properly associated with instances than with entities.)
定义了以下标题，用作实体标题。（由于第3节中讨论的术语混淆，一些实体标题与实例的关联比与实体的关联更恰当。）
The Delta-Base entity-header field is used in a delta-encoded response to specify the entity tag of the base instance.
Delta Base entity header字段用于Delta编码的响应中，以指定基本实例的实体标记。
Delta-Base = "Delta-Base" ":" entity-tag
Delta Base=“Delta Base”“：”实体标记
A Delta-Base header field MUST be included in a response with an IM header that includes a delta-coding, if the request included more than one entity tag in its If-None-Match header field.
如果请求在其if None Match标头字段中包含多个实体标记，则增量基本标头字段必须包含在包含增量编码的IM标头的响应中。
Any response with an IM header that includes a delta-coding MAY include a Delta-Base header.
具有包括增量编码的IM报头的任何响应可以包括增量基本报头。
We are not aware of other cases where a delta-encoded response MUST or SHOULD include a Delta-Base header, but we have not done an exhaustive or formal analysis. Implementors might be wise to include a Delta-Base header in every delta-encoded response.
我们不知道增量编码响应必须或应该包含增量基头的其他情况，但我们尚未进行详尽或正式的分析。实现者可能明智地在每个增量编码响应中包含一个增量基头。
A cache or proxy that receives a delta-encoded response that lacks a Delta-base header MAY add a Delta-Base header whose value is the entity tag given in the If-None-Match field of the request (but only if that field lists exactly one entity tag).
接收缺少增量基头的增量编码响应的缓存或代理可以添加增量基头，其值为请求的If None Match字段中给定的实体标记（但仅当该字段仅列出一个实体标记时）。
The IM response-header field is used to indicate the instance-manipulations, if any, that have been applied to the instance represented by the response. Typical instance manipulations include delta encoding and compression.
IM response header字段用于指示已应用于响应所表示的实例的实例操作（如果有）。典型的实例操作包括增量编码和压缩。
IM = "IM" ":" #(instance-manipulation)
IM = "IM" ":" #(instance-manipulation)
Instance-manipulations are defined in section 10.1.
第10.1节定义了实例操作。
As a special case, if the instance-manipulations include both range selection and at least one other non-identity instance-manipulation, the IM header field MUST be used to indicate the order in which all of these instance-manipulations, including range selection, were applied. If the IM header lists the "range" instance-manipulation, the response MUST include either a Content-Range header or a multipart/byteranges Content-Type in which each part contains a Content-Range header. (See section 10.10 for specific discussion of combining delta encoding and multipart/byteranges.)
作为一种特殊情况，如果实例操作包括范围选择和至少一个其他非标识实例操作，则必须使用IM头字段指示所有这些实例操作（包括范围选择）的应用顺序。如果IM头列出了“范围”实例操作，则响应必须包括内容范围头或多部分/byteranges内容类型，其中每个部分都包含内容范围头。（有关结合增量编码和多部分/字节数的具体讨论，请参见第10.10节。）
Responses that include an IM header MUST carry a response status code of 226 (IM Used), as specified in section 10.4.1.
根据第10.4.1节的规定，包含IM报头的响应必须带有226的响应状态代码（使用IM）。
The server SHOULD omit the IM header if it would list only the "range" instance-manipulation. Such responses would normally be sent with response status code 206 (Partial Content), as specified by HTTP/1.1 [10].
如果服务器只列出“范围”实例操作，则应该省略IM头。按照HTTP/1.1[10]的规定，此类响应通常会与响应状态代码206（部分内容）一起发送。
Examples of the use of the IM header include:
使用IM报头的示例包括：
IM: vcdiff
IM:vcdiff
This example indicates that the entity-body is a delta encoding of the instance, using the vcdiff encoding.
此示例指示实体体是实例的增量编码，使用vcdiff编码。
IM: diffe, deflate, range
IM：差，放气，范围
This example indicates that the instance has first been delta-encoded using the diffe encoding, then the result of that has been compressed using deflate, and finally one or more ranges of that compressed encoding have been selected.
此示例表明，该实例首先使用diff编码进行增量编码，然后使用deflate对其结果进行压缩，最后选择了该压缩编码的一个或多个范围。
IM: range, vcdiff
IM：范围，vcdiff
This example indicates that one or more ranges of the instance have been selected, and the result has then been delta encoded against identical ranges of a previous base instance.
此示例表示已选择实例的一个或多个范围，然后根据前一个基本实例的相同范围对结果进行增量编码。
A cache using a response received in reply to one request to reply to a subsequent request MUST follow the rules in section 10.6 if the cached response includes an IM header field.
如果缓存响应包含IM头字段，则使用在响应一个请求时收到的响应来响应后续请求的缓存必须遵循第10.6节中的规则。
The A-IM request-header field is similar to Accept, but restricts the instance-manipulations (section 10.1) that are acceptable in the response. As specified in section 10.5.2, a response may be the result of applying multiple instance-manipulations.
A-IM请求头字段类似于Accept，但限制响应中可接受的实例操作（第10.1节）。如第10.5.2节所述，响应可能是应用多实例操作的结果。
A-IM = "A-IM" ":" #( instance-manipulation
[ ";" "q" "=" qvalue ] )
A-IM = "A-IM" ":" #( instance-manipulation
[ ";" "q" "=" qvalue ] )
When an A-IM request-header field includes one or more delta-coding values, the request MUST contain an If-None-Match header field, listing one or more entity tags from prior responses for the request-URI.
当A-IM请求头字段包括一个或多个增量编码值时，请求必须包含一个If None Match头字段，列出请求URI先前响应中的一个或多个实体标记。
A server tests whether an instance-manipulation (among the ones it is capable of employing) is acceptable, according to a given A-IM header field, using these rules:
服务器根据给定的A-IM头字段，使用以下规则测试实例操作（在其能够采用的操作中）是否可接受：
1. If the instance-manipulation is listed in the A-IM field, then it is acceptable, unless it is accompanied by a qvalue of 0. (As defined in section 3.9 of the HTTP/1.1 specification [10], a qvalue of 0 means "not acceptable.") A server MUST NOT use a non-identity instance-manipulation for a response unless the instance-manipulation is listed in an A-IM header in the request.
1. 如果实例操作列在A-IM字段中，则它是可接受的，除非它附带Q值0。（如HTTP/1.1规范[10]第3.9节所定义，Q值为0表示“不可接受”。）服务器不得对响应使用非身份实例操纵，除非该实例操纵在请求的a-IM头中列出。
2. If multiple but incompatible instance-manipulations are acceptable, then the acceptable instance-manipulation with the highest non-zero qvalue is preferred.
2. 如果可以接受多个但不兼容的实例操作，则首选具有最高非零qvalue的可接受实例操作。
3. The "identity" instance-manipulation is always acceptable, unless specifically refused because the A-IM field includes "identity;q=0".
3. “identity”实例操作始终是可接受的，除非由于A-IM字段包含“identity；q=0”而被明确拒绝。
If an A-IM field is present in a request, and if the server cannot send a response which is acceptable according to the A-IM header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
如果请求中存在A-IM字段，并且根据A-IM标头，服务器无法发送可接受的响应，则服务器应发送带有406（不可接受）状态代码的错误响应。
If a response uses more than one instance-manipulation, the instance-manipulations MUST be applied in the order in which they appear in the A-IM request-header field.
如果响应使用多个实例操作，则必须按照实例操作在a-IM请求标头字段中出现的顺序应用实例操作。
The server's choice about whether to apply an instance-manipulation SHOULD be independent of its choice to apply any subsequent two-input instance-manipulations to the response. (Two-input instance-manipulations include delta-codings, because they take two different values as input. Compression and "range" instance-manipulations take only one input. Other instance-manipulations may be defined in the future.)
服务器对是否应用实例操作的选择应该独立于它对响应应用任何后续两个输入实例操作的选择。（两个输入实例操作包括增量编码，因为它们采用两个不同的值作为输入。压缩和“范围”实例操作仅采用一个输入。将来可能会定义其他实例操作。）
Note: the intent of this requirement is to prevent the server from generating a delta-encoded response that the client can only decode by first applying an instance-manipulation encoding to its cached base instance. A server implementor might wish to consider what the client would logically have in its cache, when deciding which instance-manipulations to apply prior to a delta-coding.
注意：此要求的目的是防止服务器生成增量编码的响应，客户端只能通过首先对其缓存的基本实例应用实例操纵编码来解码该响应。服务器实现者可能在考虑在delta编码之前应用哪些实例操作时，考虑客户端将在其缓存中逻辑地拥有什么。
Examples:
示例：
A-IM: vcdiff, gdiff
A-IM:vcdiff，gdiff
This example means that the client will accept a delta encoding in either vcdiff or gdiff format.
此示例意味着客户端将接受vcdiff或gdiff格式的增量编码。
A-IM: vcdiff, gdiff;q=0.3
A-IM: vcdiff, gdiff;q=0.3
This example means that the client will accept a delta encoding in either vcdiff or gdiff format, but prefers the vcdiff format.
此示例意味着客户端将接受vcdiff或gdiff格式的增量编码，但更喜欢vcdiff格式。
A-IM: vcdiff, diffe, gzip
A-IM:vcdiff，diff，gzip
This example means that the client will accept a delta encoding in either vcdiff or diffe format, and will accept the output of the delta encoding compressed with gzip. It also means that the client will accept a gzip compression of the instance, without any delta encoding, because A-IM provides no way to insist that gzip be used only if diffe is used.
此示例意味着客户端将接受vcdiff或diffe格式的增量编码，并将接受用gzip压缩的增量编码的输出。这还意味着客户端将接受实例的gzip压缩，而不使用任何增量编码，因为a-IM无法坚持仅在使用diff时才使用gzip。
It is left to the server implementor to choose useful combinations of acceptable instance-manipulations (for example, following diffe by gzip is useful, but following vcdiff by gzip probably is not useful).
由服务器实现者选择可接受的实例操作的有用组合（例如，遵循differ by gzip是有用的，但是遵循vcdiff by gzip可能是无用的）。
When a client or proxy receives a 226 (IM Used) response, it MAY use this response to create a cache entry in three ways:
当客户端或代理接收到226（IM已使用）响应时，它可以使用此响应以三种方式创建缓存项：
1. It MAY decode all of the instance-manipulations to recover the original instance, and store that instance in the cache. In this case, the recovered instance is stored as a status-200 response, and MUST be used in accordance with the normal HTTP caching rules.
1. 它可以解码所有实例操作以恢复原始实例，并将该实例存储在缓存中。在这种情况下，恢复的实例存储为status-200响应，必须按照正常的HTTP缓存规则使用。
2. It MAY decode all of the instance-manipulations except for range selection(s), and store the result in the cache. In this case, the result is stored as a status-206 response, and MUST be used in accordance with the normal HTTP caching rules for Partial Content.
2. 它可以解码除范围选择之外的所有实例操作，并将结果存储在缓存中。在这种情况下，结果存储为status-206响应，并且必须按照部分内容的正常HTTP缓存规则使用。
3. It MAY store the status-226 (IM Used) response as a cache entry.
3. 它可以将status-226（IM-Used）响应存储为缓存条目。
A status-226 cache entry MUST NOT be used in response to a subsequent request under any of these conditions (a cache that never stores status-226 responses may ignore these tests):
在上述任何条件下，不得使用status-226缓存条目响应后续请求（从不存储status-226响应的缓存可能会忽略这些测试）：
1. If any of the instance-manipulation values from the IM header field in the cached response do not appear in the subsequent request's A-IM header field. The comparison between the headers is done using an exact match on each instance-manipulation value including any associated imparams values (see section 10.1).
1. 如果缓存响应中IM头字段中的任何实例操作值未出现在后续请求的A-IM头字段中。使用每个实例操纵值（包括任何关联的imparams值）上的精确匹配来完成标题之间的比较（请参见第10.1节）。
2. If the order of instance-manipulation values appearing in the cached IM header field differs from the order of that set of instance-manipulations in the A-IM header field of the subsequent request.
2. 如果缓存的IM头字段中出现的实例操作值的顺序与后续请求的A-IM头字段中出现的实例操作集的顺序不同。
3. If the cache implementation is not aware of, or is not at least conditionally compliant with, the specification of any of the instance-manipulation values in the cached IM header field.
3. 如果缓存实现不知道或至少不符合cached IM header字段中任何实例操作值的规范。
Note: This rule allows for extending the set of instance-manipulations without causing deployed cache implementations to commit errors. The specification of new instance-manipulations may include additional caching rules to improve cache-hit rates in cognizant implementations.
注意：此规则允许扩展实例操作集，而不会导致部署的缓存实现提交错误。新实例操作的规范可能包括额外的缓存规则，以提高认知实现中的缓存命中率。
4. If any of the instance-manipulation values in the cached IM header field is a delta-coding, and the cache entry includes a Delta-Base header field, and that Delta-Base entity tag is not one of the entity tags listed in an If-None-Match header field of the subsequent request.
4. 如果缓存的IM头字段中的任何实例操作值是增量编码，并且缓存条目包括增量基头字段，并且该增量基实体标记不是后续请求的If None匹配头字段中列出的实体标记之一。
5. If any of the instance-manipulation values in the cached IM header field is a delta-coding, the cache entry does not include a Delta-Base header field, and the If-None-Match header field of the request that led to that cache entry does not match the If-None-Match header field of the subsequent request.
5. 如果缓存IM头字段中的任何实例操作值是增量编码，则缓存项不包括增量基本头字段，并且导致该缓存项的请求的If None Match头字段与后续请求的If None Match头字段不匹配。
If the IM header field of the cached response includes the "range" instance-manipulation, then a status-226 cache entry MUST NOT be used in response to a subsequent request if the cached response is inconsistent with the Range header field value(s) in the request, as would be the case for a cached 206 (Partial Content) response.
如果缓存响应的IM头字段包括“范围”实例操作，则如果缓存响应与请求中的范围头字段值不一致，则不得使用状态226缓存条目来响应后续请求，就像缓存206（部分内容）响应的情况一样。
Note: we know of no existing, published formal specification for deciding if a cached status-206 response is consistent with a subsequent request. We believe that either of these conditions is sufficient:
注意：我们知道没有现有的、已发布的正式规范来决定缓存的status-206响应是否与后续请求一致。我们认为以下任一条件都是充分的：
1. The ranges specified in the headers of the request that led to the cached response are the same as specified in the headers of the subsequent request.
1. 导致缓存响应的请求标头中指定的范围与后续请求标头中指定的范围相同。
2. The ranges specified in the cached response are the same as specified in the headers of the subsequent request.
2. 缓存响应中指定的范围与后续请求的标头中指定的范围相同。
Further analysis might be necessary.
可能需要进一步分析。
The use of delta encoding with content-encoded instances adds some slight complexity. When a client (perhaps a proxy) has received a delta encoded response, either or both of that new response and a cached previous response may have non-identity content-codings. We specify rules for the server and client, to prevent situations where the client is unable to make sense of the server's response.
对内容编码实例使用增量编码会增加一些轻微的复杂性。当客户机（可能是代理）接收到增量编码的响应时，该新响应和缓存的先前响应中的一个或两个可能具有非标识内容编码。我们为服务器和客户端指定规则，以防止客户端无法理解服务器响应的情况。
When a server generates a delta-encoded response, the list of content-codings the server uses (i.e., the value of the response's Content-Encoding header field) SHOULD be a prefix of the list of content-codings the server would have used had it not generated a delta encoding.
当服务器生成增量编码响应时，服务器使用的内容编码列表（即响应的内容编码头字段的值）应该是服务器在未生成增量编码的情况下将使用的内容编码列表的前缀。
This requirement allows a client receiving a delta-encoded response to apply the delta to a cached base instance without having to apply any content-codings during the process (although the client might, of course, be required to decode some content-codings).
此要求允许接收增量编码响应的客户机将增量应用于缓存的基本实例，而不必在过程中应用任何内容编码（当然，客户机可能需要解码某些内容编码）。
When a client receives a delta response with one or more non-identity content codings:
当客户端收到带有一个或多个非标识内容编码的增量响应时：
1. If both the new (delta) response and the cached response (instance) have exactly the same set of content-codings, the client applies the delta response to the cached response without removing the content-codings from either response.
1. 如果新的（增量）响应和缓存的响应（实例）具有完全相同的内容编码集，则客户端将增量响应应用于缓存的响应，而不从任何一个响应中删除内容编码。
2. If the new (delta) response and the cached response have a different set of content-codings, before applying the delta the client decodes one or more content-codings from the cached response, until the result has the same set of content-codings as the delta response.
2. 如果新（增量）响应和缓存响应具有不同的内容编码集，则在应用增量之前，客户端将从缓存响应解码一个或多个内容编码，直到结果具有与增量响应相同的内容编码集。
3. If a proxy or cache is forwarding the result of applying the delta response to a cached base instance response, or later forwards this result from a cache entry, the forwarded response MUST carry the same Content-Encoding header field as the new (delta) response (and so it must be content-encoded as indicated by that header field).
3. 如果代理或缓存正在转发将增量响应应用于缓存的基本实例响应的结果，或稍后从缓存项转发此结果，则转发的响应必须包含与新（增量）响应相同的内容编码头字段（因此它必须是由该头字段指示的内容编码头字段）。
The intent of these rules (and in particular, rule #3) is that the results are always consistent with the rule that the entity tag is associated with the result of the content-coding, and that any recipient after the application of the delta-coding receives exactly the same response it would have received as a status-200 response from the origin server (without any delta-coding).
这些规则（特别是规则#3）的目的是，结果始终与实体标记与内容编码结果关联的规则一致，并且在应用增量编码之后，任何接收者接收到的响应与它从源服务器接收到的status-200响应完全相同（没有任何增量编码）。
Suppose a client, with an empty cache, sends this request:
假设一个缓存为空的客户端发送此请求：
GET /foo.html HTTP/1.1 Host: example.com Accept-encoding: gzip
GET/foo.html HTTP/1.1主机：example.com接受编码：gzip
and the origin server responds with:
并且源服务器响应为：
HTTP/1.1 200 OK
Date: Wed, 24 Dec 1997 14:00:00 GMT
Etag: "abc"
Content-encoding: gzip
HTTP/1.1 200 OK
Date: Wed, 24 Dec 1997 14:00:00 GMT
Etag: "abc"
Content-encoding: gzip
We will use the notation URI;entity-tag to denote specific instances, so this response would cause the client to store in its cache the entity GZIP(foo.html;"abc").
我们将使用符号URI；entity标记表示特定实例，因此此响应将导致客户端在其缓存中存储实体GZIP（foo.html；“abc”）。
Then suppose that the client, a minute later, issues this conditional request:
然后假设客户端在一分钟后发出此条件请求：
GET /foo.html HTTP/1.1 Host: example.com If-none-match: "abc" Accept-encoding: gzip A-IM: vcdiff
GET/foo.html HTTP/1.1 Host:example.com如果没有匹配：“abc”接受编码：gzip A-IM:vcdiff
If the server is able to generate a delta-encoded response, it might choose one of two alternatives. The first is to compute the delta from the compressed instances (although this might not yield the most efficient coding):
如果服务器能够生成增量编码的响应，那么它可能会从两个备选方案中选择一个。首先是从压缩实例计算增量（尽管这可能不会产生最有效的编码）：
HTTP/1.1 226 IM Used
Date: Wed, 24 Dec 1997 14:01:00 GMT
Etag: "def"
Delta-base: "abc"
Content-encoding: gzip
IM: vcdiff
HTTP/1.1 226 IM Used
Date: Wed, 24 Dec 1997 14:01:00 GMT
Etag: "def"
Delta-base: "abc"
Content-encoding: gzip
IM: vcdiff
The body of this response would be the result of VCDIFF_DELTA(GZIP(foo.html;"abc"), GZIP(foo.html;"def")). The client would store as a new cache entry the entity GZIP(foo.html;"def"), after recovering that entity by applying the delta to its previous cache entry.
此响应的主体将是VCDIFF_DELTA（GZIP（foo.html；“abc”）、GZIP（foo.html；“def”））的结果。客户机将实体GZIP（foo.html；“def”）存储为一个新的缓存项，然后通过将增量应用于其先前的缓存项来恢复该实体。
The server's other alternative would be to compute the delta from the uncompressed values, returning:
服务器的另一种选择是从未压缩的值计算增量，返回：
HTTP/1.1 226 IM Used
Date: Wed, 24 Dec 1997 14:01:00 GMT
Delta-base: "abc"
Etag: "ghi"
IM: vcdiff
HTTP/1.1 226 IM Used
Date: Wed, 24 Dec 1997 14:01:00 GMT
Delta-base: "abc"
Etag: "ghi"
IM: vcdiff
The body of this response would be the result of VCDIFF_DELTA(GUNZIP(GZIP(foo.html;"abc")), foo.html;"ghi"), or more simply VCDIFF_DELTA(foo.html;"abc", foo.html;"ghi"). The client would store as a new cache entry the entity foo.html;"ghi" (i.e., without any content-coding), after recovering that entity by applying the delta to its previous cache entry.
此响应的主体将是VCDIFF_DELTA（GUNZIP（GZIP）（foo.html；“abc”））、foo.html；“ghi”）或更简单的VCDIFF_DELTA（foo.html；“abc”，foo.html；“ghi”）的结果。客户端将实体foo.html存储为新的缓存条目；“ghi”（即，没有任何内容编码），通过将增量应用于其先前的缓存条目来恢复该实体之后。
Note that the new value of foo.html (at 14:01:00 GMT) without the gzip content-coding must have a different entity tag from the compressed instance of the same underlying file.
请注意，没有gzip内容编码的foo.html的新值（在14:01:00GMT）必须与同一基础文件的压缩实例具有不同的实体标记。
The client's second request might have been:
客户端的第二个请求可能是：
GET /foo.html HTTP/1.1 Host: example.com If-none-match: "abc" Accept-encoding: gzip A-IM: diffe, gzip
GET/foo.html HTTP/1.1 Host:example.com如果没有匹配：“abc”接受编码：gzip A-IM:diffe，gzip
The client lists gzip in both the Accept-Encoding and A-IM headers, because if the server does not support delta encoding, the client would at least like to achieve the benefits of compression (as a content-coding). However, if the server does support the diffe delta-coding, the client would like the result to be compressed, and this must be done as an instance-manipulation.
客户机在接受编码和A-IM头中都列出了gzip，因为如果服务器不支持增量编码，客户机至少希望实现压缩的好处（作为内容编码）。但是，如果服务器确实支持差增量编码，则客户端希望压缩结果，而这必须作为实例操作来完成。
A server that does support diffe might reply:
不支持Differ的服务器可能会答复：
HTTP/1.1 226 IM Used
Date: Wed, 24 Dec 1997 14:01:00 GMT
Delta-base: "abc"
Etag: "ghi"
IM: diffe, gzip
HTTP/1.1 226 IM Used
Date: Wed, 24 Dec 1997 14:01:00 GMT
Delta-base: "abc"
Etag: "ghi"
IM: diffe, gzip
The body of this response would be the result of GZIP(DIFFE_DELTA(GUNZIP(GZIP(foo.html;"abc")), foo.html;"ghi")), or more simply GZIP(DIFFE_DELTA(foo.html;"abc", foo.html;"ghi")). Because the gzip compression is, in this case, an instance-manipulation and not a content-coding, it is not retained when the reassembled response is stored or forwarded, so the client would store as a new cache entry the entity foo.html;"ghi" (without any content-coding or compression).
此响应的主体将是GZIP（differ_DELTA）（GUNZIP（GZIP（foo.html；“abc”））、foo.html；“ghi”））或更简单的GZIP（differ_DELTA（foo.html；“abc”，foo.html；“ghi”））的结果。因为在这种情况下，gzip压缩是实例操作而不是内容编码，所以在存储或转发重新组装的响应时，它不会被保留，因此客户端将实体foo.html存储为新的缓存条目；“ghi”（无任何内容编码或压缩）。
We define two new cache-directives (see section 14.9 of RFC 2616 [10] for the specification of cache-directive).
我们定义了两个新的缓存指令（有关缓存指令的规范，请参见RFC 2616[10]第14.9节）。
The set of cache-response-directive values is augmented to include the retain directive.
缓存响应指令值集被扩充以包括retain指令。
cache-response-directive = ... | "retain" [ "=" delta-seconds ]
缓存响应指令=…|“保留”[“=”增量秒]
A retain directive is always a "hint" from a server to a client; it never specifies a mandatory action for the recipient.
retain指令始终是从服务器到客户端的“提示”；它从不为收件人指定强制操作。
The presence of a retain directive indicates that a delta-capable client ought to retain the instance in the response in its cache, space permitting, and ought to use the corresponding entity tag in a future request for a delta-encoded response. I.e., the server is likely to provide delta-encoded responses using the corresponding instance as a base instance. By implication, if a client has retrieved and cached several instances of a resource, some of which are marked with "retain" and some not, then there is no point in caching the instances not marked with "retain".
retain指令的存在表明，在空间允许的情况下，支持增量的客户端应该将响应中的实例保留在其缓存中，并且应该在将来请求增量编码响应时使用相应的实体标记。即，服务器可能使用相应实例作为基本实例来提供增量编码的响应。这意味着，如果客户机检索并缓存了资源的多个实例，其中一些标记为“retain”，而另一些则没有，那么缓存未标记为“retain”的实例就没有意义了。
If the retain directive includes a delta-seconds value, then the server is likely to stop using the corresponding instance as a base instance after the specified number of seconds. A client ought not use the corresponding entity tag in a future request for a delta-encoded response after that interval ends. The interval is measured from the time that the response is generated, so a client ought to include the response's Age in its calculations.
如果retain指令包含delta seconds值，则在指定的秒数之后，服务器可能会停止使用相应实例作为基本实例。在间隔结束后，客户机不应该在将来请求增量编码响应时使用相应的实体标记。时间间隔是从生成响应的时间开始测量的，因此客户机应该在计算中包括响应的年龄。
If the retain directive includes a delta-seconds value of zero, a client SHOULD NOT use the corresponding entity tag in a future request for a delta-encoded response.
如果retain指令包含delta seconds值零，则客户端不应在将来请求delta编码响应时使用相应的实体标记。
Note: We recommend that server implementors consider the bandwidth implications of sending the "retain=0" directive to clients or proxies that might not have the ability to make use of it.
注意：我们建议服务器实现者考虑将“保留＝0”指令发送给可能无法使用它的客户端或代理。
The set of cache-response-directive values is augmented to include the im directive.
缓存响应指令值集被扩充以包括im指令。
cache-response-directive = ... | "im"
缓存响应指令=…|“即时通讯”
A cache that complies with the specification for the IM header, the A-IM header, and the 226 response-status code SHOULD ignore a no-store cache-directive if an im directive is present in the same response. All other implementations MUST ignore the im directive (i.e., MUST observe a no-store directive, if present).
如果同一响应中存在IM指令，则符合IM报头、A-IM报头和226响应状态代码规范的缓存应忽略无存储缓存指令。所有其他实现必须忽略im指令（即，必须遵守no store指令，如果存在）。
The application of data compression to the diffe and gdiff delta codings has been shown to greatly reduce the size of the resulting message bodies, in many cases. (The vcdiff coding, on the other hand, is inherently compressed and does not benefit from further compression.) Therefore, it is strongly recommended that implementations that support the diffe and/or gdiff delta codings also support the gzip and/or deflate compression codings. (The deflate coding provides a more compact result.) However, this is not a requirement for the use of delta encoding, primarily because the CPU-time costs associated with compression and decompression may be excessive in some environments.
在许多情况下，将数据压缩应用于diffe和gdiff增量编码可以大大减少生成的消息体的大小。（另一方面，vcdiff编码本身是压缩的，不会从进一步压缩中受益。）因此，强烈建议支持diffe和/或gdiff增量编码的实现也支持gzip和/或deflate压缩编码。（deflate编码提供了更紧凑的结果。）但是，这不是使用增量编码的要求，主要是因为在某些环境中，与压缩和解压缩相关的CPU时间成本可能过高。
A client that supports both delta encoding and compression as instance-manipulations signals this by, for example
例如，支持增量编码和压缩作为实例操作的客户端通过以下方式发出信号：
A-IM: diffe, deflate
A-IM:diff，deflate
The ordering rule stated in section 10.5.3 requires, if the server uses both instance-manipulations in the response, that compression be applied to the result of the delta encoding, rather than vice versa. I.e., the response in this case would include
第10.5.3节中所述的排序规则要求，如果服务器在响应中同时使用两种实例操作，则应将压缩应用于增量编码的结果，而不是相反。即，本案例中的响应将包括
IM: diffe, deflate
IM：不同，放气
Note that a client might accept compression either as a content-coding or as an instance-manipulation. For example:
请注意，客户机可能接受压缩作为内容编码或实例操作。例如：
Accept-Encoding: gzip A-IM: gzip, gdiff
接受编码：gzip A-IM:gzip，gdiff
In this example, the server may apply the gzip compression, either as a content-coding or as an instance-manipulation, before delta encoding. Remember that the entity tag is assigned after content-coding but before instance-manipulation, so this choice does affect the semantics of delta encoding.
在本例中，服务器可以在增量编码之前将gzip压缩应用为内容编码或实例操作。请记住，实体标记是在内容编码之后但在实例操作之前分配的，因此此选择确实会影响增量编码的语义。
A client may request multiple, non-contiguous byte ranges in a single request. The server's response uses the "multipart/byteranges" media type (section 19.2 of [10]) to convey multiple ranges in a response. If a multipart/byteranges response is delta encoded (i.e, uses a delta-coding as an instance-manipulation), the delta-related headers are associated with the entire response, not with the individual parts. (This is because there is only one base instance and one current instance involved.) A delta-encoded response with multiple ranges MUST use the same delta-coding for all of the ranges.
客户端可以在单个请求中请求多个非连续字节范围。服务器的响应使用“multipart/byteranges”媒体类型（见[10]第19.2节）在响应中传递多个范围。如果多部分/byteranges响应是增量编码的（即，使用增量编码作为实例操作），则与增量相关的头与整个响应相关联，而不是与单个部分相关联。（这是因为只涉及一个基本实例和一个当前实例。）具有多个范围的增量编码响应必须对所有范围使用相同的增量编码。
If a server chooses to use a delta encoding for a multipart/byteranges response, it MUST generate a response in accordance with the following rules.
如果服务器选择对multipart/byteranges响应使用delta编码，则必须根据以下规则生成响应。
When a multipart/byteranges response uses a delta-coding prior to a range selection, the A-IM and IM header fields list the delta-coding before the "range" literal. (Recall that this is the approach taken to obtain a partial response after a premature termination of a message transmission.) The server firsts generates a sequence of bytes representing the difference (delta) between the base instance and the current instance, then selects the specified ranges of bytes, and transmits each such range in a part of the multipart/byteranges media type.
当多部分/byteranges响应在选择范围之前使用增量编码时，a-IM和IM头字段在“范围”文本之前列出增量编码。（回想一下，这是在消息传输提前终止后获得部分响应所采取的方法。）服务器首先生成表示基本实例和当前实例之间差异（增量）的字节序列，然后选择指定的字节范围，并在多部分/byteranges媒体类型的一部分中传输每个这样的范围。
When a multipart/byteranges response uses a delta-coding after a range selection, the A-IM and IM header fields list the delta-coding after the "range" literal. (Recall that this is the approach taken to obtain an updated version just of selected sections of an instance.) The server first selects the specified ranges from the current instance, and also selects the same specified ranges from the base instance. (Some of these selected ranges might be the empty sequence, if the instance is not long enough.) The server then generates the individual differences (deltas) between the pairs of ranges, and transmits each such difference in a part of the multipart/byteranges media type.
当多部分/byteranges响应在范围选择后使用增量编码时，a-IM和IM头字段在“范围”文本后列出增量编码。（回想一下，这是获取实例选定部分的更新版本所采用的方法。）服务器首先从当前实例中选择指定的范围，还从基本实例中选择相同的指定范围。（如果实例不够长，其中一些选定的范围可能是空序列。）然后，服务器生成范围对之间的个别差异（增量），并在多部分/字节范围媒体类型的一部分中传输每个此类差异。
11 Quantifying the protocol overhead
11量化协议开销
The proposed protocol changes increase the size of the HTTP message headers slightly. In the simplest case, a conditional request (i.e., one for a URI for which the client already has a cache entry) would include one more header, e.g.:
建议的协议更改略微增加了HTTP消息头的大小。在最简单的情况下，条件请求（即，一个针对客户端已经有缓存项的URI的请求）将包括一个或多个头，例如：
A-IM:vcdiff
A-IM:vcdiff
This is about 13 extra bytes. A recent study [23] reports mean request sizes from two different traces of 281 and 306 bytes, so the net increase in request size would be between 4% and 5%.
这大约是额外的13个字节。最近的一项研究[23]报告了来自281字节和306字节两个不同记录道的平均请求大小，因此请求大小的净增加将在4%到5%之间。
Because a client must have an existing cache entry to use as a base for a delta-encoded response, it would never send "A-IM: vcdiff" (or listing other delta encoding formats) for its unconditional requests. The same study showed that at least 46% of the requests in lengthy traces were for URLs not seen previously in the trace; this means that no more than about half of typical client requests could be conditional (and the actual fraction is likely to be smaller, given the finite size of real caches).
因为客户端必须有一个现有的缓存项作为增量编码响应的基础，所以它永远不会为其无条件请求发送“a-IM:vcdiff”（或列出其他增量编码格式）。同一项研究表明，在长跟踪中，至少有46%的请求是针对以前在跟踪中未看到的URL的；这意味着不超过一半的典型客户机请求可能是有条件的（考虑到实际缓存的有限大小，实际部分可能更小）。
The study also showed that 64% of the responses in a lengthy trace were for image content-types (GIF and JPEG). As noted in section 6, we do not currently know of a delta-encoding format suitable for such image types. Unless a client did support such a delta-encoding format, it would presumably not ask for a delta when making a conditional request for image content-types.
该研究还表明，在长跟踪中，64%的响应是针对图像内容类型（GIF和JPEG）。如第6节所述，我们目前不知道适合此类图像类型的增量编码格式。除非客户机支持这种增量编码格式，否则在对图像内容类型进行有条件请求时，它可能不会要求增量。
Taken together, these factors suggest that the mean increase in request header size would be much less than 5%, and probably below 1%.
综上所述，这些因素表明请求头大小的平均增加将远小于5%，并且可能低于1%。
Delta-encoded responses carry slightly longer headers. In the simplest case, a response carries one more header, e.g.:
增量编码的响应带有稍长的标题。在最简单的情况下，响应包含一个或多个标头，例如：
IM:vcdiff
IM:vcdiff
This is about 11 bytes. Other headers (such as "Delta-Base") might also be included. However, none of these extra headers would be included except in cases where a delta encoding is actually employed, and the sender of the response can avoid sending a delta encoding if this results in a net increase in response size. Thus, a delta-encoded response should never be larger than a regular response for the same request.
这大约是11个字节。还可能包括其他标题（如“Delta Base”）。但是，除了实际使用增量编码的情况外，不会包括这些额外的头，并且如果这导致响应大小的净增加，则响应的发送方可以避免发送增量编码。因此，对于同一请求，增量编码的响应不应大于常规响应。
Simulations suggest that, when delta encoding pays off at all, it saves several thousand bytes [23]. Thus, adding a few dozen bytes to the response headers should almost never obviate the savings in the message-body size.
模拟表明，当增量编码得到回报时，它可以节省数千字节[23]。因此，向响应头添加几十个字节几乎永远不会消除消息正文大小的节省。
Finally, the use of the "retain" Cache-Control directive might cause some additional overhead. Some server heuristics might be successful in limiting the use of these headers to situations where they would probably optimize future responses. Neither of these headers is necessary for the simpler uses of delta encoding.
最后，使用“retain”Cache Control指令可能会导致一些额外的开销。一些服务器启发法可能成功地将这些头的使用限制在可能优化未来响应的情况下。为了更简单地使用增量编码，这两个头都不是必需的。
12 Security Considerations
12安全考虑
We are not aware of any aspects of the basic delta encoding mechanism that affect the existing security considerations for the HTTP/1.1 protocol.
我们不知道影响HTTP/1.1协议现有安全考虑因素的基本增量编码机制的任何方面。
13 Acknowledgements
13致谢
Phong Vo has provided a great deal of guidance in the choice of delta encoding algorithms and formats. Issac Goldstand and Mike Dahlin provided a number of useful comments on the specification. Dave Kristol suggested many textual corrections.
Phong Vo在选择增量编码算法和格式方面提供了大量指导。Issac Goldstand和Mike Dahlin就规范提供了许多有用的意见。戴夫·克里斯托提出了许多文本更正。
14 Intellectual Property Rights
14知识产权
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights, at <http://www.ietf.org/ipr.html>.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请参阅在线权利主张列表，网址为<http://www.ietf.org/ipr.html>.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP 11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
15 References
15参考文献
1. Gaurav Banga, Fred Douglis, and Michael Rabinovich. Optimistic Deltas for WWW Latency Reduction. Proc. 1997 USENIX Technical Conference, Anaheim, CA, January, 1997, pp. 289-303.
1. Gaurav Banga、Fred Douglis和Michael Rabinovich。用于减少WWW延迟的乐观增量。过程。1997年USENIX技术会议，加利福尼亚州阿纳海姆，1997年1月，第289-303页。
2. Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2. Berners Lee，T.，Fielding，R.和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
3. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
3. Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
4. Edith Cohen, Balachander Krishnamurthy, and Jennifer Rexford. Improving End-to-End Performance of the Web Using Server Volumes and Proxy Filters. Proc. SIGCOMM '98, September, 1998, pp. 241- 253.
4. 伊迪丝·科恩、巴拉昌德·克里希纳穆尔西和詹妮弗·雷克斯福德。使用服务器卷和代理筛选器提高Web的端到端性能。过程。SIGCOMM'981998年9月，第241-253页。
5. Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
5. Deutsch，P.，“GZIP文件格式规范版本4.3”，RFC 1952，1996年5月。
6. Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
6. Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
7. Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
7. Deutsch，P.和J-L.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
8. Fred Douglis, Anja Feldmann, Balachander Krishnamurthy, and Jeffrey Mogul. Rate of Change and Other Metrics: a Live Study of the World Wide Web. Proc. Symposium on Internet Technologies and Systems, USENIX, Monterey, CA, December, 1997, pp. 147-158.
8. 弗雷德·道格利斯、安吉·费尔德曼、巴拉昌德·克里希纳穆尔西和杰弗里·莫格尔。变化率和其他指标：对万维网的现场研究。过程。互联网技术和系统研讨会，加利福尼亚州蒙特利USENIX，1997年12月，第147-158页。
9. Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
9. 菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，尼尔森，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
10. Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
10. 菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，尼尔森，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
11. Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Luotonen, L. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authnetication", RFC 2617, June 1999.
11. Franks，J.，Hallam Baker，P.，Hostetler，J.，Leach，P.，Lootonen，A.，Lootonen，L.和L.Stewart，“HTTP认证：基本和摘要访问授权”，RFC 26171999年6月。
12. Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
12. Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
13. Arthur van Hoff, John Giannandrea, Mark Hapner, Steve Carter, and Milo Medin. The HTTP Distribution and Replication Protocol. Technical Report NOTE-DRP, World Wide Web Consortium, August, 1997.
13. 阿瑟·范霍夫、约翰·詹南德里亚、马克·哈普纳、史蒂夫·卡特和米洛·梅丁。HTTP分发和复制协议。技术报告NOTE-DRP，万维网联盟，1997年8月。
14. Arthur van Hoff and Jonathan Payne. Generic Diff Format Specification. Technical Report NOTE-GDIFF, World Wide Web Consortium, August, 1997.
14. 亚瑟·范霍夫和乔纳森·佩恩。通用差异格式规范。技术报告NOTE-GDIFF，万维网联盟，1997年8月。
15. Barron C. Housel and David B. Lindquist. WebExpress: A System for Optimizing Web Browsing in a Wireless Environment. Proc. 2nd Annual Intl. Conf. on Mobile Computing and Networking, ACM, Rye, New York, November, 1996, pp. 108-116.
15. 巴伦·C·豪塞尔和大卫·B·林德奎斯特。WebExpress：在无线环境中优化Web浏览的系统。过程。第二届移动计算和网络国际年会，ACM，Rye，纽约，1996年11月，第108-116页。
16. James J. Hunt, Kiem-Phong Vo, and Walter F. Tichy. An Empirical Study of Delta Algorithms. IEEE Soft. Config. and Maint. Workshop, 1996.
16. 詹姆斯·亨特、基姆·方沃和沃尔特·蒂希。Delta算法的实证研究。IEEE软件。配置。还有保养。讲习班，1996年。
17. Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
17. Jacobson，V.，“压缩低速串行链路的TCP/IP报头”，RFC 1144，1990年2月。
18. Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
18. Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
19. David G. Korn and Kiem-Phong Vo. A Generic Differencing and Compression Data Format. Technical Report HA1630000-021899-02TM, AT&T Labs - Research, February, 1999.
19. David G.Korn和Kiem Phong Vo。一种通用的差分和压缩数据格式。技术报告HA163000-021899-02TM，AT&T实验室-研究，1999年2月。
20. Korn, D. and K. Vo, "The VCDIFF Generic Differencing and Compression Data Format", Work in Progress.
20. Korn，D.和K.Vo，“VCDIFF通用差分和压缩数据格式”，正在进行中。
21. Merriam-Webster. Webster's Seventh New Collegiate Dictionary. G. & C. Merriam Co., Springfield, MA, 1963.
21. 韦氏词典。韦伯斯特的第七部新大学词典。G.C.Merriam公司，马萨诸塞州斯普林菲尔德，1963年。
22. Jeffrey C. Mogul. Hinted caching in the Web. Proc. Seventh ACM SIGOPS European Workshop, Connemara, Ireland, September, 1996, pp. 103-108.
22. 杰弗里·莫格尔。网络中的暗示缓存。过程。第七届ACM SIGOPS欧洲研讨会，康涅马拉，爱尔兰，1996年9月，第103-108页。
23. Jeffrey C. Mogul, Fred Douglis, Anja Feldmann, and Balachander Krishnamurthy. Potential benefits of delta encoding and data compression for HTTP. Research Report 97/4, DECWRL, July, 1997.
23. 杰弗里·莫格尔、弗雷德·道格利斯、安吉·费尔德曼和巴拉昌德·克里希纳穆尔西。HTTP增量编码和数据压缩的潜在好处。研究报告97/4，1997年7月12日。
24. Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 3230, January 2002.
24. Mogul，J.和A.Van Hoff，“HTTP中的实例摘要”，RFC 3230，2002年1月。
25. Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
25. Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
26. The Open Group. The Single UNIX Specification, Version 2 - 6 Vol Set for UNIX 98. Document number T912, The Open Group, February, 1997.
26. 开放组。UNIX 98的单一UNIX规范，版本2-6卷集。文件编号T912，公开组，1997年2月。
27. W. Tichy. "RCS - A System For Version Control". Software - Practice and Experience 15, 7 (July 1985), 637-654.
27. 提奇。“RCS-版本控制系统”。软件-实践与经验15，7（1985年7月），637-654。
28. Andrew Tridgell and Paul Mackerras. The rsync algorithm. Technical Report TR-CS-96-05, Department of Computer Science, Australian National University, June, 1996.
28. 安德鲁·特里格尔和保罗·麦凯拉斯。rsync算法。技术报告TR-CS-96-05，澳大利亚国立大学计算机科学系，1996年6月。
29. Stephen Williams. Personal communication. http://ei.cs.vt.edu/~williams/DIFF/prelim.html.
29. 斯蒂芬·威廉姆斯。个人沟通。http://ei.cs.vt.edu/~williams/DIFF/prelim.html。
30. Stephen Williams, Marc Abrams, Charles R. Standridge, Ghaleb Abdulla, and Edward A. Fox. Removal Policies in Network Caches for World-Wide Web Documents. Proc. SIGCOMM '96, Stanford, CA, August, 1996, pp. 293-305.
30. 斯蒂芬·威廉姆斯、马克·艾布拉姆斯、查尔斯·斯坦德里奇、盖勒布·阿卜杜拉和爱德华·福克斯。万维网文档的网络缓存中的删除策略。过程。SIGCOMM'96，加利福尼亚州斯坦福，1996年8月，第293-305页。
16 Authors' addresses
16作者地址
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, U.S.A.
Jeffrey C.Mogul西部研究实验室康柏计算机公司美国加利福尼亚州帕洛阿尔托大学大道250号，邮编94305。
Phone: 1 650 617 3304 (email preferred) EMail: JeffMogul@acm.org
电话：16506173304（首选电子邮件）电子邮件：JeffMogul@acm.org
Balachander Krishnamurthy AT&T Labs - Research 180 Park Ave, Room D-229 Florham Park, NJ 07932-0971, U.S.A.
Balachander Krishnamurthy AT&T实验室-美国新泽西州弗洛勒姆公园研究大道180号D-229室，邮编07932-0971。
EMail: bala@research.att.com
EMail: bala@research.att.com
Fred Douglis AT&T Labs - Research 180 Park Ave, Room B-137 Florham Park, NJ 07932-0971, U.S.A.
Fred Douglis AT&T实验室-美国新泽西州弗洛姆公园研究大道180号B-137室，邮编07932-0971。
Phone: 1 973 360-8775 EMail: douglis@research.att.com
电话：1 973 360-8775电子邮件：douglis@research.att.com
Anja Feldmann University of Saarbruecken, Germany, Computer Science Department Im Stadtwald, Geb. 36.1, Zimmer 310 D-66123 Saarbruecken, Germany
安杰拉·费尔德曼大学萨尔布鲁克肯，德国，计算机科学系，IM StdtWald，Geb。德国萨尔布鲁肯Zimmer 310 D-66123 36.1
EMail: anja@cs.uni-sb.de
EMail: anja@cs.uni-sb.de
Yaron Y. Goland
雅伦·Y·格兰德
Email: yaron@goland.org
Email: yaron@goland.org
Arthur van Hoff Marimba, Inc. 440 Clyde Avenue Mountain View, CA 94043, U.S.A.
Arthur van Hoff Marimba，Inc.美国加利福尼亚州克莱德大道山景大道440号，邮编94043。
Phone: 1 650 930 5283 EMail: avh@marimba.com
电话：16509305283电子邮件：avh@marimba.com
Daniel M. Hellerstein Economic Research Service, USDA 1909 Franwall Ave, Wheaton MD 20902
Daniel M.Hellerstein经济研究服务，美国农业部，马里兰州惠顿弗兰沃尔大道1909号，邮编20902
Phone: 1 202 694-5613 or 1 301 649-4728
EMail: danielh@crosslink.net or webmaster@srehttp.org
Phone: 1 202 694-5613 or 1 301 649-4728
EMail: danielh@crosslink.net or webmaster@srehttp.org
17 Full Copyright Statement
17版权声明全文
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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 implementation may be prepared, copied, published and 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。