HTTP/1.1

1.1. 要件の表記法

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

適合性の判定基準, ~errorの取扱いに関する考慮点は、 `HTTP$r `適合性§にて定義される。 ◎ Conformance criteria and considerations regarding error handling are defined in Section 2 of [HTTP].

1.2. 構文の表記法

【 この節の他の内容は、 `~HTTP日本語訳 共通~page＠~HTTPcommon#syntax-notation$ に移譲。 】

`A§ にて、 すべての~list演算子を標準な~ABNF表記法に展開した，総集的な文法を示す。 ◎ This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], extended with the notation for case-sensitivity in strings defined in [RFC7405]. ◎ It also uses a list extension, defined in Section 5.6.1 of [HTTP], that allows for compact definition of comma-separated lists using a "#" operator (similar to how the "*" operator indicates repetition).＼ ◎ Appendix A shows the collected grammar with all list operators expanded to standard ABNF notation. ◎ As a convention, ABNF rule names prefixed with "obs-" denote obsolete grammar rules that appear for historical reasons. ◎ The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: 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), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character).

次に挙げる規則は `HTTP$r にて定義される ⇒＃ `BWS$p, `OWS$p, `RWS$p, `absolute-path$p, `field-name$p, `field-value$p, `obs-text$p, `quoted-string$p, `token$p, `transfer-coding$p ◎ The rules below are defined in [HTTP]: • BWS = <BWS, see [HTTP], Section 5.6.3> • OWS = <OWS, see [HTTP], Section 5.6.3> • RWS = <RWS, see [HTTP], Section 5.6.3> • absolute-path = <absolute-path, see [HTTP], Section 4.1> • field-name = <field-name, see [HTTP], Section 5.1> • field-value = <field-value, see [HTTP], Section 5.5> • obs-text = <obs-text, see [HTTP], Section 5.6.4> • quoted-string = <quoted-string, see [HTTP], Section 5.6.4> • token = <token, see [HTTP], Section 5.6.2> • transfer-coding = <transfer-coding, see [HTTP], Section 10.1.4>

次に挙げる規則は `URI$r にて定義される ⇒＃ `absolute-URI$p, `authority$p, `uri-host$p, `port$p, `query$p ◎ The rules below are defined in [URI]: • absolute-URI = <absolute-URI, see [URI], Section 4.3> • authority = <authority, see [URI], Section 3.2> • uri-host = <host, see [URI], Section 3.2.2> • port = <port, see [URI], Section 3.2.3> • query = <query, see [URI], Section 3.4>

2.1. ~message形式

`HTTP-message@p
	= `start-line$p `CRLF$P
	  *( `field-line$p `CRLF$P )
	  CRLF
	  [ `message-body$p ]

`start-line@p
	= `request-line$p
	/ `status-line$p

【 これは、 ~messageの “最初の行l（ `first line^en ）” とも称される。 】

理論~上は、 `~client$も要請を受信でき, `~server$も応答を受信できる — それらは `start-line$p 形式の相違から判別できるので。 実施においては、 ~serverは，要請のみを期待するように実装され （応答は，未知または妥当でない`要請~method$と解釈される）、 ~clientは，応答のみを期待するように実装されている。 ◎ In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line formats. In practice, servers are implemented to only expect a request (a response is interpreted as an unknown or invalid request method), and clients are implemented to only expect a response.

~HTTPは `RFC2045$r に類似な いくつかの~protocol要素を用立てる。 ~HTTPと~MIME~messageとの相違点は `B§ を見よ。 ◎ HTTP makes use of some protocol elements similar to the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. See Appendix B for the differences between HTTP and MIME messages.

2.2. ~messageの構文解析-法

`受信者$は、 ~HTTP~messageを，［ ~US-ASCII `USASCII$r の上位集合である符号化法による，~octet列 ］として構文解析しなければナラナイ。 特定の符号化法について目を向けずに，~HTTP~messageを［ ~Unicode文字たちが成す~streamとして構文解析する ］ことは、 ~securityの脆弱性をもたらす — それは、［ ~octet `LF$P を包含する，妥当でない~multibyte文字~並び ］の取扱いが、 文字列~処理~libraryにより，まちまちなことに因る。 文字列に基づく構文解析器を ~protocol要素の中で安全に利用できるのは、 その要素が~messageから抽出された後に限られる — ~messageを構文解析して，個々の`~field行l$を取り出した後の~header`~field値$の中など。 ◎ A recipient MUST parse an HTTP message as a sequence of octets in an encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP message as a stream of Unicode characters, without regard for the specific encoding, creates security vulnerabilities due to the varying ways that string processing libraries handle invalid multibyte character sequences that contain the octet LF (%x0A). String-based parsers can only be safely used within protocol elements after the element has been extracted from the message, such as within a header field line value after message parsing has delineated the individual field lines.

［ `start-line$p ／各`~field$ ］用の行l終了子は， `CRLF$P ~octet並びであるが、 `受信者$は，［ 1 個の `LF$P ~octet ］を行l終了子として認識して, 先行する `CR$P を無視してもヨイ。 ◎ Although the line terminator for the start-line and fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.

`送信者$は、 `内容$以外のどの~protocol要素の中にも， `CRLF$P の一部を成さない `CR$P を`生成-$してはナラナイ。 そのような `CR$P の`受信者$は、 当の要素を妥当でないと見なすか，そのような各 `CR$P を［ 当の要素を処理する／当の~messageを回送する ］前に `SP$P に置換しなければナラナイ。 ◎ A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the content. A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message.

早期の~server応用には，［ ~~改行で終了されていない`~message本体$ ］の内容を読取るのに失敗するものもあるため、 旧い~HTTP10~UA実装は，その対処法として［ `POST$m 要請の後に余分な `CRLF$P を送信する ］ことがある。 `~HTTP11$`~UA$は、 要請の前後に `CRLF$P を付け足してはナラナイ。 `~UA$は、 ~~改行で終了する要請~message本体が欲される場合には， その~~改行を成す `CRLF$P ~octetたちの分も`~message本体の長さ$に数えなければナラナイ。 ◎ Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then the user agent MUST count the terminating CRLF octets as part of the message body length.

堅牢性の~~観点からは、［ `request-line$p を受信して, 構文解析する ］ことを期待している`~server$は、［ `request-line$p に先立って受信した空~行l ］を少なくとも 1 行l以上は無視するベキである。 ◎ In the interest of robustness, a server that is expecting to receive and parse a request-line SHOULD ignore at least one empty line (CRLF) received prior to the request-line.

`送信者$は、［ `start-line$p と最初の`~header$の合間 ］に`空白$を送信してはナラナイ。 ◎ A sender MUST NOT send whitespace between the start-line and the first header field.

`~server$は、［ ~HTTP要請~messageのみを~listenしている ］とき, あるいは［［ `start-line$p から出現するものが，~HTTP要請~messageになるかどうか ］を処理している ］ときに，［ `HTTP-message$p 文法に合致しない~octet列 ］を受信したときには、 上に挙げた堅牢性の例外を除き， `400$st 応答で応答した上で接続を~closeするベキである。 ◎ When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed above, the server SHOULD respond with a 400 (Bad Request) response and close the connection.

2.3. ~HTTP~version

~HTTPは、 ~protocolの各 `~version^dfn を指示するために， "<%~major>.<%~minor>" による付番方式を利用する。 この仕様が定義する~version番号は、 "`1.1@c" である。 ~HTTP~version番号の意味論は、 `HTTP$r `~protocol~version＠~HTTPinfra#protocol.version§ にて指定される。 ◎ HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. This specification defines version "1.1". Section 2.5 of [HTTP] specifies the semantics of HTTP version numbers.

HTTP/1.x ~messageの~versionは、［ `start-line$p 内の `HTTP-version$p ~field ］により指示される。 `HTTP-version$p は文字大小区別である。 ◎ The version of an HTTP/1.x message is indicated by an HTTP-version field in the start-line. HTTP-version is case-sensitive.

`HTTP-version@p
	= `HTTP-name$p "/" `DIGIT$P "." `DIGIT$P
`HTTP-name@p
	= ~Ps"HTTP"

~versionが［ ~HTTP10 `HTTP/1.0$r あるいは未知 ］の`受信者$に向けて送信される`~HTTP11$~messageは、［ より新たな特能すべてが無視されたなら，妥当な~HTTP10~messageとして解釈できる ］ように構築される。 この仕様は、 一部の新たな特能に対し，次が守られるように［ 受信者~versionの要件 ］を設置する ⇒ `送信者$は、 自身が当の特能に適合するとしても，［ 環境設定や, ~messageの受領を通して，受信者が~HTTP11を~supportする ］ことを決定するまでは、 互換な特能のみを利用する。 ◎ When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [HTTP/1.0] or a recipient whose version is unknown, the HTTP/1.1 message is constructed such that it can be interpreted as a valid HTTP/1.0 message if all of the newer features are ignored. This specification places recipient-version requirements on some new features so that a conformant sender will only use compatible features until it has determined, through configuration or the receipt of a message, that the recipient supports HTTP/1.1.

`中継者$は、 ~HTTP~messageを処理する（すなわち，`~tunnel$として動作していない）ときは， 自身が回送する~message内に［ 自前の `HTTP-version$p ］を送信しなければナラナイ — `上流$における課題への対処法として，目的をもって降格されていない限り。 言い換えれば，`中継者$には、 ~messageの［ 受信, 送信 ］の両者において，［ その~message内の~protocol~versionが，自身が適合する~versionに合致する ］ことが確保されない限り，［ `start-line$p を盲目的に回送する ］ことは許容されない。 仮に， `HTTP-version$p を書換えないまま~HTTP~messageが回送された場合、 `下流$の`受信者$が［ その`送信者$の~versionを利用して，［ ~message送信者との今後の通信~用に安全に利用できる特能 ］を決定している ］ときに，通信~errorになるかもしれない。 ◎ Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) MUST send their own HTTP-version in forwarded messages, unless it is purposefully downgraded as a workaround for an upstream issue. In other words, an intermediary is not allowed to blindly forward the start-line without ensuring that the protocol version in that message matches a version to which that intermediary is conformant for both the receiving and sending of messages. Forwarding an HTTP message without rewriting the HTTP-version might result in communication errors when downstream recipients use the message sender's version to determine what features are safe to use for later communication with that sender.

3.1. ~method

`method$p `token^p は、［ `~target資源$上で遂行される`要請~method$ ］を指示する。 要請~methodは、 文字大小区別である。 ◎ The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.

`method@p
	= `token$p

要請~methodは、 次も含め，`要請~method§ `HTTP$r に定義される ⇒＃ ~HTTP~method~registryに関する情報, 新たな~methodを定義する際の考慮点 ◎ The request methods defined by this specification can be found in Section 9 of [HTTP], along with information regarding the HTTP method registry and considerations for defining new methods.

3.2. 要請~target

`request-target$p 【`要請~target$】は、 要請を どの~target資源に適用するかを識別する。 `~client$は、 欲される`~target~URI$から `request-target$p を導出する。 `request-target$p には、［ 要請される~method, 要請は`~proxy$向けかどうか ］の両者に依存して，次に挙げる 4 種の別個な形式がある： ◎ The request-target identifies the target resource upon which to apply the request. The client derives a request-target from its desired target URI. There are four distinct formats for the request-target, depending on both the method being requested and whether the request is to a proxy.

`request-target@p
	= `origin-form$p
	/ `absolute-form$p
	/ `authority-form$p
	/ `asterisk-form$p

