Skip to main content

RFC 7233 - Hypertext Transfer Protocol (HTTP/1.1): Range Requests

Published (发布日期): June 2014
Status (状态): Standards Track
Authors (作者): R. Fielding (Ed., Adobe), Y. Lafon (Ed., W3C), J. Reschke (Ed., greenbytes)
Obsoletes (废弃): RFC 2616

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)是一个用于分布式、协作式超文本信息系统的无状态应用层协议。本文档定义了范围请求以及构造和组合这些请求响应的规则。

Table of Contents (目录)​

1. Introduction​

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.

尽管范围请求机制被设计为允许可扩展的范围类型,但本规范仅定义了字节范围的请求。

1.1 Conformance and Error Handling​

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].

本文档中的关键词"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"和"OPTIONAL"应按[RFC2119]中的描述进行解释。

Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].

一致性标准和错误处理的考虑事项在[RFC7230]的第2.5节中定义。

1.2 Syntax Notation​

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.

本规范使用[RFC5234]的增强巴科斯-诺尔范式(ABNF)标记,并带有[RFC7230]第7节中定义的列表扩展,该扩展允许使用'#'操作符紧凑地定义逗号分隔的列表(类似于'*'操作符表示重复)。附录C描述了从其他文档导入的规则。附录D显示了将所有列表操作符扩展为标准ABNF标记的收集语法。

2. Range Units​

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.

表示可以根据各种结构单元划分为子范围,这取决于表示媒体类型固有的结构。这个"范围单位"用于Accept-Ranges(第2.3节)响应头字段以宣传对范围请求的支持,Range(第3.1节)请求头字段以描绘所请求的表示部分,以及Content-Range(第4.2节)载荷头字段以描述正在传输表示的哪个部分。

range-unit = bytes-unit / other-range-unit

2.1 Byte Ranges​

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"范围单位,用于表达数据八位字节序列的子范围。

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

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.

byte-range-spec中的first-byte-pos值给出范围中第一个字节的字节偏移量。last-byte-pos值给出范围中最后一个字节的字节偏移量; 也就是说,指定的字节位置是包含的。字节偏移量从零开始。

Examples of byte-ranges-specifier values:

byte-ranges-specifier值的示例:

  • The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499
    前500个字节(字节偏移量0-499,包含): bytes=0-499

  • The second 500 bytes (byte offsets 500-999, inclusive): bytes=500-999
    第二个500字节(字节偏移量500-999,包含): bytes=500-999

A byte-range-spec is invalid if the last-byte-pos value is present and less than the first-byte-pos.

如果last-byte-pos值存在且小于first-byte-pos,则byte-range-spec无效。

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).

客户端可以在不知道所选表示大小的情况下限制请求的字节数。如果last-byte-pos值不存在,或者如果该值大于或等于表示数据的当前长度,则字节范围被解释为表示的剩余部分(即,服务器用比所选表示当前长度少一的值替换last-byte-pos的值)。

A client can request the last N bytes of the selected representation using a suffix-byte-range-spec.

客户端可以使用suffix-byte-range-spec请求所选表示的最后N个字节。

suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT

If the selected representation is shorter than the specified suffix-length, the entire representation is used.

如果所选表示比指定的suffix-length短,则使用整个表示。

Additional examples, assuming a representation of length 10000:

其他示例,假设表示长度为10000:

  • The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=-500 or bytes=9500-
    最后500字节(字节偏移量9500-9999,包含): bytes=-500或bytes=9500-

  • The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
    仅第一个和最后一个字节(字节0和9999): bytes=0-0,-1

  • Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):
    第二个500字节的其他有效(但不规范)规范(字节偏移量500-999,包含):

    bytes=500-600,601-999
    bytes=500-700,601-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.

如果有效的byte-range-set包括至少一个first-byte-pos小于表示当前长度的byte-range-spec,或至少一个具有非零suffix-length的suffix-byte-range-spec,则byte-range-set是可满足的。否则,byte-range-set是不可满足的。

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.

在字节范围语法中,first-byte-pos、last-byte-pos和suffix-length表示为八位字节的十进制数。由于载荷长度没有预定义限制,接收方必须预期可能很大的十进制数字,并防止由于整数转换溢出导致的解析错误。

2.2 Other Range Units​

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

2.3 Accept-Ranges​

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"

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.

