Network Working Group J. Mogul
Request for Comments: 3230 Compaq WRL
Category: Standards Track A. Van Hoff
Marimba
January 2002
Network Working Group J. Mogul
Request for Comments: 3230 Compaq WRL
Category: Standards Track A. Van Hoff
Marimba
January 2002
Instance Digests 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
摘要
HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems.
HTTP/1.1定义了一个Content-MD5头，允许服务器包含响应主体的摘要。但是，这是专门定义为涵盖实际消息的主体，而不是完整文件的内容（如果响应是内容范围，或者使用增量编码，则可能会有很大的不同）。此外，Content-MD5仅限于一种特定的摘要算法；其他算法，如SHA-1（安全哈希标准），在某些情况下可能更合适。最后，HTTP/1.1没有提供客户端请求摘要的明确机制。本文提出了解决这些问题的HTTP扩展。
Table of Contents
目录
1 Introduction.................................................... 2
1.1 Other limitations of HTTP/1.1............................ 3
2 Goals........................................................... 4
3 Terminology..................................................... 5
4 Specification................................................... 6
4.1 Protocol parameter specifications........................ 6
4.1.1 Digest algorithms................................. 6
4.2 Instance digests......................................... 7
4.3 Header specifications.................................... 8
4.3.1 Want-Digest....................................... 8
4.3.2 Digest............................................ 9
5 Negotiation of Content-MD5...................................... 9
1 Introduction.................................................... 2
1.1 Other limitations of HTTP/1.1............................ 3
2 Goals........................................................... 4
3 Terminology..................................................... 5
4 Specification................................................... 6
4.1 Protocol parameter specifications........................ 6
4.1.1 Digest algorithms................................. 6
4.2 Instance digests......................................... 7
4.3 Header specifications.................................... 8
4.3.1 Want-Digest....................................... 8
4.3.2 Digest............................................ 9
5 Negotiation of Content-MD5...................................... 9
6 IANA Considerations............................................. 10
7 Security Considerations......................................... 10
8 Acknowledgements................................................ 10
9 References...................................................... 10
10 Authors' Addresses............................................. 12
11 Full Copyright Statement....................................... 13
6 IANA Considerations............................................. 10
7 Security Considerations......................................... 10
8 Acknowledgements................................................ 10
9 References...................................................... 10
10 Authors' Addresses............................................. 12
11 Full Copyright Statement....................................... 13
1 Introduction
1导言
Although HTTP is typically layered over a reliable transport protocol, such as TCP, this does not guarantee reliable transport of information from sender to receiver. Various problems, including undetected transmission errors, programming errors, corruption of stored data, and malicious intervention can cause errors in the transmitted information.
虽然HTTP通常是在可靠的传输协议（如TCP）上分层的，但这并不保证信息从发送方到接收方的可靠传输。各种问题，包括未检测到的传输错误、编程错误、存储数据损坏和恶意干预，都可能导致传输信息出错。
A common approach to the problem of data integrity in a network protocol or distributed system, such as HTTP, is the use of digests, checksums, or hash values. The sender computes a digest and sends it with the data; the recipient computes a digest of the received data, and then verifies the integrity of this data by comparing the digests.
解决网络协议或分布式系统（如HTTP）中的数据完整性问题的常用方法是使用摘要、校验和或哈希值。发送方计算摘要并将其与数据一起发送；接收方计算接收数据的摘要，然后通过比较摘要来验证此数据的完整性。
Checksums are used at virtually all layers of the IP stack. However, different digest algorithms might be used at each layer, for reasons of computational cost, because the size and nature of the data being protected varies, and because the possible threats to data integrity vary. For example, Ethernet uses a Cyclic Redundancy Check (CRC). The IPv4 protocol uses a ones-complement checksum over the IP header (but not the rest of the packet). TCP uses a ones-complement checksum over the TCP header and data, and includes a "pseudo-header" to detect certain kinds of programming errors.
校验和几乎用于IP堆栈的所有层。然而，出于计算成本的原因，由于受保护数据的大小和性质不同，以及对数据完整性的可能威胁不同，因此可能在每一层使用不同的摘要算法。例如，以太网使用循环冗余校验（CRC）。IPv4协议在IP报头（但不是数据包的其余部分）上使用一个补一校验和。TCP在TCP报头和数据上使用一个1补码校验和，并包括一个“伪报头”来检测某些类型的编程错误。
HTTP/1.1 [4] includes a mechanism for ensuring message integrity, the Content-MD5 header. This header is actually defined for MIME-conformant messages in a standalone specification [10]. According to the HTTP/1.1 specification,
HTTP/1.1[4]包括一种确保消息完整性的机制，即Content-MD5报头。此标头实际上是在独立规范中为符合MIME的消息定义的[10]。根据HTTP/1.1规范，
The Content-MD5 entity-header field [...] is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body.
Content-MD5实体头字段[…]是实体主体的MD5摘要，用于提供实体主体的端到端消息完整性检查（MIC）。
HTTP/1.1 borrowed Content-MD5 from the MIME world based on an analogy between MIME messages (e.g., electronic mail messages) and HTTP messages (requests to or responses from an HTTP server).
HTTP/1.1根据MIME消息（例如电子邮件消息）和HTTP消息（对HTTP服务器的请求或响应）之间的类比，从MIME世界借用了Content-MD5。
As discussed in more detail in section 3, this analogy between MIME messages and HTTP messages has resulted in some confusion. In particular, while a MIME message is self-contained, an HTTP message might not contain the entire representation of the current state of a resource. (More precisely, an HTTP response might not contain an entire "instance"; see section 3 for a definition of this term.)
正如第3节中更详细地讨论的，MIME消息和HTTP消息之间的这种类比导致了一些混淆。特别是，虽然MIME消息是自包含的，但HTTP消息可能不包含资源当前状态的完整表示。（更准确地说，HTTP响应可能不包含整个“实例”；有关此术语的定义，请参见第3节。）
There are at least two situations where this distinction is an issue:
至少有两种情况存在这种区别问题：
1. When an HTTP server sends a 206 (Partial Content) response, as defined in HTTP/1.1. The client may form its view of an instance (e.g., an HTML document) by combining a cache entry with the partial content in the message.
1. HTTP服务器发送206（部分内容）响应时，如HTTP/1.1中所定义。客户端可以通过将缓存条目与消息中的部分内容相结合来形成其实例视图（例如，HTML文档）。
2. When an HTTP server uses a "delta encoding", as proposed in a separate document [9]. A delta encoding represents the changes between the current instance of a resource and a previous instance, and is an efficient way of reducing the bandwidth required for cache updates. The client forms its view of an instance by applying the delta in the message to one of its cache entries.
2. 当HTTP服务器使用“增量编码”时，如单独文档[9]中所建议。增量编码表示资源的当前实例和以前实例之间的更改，是减少缓存更新所需带宽的有效方法。客户端通过将消息中的增量应用于其一个缓存项来形成其实例视图。
We include these two kinds of transformations in a potentially broader category we call "instance manipulations."
我们将这两种转换包含在一个可能更广泛的类别中，我们称之为“实例操作”
In each of these cases, the server might use a Content-MD5 header to protect the integrity of the response message. However, because the MIC in a Content-MD5 header field applies only to the entity in that message, and not to the entire instance being reassembled, it cannot protect against errors due to data corruption (e.g., of cache entries), programming errors (e.g., improper application of a partial content or delta), certain malicious attacks [9], or corruption of certain HTTP headers in transit.
在每种情况下，服务器都可能使用Content-MD5头来保护响应消息的完整性。但是，由于Content-MD5标头字段中的MIC仅适用于该消息中的实体，而不适用于正在重新组装的整个实例，因此它无法防止由于数据损坏（例如缓存条目）、编程错误（例如，不正确应用部分内容或增量）、某些恶意攻击而导致的错误[9]，或者传输过程中某些HTTP头的损坏。
Thus, the Content-MD5 header, while useful and sufficient in many cases, is not sufficient for verifying instance integrity in all uses of HTTP.
因此，Content-MD5头虽然在许多情况下有用且足够，但不足以在所有HTTP使用中验证实例完整性。
The Digest Authentication mechanism [5] provides (in addition to its other goals) a message-digest function similar to Content-MD5, except that it includes certain header fields. Like Content-MD5, it covers a specific message, not an entire instance.
摘要身份验证机制[5]提供了（除其他目标外）类似于Content-MD5的消息摘要功能，只是它包含某些头字段。与Content-MD5一样，它涵盖特定的消息，而不是整个实例。
Checksums are not free. Computing a digest takes CPU resources, and might add latency to the generation of a message. (Some of these costs can be avoided by careful caching at the sender's end, but in
校验和不是免费的。计算摘要需要CPU资源，并且可能会增加消息生成的延迟。（其中一些成本可以通过在发送方端仔细缓存来避免，但在
many cases such a cache would not have a useful hit ratio.) Transmitting a digest consumes HTTP header space (and therefore increases latency and network bandwidth requirements.) If the message recipient does not intend to use the digest, why should the message sender waste resources computing and sending it?
在许多情况下，这样的缓存不会有有用的命中率。）传输摘要会消耗HTTP报头空间（因此会增加延迟和网络带宽要求。）如果消息接收者不打算使用摘要，为什么消息发送者要浪费计算和发送摘要的资源？
The Content-MD5 header, of course, implies the use of the MD5 algorithm [15]. Other algorithms, however, might be more appropriate for some purposes. These include the SHA-1 algorithm [12] and various "fingerprinting" algorithms [7]. HTTP currently provides no standardized support for the use of these algorithms.
当然，Content-MD5标题意味着使用MD5算法[15]。然而，其他算法可能更适合某些目的。其中包括SHA-1算法[12]和各种“指纹”算法[7]。HTTP目前没有为这些算法的使用提供标准化支持。
HTTP/1.1 apparently assumes that the choice to generate a digest is up to the sender, and provides no mechanism for the recipient to indicate whether a checksum would be useful, or what checksum algorithms it would understand.
HTTP/1.1显然假定生成摘要的选择由发送方决定，并且没有为接收方提供任何机制来指示校验和是否有用，或者它将理解什么样的校验和算法。
2 Goals
2个目标
The goals of this proposal are:
本提案的目标是：
1. Digest coverage for entire instances communicated via HTTP.
1. 通过HTTP通信的整个实例的摘要覆盖率。
2. Support for multiple digest algorithms.
2. 支持多种摘要算法。
3. Negotiation of the use of digests.
3. 谈判使用摘要。
The goals do not include:
目标不包括：
- header integrity The digest mechanisms described here cover only the bodies of instances, and do not protect the integrity of associated "entity headers" or other message headers.
- 标题完整性此处描述的摘要机制仅涵盖实例主体，不保护关联的“实体标题”或其他消息标题的完整性。
- authentication The digest mechanisms described here are not meant to support authentication of the source of a digest or of a message or instance. These mechanisms, therefore, are not sufficient defense against many kinds of malicious attacks.
- 身份验证此处描述的摘要机制并不意味着支持摘要源、消息或实例的身份验证。因此，这些机制不足以抵御多种恶意攻击。
- privacy Digest mechanisms do not provide message privacy.
- 隐私摘要机制不提供消息隐私。
- authorization The digest mechanisms described here are not meant to support authorization or other kinds of access controls.
- 授权此处描述的摘要机制并不支持授权或其他类型的访问控制。
The Digest Access Authentication mechanism [5] can provide some integrity for certain HTTP headers, and does provide authentication.
摘要访问身份验证机制[5]可以为某些HTTP头提供一些完整性，并提供身份验证。
3 Terminology
3术语
HTTP/1.1 [4] defines the following terms:
HTTP/1.1[4]定义了以下术语：
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" [8]. Unfortunately, the definition for "entity" in HTTP/1.1 is similar to that used in MIME [6], based on an entirely false analogy between MIME and HTTP.
字典对“实体”的定义是“具有独立和不同存在以及客观或概念现实的事物”[8]。不幸的是，基于MIME和HTTP之间完全错误的类比，HTTP/1.1中“实体”的定义与MIME[6]中使用的定义类似。
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 is describing the current state of a resource (or a variant, subject to a set of constraints). The HTTP/1.1 specification provides 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规范在需要此概念的地方使用了笨拙的措辞。
It is too late to fix the terminological failure in the HTTP/1.1 specification, so we instead define a new term, for use in this document:
修复HTTP/1.1规范中的术语故障为时已晚，因此我们定义了一个新术语，用于本文档中：
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 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 also define this 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.
实例操作对一个或多个实例的操作，可能导致实例部分地从服务器传输到客户端，或在多个响应消息中传输。例如，范围选择或增量编码。实例操作是端到端的，通常涉及在客户端使用缓存。
4 Specification
4规格
In this specification, the key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described in RFC 2119 [2].
在本规范中，关键字“必须”、“不得”、“应该”、“不应该”和“可能”应按照RFC 2119[2]中的描述进行解释。
Digest algorithm values are used to indicate a specific digest computation. For some algorithms, one or more parameters may be supplied.
摘要算法值用于指示特定的摘要计算。对于某些算法，可以提供一个或多个参数。
digest-algorithm = token
digest-algorithm = token
The BNF for "parameter" is as is used in RFC 2616 [4]. All digest-algorithm values are case-insensitive.
“参数”的BNF与RFC 2616[4]中使用的相同。所有摘要算法值都不区分大小写。
The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values. Initially, the registry contains the following tokens:
Internet分配号码管理局（IANA）充当摘要算法值的注册表。最初，注册表包含以下令牌：
MD5 The MD5 algorithm, as specified in RFC 1321 [15]. The output of this algorithm is encoded using the base64 encoding [1].
MD5是RFC 1321[15]中规定的MD5算法。此算法的输出使用base64编码[1]进行编码。
SHA The SHA-1 algorithm [12]. The output of this algorithm is encoded using the base64 encoding [1].
SHA-1算法[12]。此算法的输出使用base64编码[1]进行编码。
UNIXsum The algorithm computed by the UNIX "sum" command, as defined by the Single UNIX Specification, Version 2 [13]. The output of this algorithm is an ASCII decimal-digit string representing the 16-bit checksum, which is the first word of the output of the UNIX "sum" command.
UNIXsum由UNIX“sum”命令计算的算法，如单一UNIX规范版本2[13]所定义。此算法的输出是一个ASCII十进制数字字符串，表示16位校验和，它是UNIX“sum”命令输出的第一个字。
UNIXcksum The algorithm computed by the UNIX "cksum" command, as defined by the Single UNIX Specification, Version 2 [13]. The output of this algorithm is an ASCII digit string representing the 32-bit CRC, which is the first word of the output of the UNIX "cksum" command.
UNIXcksum由UNIX“cksum”命令计算的算法，如单一UNIX规范版本2[13]所定义。此算法的输出是表示32位CRC的ASCII数字字符串，它是UNIX“cksum”命令输出的第一个字。
If other digest-algorithm values are defined, the associated encoding MUST either be represented as a quoted string, or MUST NOT include ";" or "," in the character sets used for the encoding.
如果定义了其他摘要算法值，则关联的编码必须表示为带引号的字符串，或者在用于编码的字符集中不得包含“；”或“，”。
An instance digest is the representation of the output of a digest algorithm, together with an indication of the algorithm used (and any parameters).
实例摘要是摘要算法输出的表示，以及所用算法（和任何参数）的指示。
instance-digest = digest-algorithm "="
<encoded digest output>
instance-digest = digest-algorithm "="
<encoded digest output>
The digest is computed on the entire instance associated with the message. The instance is a snapshot of the resource prior to the application of of any instance manipulation or transfer-coding (see section 3). The byte order used to compute the digest is the transmission byte order defined for the content-type of the instance.
摘要是在与消息关联的整个实例上计算的。实例是应用任何实例操作或传输编码之前的资源快照（参见第3节）。用于计算摘要的字节顺序是为实例的内容类型定义的传输字节顺序。
Note: the digest is computed before the application of any instance manipulation. If a range or a delta-coding [9] is used, the computation of the digest after the computation of the range or delta would not provide a digest useful for checking the integrity of the reassembled instance.
注意：摘要是在应用任何实例操作之前计算的。如果使用范围或增量编码[9]，则在计算范围或增量后计算摘要将不会提供用于检查重新组装实例完整性的摘要。
The encoded digest output uses the encoding format defined for the specific digest-algorithm. For example, if the digest-algorithm is "MD5", the encoding is base64; if the digest-algorithm is "UNIXsum", the encoding is an ASCII string of decimal digits.
编码摘要输出使用为特定摘要算法定义的编码格式。例如，如果摘要算法为“MD5”，则编码为base64；如果摘要算法为“UNIXsum”，则编码为十进制数字的ASCII字符串。
Examples:
示例：
MD5=HUXZLQLMuI/KZ5KDcJPcOA==
sha=thvDyvhfIqlvFe+A9MYgxAfm1q5=
UNIXsum=30637
MD5=HUXZLQLMuI/KZ5KDcJPcOA==
sha=thvDyvhfIqlvFe+A9MYgxAfm1q5=
UNIXsum=30637
The following headers are defined.
定义了以下标题。
The Want-Digest message header field indicates the sender's desire to receive an instance digest on messages associated with the Request-URI.
Want Digest message header字段表示发送方希望接收与请求URI关联的消息的实例摘要。
Want-Digest = "Want-Digest" ":"
#(digest-algorithm [ ";" "q" "=" qvalue])
Want-Digest = "Want-Digest" ":"
#(digest-algorithm [ ";" "q" "=" qvalue])
If a digest-algorithm is not accompanied by a qvalue, it is treated as if its associated qvalue were 1.0.
如果摘要算法没有伴随Q值，则将其视为关联的Q值为1.0。
The sender is willing to accept a digest-algorithm if and only if it is listed in a Want-Digest header field of a message, and its qvalue is non-zero.
当且仅当摘要算法列在消息的Want digest标头字段中，且其qvalue为非零时，发送方才愿意接受摘要算法。
If multiple acceptable digest-algorithm values are given, the sender's preferred digest-algorithm is the one (or ones) with the highest qvalue.
如果给出了多个可接受的摘要算法值，则发送方首选的摘要算法是Q值最高的一个（或多个）。
Examples:
示例：
Want-Digest: md5
Want-Digest: MD5;q=0.3, sha;q=1
Want-Digest: md5
Want-Digest: MD5;q=0.3, sha;q=1
The Digest message header field provides a message digest of the instance described by the message.
摘要消息头字段提供消息描述的实例的消息摘要。
Digest = "Digest" ":" #(instance-digest)
Digest = "Digest" ":" #(instance-digest)
The instance described by a message might be fully contained in the message-body, partially-contained in the message-body, or not at all contained in the message-body. The instance is specified by the Request-URI and any cache-validator contained in the message.
消息描述的实例可能完全包含在消息体中，部分包含在消息体中，或者根本不包含在消息体中。实例由请求URI和消息中包含的任何缓存验证器指定。
A Digest header field MAY contain multiple instance-digest values. This could be useful for responses expected to reside in caches shared by users with different browsers, for example.
摘要标头字段可能包含多个实例摘要值。例如，对于预期驻留在不同浏览器用户共享的缓存中的响应，这可能很有用。
A recipient MAY ignore any or all of the instance-digests in a Digest header field.
收件人可以忽略摘要标题字段中的任何或所有实例摘要。
A sender MAY send an instance-digest using a digest-algorithm without knowing whether the recipient supports the digest-algorithm, or even knowing that the recipient will ignore it.
发送方可以使用摘要算法发送实例摘要，而不知道接收方是否支持摘要算法，甚至不知道接收方将忽略它。
Examples:
示例：
Digest: md5=HUXZLQLMuI/KZ5KDcJPcOA==
Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637
Digest: md5=HUXZLQLMuI/KZ5KDcJPcOA==
Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637
5 Negotiation of Content-MD5
5内容协商-MD5
HTTP/1.1 provides a Content-MD5 header field, but does not provide any mechanism for requesting its use (or non-use). The Want-Digest header field defined in this document provides the basis for such a mechanism.
HTTP/1.1提供了Content-MD5头字段，但没有提供任何机制来请求其使用（或不使用）。本文档中定义的Want Digest header字段为这种机制提供了基础。
First, we add to the set of digest-algorithm values (in section 4.1.1) the token "contentMD5", with the provision that this digest-algorithm MUST NOT be used in a Digest header field.
首先，我们向摘要算法值集合（在第4.1.1节中）添加标记“contentMD5”，规定不得在摘要头字段中使用此摘要算法。
The presence of the "contentMD5" digest-algorithm with a non-zero qvalue in a Want-Digest header field indicates that the sender wishes to receive a Content-MD5 header on messages associated with the Request-URI.
Want digest标头字段中存在Q值非零的“contentMD5”摘要算法表示发送方希望在与请求URI关联的消息上接收Content-MD5标头。
The presence of the "contentMD5" digest-algorithm with a zero qvalue in a Want-Digest header field indicates that the sender will ignore Content-MD5 headers on messages associated with the Request-URI.
Want digest header字段中存在Q值为零的“contentMD5”摘要算法表示发送方将忽略与请求URI关联的消息上的Content-MD5标头。
6 IANA Considerations
6 IANA考虑因素
The Internet Assigned Numbers Authority (IANA) administers the name space for digest-algorithm 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 [11]).
Internet分配号码管理局（IANA）管理摘要算法值的名称空间。值及其含义必须记录在RFC或其他同行评审的、永久的、随时可用的参考文件中，并提供足够的详细信息，以便独立实现之间的互操作性成为可能。根据这些限制条件，名称分配是先到先得（见RFC 2434[11]）。
7 Security Considerations
7安全考虑
This document specifies a data integrity mechanism that protects HTTP instance data, but not HTTP entity headers, from certain kinds of accidental corruption. It is also useful in detecting at least one spoofing attack [9]. However, it is not intended as general protection against malicious tampering with HTTP messages.
本文档指定了一种数据完整性机制，用于保护HTTP实例数据（而不是HTTP实体头）免受某些意外损坏。它还可用于检测至少一种欺骗攻击[9]。但是，它不是针对恶意篡改HTTP消息的一般保护。
The HTTP Digest Access Authentication mechanism [5] provides some protection against malicious tampering.
HTTP摘要访问身份验证机制[5]提供了一些防止恶意篡改的保护。
8 Acknowledgements
8致谢
It is not clear who first realized that the Content-MD5 header field is not sufficient to provide data integrity when ranges or deltas are used.
不清楚是谁首先意识到Content-MD5头字段不足以在使用范围或增量时提供数据完整性。
Laurent Demailly may have been the first to suggest an algorithm-independent checksum header for HTTP [3]. Dave Raggett suggested the use of the term "digest" instead of "checksum" [14].
Laurent Demailly可能是第一个为HTTP提出独立于算法的校验和报头的人[3]。Dave Raggett建议使用术语“摘要”而不是“校验和”[14]。
9 References
9参考文献
[1] Freed, N. and N. Borenstein, N., "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 2049, November 1996.
[1] Freed，N.和N.Borenstein，N.，“MIME（多用途Internet邮件扩展）第一部分：指定和描述Internet邮件正文格式的机制”，RFC 2049，1996年11月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Laurent Demailly. Re: Revised Charter. http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0165.html.
[3] 劳伦特·德梅利。回复：经修订的章程。http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0165.html.
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.", RFC 2616, June 1999.
[4] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1.”，RFC2616，1999年6月。
[5] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[5] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[6] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[7] Nevin Heintze. Scalable Document Fingerprinting. Proc. Second USENIX Workshop on Electronic Commerce, USENIX, Oakland, CA, November, 1996, pp. 191-200. http://www.cs.cmu.edu/afs/cs/user/nch/www/koala/main.html.
[7] 内文·海因茨。可伸缩文档指纹。过程。第二届USENIX电子商务研讨会，USENIX，奥克兰，加利福尼亚州，1996年11月，第191-200页。http://www.cs.cmu.edu/afs/cs/user/nch/www/koala/main.html.
[8] Merriam-Webster. Webster's Seventh New Collegiate Dictionary. G. & C. Merriam Co., Springfield, MA, 1963.
[8] 韦氏词典。韦伯斯特的第七部新大学词典。G.C.Merriam公司，马萨诸塞州斯普林菲尔德，1963年。
[9] Mogul, J., Krishnamurthy, B., Douglis, F., Feldmann, A., Goland, Y. and A. van Hoff, "Delta encoding in HTTP", RFC 3229, December 2001.
[9] Mogul，J.，Krishnamurthy，B.，Douglis，F.，Feldmann，A.，Goland，Y.和A.van Hoff，“HTTP中的增量编码”，RFC 3229，2001年12月。
[10] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[10] Myers，J.和M.Rose，“Content-MD5标题字段”，RFC 18641995年10月。
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[11] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[12] National Institute of Standards and Technology. Secure Hash Standard. FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION 180-1, U.S. Department of Commerce, April, 1995. http://csrc.nist.gov/fips/fip180-1.txt.
[12] 国家标准与技术研究所。安全散列标准。联邦信息处理标准出版物180-1，美国商务部，1995年4月。http://csrc.nist.gov/fips/fip180-1.txt.
[13] The Open Group. The Single UNIX Specification, Version 2 - 6 Vol Set for UNIX 98. Document number T912, The Open Group, February, 1997.
[13] 开放组。UNIX 98的单一UNIX规范，版本2-6卷集。文件编号T912，公开组，1997年2月。
[14] Dave Raggett. Re: Revised Charter. http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0182.html.
[14] 戴夫·拉格特。回复：经修订的章程。http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0182.html.
[15] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[15] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
10 Authors' Addresses
10作者地址
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, U.S.A.
Jeffrey C.Mogul西部研究实验室康柏计算机公司美国加利福尼亚州帕洛阿尔托大学大道250号，邮编94305。
EMail: JeffMogul@acm.org
Phone: 1 650 617 3304 (email preferred)
EMail: JeffMogul@acm.org
Phone: 1 650 617 3304 (email preferred)
Arthur van Hoff Marimba, Inc. 440 Clyde Avenue Mountain View, CA 94043
Arthur van Hoff Marimba，Inc.加利福尼亚州克莱德大道440号山景城，邮编94043
EMail: avh@marimba.com
Phone: 1 (650) 930 5283
EMail: avh@marimba.com
Phone: 1 (650) 930 5283
11 Full Copyright Statement
11完整版权声明
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编辑功能的资金目前由互联网协会提供。