`request-target$p 内には、 空白は許容されない。 あいにく，一部の`~UA$は、［ ~hypertext参照に見出される空白 ］を適正に［ 符号化する／除外する ］ことに失敗する — その結果、 許容されない それらの文字が， 不正形な `request-line$p 内に `request-target$p として送信されることになる。 ◎ No whitespace is allowed in the request-target. Unfortunately, some user agents fail to properly encode or exclude whitespace found in hypertext references, resulting in those disallowed characters being sent as the request-target in a malformed request-line.

`origin-form@p
	= `absolute-path$p [ "?" `query$p ]

http://www.example.org/where?q=now

GET /where?q=now HTTP/1.1
Host: www.example.org

`absolute-form@p
	= `absolute-URI$p

GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1

`authority-form@p
	= `uri-host$p ":" `port$p

CONNECT www.example.com:80 HTTP/1.1
Host: www.example.com

`asterisk-form@p
	= "*"

OPTIONS * HTTP/1.1

OPTIONS http://www.example.org:8001 HTTP/1.1

OPTIONS * HTTP/1.1
Host: www.example.org:8001

3.3. ~target~URIの再構築-法

`~server$は、 `~target資源$を識別するために，要請から`~target~URI$を得ることになる。 それは、 要請の `request-target$p 【`要請~target$】 — 以下， %要請~target と記す — が `absolute-form$p である場合は %要請~target になる — この事例では，~serverは、 更に評価するために，この~URIを汎用な各~成分に構文解析することになる。 ◎ The target URI is the request-target when the request-target is in absolute-form. In that case, a server will parse the URI into its generic components for further evaluation.

他の場合，`~server$は、 接続~文脈と要請~messageを成す様々な各部から， 以下に従って`~target~URI$を構築し直す： ◎ Otherwise, the server reconstructs the target URI from the connection context and various parts of the request message in order to identify the target resource (Section 7.1 of [HTTP]):

• その `scheme$p 成分は： ◎ ↓

  1. `~server$の環境設定が固定的な~URI~schemeを供しているならば ⇒ その~scheme ◎ If the server's configuration provides for a fixed URI scheme,＼

  2. 他の場合，信用-済みな`外方$にある`~gateway$から~schemeが供されているならば ⇒ その~scheme ◎ or a scheme is provided by a trusted outbound gateway, that scheme is used for the target URI.＼

     これは、 ~scaleが巨大な配備に共通的にある — ~gateway~serverは、 `~client$の接続~文脈を受信して， それを`内方$にある~serverへ自前の接続で置換することになるので。 ◎ This is common in large-scale deployments because a gateway server will receive the client's connection context and replace that with their own connection to the inbound server.＼

  3. 他の場合，要請は`~secure化$された接続~越しに受信されたならば ⇒ "`https$c" ◎ Otherwise, if the request is received over a secured connection, the target URI's scheme is "https";＼
  4. 他の場合 ⇒ "`http$c" ◎ if not, the scheme is "http".

• その `authority$p 成分は：

  1. %要請~target は `authority-form$p であるならば ⇒ %要請~target
  2. 他の場合，要請には `Host$h ~headerが在って，その`~field値$は［ 空でない, かつ妥当である ］ならば ⇒ その~field値
  3. 他の場合 ⇒ 空
  ◎ If the request-target is in authority-form, the target URI's authority component is the request-target. Otherwise, the target URI's authority component is the field value of the Host header field. If there is no Host header field or if its field value is empty or invalid, the target URI's authority component is empty.

• その結合された［ `path$p, `query$p ］成分は：

  1. %要請~target は［ `authority-form$p ／ `asterisk-form$p ］であるならば ⇒ 空
  2. 他の場合【すなわち， %要請~target は `origin-form$p 】 ⇒ %要請~target
  ◎ If the request-target is in authority-form or asterisk-form, the target URI's combined path and query component is empty. Otherwise, the target URI's combined path and query component is the request-target.
• 構築し直された`~target~URI$は、 上で決定した各~成分（および文字列 "`://^c" ）を 次の順に結合し直した結果の `absolute-URI$p 【 `absolute-form$p 】になる ⇒＃ `scheme$p, "`://^c", `authority$p, 結合された［ `path$p, `query$p ］成分 ◎ The components of a reconstructed target URI, once determined as above, can be recombined into absolute-URI form by concatenating the scheme, "://", authority, and combined path and query component.

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org

https://www.example.org/pub/WWW/TheProject.html

OPTIONS * HTTP/1.1
Host: www.example.org:8080

http://www.example.org:8080

`~target~URI$の `scheme$p 用には空でない `authority$p が要求されるが （ "`http$c" ／ "`https$c" の事例は、これに該当する）， その `authority^p 成分は空な場合、 `~server$は，当の要請を却下できる — あるいは、［ 入って来る接続の文脈に整合な，環境設定された既定 ］を適用するかどうか決定することもできる。 文脈は、［ ~addressや~portの様な接続の詳細／ ~securityとして何が適用されたか／ 当の~serverの環境設定に特有な，局所的に定義された情報 ］を含むこともある。 空な `authority$p は、 要請を更に処理する前に，環境設定された既定で置換される。 ◎ If the target URI's authority component is empty and its URI scheme requires a non-empty authority (as is the case for "http" and "https"), the server can reject the request or determine whether a configured default applies that is consistent with the incoming connection's context. Context might include connection details like address and port, what security has been applied, and locally defined information specific to that server's configuration. An empty authority is replaced with the configured default before further processing of the request.

`~secure化$された接続の文脈の中で， `authority$p 用に既定の名前を給することは、［ ~UAが意図した `authority$p が既定と相違する ］かもしれない機会cがある場合には，内来的に安全でない。 `~server$は、［ この~riskを伴わずに，要請~文脈から `authority$p を一意に識別できる ］ならば，その識別情報を既定として利用してもヨイ。 別法として、 当の要請を［ 新たな`~client$を得する【~client~softwareを更新する？】方法を説明する安全な`資源$ ］へ~redirectする方が良いこともある。 ◎ Supplying a default name for authority within the context of a secured connection is inherently unsafe if there is any chance that the user agent's intended authority might differ from the default. A server that can uniquely identify an authority from the request context MAY use that identity as a default without this risk. Alternatively, it might be better to redirect the request to a safe resource that explains how to obtain a new client.

`~client$の`~target~URI$を構築し直すことは、 `~target資源$を識別する処理nの半分しか成さないことに注意。 もう半分は、 当の~target~URIは［ `~server$が応答を送信する用意がある, かつ送信-可能な資源 ］を識別するかどうか決定することであり， `HTTP$r `誤って~directされた要請の却下-法＠~HTTPsem#routing.reject§ にて定義される。 ◎ Note that reconstructing the client's target URI is only half of the process for identifying a target resource. The other half is determining whether that target URI identifies a resource for which the server is willing and able to send a response, as defined in Section 7.4 of [HTTP].

5.1. ~field行lの構文解析-法

~messageは、［ 個々の`~field名$に依存しない，汎用~algo ］を利用して構文解析される。 所与の`~field行l値$の内容は、 ~message解釈の今後の段階まで （通例的に，~messageの【当の`~field行l$を包含している】`~field節$全体が処理された後になる）， 構文解析されない。 ◎ Messages are parsed using a generic algorithm, independent of the individual field names. The contents within a given field line value are not parsed until a later stage of message interpretation (usually after the message's entire field section has been processed).

`~field名$と~colonの合間には，`空白$は許容されない。 過去においては，［ そのような空白の取扱いにおける相違点 ］から、［ 要請の~route法／応答の取扱い ］に~securityの脆弱性が導かれていた。 `~server$は、［ 受信した要請~messageにおいて，ある~headerがそのような空白を内包する場合 ］には，状態s~code `400$st で応答して それを却下しなければナラナイ。 `~proxy$は、 ~messageを`下流$に回送する前に， 応答~messageから そのような空白すべてを除去しなければナラナイ。 ◎ No whitespace is allowed between the field name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in request routing and response handling. A server MUST reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon. A proxy MUST remove any such whitespace from a response message before forwarding the message downstream.

`~field行l値$の前後には、 省略可能な空白（ `OWS$p ）が［ 先行する／後続する ］こともある — ヒトから読み易くするため、 `~field行l値$には， 1 個の `SP$P を先行させることが選好される。 `~field行l値$ 自体は、 そのような［ 頭部／尾部 ］を成す`空白$を内包しない： `~field行l値$の［ 最初の非~空白~octetより前 ／ 最後の非~空白~octetより後 ］に生じる `OWS$p は、 `~field行l$から`~field行l値$を抽出するときには，構文解析器により除外される。 ◎ A field line value might be preceded and/or followed by optional whitespace (OWS); a single SP preceding the field line value is preferred for consistent readability by humans. The field line value does not include that leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field line value, or after the last non-whitespace octet of the field line value, is excluded by parsers when extracting the field line value from a field line.

5.2. 廃用にされた行l折返し

歴史的に， HTTP/1.x における`~field値$は、 複数~行lに渡るよう拡張することもできた — 2 行l~目 以降の各~行lに， 1 個~以上の［ `SP$P ／ `HTAB$P ］を先行させること（ `obs-fold$p ）により。 この仕様は、 `~MIME型$ "`message/http$c" の中を除いて， そのような行l折返しを非推奨にする。 ◎ Historically, HTTP/1.x field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab (obs-fold). This specification deprecates such line folding except within the "message/http" media type (Section 10.1).

`obs-fold@p
	= `OWS$p `CRLF$P `RWS$p
	; 廃用にされた行l折返し
◎
obsolete line folding

`送信者$は、 行l折返しを内包する （すなわち， `obs-fold$p 規則に合致するものを包含する`~field行l値$がある） ~messageを — `~MIME型$ "`message/http$c" の中に梱包するものと意図するときを除き — `生成-$してはナラナイ。 ◎ A sender MUST NOT generate a message that includes line folding (i.e., that has any field line value that contains a match to the obs-fold rule) unless the message is intended for packaging within the "message/http" media type.

［ "`message/http$c" ~containerの中でない要請~message内 ］に `obs-fold$p を受信したときは： ◎ ↓

• `~server$は、 次のいずれかを行わなければナラナイ： ◎ A server that receives an obs-fold in a request message that is not within a "message/http" container MUST either＼

  • `400$st を送信して，~messageを却下する — それには，［［ 廃用にされた行l折返しは，受容-可能でない ］ことを説明する`表現$ ］が伴われることが好ましい。 ◎ reject the message by sending a 400 (Bad Request), preferably with a representation explaining that obsolete line folding is unacceptable, or＼
  • ［ `~field値$を解釈する／ ~messageを`下流$へ回送する ］に先立って、 受信した各 `obs-fold$p を 1 個~以上の `SP$P ~octetで置換する。 ◎ replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream.

• ［ `~proxy$／`~gateway$ ］は、 次のいずれかを行わなければナラナイ： ◎ A proxy or gateway that receives an obs-fold in a response message that is not within a "message/http" container MUST either＼

  • ~messageを破棄して， `502$st 応答に置換する — それには，［［ 受容-可能でない行l折返しを受信したこと ］を説明する`表現$ ］が伴われることが好ましい。 ◎ discard the message and replace it with a 502 (Bad Gateway) response, preferably with a representation explaining that unacceptable line folding was received, or＼
  • ［ `~field値$を解釈したり, ~messageを`下流$へ回送する ］に先立って、 受信した各 `obs-fold$p を 1 個~以上の `SP$P ~octetで置換する。 ◎ replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream.

• `~UA$は、 次を行わなければナラナイ： ◎ A user agent that receives an obs-fold in a response message that is not within a "message/http" container MUST＼

  • ［ `~field値$を解釈する ］に先立って、 受信した各 `obs-fold$p を 1 個~以上の `SP$P ~octetで置換する。 ◎ replace each received obs-fold with one or more SP octets prior to interpreting the field value.

6.1. `Transfer-Encoding^h

`Transfer-Encoding$h ~headerは、 一連の［ `~message本体$を形成するために，`内容$に適用された（または適用されることになる）`転送~符号法$ ］に対応する，一連の`転送~符号法の名前$を~listする： ◎ The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that have been (or will be) applied to the content in order to form the message body. Transfer codings are defined in Section 7.

`Transfer-Encoding@p
	= #`transfer-coding$p
	; `HTTP$r `TE§h にて定義される。
◎
defined in [HTTP], Section 10.1.4

`Transfer-Encoding$h は、［ ~binary~dataの安全な~transportを 7-bit ~transport~service越しに可能化する ］ために設計された， ~MIMEの `Content-Transfer-Encoding$h ~field `RFC2045$r に相似的である。 しかしながら，安全な~transportは、 転送~protocolを `8bit-clean^en にするという，異なる面に力点を置いている。 ~HTTPにおける `Transfer-Encoding$h には、 首に，動的に`生成-$される`内容$を正確aに区切ることが意図されている。 それはまた、［ 符号化法は、 【`中継者$を】通過中に限り適用されたものであり，`選定された表現$の特性でないこと ］を判別するものとしても~serveする。 ◎ Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport of binary data over a 7-bit transport service ([RFC2045], Section 6). However, safe transport has a different focus for an 8bit-clean transfer protocol.＼ In HTTP's case, Transfer-Encoding is primarily intended to accurately delimit dynamically generated content.＼ It also serves to distinguish encodings that are only applied in transit from the encodings that are a characteristic of the selected representation.

Transfer-Encoding: gzip, chunked

`Content-Encoding$h による`内容~符号法$と違って、 `Transfer-Encoding$h は，~messageの~propertyである — `表現$のそれではなく。 ［ 要請／応答 ］の`連鎖$沿いにある どの`受信者$も［ 受信した`転送~符号法$（たち）を復号してもヨイ／ `~message本体$に追加的な`転送~符号法$（たち）を適用してもヨイ ］ — `Transfer-Encoding$h の`~field値$にも対応する変更を加えた上で。 ［ 符号化~parameterについての追加的な情報 ］も［ この仕様で定義されない他の~header ］にて供され得る。 ◎ Unlike Content-Encoding (Section 8.4.1 of [HTTP]), Transfer-Encoding is a property of the message, not of the representation. Any recipient along the request/response chain MAY decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding changes are made to the Transfer-Encoding field value. Additional information about the encoding parameters can be provided by other header fields not defined by this specification.

`Transfer-Encoding$h は、［ `HEAD$m 要請に対する応答 ／ `GET$m 要請に対する `304$st 応答 ］内に送信してもヨイ。 どちらの応答も，`~message本体$を内包しない — それは、［ 要請が条件付き~でない `GET$m であったとするとき， `生成元~server$が~message本体に適用することになる`転送~符号法$ ］を指示する。 しかしながら、 この指示は，要求されてはいない — 応答の`連鎖$上にある どの`受信者$も（`生成元~server$も含む）、 不要になり次第，転送~符号法を除去できるので。 ◎ Transfer-Encoding MAY be sent in a response to a HEAD request or in a 304 (Not Modified) response (Section 15.4.5 of [HTTP]) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer coding to the message body if the request had been an unconditional GET. This indication is not required, however, because any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.

`~server$は、［ 自身が解さない`転送~符号法$を伴う要請~message ］を受信したときには， `501$st で応答するベキである。 ◎ A server that receives a request message with a transfer coding it does not understand SHOULD respond with 501 (Not Implemented).

`Transfer-Encoding$h は、 `~HTTP11$にて追加された。 ［ ~HTTP10の~supportのみを広告している実装 ］は、 一般に，転送~符号化-済みな`内容$を処理する方法を解さないものと見做されている — `Transfer-Encoding$h を伴って受信された~HTTP10~messageは、 【~HTTP10中継者を】通過中に`~chunked転送~符号法$を適正に取扱うことなく回送された見込みが高い。 ◎ Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will not understand how to process transfer-encoded content, and that an HTTP/1.0 message received with a Transfer-Encoding is likely to have been forwarded without proper handling of the chunked transfer coding in transit.

`Transfer-Encoding$h の早期の実装は、［ ~message~frame法のための`~chunked転送~符号法$ ］, ［ 進捗-~barに利用するために見積もられた `Content-Length$h ~header ］の両方を送信することもある。 このことが、 `Transfer-Encoding$h が `Content-Length$h を — これらが互いに非~互換とされることなく — 上書きするものと定義された~~理由である。 あいにく，そのような~messageを回送すると、 `下流$の受信者のうちいずれかが — 特に，~HTTP10しか実装していないそれが — 当の~messageを この仕様に則って構文解析するのに失敗する場合に，［ `要請~密入$／`応答~分割$ ］攻撃に対する脆弱性を導き得る。 ◎ Early implementations of Transfer-Encoding would occasionally send both a chunked transfer coding for message framing and an estimated Content-Length header field for use by progress bars. This is why Transfer-Encoding is defined as overriding Content-Length, as opposed to them being mutually incompatible. Unfortunately, forwarding such a message can lead to vulnerabilities regarding request smuggling (Section 11.2) or response splitting (Section 11.1) attacks if any downstream recipient fails to parse the message according to this specification, particularly when a downstream recipient only implements HTTP/1.0.

［ `~server$／`~client$ ］は，受信した~HTTP10~messageが `Transfer-Encoding$h ~headerを包含している場合には、 `Content-Length$h が在る場合でも，［ ~messageの~frame法には~~欠陥がある ］かのように扱った上で， ~messageを処理した後に接続を~closeしなければナラナイ。 ~messageの`送信者$は、［ 接続を更に利用すると誤解釈され得るような，~messageを成すある部位 ］を~buffer内に維持しているかもしれないので。 ◎ A server or client that receives an HTTP/1.0 message containing a Transfer-Encoding header field MUST treat the message as if the framing is faulty, even if a Content-Length is present, and close the connection after processing the message. The message sender might have retained a portion of the message, in buffer, that could be misinterpreted by further use of the connection.

6.2. `Content-Length^h

`送信者$は、 `Transfer-Encoding$h ~headerを包含する どの~messageにも， `Content-Length$h ~headerを送信してはナラナイ。 ◎ A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.

注記： ~HTTPにおける［ ~message~frame法のための `Content-Length$h の利用 ］は、［ ~MIMEにおける同じ~fieldの利用 ］から有意に相違する — そこでの `Content-Length^h は、 省略可能な~fieldであり， `~MIME型$ "`message/external-body^c" の中でしか利用されない。 ◎ Note: HTTP's use of Content-Length for message framing differs significantly from the same field's use in MIME, where it is an optional field used only within the "message/external-body" media-type.

6.3. ~message本体の長さ

`~message本体$の長さ（以下， `本体~長さ@ ）は、［ 以下に挙げる各~項のうち，当の~messageが該当する~~最初の項 ］に対応する記述に従って決定される： ◎ The length of a message body is determined by one of the following (in order of precedence):

`HEAD$m 要請に対する応答である ◎ Any response to a HEAD request and＼

［ `1xx$st ／ `204$st／ `304$st ］応答である ◎ any response with a 1xx (Informational), 204 (No Content), or 304 (Not Modified) status code＼

~message内にどのような~headerが在るかに関わらず，常に［ 一連の~headerの後の最初の`空~行l$ ］で終了される。 従って，`~message本体$も`~trailer節$も包含し得ない。 ◎ is always terminated by the first empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message body or trailer section.

`CONNECT$m 要請に対する， `2xx$st 応答である ◎ Any 2xx (Successful) response to a CONNECT request＼

これは，接続が、［ `~header節$を締めくくる`空~行l$の直後から，`~tunnel$になる ］ことを含意する。 `~client$は、 そのような~message内に受信した どの［ `Content-Length$h ／ `Transfer-Encoding$h ］~headerも，無視しなければナラナイ。 ◎ implies that the connection will become a tunnel immediately after the empty line that concludes the header fields. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in such a message.

`Transfer-Encoding$h ~headerが在る ◎ ↓

受信した~messageに `Content-Length$h ~headerも在る場合、 `Transfer-Encoding$h が `Content-Length$h を上書きする。 そのような~messageは［ `要請~密入$や`応答~分割$ ］を遂行する試みを指示しているかもしれないので、 ~errorとして取扱われる~OUGHT。 `中継者$は，そのような~messageを`下流$へ回送することを選ぶ場合は、 それに先立って，まず受信した `Content-Length$h ~headerを除去してから， `Transfer-Encoding^h を（下に述べるとおりに）処理しなければナラナイ。 ◎ If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 11.2) or response splitting (Section 11.1) and ought to be handled as an error. An intermediary that chooses to forward the message MUST first remove the received Content-Length field and process the Transfer-Encoding (as described below) prior to forwarding the message downstream.

• `最終-転送~符号法$は`~chunked$である場合 ⇒ `本体~長さ$は、 ~chunk化された~dataを［ その転送~符号法により，~dataの完了が指示される ］まで読取って復号することにより，決定される。 ◎ If a Transfer-Encoding header field is present and the chunked transfer coding (Section 7.1) is the final encoding,＼ the message body length is determined by reading and decoding the chunked data until the transfer coding indicates the data is complete.
• 他の場合、 ~messageは応答であるならば ⇒ `本体~長さ$は、 `~server$により~closeされるまで接続を読取ることにより，決定される。 ◎ If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding,＼ the message body length is determined by reading the connection until it is closed by the server.
• 他の場合（~messageは要請である） ⇒ `本体~長さ$は、 依拠-可能に決定し得ない — `~server$は、 状態s~code `400$st で応答した上で，接続を~closeしなければナラナイ。 ◎ If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding,＼ the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection.

妥当でない `Content-Length$h ~headerが在る ◎ If a message is received without Transfer-Encoding and with an invalid Content-Length header field, then＼

~message~frame法は妥当でない。 その`~field値$が［ ~commaで分離された~list（ `HTTP$r `~list＠~HTTPinfra#abnf.extension§）として成功裡に構文解析でき、 ~list内のすべての値は，妥当かつ互いに同じである場合 （その事例では、 当の~messageは，［ `Content-Length$h `~field値$として，その値が 1 個だけ利用された ］ものとして処理される） ］†を除き… ◎ the message framing is invalid and the recipient MUST treat it as an unrecoverable error, unless the field value can be successfully parsed as a comma-separated list (Section 5.6.1 of [HTTP]), all values in the list are valid, and all values in the list are the same (in which case, the message is processed with that single value used as the Content-Length field value).＼

【† `Content-Length$h は`単数~field$であるが、 ここでは特別に取扱われている。 加えて、 この条件を満たす場合でも，~messageを却下することは `許容されている＠~HTTPsem#invalid-Content-Length$。 】【† 同じ数を表現する異なる値（ `012^c と `12^c など）が，同じと見なされるかどうかは、 はっきりしない。 】

…を除き，`受信者$は、 それを回復-不能な~errorとして扱った上で，次に従って動作しなければナラナイ — 当の~errorが： ◎ ↑ ◎ If the unrecoverable error is＼

• 要請~内にある場合 ⇒ `~server$は、 状態s~code `400$st で応答した上で，接続を~closeする。 ◎ in a request message, the server MUST respond with a 400 (Bad Request) status code and then close the connection.＼
• `~proxy$が受信した応答~内にある場合 ⇒ `~proxy$は、 `~server$への接続を~closeし, 受信した応答を破棄した上で，`~client$に向けて［ `502$st 応答 ］を送信する。 ◎ If it is in a response message received by a proxy, the proxy MUST close the connection to the server, discard the received response, and send a 502 (Bad Gateway) response to the client.＼
• `~UA$が受信した応答~内にある場合 ⇒ `~UA$は、 `~server$への接続を~closeした上で，受信した応答を破棄する。 ◎ If it is in a response message received by a user agent, the user agent MUST close the connection to the server and discard the received response.

妥当な `Content-Length$h ~headerが在る ◎

その~decimal値【その`~field値$を~decimal数として解釈した結果】が、 ~octet数による，期待される`本体~長さ$を定義する。 ［ 送信者が接続を~closeした ］または［ 受信者が指示された~octet数を受信する前に，制限時間を超えた ］場合、 `受信者$は，~messageが`不完全$であると見なして接続を~closeしなければナラナイ。 ◎ If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the expected message body length in octets. If the sender closes the connection or the recipient times out before the indicated number of octets are received, the recipient MUST consider the message to be incomplete and close the connection.

要請である ◎

`本体~長さ$は 0 である（~message本体は無い）。 ◎ If this is a request message and none of the above are true, then the message body length is zero (no message body is present).

その他の場合 — すなわち，`本体~長さ$が宣言されていない応答~messageである ◎ Otherwise, this is a response message without a declared message body length, so＼

`本体~長さ$は［ `~server$が接続を~closeするに先立って受信した~octet数 ］により決定される。 ◎ the message body length is determined by the number of octets received prior to the server closing the connection.

応答~messageが［ 成功裡に完了し，~closeで区切られたもの ］なのか,［ ~network失敗により中断され，部分的に受信されたもの ］なのかを判別する仕方はないので、 `~server$は，アリな所では、 自身が`生成-$する~messageを［ 符号化法または長さ 【 `Transfer-Encoding$h または `Content-Length$h 】 ］で区切るベキである。 ~closeで区切る特能は、 首に［ ~HTTP10との後方-互換性 ］用に存在する。 ◎ Since there is no way to distinguish a successfully completed, close-delimited response message from a partially received message interrupted by network failure, a server SHOULD generate encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility with HTTP/1.0.

注記： 要請~messageが~closeで区切られることは決してない。 それらは常に、 長さまたは`転送~符号法$で明示的に~frame化され，どちらも無いことは［ 当の要請は`~header節$の直後で終端する ］ことを含意するので。 ◎ Note: Request messages are never close-delimited because they are always explicitly framed by length or transfer coding, with the absence of both implying the request ends immediately after the header section.

`~server$は、［ `~message本体$は包含するが `Content-Length$h は包含しない ］要請に対し， `411$st で応答して却下してもヨイ。 ◎ A server MAY reject a request that contains a message body but not a Content-Length by responding with 411 (Length Required).

~chunked以外の`転送~符号法$が適用されていない限り，［ `~message本体$を包含している要請 ］を送信する`~client$は、 その`本体~長さ$が前もって既知であるときは，［ `~chunked転送~符号法$ ］ではなく［ 妥当な `Content-Length$h ~header ］を利用するベキである — 一部の既存の~serviceは、 `~chunked転送~符号法$を解するにも関わらず， ~chunkedに対し状態s~code `411$st で応答するので。 これは概して、 そのような~serviceが［ 呼び出される手前の所に，`内容$の長さを要求する`~gateway$を介する ］ように実装されていて，~serverが［ 要請~全体を処理する前に，~bufferできないか そうする用意がない ］ためである。 ◎ Unless a transfer coding other than chunked has been applied, a client that sends a request containing a message body SHOULD use a valid Content-Length header field if the message body length is known in advance, rather than the chunked transfer coding, since some existing services respond to chunked with a 411 (Length Required) status code even though they understand the chunked transfer coding. This is typically because such services are implemented via a gateway that requires a content length in advance of being called, and the server is unable or unwilling to buffer the entire request before processing.

`~UA$は、［ `~message本体$を包含する要請 ］を送信するときは，妥当な `Content-Length$h ~headerを送信するか`~chunked転送~符号法$を利用しなければナラナイ。 `~client$は、［ `~server$が`~HTTP11$（以上の~version）の要請を取扱える ］ことを知っている場合を除き，`~chunked転送~符号法$を利用してはナラナイ — そのような知識は、 特定の利用者~環境設定や, ~~直前に受信した応答の`~version$を記憶する形をとるであろう。 ◎ A user agent that sends a request that contains a message body MUST send either a valid Content-Length header field or use the chunked transfer coding. A client MUST NOT use the chunked transfer coding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.

7.1. ~chunked転送~符号法

`chunked-body@p
	= *`chunk$p `last-chunk$p `trailer-section$p `CRLF$P
`chunk@p
	= `chunk-size$p [ `chunk-ext$p ] `CRLF$P `chunk-data$p `CRLF$P
`chunk-size@p
	= 1*`HEXDIG$P
`last-chunk@p
	= 1*("0") [ `chunk-ext$p ] `CRLF$P
`chunk-data@p
	= 1*OCTET
	; ~~長さ `chunk-size^p の~octet列
◎
a sequence of chunk-size octets

`chunk-size$p ~fieldは、 1 個以上の~hex数字からなる文字列であり， ~octet数による `chunk-data$p の~sizeを指示する。 ~chunked転送~符号法が完了するのは、［ `chunk-size$p が 0 にされた~chunk — 場合によっては`~trailer節$も後続する — が受信され，最後に空~行lにより終了された ］ときである。 ◎ The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked transfer coding is complete when a chunk with a chunk-size of zero is received, possibly followed by a trailer section, and finally terminated by an empty line.

`受信者$は、 ~chunked転送~符号法を構文解析して復号できなければナラナイ。 ◎ A recipient MUST be able to parse and decode the chunked transfer coding.

`~HTTP11$は、 ~chunk化された応答の~sizeを［ `中継者$が応答~全体を~bufferできることが確約される ］ように制限する手段を，何ら定義しない。 加えて，~chunk~sizeが巨大~過ぎる場合、 受信している実装が~sizeを正確aに表現できないと，桁溢れや精度の損失が生じ得る。 したがって，`受信者$は、［ ~hexadecimalを成す数字列が巨大になり得ること／ 整数~変換の桁溢れ／ 整数~変換に因る精度~損失 ］を見越して，それらによる~errorを防止しなければナラナイ ◎ HTTP/1.1 does not define any means to limit the size of a chunked response such that an intermediary can be assured of buffering the entire response. Additionally, very large chunk sizes may cause overflows or loss of precision if their values are not represented accurately in a receiving implementation. Therefore, recipients MUST anticipate potentially large hexadecimal numerals and prevent parsing errors due to integer conversion overflows or precision loss due to integer representation.

~chunked符号法に定義される~parameterは無い。 ~parameterが在っても、 ~errorに扱われるベキではない。 ◎ The chunked coding does not define any parameters. Their presence SHOULD be treated as an error.

`chunk-ext@p
	= *( `BWS$p ";" `BWS$p `chunk-ext-name$p [ `BWS$p "=" `BWS$p `chunk-ext-val$p ] )
