[要約] RFC 7233は、HTTP/1.1の範囲リクエストに関する仕様であり、リソースの一部のみを要求するためのメカニズムを提供します。目的は、ネットワークの効率性を向上させ、大きなリソースの一部のみを転送することで帯域幅を節約することです。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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].
このドキュメントのキーワード「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で定義されています。
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.
表現は、表現のメディアタイプに固有の構造に応じて、さまざまな構造単位に従ってサブレンジに分割できます。この「範囲単位」は、Accept-Ranges（セクション2.3）応答ヘッダーフィールドで使用され、範囲要求のサポートをアドバタイズします。表現のどの部分が転送されるかを説明する範囲（4.2節）ペイロードヘッダーフィールド。
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"
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:
バイト範囲指定子の値の例：
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 2番目の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.
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値が存在しない場合、または値が表現データの現在の長さ以上である場合、バイト範囲は表現の残りとして解釈されます（つまり、サーバーは最後の値を置き換えます） -選択した表現の現在の長さよりも1小さい値を持つ-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
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.
選択した表現が指定されたサフィックス長より短い場合、表現全体が使用されます。
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 2番目の500バイトの他の有効な（ただし、正規ではない）指定（バイトオフセット500〜999を含む）：
bytes=500-600,601-999 bytes=500-700,601-999
バイト= 500〜600、601〜999バイト= 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を持つ少なくとも1つのbyte-range-spec、または非サフィックス長がゼロの場合、バイト範囲セットは満足できます。そうでなければ、バイト範囲セットは満足できません。
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はオクテットの10進数として表されます。ペイロードの長さには事前定義の制限がないため、受信者は潜在的に大きな10進数を予測し、整数変換のオーバーフローによる解析エラーを防止する必要があります。
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
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
特定のターゲットリソースのバイト範囲リクエストをサポートするオリジンサーバーが送信してもよい（MAY）
Accept-Ranges: bytes
Accept-Ranges：バイト
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.
サポートされている範囲の単位を示します。クライアントは、関連するリソースのこのヘッダーフィールドを受信せずに範囲要求を生成できます（MAY）。範囲の単位はセクション2で定義されています。
A server that does not support any kind of range request for the target resource MAY send
ターゲットリソースに対するいかなる種類の範囲リクエストもサポートしていないサーバーは送信してもよい（MAY）
Accept-Ranges: none
Accept-Ranges：なし
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リクエストの「範囲」ヘッダーフィールドは、メソッドのセマンティクスを変更して、選択された表現データ全体ではなく、選択された表現データの1つ以上のサブ範囲のみの転送を要求します。
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ヘッダーフィールドを無視してもよい（MAY）。ただし、範囲は部分的に失敗した転送からの効率的な回復と大きな表現の部分的な取得をサポートするため、オリジンサーバーと中間キャッシュは可能な限りバイト範囲をサポートする必要があります。サーバーは、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ヘッダーフィールドを破棄してもよい（MAY）。
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.
範囲要求をサポートするサーバーは、2つ以上の重複する範囲、または昇順でリストされていない多数の小さな範囲のセットで構成される範囲ヘッダーフィールドを無視または拒否することができます。サービス拒否攻撃（セクション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.
複数の範囲を要求しているクライアントは、後の部分を前に要求する特定の必要がない限り、それらの範囲を昇順（通常は完全な表現で受信される順序）でリストする必要があります（SHOULD）。たとえば、パーツの内部カタログで大きな表現を処理するユーザーエージェントは、特に表現が逆の順序で保存されたページで構成されていて、ユーザーエージェントが一度に1つのページを転送したい場合は、最初に後のパーツを要求する必要があります。
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（部分的コンテンツ）応答を送信する必要があります（SHOULD）セクション4で定義されているように、要求された充足可能範囲に対応する1つ以上の部分表現を含むペイロード
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）応答を送信する必要があります（SHOULD）。
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でRangeヘッダーフィールドを使用できます（If-Unmodified-SinceとIfのいずれかまたは両方を使用） -一致。）ただし、表現が変更されたために前提条件が満たされない場合、クライアントは現在の表現全体を取得するために2番目の要求を行う必要があります。
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」ヘッダーフィールドを使用すると、クライアントは2番目のリクエストを「短絡」できます。非公式には、その意味は次のとおりです。表現が変更されていない場合は、範囲で要求しているパーツを送ってください。それ以外の場合は、表現全体を送ってください。
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ヘッダーフィールドを生成してはなりません（MUST NOT）。サーバーは、範囲ヘッダーフィールドを含まないリクエストで受信したIf-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].
クライアントは、弱いとマークされているエンティティタグを含むIf-Rangeヘッダーフィールドを生成してはなりません（MUST NOT）。クライアントが対応する表現のエンティティタグを持たず、日付が[RFC7232]のセクション2.2.2で定義されている意味で強力なバリデータでない限り、クライアントはHTTP-dateを含むIf-Rangeヘッダーフィールドを生成してはなりません（MUST NOT）。
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前提条件を評価するサーバーは、エンティティタグを比較するときに強力な比較関数を使用する必要があり（[RFC7232]のセクション2.3.2）、強力ではないHTTP日付バリデーターが提供されている場合、条件をfalseとして評価する必要があります。 [RFC7232]のセクション2.2.2で定義されている意味でのバリデーター。有効なエンティティタグは、DQUOTEの最初の2文字を調べることにより、有効な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ヘッダーフィールドで指定されたバリデーターが、ターゲットリソースの選択された表現の現在のバリデーターと一致する場合、サーバーは要求に応じてRangeヘッダーフィールドを処理する必要があります（SHOULD）。バリデーターが一致しない場合、サーバーはRangeヘッダーフィールドを無視する必要があります。完全一致によるこの比較は、バリデーターがHTTP日付である場合を含め、If-Unmodified-Since条件を評価するときに使用される「以前の値または等しい」比較とは異なることに注意してください。
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）にある満足できる範囲に対応する選択された表現の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 ...
... 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メディアタイプとその必須の境界パラメーターを含む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フィールドを生成する必要があります（SHOULD）。例えば：
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
...最初の範囲... --THIS_STRING_SEPARATES Content-Type：application / pdf Content-Range：bytes 7000-7999 / 8000
...the second range --THIS_STRING_SEPARATES--
... 2番目の範囲--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.
複数の範囲が要求された場合、サーバーは、対応するバイト範囲仕様の出現順序に関係なく、重複する範囲、または複数の部分を送信するオーバーヘッドよりも小さいギャップで区切られている範囲を合体させることができます（MAY）。受信したRangeヘッダーフィールド。 multipart / 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.
複数のパートをリクエストしないクライアントはマルチパートレスポンスをサポートしない可能性があるため、サーバーは単一の範囲のリクエストに対するマルチパートレスポンスを生成してはいけません（MUST NOT）。ただし、複数の範囲が要求され、1つの範囲のみが充足可能であることが判明した場合、または合体後に1つの範囲のみが残った場合、サーバーは単一のボディパーツのみでマルチパート/バイト範囲ペイロードを生成できますmultipart / byteranges応答を処理できないクライアントは、複数の範囲を要求する要求を生成してはなりません（MUST NOT）。
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）応答でフィールドが送信された場合、サーバーは上記の必須フィールドに加えて、次のヘッダーフィールドを生成する必要があります：日付、キャッシュ制御、Eタグ、 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.
If-Rangeヘッダーフィールドのあるリクエストに応答して206が生成された場合、クライアントはそれらのヘッダーフィールドを含む以前の応答をすでに持っていると理解されているため、送信者は上記の必要なフィールド以外の他の表現ヘッダーフィールドを生成してはなりません（SHOULD NOT）。それ以外の場合、送信者は、同じ要求に対する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を参照）。
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
Content-Range = byte-content-range / other-content-range
byte-content-range = bytes-unit SP ( byte-range-resp / unsatisfied-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.
バイト範囲の場合、完全な長さが不明または判別が困難でない限り、送信者は範囲が抽出された表現の完全な長さを示す必要があります（SHOULD）。完全長の代わりにアスタリスク文字（ "*"）は、ヘッダーフィールドが生成されたときに表現の長さが不明であることを示します。
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
Content-Range：バイト42-1233 / 1234
and this second example illustrates when the complete length is unknown:
この2番目の例は、完全な長さが不明な場合を示しています。
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が含まれている場合、またはその値が最後のバイト以下の完全な長さの値である場合は、無効です。バイト位置の値。無効なContent-Rangeの受信者は、受信したコンテンツを格納された表現と再結合してはなりません（MUST NOT）。
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ヘッダーフィールドを送信する必要があります（SHOULD）。
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.
Content-Rangeヘッダーフィールドは、その意味を明示的に説明しないステータスコードには意味がありません。この仕様の場合、206（部分的なコンテンツ）および416（範囲が満たされない）ステータスコードのみがContent-Rangeの意味を説明します。
The following are examples of Content-Range values in which the selected representation contains a total of 1234 bytes:
以下は、選択された表現が合計1234バイトを含むContent-Range値の例です。
o The first 500 bytes:
o 最初の500バイト：
Content-Range: bytes 0-499/1234
Content-Range：バイト0-499 / 1234
o The second 500 bytes:
o 2番目の500バイト：
Content-Range: bytes 500-999/1234
Content-Range：バイト500-999 / 1234
o All except for the first 500 bytes:
o 最初の500バイトを除くすべて：
Content-Range: bytes 500-1233/1234
Content-Range：バイト500-1233 / 1234
o The last 500 bytes:
o 最後の500バイト：
Content-Range: bytes 734-1233/1234
Content-Range：バイト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]).
接続が時期尚早に閉じられた場合、または要求が1つ以上の範囲指定を使用した場合、応答は表現の部分範囲のみを転送する可能性があります。このような転送を数回行った後、クライアントは同じ表現の複数の範囲を受け取った可能性があります。これらの範囲は、すべてが同じ強力なバリデーターを共有している場合にのみ安全に組み合わせることができます（[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（部分コンテンツ）応答であり、一致する格納済み応答の少なくとも1つが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.
結合された応答メッセージの本文は、新しい応答と選択された各応答の部分的なコンテンツ範囲の結合で構成されます。ユニオンが表現の全範囲で構成される場合、クライアントは、完全な長さを反映するContent-Lengthヘッダーフィールドを含む完全な200（OK）応答であるかのように、結合された応答を処理する必要があります。それ以外の場合、クライアントは一連の連続範囲を次のいずれかとして処理する必要があります。結合された応答が表現の接頭辞である場合、不完全な200（OK）応答、マルチパート/バイト範囲本体を含む単一の206（部分コンテンツ）応答、または、それぞれがContent-Rangeヘッダーフィールドで示される1つの連続範囲を持つ複数の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（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.
注：サーバーは範囲を自由に無視できるため、多くの実装は選択された表現全体を200（OK）応答で単に応答します。これは、ほとんどのクライアントがタスクを完了するために200（OK）を受け取る準備ができているためです（効率は落ちますが）。また、完全な表現を受け取るまでクライアントが無効な部分リクエストを停止しない場合もあります。したがって、クライアントは、最も適切である場合でも、416（Range Not Satisfiable）応答の受信に依存することはできません。
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 Range Unitの登録には、次のフィールドを含める必要があります。
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 | |
+-------------+---------------------------------------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
変更管理者は、「IETF（iesg@ietf.org）-Internet Engineering Task Force」です。
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）ステータスコードレジストリ」が更新され、以下の登録が含まれています。
+-------+-----------------------+-------------+
| 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 |
+-------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
変更管理者は、「IETF（iesg@ietf.org）-Internet Engineering Task Force」です。
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
サブタイプ名：バイト範囲
Required parameters: boundary
必須パラメーター：境界
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: only "7bit", "8bit", or "binary" are permitted
エンコードに関する考慮事項：「7ビット」、「8ビット」、または「バイナリ」のみが許可されます
Security considerations: see Section 6
セキュリティに関する考慮事項：セクション6を参照
Interoperability considerations: N/A
相互運用性に関する考慮事項：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.
このメディアタイプを使用するアプリケーション：1つのリクエストで複数の範囲をサポートするHTTPコンポーネント。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：なし
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：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
使用目的：COMMON
Restrictions on usage: N/A
使用上の制限：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.
制約のない複数の範囲のリクエストは、サービス拒否攻撃の影響を受けやすくなります。これは、同じデータの多くの重複する範囲をリクエストするのに必要な労力は、多くの部分でリクエストされたデータを提供しようとすることによって消費される時間、メモリ、帯域幅に比べてわずかであるためです。サーバーは、特に範囲が明確な理由なしに順不同で要求された場合に、3つ以上の重複する範囲または単一のセット内の多数の小さな範囲に対する要求など、悪質な範囲要求を無視、合体、または拒否する必要があります。マルチパート範囲リクエストは、ランダムアクセスをサポートするようには設計されていません。
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、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年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]クロッカー、D。、エド。および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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、2014年6月。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、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。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、June 2014。
[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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-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、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Appendix A. Internet Media Type multipart/byteranges
付録A.インターネットメディアタイプ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メディアタイプには、1つ以上のボディパーツが含まれ、それぞれに独自のContent-TypeフィールドとContent-Rangeフィールドがあります。必須の境界パラメータは、各ボディパーツを区切るために使用される境界文字列を指定します。
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. 多くのクライアントとサーバーは、マルチパート/ xバイト範囲のメディアタイプを使用するバイト範囲仕様の初期のドラフトにコーディングされました。
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
--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
...最初の範囲... --THIS_STRING_SEPARATES Content-Type：video / example Content-Range：exampleunit 11.2-14.3 / 25
...the second range --THIS_STRING_SEPARATES--
... 2番目の範囲--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)
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）
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（10進数0-9） 、DQUOTE（二重引用符）、HEXDIG（16進数の0-9 / AF / af）、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>
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>
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.3>
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
suffix-byte-range-spec = "-" suffix-length suffix-length = 1 * DIGIT
token = <token, see [RFC7230], Section 3.2.6>
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
Accept-Rangesヘッダーフィールド7
C Content-Range header field 12
C Content-Rangeヘッダーフィールド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
G文法Accept-Ranges 7許容範囲7バイトコンテンツ範囲12バイト範囲12バイト範囲応答12バイト範囲セット5バイト範囲指定5バイト範囲指定子5バイト単位5完全な長さ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 range-指定子5 suffix-byte-range-spec 6 suffix-length-6 unsatisfied-range 12
I If-Range header field 9
I-Rangeヘッダーフィールド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メディアタイプマルチパート/バイト範囲18、21マルチパート/ xバイト範囲19マルチパート/バイト範囲メディアタイプ18、21マルチパート/ xバイト範囲メディアタイプ21
R Range header field 8
R Rangeヘッダーフィールド8
Authors' Addresses
著者のアドレス
Roy T. Fielding (editor) Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
ロイT.フィールディング（編集者）Adobe Systems Incorporated 345 Park Ave San Jose、CA 95110 USA
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
イヴ・ラフォン（編集者）W3C / ERCIM 2004ワールドワイドウェブコンソーシアム、rte des Lucioles Sophia-Antipolis、AM 06902フランス
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、NW 48155ドイツ
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/