支持给定目标资源的字节范围请求的源服务器可以发送Accept-Ranges: bytes以指示支持哪些范围单位。客户端可以在没有收到所涉及资源的此头字段的情况下生成范围请求。范围单位在第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.

不支持目标资源的任何类型的范围请求的服务器可以发送Accept-Ranges: none以建议客户端不要尝试范围请求。

3. Range Requests​

3.1 Range​

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

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.

服务器可以忽略Range头字段。但是,源服务器和中间缓存应该尽可能支持字节范围,因为Range支持从部分失败的传输中有效恢复和部分检索大表示。服务器必须忽略使用GET以外的请求方法接收的Range头字段。

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.

源服务器必须忽略包含它不理解的范围单位的Range头字段。代理可以丢弃包含它不理解的范围单位的Range头字段。

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.

支持范围请求的服务器可以忽略或拒绝由两个以上重叠范围组成的Range头字段,或未按升序列出的许多小范围的集合,因为这两者都是客户端损坏或故意拒绝服务攻击的迹象(第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.

Range头字段在评估[RFC7232]中定义的前提条件头字段之后评估,并且仅当在没有Range头字段的情况下结果将是200(OK)响应时。换句话说,当条件GET将导致304(Not Modified)响应时,Range被忽略。

The If-Range header field (Section 3.2) can be used as a precondition to applying the Range header field.

If-Range头字段(第3.2节)可以用作应用Range头字段的前提条件。

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.

如果所有前提条件都为真,服务器支持目标资源的Range头字段,并且指定的范围有效且可满足(如第2.1节所定义),则服务器应该发送206(Partial Content)响应,其中载荷包含一个或多个与请求的可满足范围相对应的部分表示,如第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.

如果所有前提条件都为真,服务器支持目标资源的Range头字段,并且指定的范围无效或不可满足,则服务器应该发送416(Range Not Satisfiable)响应。

3.2 If-Range​

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.

如果客户端具有表示的部分副本并希望具有整个表示的最新副本,它可以将Range头字段与条件GET一起使用(使用If-Unmodified-Since和If-Match中的一个或两个)。但是,如果因为表示已被修改而导致前提条件失败,则客户端将不得不发出第二个请求以获得整个当前表示。

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"头字段允许客户端"短路"第二个请求。非正式地,其含义如下: 如果表示未改变,请将我在Range中请求的部分发送给我; 否则,请将整个表示发送给我。

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.

客户端不得在不包含Range头字段的请求中生成If-Range头字段。服务器必须忽略在不包含Range头字段的请求中接收的If-Range头字段。源服务器必须忽略在不支持Range请求的目标资源的请求中接收的If-Range头字段。

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].

客户端不得生成包含标记为弱的entity-tag的If-Range头字段。除非客户端对相应表示没有entity-tag并且日期是[RFC7232]第2.2.2节定义意义上的强验证器,否则客户端不得生成包含HTTP-date的If-Range头字段。

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 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.

评估If-Range前提条件的服务器在比较entity-tags时必须使用强比较函数([RFC7232]的第2.3.2节),如果提供的HTTP-date验证器不是[RFC7232]第2.2.2节定义意义上的强验证器,则必须将条件评估为假。可以通过检查前两个字符是否为DQUOTE来区分有效的entity-tag和有效的HTTP-date。

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头字段中给定的验证器与目标资源所选表示的当前验证器匹配,则服务器应该按请求处理Range头字段。如果验证器不匹配,服务器必须忽略Range头字段。请注意,这种精确匹配的比较,包括当验证器是HTTP-date时,与评估If-Unmodified-Since条件时使用的"早于或等于"比较不同。

4. Responses to a Range Request​