`chunk-ext-name@p
	= `token$p
`chunk-ext-val@p
	= `token$p
	/ `quoted-string$p

`trailer-section@p
	= *( `field-line$p `CRLF$P )

length := 0
read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) {
   read chunk-data and CRLF
   append chunk-data to content
   length := length + chunk-size
   read chunk-size, chunk-ext (if any), and CRLF
}
read trailer field
while (trailer field is not empty) {
   if (trailer fields are stored/forwarded separately) {
       append trailer field to existing trailer fields
   }
   else if (trailer field is understood and defined as mergeable) {
       merge trailer field with existing header fields
   }
   else {
       discard trailer field
   }
   read trailer field
}
Content-Length := length
Remove "chunked" from Transfer-Encoding

7.2. 圧縮~用の転送~符号法

次に挙げる圧縮~用の`転送~符号法の名前$は、 対応する`内容~符号法の名前$と同じ~algoにより定義される ⇒＃ `compress$c （および `x-compress^c ）, `deflate$c, `gzip$c （および `x-gzip^c ） ◎ The following transfer coding names for compression are defined by the same algorithm as their corresponding content coding: ◎ compress (and x-compress) • See Section 8.4.1.1 of [HTTP]. deflate • See Section 8.4.1.2 of [HTTP]. gzip (and x-gzip) • See Section 8.4.1.3 of [HTTP].

これらの圧縮~符号法に定義される~parameterは無い。 これらの圧縮~符号法に~parameterが在る場合、 ~errorとして扱われるベキである。 ◎ The compression codings do not define any parameters. The presence of parameters with any of these compression codings SHOULD be treated as an error.

7.3. 転送~符号法~registry

`転送~符号法の名前$用の名前空間は、 `~HTTP転送~符号法~registry$cite にて保守され，定義される。 ◎ The "HTTP Transfer Coding Registry" defines the namespace for transfer coding names. It is maintained at <https://www.iana.org/assignments/http-parameters>.

各~登録は、 次に挙げる~fieldを含んでいなければナラナイ ⇒＃ 名前, 記述, 仕様~textへの~pointer ◎ Registrations MUST include the following fields: • Name • Description • Pointer to specification text

各 `転送~符号法の名前$は、 `内容~符号法の名前$ `HTTP$r と重合してはナラナイ — 符号化法の形式変換 （`内容~符号法§にて定義される各種 圧縮~符号法など） が一致している場合を除き。 ◎ Names of transfer codings MUST NOT overlap with names of content codings (Section 8.4.1 of [HTTP]) unless the encoding transformation is identical, as is the case for the compression codings defined in Section 7.2.

`TE$h ~headerは、 複数の転送~符号法が受容-可能なときに， 順位~値として名前 "`q^c" の疑似~parameterを利用する。 多義性を避けるため、 将来における転送~符号法の登録は， "`q^c" （文字大小無視）と呼ばれる~parameterを定義するベキでない。 ◎ The TE header field (Section 10.1.4 of [HTTP]) uses a pseudo-parameter named "q" as the rank value when multiple transfer codings are acceptable. Future registrations of transfer codings SHOULD NOT define parameters called "q" (case-insensitively) in order to avoid ambiguities.

