Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7233 Adobe
Obsoletes: 2616 Y. Lafon, Ed.
Category: Standards Track W3C
ISSN: 2070-1721 J. Reschke, Ed.
greenbytes
June 2014
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7233 Adobe
Obsoletes: 2616 Y. Lafon, Ed.
Category: Standards Track W3C
ISSN: 2070-1721 J. Reschke, Ed.
greenbytes
June 2014
Hypertext Transfer Protocol (HTTP/1.1): Range Requests
超文本传输协议（HTTP/1.1）：范围请求
Abstract
摘要
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.
超文本传输协议（HTTP）是用于分布式、协作式超文本信息系统的无状态应用程序级协议。本文档定义了范围请求以及构造和组合这些请求响应的规则。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7233.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7233.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Conformance and Error Handling .............................4
1.2. Syntax Notation ............................................4
2. Range Units .....................................................5
2.1. Byte Ranges ................................................5
2.2. Other Range Units ..........................................7
2.3. Accept-Ranges ..............................................7
3. Range Requests ..................................................8
3.1. Range ......................................................8
3.2. If-Range ...................................................9
4. Responses to a Range Request ...................................10
4.1. 206 Partial Content .......................................10
4.2. Content-Range .............................................12
4.3. Combining Ranges ..........................................14
4.4. 416 Range Not Satisfiable .................................15
5. IANA Considerations ............................................16
5.1. Range Unit Registry .......................................16
5.1.1. Procedure ..........................................16
5.1.2. Registrations ......................................16
5.2. Status Code Registration ..................................17
5.3. Header Field Registration .................................17
5.4. Internet Media Type Registration ..........................17
5.4.1. Internet Media Type multipart/byteranges ...........18
6. Security Considerations ........................................19
6.1. Denial-of-Service Attacks Using Range .....................19
7. Acknowledgments ................................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
Appendix A. Internet Media Type multipart/byteranges ..............21
Appendix B. Changes from RFC 2616 .................................22
Appendix C. Imported ABNF .........................................22
Appendix D. Collected ABNF ........................................23
Index .............................................................24
1. Introduction ....................................................4
1.1. Conformance and Error Handling .............................4
1.2. Syntax Notation ............................................4
2. Range Units .....................................................5
2.1. Byte Ranges ................................................5
2.2. Other Range Units ..........................................7
2.3. Accept-Ranges ..............................................7
3. Range Requests ..................................................8
3.1. Range ......................................................8
3.2. If-Range ...................................................9
4. Responses to a Range Request ...................................10
4.1. 206 Partial Content .......................................10
4.2. Content-Range .............................................12
4.3. Combining Ranges ..........................................14
4.4. 416 Range Not Satisfiable .................................15
5. IANA Considerations ............................................16
5.1. Range Unit Registry .......................................16
5.1.1. Procedure ..........................................16
5.1.2. Registrations ......................................16
5.2. Status Code Registration ..................................17
5.3. Header Field Registration .................................17
5.4. Internet Media Type Registration ..........................17
5.4.1. Internet Media Type multipart/byteranges ...........18
6. Security Considerations ........................................19
6.1. Denial-of-Service Attacks Using Range .....................19
7. Acknowledgments ................................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
Appendix A. Internet Media Type multipart/byteranges ..............21
Appendix B. Changes from RFC 2616 .................................22
Appendix C. Imported ABNF .........................................22
Appendix D. Collected ABNF ........................................23
Index .............................................................24
Hypertext Transfer Protocol (HTTP) clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. When a client has stored a partial representation, it is desirable to request the remainder of that representation in a subsequent request rather than transfer the entire representation. Likewise, devices with limited local storage might benefit from being able to request only a subset of a larger representation, such as a single page of a very large document, or the dimensions of an embedded image.
超文本传输协议（HTTP）客户端经常遇到由于取消请求或断开连接而导致的数据传输中断。当客户机存储了部分表示时，希望在后续请求中请求该表示的其余部分，而不是传输整个表示。类似地，具有有限本地存储的设备可能受益于能够仅请求更大表示的子集，例如非常大文档的单个页面或嵌入图像的尺寸。
This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability. Partial responses are indicated by a distinct status code to not be mistaken for full responses by caches that might not implement the feature.
本文档定义了HTTP/1.1范围请求、部分响应和multipart/byteranges媒体类型。范围请求是HTTP的一个可选功能，其设计目的是使未实现此功能（或不支持目标资源使用此功能）的收件人可以像响应普通GET请求一样进行响应，而不会影响互操作性。部分响应由不同的状态代码表示，以避免被可能未实现该功能的缓存误认为完全响应。
Although the range request mechanism is designed to allow for extensible range types, this specification only defines requests for byte ranges.
尽管范围请求机制设计为允许扩展范围类型，但该规范仅定义字节范围的请求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].
[RFC7230]第2.5节定义了与错误处理相关的一致性标准和注意事项。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix C describes rules imported from other documents. Appendix D shows the collected grammar with all list operators expanded to standard ABNF notation.
本规范使用[RFC7230]第7节中定义的[RFC5234]的增广巴科斯-诺尔形式（ABNF）符号和列表扩展，允许使用“#”运算符（类似于“*”运算符表示重复）对逗号分隔的列表进行紧凑定义。附录C描述了从其他文件导入的规则。附录D显示了收集的语法，所有列表运算符都扩展为标准ABNF表示法。
A representation can be partitioned into subranges according to various structural units, depending on the structure inherent in the representation's media type. This "range unit" is used in the Accept-Ranges (Section 2.3) response header field to advertise support for range requests, the Range (Section 3.1) request header field to delineate the parts of a representation that are requested, and the Content-Range (Section 4.2) payload header field to describe which part of a representation is being transferred.
表示可以根据各种结构单元划分为子范围，具体取决于表示的媒体类型中固有的结构。该“范围单位”用于接受范围（第2.3节）响应标题字段，以公布对范围请求的支持；范围（第3.1节）请求标题字段，以描述请求的表示部分；以及内容范围（第4.2节）有效负载标头字段，用于描述正在传输表示的哪一部分。
range-unit = bytes-unit / other-range-unit
range-unit = bytes-unit / other-range-unit
Since representation data is transferred in payloads as a sequence of octets, a byte range is a meaningful substructure for any representation transferable over HTTP (Section 3 of [RFC7231]). The "bytes" range unit is defined for expressing subranges of the data's octet sequence.
由于表示数据以八位字节序列的形式在有效负载中传输，因此字节范围对于通过HTTP传输的任何表示都是有意义的子结构（RFC7231第3节）。“字节”范围单位定义用于表示数据的八位字节序列的子范围。
bytes-unit = "bytes"
bytes-unit = "bytes"
A byte-range request can specify a single range of bytes or a set of ranges within a single representation.
字节范围请求可以在单个表示中指定单个字节范围或一组范围。
byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
The first-byte-pos value in a byte-range-spec gives the byte-offset of the first byte in a range. The last-byte-pos value gives the byte-offset of the last byte in the range; that is, the byte positions specified are inclusive. Byte offsets start at zero.
字节范围规范中的第一个字节pos值给出了范围中第一个字节的字节偏移量。最后一个字节的pos值给出该范围内最后一个字节的字节偏移量；也就是说，指定的字节位置是包含的。字节偏移量从零开始。
Examples of byte-ranges-specifier values:
字节范围说明符值的示例：
o The first 500 bytes (byte offsets 0-499, inclusive):
o 前500个字节（字节偏移量0-499，含）：
bytes=0-499
字节=0-499
o The second 500 bytes (byte offsets 500-999, inclusive):
o 第二个500字节（字节偏移量500-999，含）：
bytes=500-999
字节=500-999
A byte-range-spec is invalid if the last-byte-pos value is present and less than the first-byte-pos.
如果存在最后一个字节pos值且小于第一个字节pos值，则字节范围规范无效。
A client can limit the number of bytes requested without knowing the size of the selected representation. If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the representation data, the byte range is interpreted as the remainder of the representation (i.e., the server replaces the value of last-byte-pos with a value that is one less than the current length of the selected representation).
客户端可以限制请求的字节数，而不知道所选表示的大小。如果缺少最后一个字节的pos值，或者如果该值大于或等于表示数据的当前长度，则字节范围将被解释为表示的剩余部分（即，服务器将最后一个字节的pos值替换为小于所选表示的当前长度的值）。
A client can request the last N bytes of the selected representation using a suffix-byte-range-spec.
客户端可以使用后缀-byte-range-spec请求所选表示的最后N个字节。
suffix-byte-range-spec = "-" suffix-length suffix-length = 1*DIGIT
后缀字节范围spec=“-”后缀长度后缀长度=1*位
If the selected representation is shorter than the specified suffix-length, the entire representation is used.
如果选定的表示形式短于指定的后缀长度，则使用整个表示形式。
Additional examples, assuming a representation of length 10000:
其他示例，假设长度为10000：
o The final 500 bytes (byte offsets 9500-9999, inclusive):
o 最后500个字节（字节偏移量9500-9999，含）：
bytes=-500
字节=-500
Or:
或：
bytes=9500-
字节=9500-
o The first and last bytes only (bytes 0 and 9999):
o 仅第一个和最后一个字节（字节0和9999）：
bytes=0-0,-1
字节=0-0，-1
o Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):
o 第二个500字节的其他有效（但非规范）规范（字节偏移量500-999，含）：
bytes=500-600,601-999 bytes=500-700,601-999
字节=500-600601-999字节=500-700601-999
If a valid byte-range-set includes at least one byte-range-spec with a first-byte-pos that is less than the current length of the representation, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set is satisfiable. Otherwise, the byte-range-set is unsatisfiable.
如果有效的字节范围集包括至少一个第一字节位置小于表示当前长度的字节范围规范，或至少一个后缀长度为非零的后缀字节范围规范，则字节范围集是可满足的。否则，字节范围集将无法满足要求。
In the byte-range syntax, first-byte-pos, last-byte-pos, and suffix-length are expressed as decimal number of octets. Since there is no predefined limit to the length of a payload, recipients MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.
在字节范围语法中，第一个字节pos、最后一个字节pos和后缀长度表示为八位字节的十进制数。由于对有效负载的长度没有预定义的限制，因此收件人必须预测可能较大的十进制数字，并防止由于整数转换溢出而导致的解析错误。
Range units are intended to be extensible. New range units ought to be registered with IANA, as defined in Section 5.1.
射程单位是可扩展的。根据第5.1节的定义，新的量程单位应向IANA注册。
other-range-unit = token
other-range-unit = token
The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.
“Accept Ranges”标头字段允许服务器指示它支持目标资源的范围请求。
Accept-Ranges = acceptable-ranges
acceptable-ranges = 1#range-unit / "none"
Accept-Ranges = acceptable-ranges
acceptable-ranges = 1#range-unit / "none"
An origin server that supports byte-range requests for a given target resource MAY send
支持给定目标资源的字节范围请求的源服务器可以发送
Accept-Ranges: bytes
接受范围：字节
to indicate what range units are supported. A client MAY generate range requests without having received this header field for the resource involved. Range units are defined in Section 2.
指示支持的范围单位。客户端可能会生成范围请求，而不会收到所涉及资源的此标头字段。范围单位在第2节中定义。
A server that does not support any kind of range request for the target resource MAY send
不支持任何类型的目标资源范围请求的服务器可能会发送
Accept-Ranges: none
接受范围：无
to advise the client not to attempt a range request.
建议客户不要尝试范围请求。
The "Range" header field on a GET request modifies the method semantics to request transfer of only one or more subranges of the selected representation data, rather than the entire selected representation data.
GET请求上的“Range”头字段修改方法语义，以请求仅传输选定表示数据的一个或多个子范围，而不是整个选定表示数据。
Range = byte-ranges-specifier / other-ranges-specifier
other-ranges-specifier = other-range-unit "=" other-range-set
other-range-set = 1*VCHAR
Range = byte-ranges-specifier / other-ranges-specifier
other-ranges-specifier = other-range-unit "=" other-range-set
other-range-set = 1*VCHAR
A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations. A server MUST ignore a Range header field received with a request method other than GET.
服务器可能会忽略范围标头字段。然而，源服务器和中间缓存应该尽可能支持字节范围，因为范围支持从部分失败的传输中进行有效恢复和部分检索大型表示。服务器必须忽略使用GET以外的请求方法接收的范围标头字段。
An origin server MUST ignore a Range header field that contains a range unit it does not understand. A proxy MAY discard a Range header field that contains a range unit it does not understand.
原始服务器必须忽略包含其不了解的范围单位的范围标头字段。代理可能会放弃包含其不理解的范围单位的范围标头字段。
A server that supports range requests MAY ignore or reject a Range header field that consists of more than two overlapping ranges, or a set of many small ranges that are not listed in ascending order, since both are indications of either a broken client or a deliberate denial-of-service attack (Section 6.1). A client SHOULD NOT request multiple ranges that are inherently less efficient to process and transfer than a single range that encompasses the same data.
支持范围请求的服务器可能会忽略或拒绝包含两个以上重叠范围的范围标头字段，或不按升序列出的一组小范围，因为这两个字段都表示客户端已损坏或蓄意拒绝服务攻击（第6.1节）。客户端不应请求多个范围，这些范围的处理和传输效率本质上低于包含相同数据的单个范围。
A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier. For example, a user agent processing a large representation with an internal catalog of parts might need to request later parts first, particularly if the representation consists of pages stored in reverse order and the user agent wishes to transfer one page at a time.
请求多个范围的客户端应按升序（通常以完整表示形式接收这些范围的顺序）列出这些范围，除非特别需要提前请求后面的部分。例如，处理具有内部零件目录的大型表示的用户代理可能需要首先请求后续零件，特别是当表示包含按相反顺序存储的页面并且用户代理希望一次传输一个页面时。
The Range header field is evaluated after evaluating the precondition header fields defined in [RFC7232], and only if the result in absence of the Range header field would be a 200 (OK) response. In other words, Range is ignored when a conditional GET would result in a 304 (Not Modified) response.
在评估[RFC7232]中定义的前提条件标头字段后，仅当不存在范围标头字段的结果为200（确定）响应时，才评估范围标头字段。换句话说，当条件GET将导致304（未修改）响应时，范围将被忽略。
The If-Range header field (Section 3.2) can be used as a precondition to applying the Range header field.
If范围标题字段（第3.2节）可用作应用范围标题字段的先决条件。
If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are valid and satisfiable (as defined in Section 2.1), the server SHOULD send a 206 (Partial Content) response with a payload containing one or more partial representations that correspond to the satisfiable ranges requested, as defined in Section 4.
如果所有前提条件均为true，则服务器支持目标资源的范围标头字段，并且指定的范围有效且可满足（如第2.1节所定义），服务器应发送206（部分内容）有效载荷包含一个或多个部分表示的响应，该部分表示对应于第4节中定义的请求的可满足范围。
If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the server SHOULD send a 416 (Range Not Satisfiable) response.
如果所有前提条件均为true，则服务器支持目标资源的范围标头字段，并且指定的范围无效或不可满足，则服务器应发送416（范围不可满足）响应。
If a client has a partial copy of a representation and wishes to have an up-to-date copy of the entire representation, it could use the Range header field with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the precondition fails because the representation has been modified, the client would then have to make a second request to obtain the entire current representation.
如果客户机拥有表示的部分副本，并且希望拥有整个表示的最新副本，则可以将范围标头字段与条件GET一起使用（如果未修改，则使用“自”和“如果匹配”），或者同时使用两者。但是，如果前提条件因表示已修改而失败，然后，客户机必须发出第二个请求以获取整个当前表示。
The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is as follows: if the representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation.
“If Range”头字段允许客户端“短路”第二个请求。非正式地说，其含义如下：如果表述没有改变，请将我要求的范围内的零件发送给我；否则，请将整个陈述发送给我。
If-Range = entity-tag / HTTP-date
If-Range = entity-tag / HTTP-date
A client MUST NOT generate an If-Range header field in a request that does not contain a Range header field. A server MUST ignore an If-Range header field received in a request that does not contain a Range header field. An origin server MUST ignore an If-Range header field received in a request for a target resource that does not support Range requests.
客户端不得在不包含范围标头字段的请求中生成If范围标头字段。服务器必须忽略在不包含范围标头字段的请求中接收的If范围标头字段。源服务器必须忽略在对不支持范围请求的目标资源的请求中接收到的If范围标头字段。
A client MUST NOT generate an If-Range header field containing an entity-tag that is marked as weak. A client MUST NOT generate an If-Range header field containing an HTTP-date unless the client has no entity-tag for the corresponding representation and the date is a strong validator in the sense defined by Section 2.2.2 of [RFC7232].
客户端不得生成包含标记为弱的实体标记的If范围标头字段。客户机不得生成包含HTTP日期的If范围标头字段，除非客户机没有相应表示的实体标记，并且该日期是[RFC7232]第2.2.2节定义的强验证器。
A server that evaluates an If-Range precondition MUST use the strong comparison function when comparing entity-tags (Section 2.3.2 of [RFC7232]) and MUST evaluate the condition as false if an HTTP-date
评估If范围前提条件的服务器在比较实体标记时必须使用强比较功能（RFC7232的第2.3.2节），并且如果HTTP日期
validator is provided that is not a strong validator in the sense defined by Section 2.2.2 of [RFC7232]. A valid entity-tag can be distinguished from a valid HTTP-date by examining the first two characters for a DQUOTE.
提供的验证程序不是[RFC7232]第2.2.2节定义的强验证程序。通过检查DQUOTE的前两个字符，可以将有效的实体标记与有效的HTTP日期区分开来。
If the validator given in the If-Range header field matches the current validator for the selected representation of the target resource, then the server SHOULD process the Range header field as requested. If the validator does not match, the server MUST ignore the Range header field. Note that this comparison by exact match, including when the validator is an HTTP-date, differs from the "earlier than or equal to" comparison used when evaluating an If-Unmodified-Since conditional.
如果If Range header字段中给出的验证器与目标资源的选定表示形式的当前验证器匹配，则服务器应根据请求处理Range header字段。如果验证程序不匹配，服务器必须忽略范围标头字段。请注意，此精确匹配比较（包括验证程序为HTTP日期时）不同于计算If未修改的自条件时使用的“早于或等于”比较。
The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges found in the request's Range header field (Section 3.1).
206（部分内容）状态代码表示服务器通过传输与在请求的范围标头字段（第3.1节）中找到的可满足范围相对应的所选表示的一个或多个部分，成功满足目标资源的范围请求。
If a single part is being transferred, the server generating the 206 response MUST generate a Content-Range header field, describing what range of the selected representation is enclosed, and a payload consisting of the range. For example:
如果正在传输单个部件，则生成206响应的服务器必须生成一个Content Range报头字段，该字段描述所选表示的范围，以及由该范围组成的有效负载。例如：
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
... 26012 bytes of partial image data ...
... 26012字节的部分图像数据。。。
If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A, and a Content-Type header field containing the multipart/byteranges media type and its required boundary parameter. To avoid confusion with single-part responses, a server MUST NOT generate a Content-Range header field in the HTTP header section of a multiple part response (this field will be sent in each part instead).
如果正在传输多个部分，则生成206响应的服务器必须生成附录a中定义的“multipart/byteranges”有效负载，以及包含multipart/byteranges媒体类型及其所需边界参数的内容类型标头字段。为避免与单部分响应混淆，服务器不得在多部分响应的HTTP头部分中生成内容范围头字段（此字段将在每个部分中发送）。
Within the header area of each body part in the multipart payload, the server MUST generate a Content-Range header field corresponding to the range being enclosed in that body part. If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part. For example:
在多部分有效负载中每个主体部分的标题区域内，服务器必须生成一个内容范围标题字段，该字段对应于该主体部分中包含的范围。如果选定的表示将在200（确定）响应中具有内容类型标题字段，则服务器应在每个身体部位的标题区域中生成相同的内容类型字段。例如：
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000
...the second range --THIS_STRING_SEPARATES--
…第二个范围--这个字符串--
When multiple ranges are requested, a server MAY coalesce any of the ranges that overlap, or that are separated by a gap that is smaller than the overhead of sending multiple parts, regardless of the order in which the corresponding byte-range-spec appeared in the received Range header field. Since the typical overhead between parts of a multipart/byteranges payload is around 80 bytes, depending on the selected representation's media type and the chosen boundary parameter length, it can be less efficient to transfer many small disjoint parts than it is to transfer the entire selected representation.
当请求多个范围时，服务器可以合并重叠的或由小于发送多个部分的开销的间隙分隔的任何范围，而不管相应的字节范围规范出现在接收范围标头字段中的顺序如何。由于多部分/byteranges有效负载各部分之间的典型开销约为80字节，这取决于所选表示的媒体类型和所选边界参数长度，因此传输许多小的不相交部分的效率可能低于传输整个所选表示的效率。
A server MUST NOT generate a multipart response to a request for a single range, since a client that does not request multiple parts might not support multipart responses. However, a server MAY generate a multipart/byteranges payload with only a single body part if multiple ranges were requested and only one range was found to be satisfiable or only one range remained after coalescing. A client that cannot process a multipart/byteranges response MUST NOT generate a request that asks for multiple ranges.
服务器不得对单个范围的请求生成多部分响应，因为不请求多个部分的客户端可能不支持多部分响应。但是，如果请求了多个范围，并且发现只有一个范围是可满足的，或者合并后只剩下一个范围，则服务器可以生成只有一个身体部位的多部分/byteranges有效负载。无法处理多部分/byteranges响应的客户端不得生成请求多个范围的请求。
When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field,
生成多部分响应有效负载时，服务器应按照接收范围标头字段中相应字节范围规范出现的相同顺序发送部分，
excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges. A client that receives a multipart response MUST inspect the Content-Range header field present in each body part in order to determine which range is contained in that body part; a client cannot rely on receiving the same ranges that it requested, nor the same order that it requested.
不包括被认为不可满足的范围或合并到其他范围的范围。接收多部分响应的客户端必须检查每个主体部分中存在的内容范围标头字段，以确定该主体部分中包含的范围；客户端不能依赖于接收其请求的相同范围，也不能接收其请求的相同顺序。
When a 206 response is generated, the server MUST generate the following header fields, in addition to those required above, if the field would have been sent in a 200 (OK) response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and Vary.
当生成206响应时，如果该字段将在对同一请求的200（确定）响应中发送，则除了上述所需字段外，服务器还必须生成以下标题字段：日期、缓存控制、ETag、过期、内容位置和更改。
If a 206 is generated in response to a request with an If-Range header field, the sender SHOULD NOT generate other representation header fields beyond those required above, because the client is understood to already have a prior response containing those header fields. Otherwise, the sender MUST generate all of the representation header fields that would have been sent in a 200 (OK) response to the same request.
如果响应具有If Range报头字段的请求而生成206，则发送方不应生成超出上述要求的其他表示报头字段，因为客户机被理解为已经具有包含这些报头字段的先前响应。否则，发送方必须生成在对同一请求的200（OK）响应中发送的所有表示标头字段。
A 206 response is cacheable by default; i.e., unless otherwise indicated by explicit cache controls (see Section 4.2.2 of [RFC7234]).
默认情况下，206响应是可缓存的；i、 e.，除非显式缓存控制另有说明（见[RFC7234]第4.2.2节）。
The "Content-Range" header field is sent in a single part 206 (Partial Content) response to indicate the partial range of the selected representation enclosed as the message payload, sent in each part of a multipart 206 response to indicate the range enclosed within each body part, and sent in 416 (Range Not Satisfiable) responses to provide information about the selected representation.
“内容范围”报头字段在单个部分206（部分内容）响应中发送，以指示作为消息有效负载包含的所选表示的部分范围，在多部分206响应的每个部分中发送，以指示包含在每个主体部分中的范围，并在416（范围不可满足）中发送响应以提供有关所选表示的信息。
Content-Range = byte-content-range / other-content-range
内容范围=字节内容范围/其他内容范围
byte-content-range = bytes-unit SP ( byte-range-resp / unsatisfied-range )
字节内容范围=字节单位SP（字节范围对应/未满足范围）
byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range = first-byte-pos "-" last-byte-pos
unsatisfied-range = "*/" complete-length
byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range = first-byte-pos "-" last-byte-pos
unsatisfied-range = "*/" complete-length
complete-length = 1*DIGIT
complete-length = 1*DIGIT
other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR
other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR
If a 206 (Partial Content) response contains a Content-Range header field with a range unit (Section 2) that the recipient does not understand, the recipient MUST NOT attempt to recombine it with a stored representation. A proxy that receives such a message SHOULD forward it downstream.
如果206（部分内容）响应包含一个内容范围标头字段，该字段包含收件人不理解的范围单元（第2节），则收件人不得尝试将其与存储的表示重新组合。接收此类消息的代理应将其转发到下游。
For byte ranges, a sender SHOULD indicate the complete length of the representation from which the range has been extracted, unless the complete length is unknown or difficult to determine. An asterisk character ("*") in place of the complete-length indicates that the representation length was unknown when the header field was generated.
对于字节范围，发送方应指明从中提取范围的表示的完整长度，除非完整长度未知或难以确定。替换完整长度的星号字符（“*”）表示生成标头字段时表示长度未知。
The following example illustrates when the complete length of the selected representation is known by the sender to be 1234 bytes:
以下示例说明了发送方知道选定表示的完整长度为1234字节时的情况：
Content-Range: bytes 42-1233/1234
内容范围：字节42-1233/1234
and this second example illustrates when the complete length is unknown:
第二个例子说明了当完整长度未知时：
Content-Range: bytes 42-1233/*
Content-Range: bytes 42-1233/*
A Content-Range field value is invalid if it contains a byte-range-resp that has a last-byte-pos value less than its first-byte-pos value, or a complete-length value less than or equal to its last-byte-pos value. The recipient of an invalid Content-Range MUST NOT attempt to recombine the received content with a stored representation.
如果内容范围字段值包含的字节范围resp的最后一个字节pos值小于其第一个字节pos值，或完整长度值小于或等于其最后一个字节pos值，则该字段值无效。无效内容范围的收件人不得尝试将接收到的内容与存储的表示形式重新组合。
A server generating a 416 (Range Not Satisfiable) response to a byte-range request SHOULD send a Content-Range header field with an unsatisfied-range value, as in the following example:
对字节范围请求生成416（范围不可满足）响应的服务器应发送带有未满足范围值的内容范围标头字段，如下例所示：
Content-Range: bytes */1234
Content-Range: bytes */1234
The complete-length in a 416 response indicates the current length of the selected representation.
416响应中的完整长度表示所选表示的当前长度。
The Content-Range header field has no meaning for status codes that do not explicitly describe its semantic. For this specification, only the 206 (Partial Content) and 416 (Range Not Satisfiable) status codes describe a meaning for Content-Range.
内容范围标题字段对于没有明确描述其语义的状态代码没有任何意义。对于本规范，只有206（部分内容）和416（范围不可满足）状态代码描述了内容范围的含义。
The following are examples of Content-Range values in which the selected representation contains a total of 1234 bytes:
以下是所选表示法总共包含1234字节的内容范围值示例：
o The first 500 bytes:
o 前500个字节：
Content-Range: bytes 0-499/1234
内容范围：字节0-499/1234
o The second 500 bytes:
o 第二个500字节：
Content-Range: bytes 500-999/1234
内容范围：字节500-999/1234
o All except for the first 500 bytes:
o 除前500个字节外的所有字节：
Content-Range: bytes 500-1233/1234
内容范围：字节500-1233/1234
o The last 500 bytes:
o 最后500字节：
Content-Range: bytes 734-1233/1234
内容范围：字节734-1233/1234
A response might transfer only a subrange of a representation if the connection closed prematurely or if the request used one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation. These ranges can only be safely combined if they all have in common the same strong validator (Section 2.1 of [RFC7232]).
如果连接过早关闭或请求使用了一个或多个范围规范，则响应可能仅传输表示的子范围。在多次这样的传输之后，客户机可能已经收到了相同表示的多个范围。只有当这些范围都具有相同的强验证器时（RFC7232第2.1节），才能安全地组合这些范围。
A client that has received multiple partial responses to GET requests on a target resource MAY combine those responses into a larger continuous range if they share the same strong validator.
接收到多个部分响应以获取目标资源上的请求的客户端可能会将这些响应合并到一个更大的连续范围中，如果它们共享同一个强验证器。
If the most recent response is an incomplete 200 (OK) response, then the header fields of that response are used for any combined response and replace those of the matching stored responses.
如果最近的响应是不完整的200（OK）响应，则该响应的头字段将用于任何组合响应，并替换匹配存储响应的头字段。
If the most recent response is a 206 (Partial Content) response and at least one of the matching stored responses is a 200 (OK), then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching stored responses are 206 responses, then the stored response with the most recent header fields is used as the source of header fields for the combined response, except that the client MUST use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding header fields in the stored response.
如果最近的响应是206（部分内容）响应，并且匹配的存储响应中的至少一个是200（确定），则组合响应报头字段由最近的200个响应的报头字段组成。如果所有匹配的存储响应都是206个响应，则具有最新标头字段的存储响应将用作组合响应的标头字段源，但客户端必须使用新响应中提供的除内容范围之外的其他标头字段，替换存储响应中相应标头字段的所有实例。
The combined response message body consists of the union of partial content ranges in the new response and each of the selected responses. If the union consists of the entire range of the representation, then the client MUST process the combined response as if it were a complete 200 (OK) response, including a Content-Length header field that reflects the complete length. Otherwise, the client MUST process the set of continuous ranges as one of the following: an incomplete 200 (OK) response if the combined response is a prefix of the representation, a single 206 (Partial Content) response containing a multipart/byteranges body, or multiple 206 (Partial Content) responses, each with one continuous range that is indicated by a Content-Range header field.
组合响应消息正文由新响应中的部分内容范围和每个选定响应的联合组成。如果联合由表示的整个范围组成，那么客户端必须处理组合响应，就像处理完整的200（OK）响应一样，包括反映完整长度的内容长度标题字段。否则，客户端必须将连续范围集处理为以下之一：如果组合响应是表示的前缀，则为不完整的200（OK）响应，包含多部分/byteranges主体的单个206（部分内容）响应，或多个206（部分内容）响应，每个都有一个由内容范围标题字段指示的连续范围。
The 416 (Range Not Satisfiable) status code indicates that none of the ranges in the request's Range header field (Section 3.1) overlap the current extent of the selected resource or that the set of ranges requested has been rejected due to invalid ranges or an excessive request of small or overlapping ranges.
416（范围不可满足）状态代码表示请求的范围标头字段（第3.1节）中没有任何范围与所选资源的当前范围重叠，或者请求的范围集由于无效范围或小范围或重叠范围的过度请求而被拒绝。
For byte ranges, failing to overlap the current extent means that the first-byte-pos of all of the byte-range-spec values were greater than the current length of the selected representation. When this status code is generated in response to a byte-range request, the sender SHOULD generate a Content-Range header field specifying the current length of the selected representation (Section 4.2).
对于字节范围，未能重叠当前范围意味着所有字节范围规范值的第一个字节位置大于所选表示的当前长度。当响应字节范围请求生成此状态代码时，发送方应生成一个内容范围标题字段，指定所选表示的当前长度（第4.2节）。
For example:
例如：
HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022
HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022
Note: Because servers are free to ignore Range, many implementations will simply respond with the entire selected representation in a 200 (OK) response. That is partly because most clients are prepared to receive a 200 (OK) to complete the task (albeit less efficiently) and partly because clients might not stop making an invalid partial request until they have received a complete representation. Thus, clients cannot depend on receiving a 416 (Range Not Satisfiable) response even when it is most appropriate.
注意：因为服务器可以自由忽略范围，所以许多实现只需在200（OK）响应中使用整个选定的表示进行响应。这部分是因为大多数客户机准备接收200（OK）来完成任务（尽管效率较低），部分是因为客户机在收到完整的表示之前可能不会停止发出无效的部分请求。因此，即使在最合适的情况下，客户端也不能依赖于接收416（范围不可满足）响应。
The "HTTP Range Unit Registry" defines the namespace for the range unit names and refers to their corresponding specifications. The registry has been created and is now maintained at <http://www.iana.org/assignments/http-parameters>.
“HTTP范围单元注册表”定义范围单元名称的名称空间，并引用其相应的规范。注册表已创建，现在维护在<http://www.iana.org/assignments/http-parameters>.
Registration of an HTTP Range Unit MUST include the following fields:
HTTP范围单元的注册必须包括以下字段：
o Name
o 名称
o Description
o 描述
o Pointer to specification text
o 指向规范文本的指针
Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).
添加到此命名空间的值需要IETF审查（请参见[RFC5226]，第4.1节）。
The initial range unit registry contains the registrations below:
初始范围单位注册表包含以下注册：
+-------------+---------------------------------------+-------------+
| Range Unit | Description | Reference |
| Name | | |
+-------------+---------------------------------------+-------------+
| bytes | a range of octets | Section 2.1 |
| none | reserved as keyword, indicating no | Section 2.3 |
| | ranges are supported | |
+-------------+---------------------------------------+-------------+
+-------------+---------------------------------------+-------------+
| Range Unit | Description | Reference |
| Name | | |
+-------------+---------------------------------------+-------------+
| bytes | a range of octets | Section 2.1 |
| none | reserved as keyword, indicating no | Section 2.3 |
| | ranges are supported | |
+-------------+---------------------------------------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
变更控制者是：“IETF(iesg@ietf.org)-互联网工程工作队”。
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at <http://www.iana.org/assignments/http-status-codes> has been updated to include the registrations below:
“超文本传输协议（HTTP）状态代码注册表”位于<http://www.iana.org/assignments/http-status-codes>已更新，包括以下注册：
+-------+-----------------------+-------------+
| Value | Description | Reference |
+-------+-----------------------+-------------+
| 206 | Partial Content | Section 4.1 |
| 416 | Range Not Satisfiable | Section 4.4 |
+-------+-----------------------+-------------+
+-------+-----------------------+-------------+
| Value | Description | Reference |
+-------+-----------------------+-------------+
| 206 | Partial Content | Section 4.1 |
| 416 | Range Not Satisfiable | Section 4.4 |
+-------+-----------------------+-------------+
HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.
HTTP头字段在“消息头”注册表中注册，该注册表维护在<http://www.iana.org/assignments/message-headers/>.
This document defines the following HTTP header fields, so their associated registry entries have been updated according to the permanent registrations below (see [BCP90]):
本文档定义了以下HTTP头字段，因此已根据下面的永久注册更新了其关联的注册表项（请参见[BCP90]）：
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Accept-Ranges | http | standard | Section 2.3 |
| Content-Range | http | standard | Section 4.2 |
| If-Range | http | standard | Section 3.2 |
| Range | http | standard | Section 3.1 |
+-------------------+----------+----------+-------------+
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Accept-Ranges | http | standard | Section 2.3 |
| Content-Range | http | standard | Section 4.2 |
| If-Range | http | standard | Section 3.2 |
| Range | http | standard | Section 3.1 |
+-------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
变更控制者是：“IETF(iesg@ietf.org)-互联网工程工作队”。
IANA maintains the registry of Internet media types [BCP13] at <http://www.iana.org/assignments/media-types>.
IANA在以下位置维护互联网媒体类型注册表[BCP13]<http://www.iana.org/assignments/media-types>.
This document serves as the specification for the Internet media type "multipart/byteranges". The following has been registered with IANA.
本文件作为互联网媒体类型“multipart/byteranges”的规范。以下内容已在IANA注册。
Type name: multipart
类型名称：多部分
Subtype name: byteranges
子类型名称：byteranges
Required parameters: boundary
所需参数：边界
Optional parameters: N/A
可选参数：不适用
Encoding considerations: only "7bit", "8bit", or "binary" are permitted
编码注意事项：只允许使用“7位”、“8位”或“二进制”
Security considerations: see Section 6
安全注意事项：见第6节
Interoperability considerations: N/A
互操作性注意事项：不适用
Published specification: This specification (see Appendix A).
出版规范：本规范（见附录A）。
Applications that use this media type: HTTP components supporting multiple ranges in a single request.
使用此媒体类型的应用程序：在单个请求中支持多个范围的HTTP组件。
Fragment identifier considerations: N/A
片段标识符注意事项：不适用
Additional information:
其他信息：
Deprecated alias names for this type: N/A
此类型的已弃用别名：不适用
Magic number(s): N/A
Magic number(s): N/A
File extension(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Authors' Addresses section.
联系人和电子邮件地址了解更多信息：请参阅作者地址部分。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: See Authors' Addresses section.
作者：参见作者地址部分。
Change controller: IESG
更改控制器：IESG
This section is meant to inform developers, information providers, and users of known security concerns specific to the HTTP range request mechanisms. More general security considerations are addressed in HTTP messaging [RFC7230] and semantics [RFC7231].
本节旨在告知开发人员、信息提供商和用户HTTP范围请求机制特有的已知安全问题。HTTP消息传递[RFC7230]和语义[RFC7231]中介绍了更一般的安全注意事项。
Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts. Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason. Multipart range requests are not designed to support random access.
无约束的多范围请求容易受到拒绝服务攻击，因为请求相同数据的多个重叠范围所需的工作量与尝试在多个部分提供请求的数据所消耗的时间、内存和带宽相比微不足道。服务器应该忽略、合并或拒绝异常的范围请求，例如对两个以上重叠范围的请求或对单个集合中许多小范围的请求，特别是在没有明显原因而顺序错误地请求范围时。多部分范围请求的设计不支持随机访问。
See Section 10 of [RFC7230].
见[RFC7230]第10节。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年6月。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 72312014年6月。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：条件请求”，RFC 7232，2014年6月。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，2014年6月。
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[BCP13]Freed，N.，Klensin，J.和T.Hansen，“媒体类型规范和注册程序”，BCP 13，RFC 6838，2013年1月。
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[BCP90]Klyne，G.，Nottingham，M.，和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC2616] 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.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Appendix A. Internet Media Type multipart/byteranges
附录A.互联网媒体类型多部分/byteranges
When a 206 (Partial Content) response message includes the content of multiple ranges, they are transmitted as body parts in a multipart message body ([RFC2046], Section 5.1) with the media type of "multipart/byteranges".
当206（部分内容）响应消息包括多个范围的内容时，它们作为多部分消息正文（[RFC2046]，第5.1节）中的正文部分进行传输，媒体类型为“多部分/字节”。
The multipart/byteranges media type includes one or more body parts, each with its own Content-Type and Content-Range fields. The required boundary parameter specifies the boundary string used to separate each body part.
multipart/byteranges媒体类型包括一个或多个主体部分，每个主体部分都有自己的内容类型和内容范围字段。所需的边界参数指定用于分隔每个实体零件的边界字符串。
Implementation Notes:
实施说明：
1. Additional CRLFs might precede the first boundary string in the body.
1. 附加的CRLF可能位于正文中第一个边界字符串之前。
2. Although [RFC2046] permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.
2. 尽管[RFC2046]允许引用边界字符串，但某些现有实现不正确地处理引用的边界字符串。
3. A number of clients and servers were coded to an early draft of the byteranges specification that used a media type of multipart/ x-byteranges, which is almost (but not quite) compatible with this type.
3. 许多客户端和服务器被编码到byteranges规范的早期草案中，该规范使用了一种媒体类型multipart/x-byteranges，它几乎（但不完全）与这种类型兼容。
Despite the name, the "multipart/byteranges" media type is not limited to byte ranges. The following example uses an "exampleunit" range unit:
尽管名称不同，“multipart/byteranges”媒体类型不限于字节范围。以下示例使用“exampleunit”范围单位：
HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 2331785
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 2331785
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type: video/example
Content-Range: exampleunit 1.2-4.3/25
--THIS_STRING_SEPARATES
Content-Type: video/example
Content-Range: exampleunit 1.2-4.3/25
...the first range...
--THIS_STRING_SEPARATES
Content-Type: video/example
Content-Range: exampleunit 11.2-14.3/25
...the first range...
--THIS_STRING_SEPARATES
Content-Type: video/example
Content-Range: exampleunit 11.2-14.3/25
...the second range --THIS_STRING_SEPARATES--
…第二个范围--这个字符串--
Servers are given more leeway in how they respond to a range request, in order to mitigate abuse by malicious (or just greedy) clients. (Section 3.1)
服务器在如何响应范围请求方面有更多的余地，以减轻恶意（或贪婪）客户端的滥用。（第3.1节）
A weak validator cannot be used in a 206 response. (Section 4.1)
弱验证器不能用于206响应中。（第4.1节）
The Content-Range header field only has meaning when the status code explicitly defines its use. (Section 4.2)
内容范围标题字段仅在状态代码明确定义其用途时才有意义。（第4.2节）
This specification introduces a Range Unit Registry. (Section 5.1)
本规范介绍了范围单位注册表。（第5.1节）
multipart/byteranges can consist of a single part. (Appendix A)
多部分/字节表可以由单个部分组成。（附录A）
The following core rules are included by reference, as defined in Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).
根据[RFC5234]附录B.1中的定义，以下核心规则通过引用包括在内：ALPHA（字母）、CR（回车）、CRLF（CR LF）、CTL（控件）、Digital（十进制0-9）、DQUOTE（双引号）、HEXDIG（十六进制0-9/A-F/A-F）、LF（换行符）、OCTET（任何8位数据序列）、SP（空格）和VCHAR（任何可见的US-ASCII字符）。
Note that all rules derived from token are to be compared case-insensitively, like range-unit and acceptable-ranges.
请注意，从令牌派生的所有规则都将不区分大小写进行比较，如范围单位和可接受范围。
The rules below are defined in [RFC7230]:
[RFC7230]中定义了以下规则：
OWS = <OWS, see [RFC7230], Section 3.2.3>
token = <token, see [RFC7230], Section 3.2.6>
OWS = <OWS, see [RFC7230], Section 3.2.3>
token = <token, see [RFC7230], Section 3.2.6>
The rules below are defined in other parts:
以下规则在其他部分中定义：
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
entity-tag = <entity-tag, see [RFC7232], Section 2.3>
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
entity-tag = <entity-tag, see [RFC7232], Section 2.3>
In the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230].
在下面收集的ABNF中，列表规则按照[RFC7230]的第1.2节展开。
Accept-Ranges = acceptable-ranges
Accept-Ranges = acceptable-ranges
Content-Range = byte-content-range / other-content-range
Content-Range = byte-content-range / other-content-range
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
If-Range = entity-tag / HTTP-date
If-Range = entity-tag / HTTP-date
OWS = <OWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
Range = byte-ranges-specifier / other-ranges-specifier
范围=字节范围说明符/其他范围说明符
acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
range-unit ] ) ) / "none"
acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
range-unit ] ) ) / "none"
byte-content-range = bytes-unit SP ( byte-range-resp /
unsatisfied-range )
byte-range = first-byte-pos "-" last-byte-pos
byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range-set = *( "," OWS ) ( byte-range-spec /
suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
suffix-byte-range-spec ) ] )
byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
byte-ranges-specifier = bytes-unit "=" byte-range-set
bytes-unit = "bytes"
byte-content-range = bytes-unit SP ( byte-range-resp /
unsatisfied-range )
byte-range = first-byte-pos "-" last-byte-pos
byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range-set = *( "," OWS ) ( byte-range-spec /
suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
suffix-byte-range-spec ) ] )
byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
byte-ranges-specifier = bytes-unit "=" byte-range-set
bytes-unit = "bytes"
complete-length = 1*DIGIT
complete-length = 1*DIGIT
entity-tag = <entity-tag, see [RFC7232], Section 2.3>
entity-tag = <entity-tag, see [RFC7232], Section 2.3>
first-byte-pos = 1*DIGIT
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR
other-range-set = 1*VCHAR
other-range-unit = token
other-ranges-specifier = other-range-unit "=" other-range-set
other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR
other-range-set = 1*VCHAR
other-range-unit = token
other-ranges-specifier = other-range-unit "=" other-range-set
range-unit = bytes-unit / other-range-unit
range-unit = bytes-unit / other-range-unit
suffix-byte-range-spec = "-" suffix-length
后缀字节范围spec=“-”后缀长度
suffix-length = 1*DIGIT
suffix-length = 1*DIGIT
token = <token, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
unsatisfied-range = "*/" complete-length
unsatisfied-range = "*/" complete-length
Index
指数
2 206 Partial Content (status code) 10
2 206部分内容（状态代码）10
4 416 Range Not Satisfiable (status code) 15
4 416范围不可满足（状态代码）15
A Accept-Ranges header field 7
A接受范围标题字段7
C Content-Range header field 12
C内容范围标题字段12
G Grammar Accept-Ranges 7 acceptable-ranges 7 byte-content-range 12 byte-range 12 byte-range-resp 12 byte-range-set 5 byte-range-spec 5 byte-ranges-specifier 5 bytes-unit 5 complete-length 12 Content-Range 12 first-byte-pos 5 If-Range 9 last-byte-pos 5 other-content-range 12 other-range-resp 12 other-range-unit 5, 7 Range 8 range-unit 5 ranges-specifier 5 suffix-byte-range-spec 6 suffix-length 6 unsatisfied-range 12
语法接受范围7可接受范围7字节内容范围12字节范围12字节范围对应12字节范围集合5字节范围规范5字节范围说明符5字节单元5完整长度12内容范围12第一字节位置5如果范围9最后一个字节位置5其他内容范围12其他范围对应12其他范围单元5，7范围8范围单元5范围说明符5后缀字节范围规范6后缀长度6未满足范围12
I If-Range header field 9
I如果范围标题字段9
M Media Type multipart/byteranges 18, 21 multipart/x-byteranges 19 multipart/byteranges Media Type 18, 21 multipart/x-byteranges Media Type 21
M媒体类型multipart/byteranges 18、21 multipart/x-byteranges 19 multipart/byteranges媒体类型18、21 multipart/x-byteranges媒体类型21
R Range header field 8
R范围标题字段8
Authors' Addresses
作者地址
Roy T. Fielding (editor) Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
Roy T.Fielding（编辑）美国加利福尼亚州圣何塞公园大道345号Adobe系统公司，邮编95110
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
Yves Lafon (editor) World Wide Web Consortium W3C / ERCIM 2004, rte des Lucioles Sophia-Antipolis, AM 06902 France
Yves Lafon（编辑）万维网联盟W3C/ERCIM 2004，法国阿拉巴马州索菲亚安提波利斯路西奥酒店
EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/
EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F.Reschke（编辑）greenbytes GmbH Hafenweg 16 Muenster，西北48155德国
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/