4.1 206 Partial Content​

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(Partial Content)状态码表示服务器通过传输所选表示的一个或多个部分来成功满足目标资源的范围请求,这些部分对应于请求的Range头字段(第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

... 26012 bytes of partial image data ...

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媒体类型及其所需boundary参数的Content-Type头字段。为避免与单部分响应混淆,服务器不得在多部分响应的HTTP头部分中生成Content-Range头字段(此字段将在每个部分中发送)。

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:

在多部分载荷中每个主体部分的头区域内,服务器必须生成与该主体部分中包含的范围相对应的Content-Range头字段。如果所选表示在200(OK)响应中会有Content-Type头字段,则服务器应该在每个主体部分的头区域中生成相同的Content-Type字段。例如:

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

...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.

当请求多个范围时,服务器可以合并任何重叠的范围,或由小于发送多个部分的开销的间隙分隔的范围,而不管相应的byte-range-spec在接收的Range头字段中出现的顺序如何。由于multipart/byteranges载荷各部分之间的典型开销约为80字节,这取决于所选表示的媒体类型和所选boundary参数长度,传输许多小的不相交部分可能不如传输整个所选表示有效。

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.

服务器不得对单个范围的请求生成多部分响应,因为不请求多个部分的客户端可能不支持多部分响应。但是,如果请求了多个范围并且只有一个范围被发现是可满足的,或者合并后只剩下一个范围,则服务器可以生成只有单个主体部分的multipart/byteranges载荷。无法处理multipart/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.

当生成多部分响应载荷时,服务器应该按照相应的byte-range-spec在接收的Range头字段中出现的相同顺序发送部分,不包括那些被认为不可满足或已合并到其他范围中的范围。接收多部分响应的客户端必须检查每个主体部分中存在的Content-Range头字段,以确定该主体部分中包含哪个范围; 客户端不能依赖接收其请求的相同范围,也不能依赖其请求的相同顺序。

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(OK)响应中发送,服务器必须生成以下头字段: Date、Cache-Control、ETag、Expires、Content-Location和Vary。

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.

如果206是响应带有If-Range头字段的请求而生成的,则发送方不应该生成除上面要求的以外的其他表示头字段,因为理解客户端已经有包含这些头字段的先前响应。否则,发送方必须生成在对同一请求的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响应默认是可缓存的; 即,除非明确的缓存控制另有说明(参见[RFC7234]的第4.2.2节)。

4.2 Content-Range​

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.

"Content-Range"头字段在单部分206(Partial Content)响应中发送以指示作为消息载荷封闭的所选表示的部分范围,在多部分206响应的每个部分中发送以指示每个主体部分中封闭的范围,以及在416(Range Not Satisfiable)响应中发送以提供有关所选表示的信息。

Content-Range = byte-content-range / other-content-range

byte-content-range = bytes-unit SP
                     ( byte-range-resp / unsatisfied-range )

byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range = first-byte-pos "-" last-byte-pos
unsatisfied-range = "*/" complete-length

complete-length = 1*DIGIT

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(Partial Content)响应包含带有接收方不理解的范围单位(第2节)的Content-Range头字段,则接收方不得尝试将其与存储的表示重新组合。接收此类消息的代理应该将其转发到下游。

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.

对于字节范围,发送方应该指示从中提取范围的表示的完整长度,除非完整长度未知或难以确定。用星号字符("*")代替complete-length表示在生成头字段时表示长度未知。

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

and this second example illustrates when the complete length is unknown:

这个第二个示例说明当完整长度未知时:

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.

如果Content-Range字段值包含last-byte-pos值小于其first-byte-pos值的byte-range-resp,或complete-length值小于或等于其last-byte-pos值,则该字段值无效。无效Content-Range的接收方不得尝试将接收的内容与存储的表示重新组合。

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(Range Not Satisfiable)响应的服务器应该发送带有unsatisfied-range值的Content-Range头字段,如以下示例所示:

Content-Range: bytes */1234

The complete-length in a 416 response indicates the current length of the selected representation.

416响应中的complete-length指示所选表示的当前长度。

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.

Content-Range头字段对于没有明确描述其语义的状态码没有意义。对于本规范,只有206(Partial Content)和416(Range Not Satisfiable)状态码描述了Content-Range的含义。

The following are examples of Content-Range values in which the selected representation contains a total of 1234 bytes:

以下是Content-Range值的示例,其中所选表示总共包含1234字节:

  • The first 500 bytes: Content-Range: bytes 0-499/1234
    前500字节: Content-Range: bytes 0-499/1234

  • The second 500 bytes: Content-Range: bytes 500-999/1234
    第二个500字节: Content-Range: bytes 500-999/1234

  • All except for the first 500 bytes: Content-Range: bytes 500-1233/1234
    除前500字节外的所有内容: Content-Range: bytes 500-1233/1234

  • The last 500 bytes: Content-Range: bytes 734-1233/1234
    最后500字节: Content-Range: bytes 734-1233/1234

4.3 Combining Ranges​

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]).