この名前空間に追加される値は、 `~IETFによる考査$が要求され，［ この仕様にて定義される`転送~符号法$の目的 ］に適合しなければナラナイ。 ◎ Values to be added to this namespace require IETF Review (see Section 4.8 of [RFC8126]) and MUST conform to the purpose of transfer coding defined in this specification.

~program名は、 符号化~形式の識別~用には望ましくないので， 将来の符号化法には利用しないことが奨励される。 ◎ Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.

7.4. 転送~符号法の折衝-法

~HTTP11にて利用される `TE$h ~fieldは、 次を指示する ⇒＃ ~clientは、`~chunked$の他に，どの`転送~符号法$を応答~内に受容する用意があるか／ ~clientは、`~chunked転送~符号法$にて`~trailer$を保全する用意があるかどうか ◎ The TE field (Section 10.1.4 of [HTTP]) is used in HTTP/1.1 to indicate what transfer codings, besides chunked, the client is willing to accept in the response and whether the client is willing to preserve trailer fields in a chunked transfer coding.

`~client$は、 `TE$h 内に，`転送~符号法の名前$として "`chunked$c" を送信してはナラナイ — `~HTTP11$`受信者$に対しては、 `~chunked$は常に受容-可能なので。 ◎ A client MUST NOT send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.

TE: deflate
TE:
TE: trailers, deflate;q=0.5

`~client$は，複数の`転送~符号法$が受容-可能なときは、 文字大小無視な "`q=^c" ~parameterを利用して， それらの符号法の選好を順位~付けてもヨイ。 この “順位” 値は、 0 以上 1 以下の実数であり，値が大きいほど選好される （`内容~折衝$~fieldにて利用される`品質値$（ “`qvalue^en” ）に類似する） ⇒＃ `0.001^c は、最も選好されないことを表す【小数部は 3 桁までなので】／ `1^c は、最も選好されることを表す／ `0^c は、 “受容-可能でない” ことを意味する ◎ When multiple transfer codings are acceptable, the client MAY rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation fields; see Section 12.4.2 of [HTTP]).＼ The rank value is a real number in the range 0 through 1, where＼ 0.001 is the least preferred and＼ 1 is the most preferred;＼ a value of 0 means "not acceptable".

［ `TE$h の`~field値$が空, または `TE$h ~header【！~field】は無い ］場合、 受容-可能な`転送~符号法$は "`chunked$c" に限られる。 転送~符号法を伴わない~messageは、 常に受容-可能である。 ◎ If the TE field value is empty or if no TE field is present, the only acceptable transfer coding is chunked. A message with no transfer coding is always acceptable.

~keyword "`trailers$c" は、 送信者は`~trailer$を破棄しないことを指示する （ `HTTP$r `~trailer＠~HTTPinfra#trailer.fields§ ）。 ◎ The keyword "trailers" indicates that the sender will not discard trailer fields, as described in Section 6.5 of [HTTP].

`TE$h ~headerは，直近への接続に限り適用されるので、 `TE$h の`送信者$は — ［ `TE$h の意味論を~supportしない`中継者$による `TE$h ~headerの回送 ］を防止するため — `Connection$h ~headerの中に "`TE^c" `接続~option$も送信しなければナラナイ。 ◎ Since the TE header field only applies to the immediate connection, a sender of TE MUST also send a "TE" connection option within the Connection header field (Section 7.6.1 of [HTTP]) in order to prevent the TE header field from being forwarded by intermediaries that do not support its semantics.

9.1. 確立法

接続が，様々な［ ~transport／~session ］層の~protocolを介して確立される方法について述べることは、 この仕様の視野を超える。 各~HTTP~接続は、 1 個の下層の~transport接続に対応付けられる。 ◎ It is beyond the scope of this specification to describe how connections are established via various transport- or session-layer protocols. Each HTTP connection maps to one underlying transport connection.

9.2. 応答から要請への結付け

~HTTP11には、［ 所与の要請~message ］を［ 1 個~以上の，対応する応答~message ］に結付けるような要請~識別子は，ない。 よって，その結付けは［ 同じ接続~上で要請が為された順序が，応答が到着した順序に正確に対応する ］ことに依拠する。 1 個の要請に対し複数個の応答~messageが生じるのは、［ 同じ要請に対する`最終-応答$に， 1 個~以上の`非最終-応答$（ `1xx$st 応答）が先行するとき ］に限られる。 ◎ HTTP/1.1 does not include a request identifier for associating a given request message with its corresponding one or more response messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made on the same connection. More than one response message per request only occurs when one or more informational responses (1xx; see Section 15.2 of [HTTP]) precede a final response to the same request.

`~client$は、 接続~上に `応答待ち要請@ — まだ`最終-応答$（非 `1xx$st 応答）が受信されていない要請 — が複数個あるときには、 次に従わなければナラナイ ⇒ それらの要請からなる，送信した順序による~listを保守した上で、 その接続~上で応答~messageを受信したときは、 ~listから最初の応答待ち要請を抜き取って，受信した応答に結付ける。 ◎ A client that has more than one outstanding request on a connection MUST maintain a list of outstanding requests in the order sent and MUST associate each received response message on that connection to the first outstanding request that has not yet received a final (non-1xx) response.

`~client$は、 `応答待ち要請$が無い接続~上で~dataを受信したとしても，妥当な応答と見なしてはナラナイ。 `~client$は、 そのような接続を~closeするベキである — ~messageの区切りは、 今や多義的なので （当の~dataが，`~messageの構文解析-法§により破棄できる何個かの `CRLF$P のみからなる場合は別として）。 ◎ If a client receives data on a connection that doesn't have outstanding requests, the client MUST NOT consider that data to be a valid response; the client SHOULD close the connection, since message delimitation is now ambiguous, unless the data consists only of one or more CRLF (which can be discarded per Section 2.2).

9.3. 持続性

`~HTTP11$では、 `持続的な接続^dfn は，既定で利用できる — これは、 単独の接続~越しに，複数の［ 要請や応答 ］を運べるようにする。 ~HTTP実装は、 `持続的な接続$を~supportするベキである。 ◎ HTTP/1.1 defaults to the use of "persistent connections", allowing multiple requests and responses to be carried over a single connection. HTTP implementations SHOULD support persistent connections.

`受信者$は、［ 最も近過去に受信した~message ］内の［ `~protocol~version$, および［ 在るならば `Connection$h ~header ］］に基づいて，［ 接続が現在の応答の後にも持続することになるかどうか 【！ or not based on = or not, based on 】 ］を決定する： ◎ A recipient determines whether a connection is persistent or not based on the protocol version and Connection header field (Section 7.6.1 of [HTTP]) in the most recently received message, if any:

1. "`close$c" `接続~option$が在るならば、 持続しない。 ◎ If the "close" connection option is present (Section 9.6), the connection will not persist after the current response; else,
2. 他の場合， 受信した~protocolは`~HTTP11$（以上の~version）ならば、 持続する。 ◎ If the received protocol is HTTP/1.1 (or later), the connection will persist after the current response; else,

3. 他の場合， ~AND↓ が満たされるならば、 持続する：

   • 受信した~protocolは~HTTP10である。
   • "`keep-alive$c" `接続~option$が在る。
   • 受信者は~proxyでない, または~messageは応答である。
   • 受信者は［ ~HTTP10による "`keep-alive$c" の仕組み ］を尊守するよう望んでいる。
   ◎ If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, either the recipient is not a proxy or the message is a response, and the recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response; otherwise,
4. 他の場合，持続しない。 ◎ The connection will close after the current response.

`持続的な接続$を~supportしない`~client$は、 各~要請~messageごとに， "`close$c" `接続~option$を送信しなければナラナイ。 ◎ A client that does not support persistent connections MUST send the "close" connection option in every request message.

`持続的な接続$を~supportしない`~server$は、 各［ `最終-応答$を成す~message ］ごとに， "`close$c" `接続~option$を送信しなければナラナイ。 ◎ A server that does not support persistent connections MUST send the "close" connection option in every response message that does not have a 1xx (Informational) status code.

`~client$は、 自身が［ "`close$c" `接続~option$を送信するか受信する ］または［ "`keep-alive$c" `接続~option$を伴わない~HTTP10応答を受信する ］まで、 `持続的な接続$上に，追加的な要請を送信してもヨイ。 ◎ A client MAY send additional requests on a persistent connection until it sends or receives a "close" connection option or receives an HTTP/1.0 response without a "keep-alive" connection option.

持続的であり続けるためには、 接続~上の どの~messageも — `~message本体§に述べたように — その長さが~message自身により定義される必要がある （すなわち，長さは接続の~closureにより定義されるものではない）。 `~server$は、［ 要請の`~message本体$全体を読取る ］または［ 自身が応答を送信した後に接続を~closeする ］のいずれかをしなければナラナイ — さもなければ、［ `持続的な接続$上に残っている~data ］が［ その次の要請として誤解釈される ］ことになる。 同様に，`~client$は、［ 後続な要請に同じ接続を再利用する ］ことを意図するならば，［ 応答の`~message本体$全体 ］を読取らなければナラナイ。 ◎ In order to remain persistent, all messages on a connection need to have a self-defined message length (i.e., one not defined by closure of the connection), as described in Section 6. A server MUST read the entire request message body or close the connection after sending its response; otherwise, the remaining data on a persistent connection would be misinterpreted as the next request. Likewise, a client MUST read the entire response message body if it intends to reuse the same connection for a subsequent request.

`~proxy$~serverは、 ~HTTP10`~client$と伴に `持続的な接続$を保守してはナラナイ （多くの~HTTP10~clientにより実装されている `Keep-Alive$h ~headerに伴われる問題の情報, 論点については、 `Keep-Alive§h を見よ）。 ◎ A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Appendix C.2.2 for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).

~HTTP10~clientに対する後方-互換性についての更なる情報は、 `Keep-Alive§h を見よ。 ◎ See Appendix C.2.2 for more information on backwards compatibility with HTTP/1.0 clients.

9.4. 同時並行性

`~client$は、 所与の`~server$に対し保守する［ 同時~open接続~数 ］を制限する~OUGHT。 ◎ A client ought to limit the number of simultaneous open connections that it maintains to a given server.

~HTTPの以前の改訂では，接続~数に特定の~~上限を設けていたが、 これは，多くの応用にとり実用的でないことが判っている。 そのため，この仕様は、 特定0の最大~接続~数を義務付けない — 代わりに、 ~clientが複数の接続を~openするにあたっては，保守的になることを奨励する。 ◎ Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections.

複数~接続は、 概して， “`head-of-line blocking^en” 問題 — ［ `~server$側に重い処理を要したり, 巨大な`内容$を転送する ］ような要請が、 同じ接続~上の後続な要請を阻むこと — を避けるために利用される。 しかしながら、 接続のそれぞれが~server資源を消費する。 ◎ Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant server-side processing and/or transfers very large content would block subsequent requests on the same connection. However, each connection consumes server resources.

更には，複数~接続が利用された場合、 混雑した~networkに望ましくない副作用をもたらし得る。 より多数な接続が利用された場合、 混雑していない~networkにも副作用をもたらし得る — それらを集成した，初期~時には同期された送信による挙動は、 より少数な並列的な接続が利用されていたなら無かった混雑の原因になり得るので。 ◎ Furthermore, using multiple connections can cause undesirable side effects in congested networks. Using larger numbers of connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used.

`~server$は、 単独の~clientからの過度な~open接続~数など，［ 濫用的あるいは, ~DoS攻撃の特性を有している ］と判断した流通を却下することもあることに注意。 ◎ Note that a server might reject traffic that it deems abusive or characteristic of a denial-of-service attack, such as an excessive number of open connections from a single client.