如果连接过早关闭或如果请求使用了一个或多个Range规范,响应可能仅传输表示的子范围。经过几次这样的传输后,客户端可能已经接收了同一表示的多个范围。只有当这些范围都具有相同的强验证器([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.

对目标资源的GET请求接收了多个部分响应的客户端如果它们共享相同的强验证器,则可以将这些响应组合成更大的连续范围。

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(Partial Content)响应,并且至少有一个匹配的存储响应是200(OK),则组合响应头字段由最近的200响应的头字段组成。如果所有匹配的存储响应都是206响应,则具有最新头字段的存储响应用作组合响应的头字段源,但客户端必须使用新响应中提供的除Content-Range之外的其他头字段,以替换存储响应中相应头字段的所有实例。

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)响应处理,包括反映完整长度的Content-Length头字段。否则,客户端必须将连续范围集作为以下之一处理: 如果组合响应是表示的前缀,则为不完整的200(OK)响应,包含multipart/byteranges主体的单个206(Partial Content)响应,或多个206(Partial Content)响应,每个都有一个由Content-Range头字段指示的连续范围。

4.4 416 Range Not Satisfiable​

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(Range Not Satisfiable)状态码表示请求的Range头字段(第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).

对于字节范围,未能与当前范围重叠意味着所有byte-range-spec值的first-byte-pos大于所选表示的当前长度。当响应字节范围请求生成此状态码时,发送方应该生成指定所选表示当前长度的Content-Range头字段(第4.2节)。

For example:

例如:

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.

注意: 由于服务器可以自由地忽略Range,许多实现将简单地在200(OK)响应中响应整个所选表示。这部分是因为大多数客户端准备接收200(OK)以完成任务(尽管效率较低),部分是因为客户端可能不会停止发出无效的部分请求,直到它们收到完整的表示。因此,即使在最合适的情况下,客户端也不能依赖接收416(Range Not Satisfiable)响应。

5. IANA Considerations​

5.1 Range Unit Registry​

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/。

5.1.1 Procedure​

Registration of an HTTP Range Unit MUST include the following fields:

HTTP范围单位的注册必须包括以下字段:

  • Name (名称)
  • Description (描述)
  • Pointer to specification text (规范文本指针)

Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).

要添加到此命名空间的值需要IETF审查(参见[RFC5226],第4.1节)。

5.1.2 Registrations​

The initial range unit registry contains the registrations below:

初始范围单位注册表包含以下注册:

Range Unit NameDescriptionReference
bytesa range of octetsSection 2.1
nonereserved as keyword, indicating no ranges are supportedSection 2.3

The change controller is: "IETF ([email protected]) - Internet Engineering Task Force".

变更控制者是: "IETF ([email protected]) - Internet Engineering Task Force"。

5.2 Status Code Registration​

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://www.iana.org/assignments/http-status-codes的"超文本传输协议(HTTP)状态码注册表"已更新以包含以下注册:

ValueDescriptionReference
206Partial ContentSection 4.1
416Range Not SatisfiableSection 4.4

5.3 Header Field Registration​

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 NameProtocolStatusReference
Accept-RangeshttpstandardSection 2.3
Content-RangehttpstandardSection 4.2
If-RangehttpstandardSection 3.2
RangehttpstandardSection 3.1

The change controller is: "IETF ([email protected]) - Internet Engineering Task Force".

变更控制者是: "IETF ([email protected]) - Internet Engineering Task Force"。

5.4 Internet Media Type Registration​

IANA maintains the registry of Internet media types [BCP13] at http://www.iana.org/assignments/media-types/.

IANA在http://www.iana.org/assignments/media-types/维护Internet媒体类型注册表[BCP13]。

This document serves as the specification for the Internet media type "multipart/byteranges". The following has been registered with IANA.

本文档作为Internet媒体类型"multipart/byteranges"的规范。以下已在IANA注册。

5.4.1 Internet Media Type multipart/byteranges​

  • Type name: multipart
  • Subtype name: byteranges
  • Required parameters: boundary
  • Optional parameters: N/A
  • Encoding considerations: only "7bit", "8bit", or "binary" are permitted
  • Security considerations: see Section 6
  • Interoperability considerations: N/A
  • Published specification: This specification (see Appendix A).
  • Applications that use this media type: HTTP components supporting multiple ranges in a single request.
  • Fragment identifier considerations: N/A
  • Additional information:
    • Deprecated alias names for this type: N/A
    • Magic number(s): N/A
    • File extension(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

6. Security Considerations​

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]中解决。

6.1 Denial-of-Service Attacks Using Range​

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.

无约束的多范围请求易受拒绝服务攻击,因为请求同一数据的许多重叠范围所需的工作量与尝试在许多部分中提供所请求数据所消耗的时间、内存和带宽相比微不足道。服务器应该忽略、合并或拒绝过分的范围请求,例如请求两个以上的重叠范围或单个集合中的许多小范围,特别是当范围无明显原因乱序请求时。多部分范围请求不是为了支持随机访问而设计的。

7. Acknowledgments​

See Section 10 of [RFC7230].

参见[RFC7230]的第10节。

8. References​

8.1 Normative References​

  • [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
  • [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
  • [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
  • [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.

8.2 Informative References​

  • [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
  • [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
  • [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.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

Appendix A. Internet Media Type multipart/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(Partial Content)响应消息包括多个范围的内容时,它们作为主体部分在多部分消息主体([RFC2046],第5.1节)中传输,媒体类型为"multipart/byteranges"。

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媒体类型包括一个或多个主体部分,每个都有自己的Content-Type和Content-Range字段。所需的boundary参数指定用于分隔每个主体部分的边界字符串。

Implementation Notes:

实现注意事项:

  1. Additional CRLFs might precede the first boundary string in the body.
    主体中第一个边界字符串之前可能有额外的CRLF。

  2. Although [RFC2046] permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.
    虽然[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.
    许多客户端和服务器是按照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

--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 second range
--THIS_STRING_SEPARATES--

Appendix B. Changes from RFC 2616​

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)

Content-Range头字段仅在状态码明确定义其使用时才有意义。(第4.2节)

This specification introduces a Range Unit Registry. (Section 5.1)

本规范引入了范围单位注册表。(第5.1节)

multipart/byteranges can consist of a single part. (Appendix A)

multipart/byteranges可以由单个部分组成。(附录A)

Appendix C. Imported ABNF​

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(控制字符)、DIGIT(十进制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.

请注意,从token派生的所有规则都应不区分大小写地进行比较,如range-unit和acceptable-ranges。

The rules below are defined in [RFC7230]:

以下规则在[RFC7230]中定义:

OWS = <OWS, see [RFC7230], Section 3.2>
token = <token, see [RFC7230], Section 3.2>

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>

Appendix D. Collected ABNF​

In the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230].

在下面收集的ABNF中,列表规则按照[RFC7230]第1.2节进行扩展。

Accept-Ranges = acceptable-ranges

Content-Range = byte-content-range / other-content-range

HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>

If-Range = entity-tag / HTTP-date

OWS = <OWS, see [RFC7230], Section 3.2>

Range = byte-ranges-specifier / other-ranges-specifier

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"

complete-length = 1*DIGIT

entity-tag = <entity-tag, see [RFC7232], Section 2.3>

first-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

range-unit = bytes-unit / other-range-unit

suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT

token = <token, see [RFC7230], Section 3.2>

unsatisfied-range = "*/" complete-length

Index (索引)​

2​

  • 206 Partial Content (status code) - Section 4.1

4​

  • 416 Range Not Satisfiable (status code) - Section 4.4

A​

  • Accept-Ranges header field - Section 2.3

C​

  • Content-Range header field - Section 4.2

I​

  • If-Range header field - Section 3.2

M​

  • Media Type
    • multipart/byteranges - Section 5.4.1, Appendix A
    • multipart/x-byteranges - Appendix A

R​

  • Range header field - Section 3.1

Authors' Addresses (作者地址)​

Roy T. Fielding (editor)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA

Email: [email protected]
URI: http://roy.gbiv.com/

Yves Lafon (editor)
World Wide Web Consortium
W3C / ERCIM
2004, rte des Lucioles
Sophia-Antipolis, AM 06902
France

Email: [email protected]
URI: http://www.raubacapeu.net/people/yves/

Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany

Email: [email protected]
URI: http://greenbytes.de/tech/webdav/

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

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.

HTTP/1.1 Specification Series (HTTP/1.1规范系列)​

RFC 7233 is part of the HTTP/1.1 specification series:

  1. RFC 7230 - Message Syntax and Routing (消息语法与路由)
  2. RFC 7231 - Semantics and Content (语义与内容)
  3. RFC 7232 - Conditional Requests (条件请求)
  4. RFC 7233 - Range Requests (范围请求) ← This Document
  5. RFC 7234 - Caching (缓存)
  6. RFC 7235 - Authentication (认证)