9.5. 失敗と制限時間

`~server$は、 通例的に，何らかの制限時間~値を持つ — 作動中でない接続が それを超過したときは、 もはや保守しなくなるような。 ~proxy~serverは、 この値をより高くすることもある — `~client$は、 同じ~proxy~serverを通して，更なる接続を~~確立する見込みが高いので。 `持続的な接続$の利用は、［ `~client$／`~server$ ］どちらに対しても［ この制限時間の長さ（または その有無） ］に要件を設置しない。 ◎ Servers will usually have some timeout value beyond which they will no longer maintain an inactive connection. Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same proxy server. The use of persistent connections places no requirements on the length (or existence) of this timeout for either the client or the server.

制限時間を望む［ `~client$／`~server$ ］は、 接続~上に上品な~closeを発行するベキである。 実装は、［ ~open接続にて受信される~closure通達 ］を常時~監視して，それに対し適切に応答するベキである — 接続の両~側に向けて~closureを促すことで，割振られた~system資源を取戻せるようになるので。 ◎ A client or server that wishes to time out SHOULD issue a graceful close on the connection. Implementations SHOULD constantly monitor open connections for a received closure signal and respond to it as appropriate, since prompt closure of both sides of a connection enables allocated system resources to be reclaimed.

［ `~client$／`~server$／`~proxy$ ］は、 ~transport接続をいつでも~closeしてもヨイ。 例えば、 ~serverが “遊休~中” の接続を~closeすると裁定したと同時に， ~clientが新たな要請の送信を開始することもあり得る — その場合、 ~server視点からは，遊休~中に接続が~closeされているように見える一方で、 ~client視点からは，要請は進捗~中に見えることになる。 ◎ A client, server, or proxy MAY close the transport connection at any time. For example, a client might have started to send a new request at the same time that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed while it was idle, but from the client's point of view, a request is in progress.

`~server$は、 アリなときは，`持続的な接続$を維持させ, ［ 一時的な過負荷は、 下層~transportの~flow制御の仕組みにより解決できる ］ようにするベキである — `~client$が再試行する期待に基づいて，接続を終了させる技法は、［ ~network混雑／~server負荷 ］を悪化させ得るので。 ◎ A server SHOULD sustain persistent connections, when possible, and allow the underlying transport's flow-control mechanisms to resolve temporary overloads rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate network congestion or server load.

`~message本体$を送信している`~client$は、 要請を伝送している間，~error応答に関して~network接続を監視するベキである。 【すなわち，】~clientは、 応答から［ `~server$は、 `~message本体$を受信することを望まず，接続を~closeしている ］ことが指示された場合には，［ 本体の伝送処理を即時に止めた上で，自身の側の接続を~closeする ］ベキである。 ◎ A client sending a message body SHOULD monitor the network connection for an error response while it is transmitting the request. If the client sees a response that indicates the server does not wish to receive the message body and is closing the connection, the client SHOULD immediately cease transmitting the body and close its side of the connection.

9.6. 解体

"`close@c" `接続~option$は、［ `送信者$は、 応答の完了~後に，この接続を~closeすることになる ］ことの通達として定義される。 `送信者$は、 接続を~closeするよう意図するときは， "`close$c" `接続~option$を包含している `Connection$h ~headerを送信するベキである。 ◎ The "close" connection option is defined as a signal that the sender will close this connection after completion of the response. A sender SHOULD send a Connection header field (Section 7.6.1 of [HTTP]) containing the "close" connection option when it intends to close a connection.＼

Connection: close

`~field名$ `Close^h は、 予約-済みであることに注意 — その名前を~headerとして利用すると、 "`close$c" `接続~option$と競合するかもしれないので。 ◎ Note that the field name "Close" is reserved, since using that name as a header field might conflict with the "close" connection option.

`~server$が，~TCP接続の~closeを即時に遂行した場合、［ `~client$が最後の~HTTP応答を読取れなくなる ］有意な~riskがある： ~server【側の~TCP~stack】が，［ 全部的に~closeされた接続 ］上で［ ~clientから追加的な~data ］を受信した場合 — 例えば、 ~clientが，~serverの応答を受信する前に送信した 別の要請など — ~serverの~TCP~stackは、 ~clientへ向けて，~reset~packetを送信することになる。 が、 あいにく，~reset~packet【を受け取った~client側の~TCP~stack】は、 ~clientの~HTTP構文解析器が［ ~clientからは認知されてない入力~buffer ］を読取って解釈する前に， ~bufferを消去し得る。 ◎ If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able to read the last HTTP response. If the server receives additional data from the client on a fully closed connection, such as another request sent by the client before receiving the server's response, the server's TCP stack will send a reset packet to the client; unfortunately, the reset packet might erase the client's unacknowledged input buffers before they can be read and interpreted by the client's HTTP parser.

~reset問題が［ ~TCPに固有なのか，他の~transport接続~protocolにも見出され得るのか ］は、 未知である。 ◎ It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.

~clientから書込n側のみ~closeされた~TCP接続は、［ 要請~messageを区切る ］ことも［ ~clientは応答に関心を~~失ったことを含意する ］こともないことに注意。 一般に，際どい事例を通達する際には、 ~transportによる通達には依拠し得ない — ~HTTP11は、 ~transportからは独立なので。 ◎ Note that a TCP connection that is half-closed by the client does not delimit a request message, nor does it imply that the client is no longer interested in a response. In general, transport signals cannot be relied upon to signal edge cases, since HTTP/1.1 is independent of transport.

9.7. ~TLS接続の起動

概念的に，~TLS越しの~HTTPは、 単純に，~HTTP~messageを［ ~TLS `TLS13$r を介して`~secure化$された接続 ］越しに送信する。 ◎ Conceptually, HTTP/TLS is simply sending HTTP messages over a connection secured via TLS [TLS13].

~HTTP~clientは、 ~TLS~clientとしても動作する。 `~client$は、 適切な~port上で`~server$への接続を起動して，~TLS~handshakeを始めるために~TLS `ClientHello^i を送信する。 ~TLS~handshakeが完遂したとき、 ~clientは，最初の~HTTP要請を起動できる。 すべての~HTTP~dataは，~TLS “応用~data” として送信されなければナラナイが、 他の~~点では，~HTTP用の通常の接続の様に扱われる （`持続的な接続$として再利用される場合も含めて）。 ◎ The HTTP client also acts as the TLS client. It initiates a connection to the server on the appropriate port and sends the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished, the client may then initiate the first HTTP request. All HTTP data MUST be sent as TLS "application data" but is otherwise treated like a normal connection for HTTP (including potential reuse as a persistent connection).

9.8. ~TLS接続の~closure

~TLSは、［ （~errorでない）接続を~closeするに先立って，~closure~alertの交換-を利用する ］ことで，~secureな接続の~closureを供する — `TLS13$r `6.1＠~RFCx/rfc8446.html#section-6.1§ を見よ。 妥当な~closure~alertを受信した実装は、 その接続~上では，それ以上~dataは受信されないことを確約できる。 ◎ TLS uses an exchange of closure alerts prior to (non-error) connection closure to provide secure connection closure; see Section 6.1 of [TLS13]. When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection.

実装は、 自身が~careする~message~dataすべてを［ 送信した／受信した ］ものと — 概して，~HTTP~message境界を検出することにより — 知れたとき、 ~closure~alertを送信してから — 相手の端点【！~peer】から~closure~alertが送信されてくるのを待機することなく — 接続を~closeすることにより， “不完全な~close” を生成するかもしれない。 ◎ When an implementation knows that it has sent or received all the message data that it cares about, typically by detecting HTTP message boundaries, it might generate an "incomplete close" by sending a closure alert and then closing the connection without waiting to receive the corresponding closure alert from its peer.

不完全な~closeは、 すでに受信した~dataの~securityについて疑いを示すものではないが， 後続な~dataは切落されたかもしれないことを指示することもある。 ~TLSは，~HTTP~message~frame法を直に自覚しないので、 ~HTTP~data自体を精査して，~messageは完全であるかどうか決定することが必要yである。 不完全な~messageの取扱いは、 `8§ にて定義される。 ◎ An incomplete close does not call into question the security of the data already received, but it could indicate that subsequent data might have been truncated. As TLS is not directly aware of HTTP message framing, it is necessary to examine the HTTP data itself to determine whether messages are complete. Handling of incomplete messages is defined in Section 8.

不完全な~closeに遭遇した`~client$は、 次のいずれかに該当するときは，すべての要請は完了したものと扱うベキである： ◎ When encountering an incomplete close, a client SHOULD treat as completed all requests for which it has received either

• `Content-Length$h ~headerに指定された分の~dataを受信した ◎ as much data as specified in the Content-Length header field or
• `~chunked転送~符号法$【！Transfer-Encoding of chunked】が利用されていて，それを終了させる長さ 0 の~chunkを受信した ◎ the terminal zero-length chunk (when Transfer-Encoding of chunked is used).

`~chunked転送~符号法$も `Content-Length$h も伴わない応答が`完全$になるのは、 妥当な~closure~alertを受信した場合に限られる。 不完全な~messageを完全なものとして扱う実装は、攻撃に晒され得る。 ◎ A response that has neither chunked transfer coding nor Content-Length is complete only if a valid closure alert has been received. Treating an incomplete message as complete could expose implementations to attack.

不完全な~closeを検出した`~client$は、 それを上品に回復するベキである。 ◎ A client detecting an incomplete close SHOULD recover gracefully.

`~client$は、 接続を~closeする前に，~closure~alertを送信しなければナラナイ。 ~clientは、 それ以上の~dataを受信するものと期待しないならば，［ `~server$の~closure~alertを待機することなく，単純に接続を~closeする ］ことを選んでもヨイ — それは、 ~server側にとって不完全な~closeを生成することになる。 ◎ Clients MUST send a closure alert before closing the connection. Clients that do not expect to receive any more data MAY choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on the server side.

`~server$は、 `~client$から不完全な~closeを受信することに備えておくベキである — ~clientは、 ~serverからの~dataが どこで終端するか突き止めれることが多いので。 ◎ Servers SHOULD be prepared to receive an incomplete close from the client, since the client can often locate the end of server data.

`~server$は、 接続を~closeする前に， `~client$との~closure~alertの交換を起動しようと試みなければナラナイ。 ~closure~alertを送信した~serverは、 接続を~closeしてもヨイ — それは、 ~client側にとって不完全な~closeを生成することになる。 ◎ Servers MUST attempt to initiate an exchange of closure alerts with the client before closing the connection. Servers MAY close the connection after sending the closure alert, thus generating an incomplete close on the client side.

10.1. ~MIME型 `message/http^c

`~MIME型$ "`message/http^c" は、 単独の~HTTP［ 要請／応答 ］~messageを同封するために利用できる — それが、 すべての "message" 型に対し，~MIMEによる［ 行lの長さと符号化法に関する制約 ］を順守する限りにおいて。 "`message/http^c" の中の`~field値$には行lの長さに制限があるので、 `~field値$を複数~行lに連ねて伝達するためとして — `5.2§ にて述べたとおり — 行l折返し（ `obs-fold$p ）の利用も許容される。 "`message/http^c" ~dataの`受信者$は、 当の~messageを消費するときには，［ そのような廃用にされた各 行l折返し ］を 1 個以上の `SP$P で置換しなければナラナイ。 ◎ The "message/http" media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. Because of the line length limitations, field values within "message/http" are allowed to use line folding (obs-fold), as described in Section 5.2, to convey the field value over multiple lines. A recipient of "message/http" data MUST replace any obsolete line folding with one or more SP characters when the message is consumed.

10.2. ~MIME型 `application/http^c

`~MIME型$ "`application/http^c" は、 ~pipeline化された 1 個~以上の~HTTP［ 要請~messageのみ／応答~messageのみ ］を同封するときに利用できる。 ◎ The "application/http" media type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).

11.1. 応答~分割

`応答~分割^dfn （ `response splitting^en ） （いわゆる `CRLF$P 注入）は、 ~Web利用eに対する様々な攻撃にて共通的に利用される技法であり，［ ~HTTP~message~frame法の，行lに基づく資質 ］と［ `持続的な接続$における，要請から応答への順序~付けられた結付け ］を悪用する `Klein$r 。 この技法は，特に、 要請が`共用~cache$を通して渡されるとき，被害を大きくし得る。 ◎ Response splitting (a.k.a. CRLF injection) is a common technique, used in various attacks on Web usage, that exploits the line-based nature of HTTP message framing and the ordered association of requests to responses on persistent connections [Klein]. This technique can be particularly damaging when the requests pass through a shared cache.

応答~分割は、［ 要請の何らかの~parameter — 後に，復号され, 応答の何らかの~headerの中に 復唱されるような~parameter — の中に，攻撃者が符号化-済み~dataを送信できる ］ような，`~server$における脆弱性（通例的に応用~serverの中）を悪用する。 ~dataが，［ それを復号した結果が，応答が終端され, 後続な応答が始まる ］ように見せかけて細工されていた場合、 応答は分割され，［ 2 番目であるように見せかけた応答 ］の内容が攻撃者により制御される。 しかる後，攻撃者は、［ 同じ`持続的な接続$ 上に，他の何らかの要請を為して ］，`受信者$（`中継者$も含む）に［ 分割-の~~後半部分が， 2 番目の要請に対する`権限的$な回答である ］と信じ込ませることも可能になる。 ◎ Response splitting exploits a vulnerability in servers (usually within an application server) where an attacker can send encoded data within some parameter of the request that is later decoded and echoed within any of the response header fields of the response. If the decoded data is crafted to look like the response has ended and a subsequent response has begun, the response has been split, and the content within the apparent second response is controlled by the attacker. The attacker can then make any other request on the same persistent connection and trick the recipients (including intermediaries) into believing that the second half of the split is an authoritative answer to the second request.

例えば， `request-target$p の中の~parameterは、［ 応用~serverにより読取られ, ~redirectの中で再利用される ］結果，応答の `Location$h ~header内に同じ~parameterが復唱され得る。 応用により復号された~parameterが［ 応答~header内に置かれるとき，適正に符号化されない ］場合、 攻撃者は，［ 符号化-済みな `CRLF$P ~octetその他の内容 ］を送信して，応用による 1 個の応答を 2 個~以上の応答に見せかけられるようになる。 ◎ For example, a parameter within the request-target might be read by an application server and reused within a redirect, resulting in the same parameter being echoed in the Location header field of the response. If the parameter is decoded by the application and not properly encoded when placed in the response field, the attacker can send encoded CRLF octets and other content that will make the application's single response look like two or more responses.

応答~分割に抗する共通的な防御策は、 要請の中の［ 符号化-済みな `CR$P `LF$P 並びに見せかけた~data ］を~filterするものであるが、 それは［ 応用~serverが~URIの復号しか遂行していない ］ことを前提にしており，より見え難い~data形式変換 — ~charset符号変換, ~XML実体~翻訳, base64 復号, sprintf 再整形, 等々 — は~~考慮されていない。 それより，［ ~serverの中核~protocol~library ］以外のどこであれ［ `~header節$の中に `CR$P や `LF$P を送信する ］のを防止する方が、 効果的な軽減策になる — それは、 ~headerの出力を［ 不良~octetを~filterする~API ］に制約して，［ 応用~serverが~protocol~streamへ直に書込む ］ことを許容しないことを意味する。 ◎ A common defense against response splitting is to filter requests for data that looks like encoded CR and LF (e.g., "%0D" and "%0A"). However, that assumes the application server is only performing URI decoding rather than more obscure data transformations like charset transcoding, XML entity translation, base64 decoding, sprintf reformatting, etc. A more effective mitigation is to prevent anything other than the server's core protocol libraries from sending a CR or LF within the header section, which means restricting the output of header fields to APIs that filter for bad octets and not allowing application servers to write directly to the protocol stream.

11.2. 要請~密入

`要請~密入^dfn （ `request smuggling^en ） `Linhart$r は、［ 様々な受信者~間での，~protocol構文解析-法における相違点 ］を悪用して，［ 無害に見せかけた要請 ］の中に［ （さもなければ施策により阻止されるか不能化されるような）追加的な要請 ］を隠す技法である。 `応答~分割$と同様に、 要請~密入は，~HTTP利用eにおいて種々の攻撃を導き得る。 ◎ Request smuggling ([Linhart]) is a technique that exploits differences in protocol parsing among various recipients to hide additional requests (which might otherwise be blocked or disabled by policy) within an apparently harmless request. Like response splitting, request smuggling can lead to a variety of attacks on HTTP usage.

この仕様は、 要請~密入の実効性を抑制するため， `~message本体の長さ§にて — 特に，~message~frame法に関して — 要請の構文解析に課される新たな要件を導入した。 ◎ This specification has introduced new requirements on request parsing, particularly with regard to message framing in Section 6.3, to reduce the effectiveness of request smuggling.

11.3. ~messageの完全性

~HTTPは、［ ~messageの完全性を確保するための，特定の仕組み ］は定義しない。 代わりに，［ 下層~transport~protocolの~error検出~能 ］および［ 完全かどうかを検出するための［ 長さ／~chunkで区切られる~frame法 ］の利用 ］に依拠する。 歴史的に、［ 単一な，完全性の仕組み ］の欠如は，［ ほとんどの~HTTP通信が正式でない性向にあること ］を根拠に正当化されていた。 しかしながら、［ 情報~accessの仕組みとしての~HTTP ］が普及した結果，［ ~message完全性の検証yが不可欠な環境 ］下での利用は増えている。 ◎ HTTP does not define a specific mechanism for ensuring message integrity, instead relying on the error-detection ability of underlying transport protocols and the use of length or chunk-delimited framing to detect completeness. Historically, the lack of a single integrity mechanism has been justified by the informal nature of most HTTP communication. However, the prevalence of HTTP as an information access mechanism has resulted in its increasing use within environments where verification of message integrity is crucial.

"`https$c" ~schemeで供される仕組みは、 認証された暗号化など，~messageの改変に抗する保護を供する。 しかしながら，［ 接続の~closureが利用されても，~messageは切落され得ない ］ことを確保するよう~careする必要がある（ `9.8§ を見よ）。 `~UA$は、 不完全な~messageに対し，［ 受容するのを拒否する／特別に扱う ］かもしれない。 例えば，［ 医療~履歴や薬剤相互作用についての情報 ］を視るために利用されている~browserは、［ そのような情報が転送の間に［ 不完全である／失効した／破損した ］ことが~protocolにより検出された ］ことを，利用者に指示できることが必要yである。 そのような仕組みは、［ ~UA拡張や, 応答~内に~message完全性~metadataが在ること ］を介して，選択的に可能化できるであろう。 ◎ The mechanisms provided with the "https" scheme, such as authenticated encryption, provide protection against modification of messages. Care is needed, however, to ensure that connection closure cannot be used to truncate messages (see Section 9.8). User agents might refuse to accept incomplete messages or treat them specially. For example, a browser being used to view medical history or drug interaction information needs to indicate to the user when such information is detected by the protocol to be incomplete, expired, or corrupted during transfer. Such mechanisms might be selectively enabled via user agent extensions or the presence of message integrity metadata in a response.

"`http$c" ~schemeは、 ~messageに対する［ 偶発的／悪意的 ］な改変に抗する保護は，供さない。 ◎ The "http" scheme provides no protection against accidental or malicious modification of messages.

"`https$c" ~schemeが利用されているときでも、［ 中継者による，~messageに対する求まれない改変 ］の~riskを軽減するために，~protocolに対する拡張が利用されるかもしれない。 完全性は、 拡張-可能な~metadata~fieldを介して~messageに選択的に追加された［ ~message認証~code／~digital署名 ］を利用して確約されることもあろう。 ◎ Extensions to the protocol might be used to mitigate the risk of unwanted modification of messages by intermediaries, even when the "https" scheme is used. Integrity might be assured by using message authentication codes or digital signatures that are selectively added to messages via extensible metadata fields.

11.4. ~messageの機密性

~HTTPは、［ ~messageの機密性が欲されるときに，それを供する ］にあたり，下層の~transport~protocolに依拠する。 ~HTTPは、［ 多くの形をとる，暗号化された接続 ］にも利用し得るように，［ ~transport~protocolに依存しない ］ように特定的に設計されてきた。 そのような~transportの選定は、［ 選ばれた~URI~schemeや, ~UA環境設定 ］により識別されている。 ◎ HTTP relies on underlying transport protocols to provide message confidentiality when that is desired. HTTP has been specifically designed to be independent of the transport protocol, such that it can be used over many forms of encrypted connection, with the selection of such transports being identified by the choice of URI scheme or within user agent configuration.

機密的~接続を要求する`資源$を識別するためには、 "`https$c" ~schemeを利用できる。 ◎ The "https" scheme can be used to identify resources that require a confidential connection, as described in Section 4.2.2 of [HTTP].

12.1. ~field名の登録

~IANAは、 次の表tに挙げる~field名を — `HTTP$r `18.4＠~HTTPinfra#field.name.registration§に従って — `~HTTP~field名~registry＠~IANA-a/http-fields$cite （ `Hypertext Transfer Protocol (HTTP) Field Name Registry^en ） に追加した： ◎ IANA has added the following field names to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields>, as described in Section 18.4 of [HTTP].

12.2. ~MIME型の登録

~IANAは、 `~MIME型~registry＠~IANA-a/media-types$cite （ `Media Types registry^en ） を［ `~MIME型$［ `message/http$c, `message/http$c ］用の登録~情報 ］を伴うよう更新した。 ◎ IANA has updated the "Media Types" registry at <https://www.iana.org/assignments/media-types> with the registration information in Sections 10.1 and 10.2 for the media types "message/http" and "application/http", respectively.

12.3. 転送~符号法の登録

~IANAは、 `~HTTP転送~符号法~registry$cite （ `HTTP Transfer Coding Registry^en ） を更新した — `7.3§ の登録~手続-に従って， 次の表tに要約される【！内容~符号法】`転送~符号法の名前$を伴うよう： ◎ IANA has updated the "HTTP Transfer Coding Registry" at <https://www.iana.org/assignments/http-parameters/> with the registration procedure of Section 7.3 and the content coding names summarized in the table below.

注記： 符号法の名前 "`trailers^c" は、 予約される — その利用は、 `TE$h ~headerにおける ~keyword "`trailers$c" と競合することになるので。 ◎ Note: the coding name "trailers" is reserved because its use would conflict with the keyword "trailers" in the TE header field (Section 10.1.4 of [HTTP]).

12.4. ~ALPN~protocol~IDの登録

~IANAは、 `~ALPN~protocol~ID~registry＠~IANA-a/tls-extensiontype-values/$cite （ `TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs^en ） を更新した — 次の登録を伴うよう： ◎ IANA has updated the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry at <https://www.iana.org/assignments/tls-extensiontype-values/> with the registration below:

B.1. `MIME-Version^h

~HTTPは、 ~MIME準拠な~protocolではない。 しかしながら，~messageを構築するときに［ 単独の `MIME-Version^h ~header ］を内包することで、［ ~MIME~protocolの どの~versionが利用されたか ］を指示できる。 `MIME-Version^h ~headerの利用は、［ ~messageが（ `RFC2045$r にて定義されるとおり）~MIME~protocolに全部的に適合している ］ことを指示する。 `送信者$は、［ ~HTTP~messageを厳密な~MIME環境に~exportする ］ときには（アリな所では）全部的な適合性を確保する責を負う。 ◎ HTTP is not a MIME-compliant protocol. However, messages can include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message. Use of the MIME-Version header field indicates that the message is in full conformance with the MIME protocol (as defined in [RFC2045]). Senders are responsible for ensuring full conformance (where possible) when exporting HTTP messages to strict MIME environments.

B.2. 正準-形への変換

~MIMEは、 `2049/4$rfc にて述べられるとおり，転送に先立って，［ ~Internet~mail本体 部分 ］を正準-形に変換するよう要求する。 `RFC2046$r は， "`text^c" 型の内容においては、 改行を `CRLF$P として表現することも要求し，他所における［ `CR$P ／ `LF$P ］の利用を禁止する。 対照的に，~HTTPは、 `内容$の中の改行が［ `CRLF$P, `CR$P, `LF$P ］のどれを利用して指示されようが，~careしない。 ◎ MIME requires that an Internet mail body part be converted to canonical form prior to being transferred, as described in Section 4 of [RFC2049], and that content with a type of "text" represents line breaks as CRLF, forbidding the use of CR or LF outside of line break sequences [RFC2046]. In contrast, HTTP does not care whether CRLF, bare CR, or bare LF are used to indicate a line break within content.

~HTTPから厳密な~MIME環境への［ `~proxy$／`~gateway$ ］は、［ ~text`~MIME型$の中のすべての改行 ］を［ `RFC2049$r による正準-形 `CRLF$P ］に転化する~OUGHT。 しかしながら，これは、［ `Content-Encoding$h が在ること ］, および［ ~HTTPが［［ `CR$P ／ `LF$P ］を表現する~octet［ 13 ／ 10 ］を利用しない，一部の`~charset$ ］の利用を許容する事実 ］により，複雑化することもあることに注意。 ◎ A proxy or gateway from HTTP to a strict MIME environment ought to translate all line breaks within text media types to the RFC 2049 canonical form of CRLF. Note, however, this might be complicated by the presence of a Content-Encoding and by the fact that HTTP allows the use of some charsets that do not use octets 13 and 10 to represent CR and LF, respectively.

変換は、［ 内容が~~元々正準-形である場合 ］を除き，［ 元の内容に適用された暗号用の~checksum ］を［ それが何であれ非互換化する ］ことになる。 したがって、［ ~HTTPにおいて，そのような~checksumを利用する内容 ］には，正準-形が推奨される。 ◎ Conversion will break any cryptographic checksums applied to the original content unless the original content is already in canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP.

B.3. 日時~形式の変換

`~HTTP11$は、 日時の比較~処理nを単純~化するために， 制約された日時~形式たちが成す集合（ `HTTP$r `日付時刻の形式＠~HTTPinfra#http.date§）を利用する。 他の~protocolからの［ `~proxy$／`~gateway$ ］は、［ ~message内に在るどの `Date$h ~headerも，いずれかの~HTTP11形式に適合する ］ことを — 必要yなら，日時を書換えて — 確保する~OUGHT。 ◎ HTTP/1.1 uses a restricted set of date formats (Section 5.6.7 of [HTTP]) to simplify the process of date comparison. Proxies and gateways from other protocols ought to ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.

B.4. `Content-Encoding^h の変換

~MIMEは、 ~HTTPの `Content-Encoding$h ~headerに等価な概念を含まない。 これは，`~MIME型$の改変子として動作するので、 ~HTTPから~MIME準拠な~protocolへの［ `~proxy$／`~gateway$ ］は，~messageを回送する前に［ `Content-Type$h ~headerの値を変更する ］か［ `表現$を復号する ］~OUGHT。 （~Internet~mail用の `Content-Type$h の試験的な応用には、 `Content-Encoding$h と等価な機能を遂行するために， `media-type$p ~parameterに "`;conversions=<content-coding>^c" を利用しているものもある。 しかしながら，この~parameterは、 ~MIME標準の一部ではない）。 ◎ MIME does not include any concept equivalent to HTTP's Content-Encoding header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols ought to either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards.)

B.5. `Content-Transfer-Encoding^h の変換

~HTTPは、［ ~MIMEの `Content-Transfer-Encoding$h ~field ］を利用しない。 ~MIME準拠な~protocolから~HTTPへの［ `~proxy$／`~gateway$ ］は、 応答~messageを~HTTP~clientへ送達するに先立って， すべての `Content-Transfer-Encoding^h を除去する必要がある。 ◎ HTTP does not use the Content-Transfer-Encoding field of MIME. Proxies and gateways from MIME-compliant protocols to HTTP need to remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.

~HTTPから~MIME準拠な~protocolへの［ `~proxy$／`~gateway$ ］は、 ~messageが［ 当の~protocol上で安全に~transportされる，正しい［ 形式, 符号化法 ］である ］ことを確保する責を負う — ここでの “安全な~transport” は、 利用される~protocolによる制限により定義される。 そのような［ ~proxy／~gateway ］は、 当の~dataを［ 形式変換して，適切な `Content-Transfer-Encoding$h で~labelする ］~OUGHT — そうすることで［ 行先~protocol越しの~transportが安全になる見込み ］が改善される場合には。 ◎ Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol being used. Such a proxy or gateway ought to transform and label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol.

B.6. ~MHTMLと行l長さ制限

~MHTML `RFC2557$r 実装と~codeを共有する~HTTP実装は、 ~MIMEにおける行l長さ制限を自覚しておく必要がある。 この制限は~HTTPには無いので、 ~HTTPは長い行lを折返さない。 ［ ~HTTPにより~transportされている~MHTML~message ］は、 行lの［ 長さ制限, 折返し, 正準-化, 等々 ］を含め，~MHTMLのすべての規約に従う — ~HTTPは、 `~message本体$を改変を伴わずに転送し， "`multipart/byteranges$c" 型は別として，そこに包含され得るどの［ 内容／~MIME~header行l ］も解釈しないので。 ◎ HTTP implementations that share code with MHTML [RFC2557] implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations and folding, canonicalization, etc., since HTTP transfers message-bodies without modification and, aside from the "multipart/byteranges" type (Section 14.6 of [HTTP]), does not interpret the content or any MIME header lines that might be contained therein.

C.1. ~HTTP09からの変更点

~HTTP09は，要請~内の~headerを~supportしなかったので、［ 名前に基づく仮想~host（ `Host$h ~headerの検分による`資源$の選定） ］を~supportするための仕組みも無かった。 ［ 名前に基づく仮想~host ］を実装する どの`~server$も，~HTTP09の~supportを不能化する~OUGHT。 事実，~HTTP09として出現するほとんどの要請は、 `request-target$p を適正に符号化できない~clientにより， 不良に構築された HTTP/1.x 要請である。 ◎ Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts (selection of resource by inspection of the Host header field). Any server that implements name-based virtual hosts ought to disable support for HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, badly constructed HTTP/1.x requests caused by a client failing to properly encode the request-target.

C.2. ~HTTP10からの変更点

C.3. RFC 7230 からの変更点

~HTTPの［ 設計~目標／ 歴史／ ~architecture／ 適合性~判定基準／ ~protocol~version法／ ~URI／ ~message~route法／ `~field値$ ］を導入している ほとんどの節は、 `HTTP$r に移動された。 この文書は、 ~HTTP11に特有な［ ~message法の構文, 接続~管理 ］用の要件に抑制された。 ◎ Most of the sections introducing HTTP's design goals, history, architecture, conformance criteria, protocol versioning, URIs, message routing, and header fields have been moved to [HTTP]. This document has been reduced to just the messaging syntax and connection management requirements specific to HTTP/1.1.

`内容$の外側における［ `CRLF$P の一部を成さない `CR$P ］を禁制した。 （`~messageの構文解析-法§） ◎ Bare CRs have been prohibited outside of content. (Section 2.2)

`authority-form$p の~ABNF定義を［ ~URIを成す より一般的な（ `port$p を省略可能な） `authority$p 成分 ］から［ `CONNECT$m により要求される，より特定な `host:port^c 形式 ］に変更した。 （ `3.2.3§ ） ◎ The ABNF definition of authority-form has changed from the more general authority component of a URI (in which port is optional) to the specific host:port format that is required by CONNECT. (Section 3.2.3)

多義的な~message~frame法を処理するときは、［ `応答~分割$／`要請~密入$ ］攻撃を避けることを`受信者$に要求した。 （ `Transfer-Encoding§h ） ◎ Recipients are required to avoid smuggling/splitting attacks when processing an ambiguous message framing. (Section 6.1)

`~chunk拡張$用の~ABNFにおいて、［ "`;^c" ／ "`=^c" ］の前後における（不良）`空白$を導入し直した。 その空白は `RFC7230$r において除去されたが、 その変更は既存の実装を非互換化することが見出されたので。 （`~chunk拡張§） ◎ In the ABNF for chunked extensions, (bad) whitespace around ";" and "=" has been reintroduced. Whitespace was removed in [RFC7230], but that change was found to break existing implementations. (Section 7.1.1)

`~trailer$の意味論は、 今や，`~chunked転送~符号法$に特有なそれを超越する。 ~chunked用の復号~algo（ `7.1.3§ ）は、 `~trailer$を`~header節$とは別々に［ 格納する／回送する ］ことを奨励するため，更新された — `~trailer$を`~header節$の中へ併合するのが許容されるのは、［ 対応する~header定義において，併合する方法が定義されていて, そうすることが許可されている ］ことを受信者が知っている場合に限られ、 他の場合は併合することなく破棄するように。 `trailer part^en は、 今や `trailer section^en（ `~trailer節$ ）と呼ばれる — より `header section^en（ `~header節$ ）と一貫するよう, かつ `body part^en とは別個になるよう。 （ `7.1.2§ ） ◎ Trailer field semantics now transcend the specifics of chunked transfer coding. The decoding algorithm for chunked (Section 7.1.3) has been updated to encourage storage/forwarding of trailer fields separately from the header section, to only allow merging into the header section if the recipient knows the corresponding field definition permits and defines how to merge, and otherwise to discard the trailer fields instead of merging. The trailer part is now called the trailer section to be more consistent with the header section and more distinct from a body part. (Section 7.1.2)

"`q^c" と呼ばれる転送~符号法~parameterは、 許容しないようにした — `TE$h ~headerにおける `weight$p 【 `RFC7230$r においては `rank^p 】の利用と競合するのを避けるため。 （ `7.3§ ） ◎ Transfer coding parameters called "q" are disallowed in order to avoid conflicts with the use of ranks in the TE header field. (Section 7.3)