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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

適合性の判定基準, および ~errorの取扱いに関する考慮点は、 `2.5$sec にて定義される。 ◎ Conformance criteria and considerations regarding error handling are defined in Section 2.5.

1.2. 構文の表記法

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

`総集的~ABNF＠~723Xabnf#abnf-7230$ にて、他の文書から取込まれた規則, および すべての`~list演算子$を標準な~ABNF表記法に展開した，総集的な文法を示す。 ◎ This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix B shows the collected grammar with all list operators expanded to standard ABNF notation. ◎ 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). ◎ As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.

2.1. ~client／~serverによる~messaging

~HTTPは、［ `~target資源$と, 資源~間の関係性 ］を指示するために， URI 標準 `3986$R に依拠する。 ~messageは、［［ Internet mail `5322$R ／ MIME `2045$R ］に利用されるものに類似な形式 ］で渡される（HTTP と~MIME~messageとの間の相違点については、 `7231$R `付録 A＠~7231#appendix-A$ を見よ）。 ◎ HTTP relies upon the Uniform Resource Identifier (URI) standard [RFC3986] to indicate the target resource (Section 5.1) and relationships between resources. Messages are passed in a format similar to that used by Internet mail [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [RFC7231] for the differences between HTTP and MIME messages).

ほとんどの~HTTP通信は、［ `~URI$により識別される何らかの`資源$ ］の`表現$に対する，検索取得 要請（ `GET$m ）からなる。 最も単純な事例では、これは，［ `~UA$（ `UA^var ）と`生成元~server$（ `O^var ）との間の，単独の双方向-接続（ `===^c ） ］を介して成遂げられるであろう： ◎ Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and the origin server (O).

       要請   >
  `UA^var ======================================= `O^var
                              <   応答

`6.3$sec にて定義されるように、同じ接続が，複数の［ 要請／応答 ］の交換に利用されることもある。 ◎ A connection might be used for multiple request/response exchanges, as defined in Section 6.3.

GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Hello World! My payload includes a trailing CRLF.

2.2. 実装の多様性

~HTTPの設計を考慮するとき、［ すべての`~UA$は 一般用~browserで, すべての`生成元~server$は 巨大な公共~web~siteである ］ような考えに陥り易いが、実施においては，あてはまらない。 ~HTTP`~UA$には、次のものも普通に見られる：［ 家電, 視聴覚機器, 計測機器, ~firmware更新~script, ~command-line~program, 携帯~app, ~sizeや形状が様々な通信~機器 ］, 等々。 同様に、~HTTP `生成元~server$には，次のものも普通に見られる：［ 住宅用自動化設備, 環境設定-可能な~network用~component, 事務機械, 自律型robot, ニュースフィード, 交通camera, ad selector 【“広告セレクタ”】, 動画配信~platform ］, 等々。 ◎ When considering the design of HTTP, it is easy to fall into a trap of thinking that all user agents are general-purpose browsers and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household appliances, stereos, scales, firmware update scripts, command-line programs, mobile apps, and communication devices in a multitude of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking components, office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video-delivery platforms.

用語 “`~UA$” は、要請の時点に［ ~software~agentと直にヤリトリしているヒト利用者が居る ］ことを含意するわけではない。 多くの事例で、`~UA$は~backgroundにて稼働するように ~installされ, あるいは環境設定されていて，その結果を（あるいは，その中の関心がある／誤りがありそうな部分のみを）今後の検分~用に保存する。 例えば，~spiderは、概して，所与の~URIから開始して，~Webを~hypertext~graphとして巡る間、一定の挙動に従うように環境設定される。 ◎ The term "user agent" does not imply that there is a human user directly interacting with the software agent at the time of a request. In many cases, a user agent is installed or configured to run in the background and save its results for later inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph.

~HTTP実装の多様性は、すべての`~UA$が［ 利用者に向けて対話的に何かを示唆したり, ~securityや~privacyに関する懸念のために必要十分な警告を供せる ］わけではないことを意味する。 この仕様が［ 利用者~向けに~errorを報告する ］ことを要求する，少数の事例では、そのような報告が［ ~error~consoleや~log~fileにのみ観測-可能である ］ことも受容-可能である。 同様に，自動化された動作についても、［ 続行する前に利用者による確認を要する ］ような要件は，［ ~~事前の環境設定の選択, 稼働時~option, 安全でない動作に対する単純な回避法 ］などを介して~~満たされ得る — 確認は、利用者がすでにその選択を済ませていた場合には，いかなる［ 特定の利用者~interfaceや, 通常~処理の中断 ］も含意しない。 ◎ The implementation diversity of HTTP means that not all user agents can make interactive suggestions to their user or provide adequate warning for security or privacy concerns. In the few cases where this specification requires reporting of errors to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise, requirements that an automated action be confirmed by the user before proceeding might be met via advance configuration choices, run-time options, or simple avoidance of the unsafe action; confirmation does not imply any specific user interface or interruption of normal processing if the user has already made that choice.

2.3. 中継者

~HTTPは、要請が接続の `連鎖@ を通り抜けられるようにするため， `中継者@ の利用も可能化する。 ~HTTP中継者は、 3 種の共通な形［ `~proxy$, `~gateway$, `~tunnel$ ］がある。 一部の事例では、単独の中継者が，各~要請の資質に基づいて 自身の挙動を［ `生成元~server$, `~proxy$, `~gateway$, `~tunnel$ ］のいずれかに切替えながら，動作することもある。 ◎ HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of HTTP intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.

       >             >             >             >
  `UA^var =========== `A^var =========== `B^var =========== `C^var =========== `O^var
             <             <             <             <

用語 `上流@ ／ `下流@ は、［ ~messageが流れる方向 ］に関係して，要件を述べるときに用いられる： すべての~messageは上流から下流へ流れる。 用語 `内方@ ／ `外方@ は、［ 要請が経路制御される方向 ］に関係して，要件を述べるときに用いられる： “内方” は`生成元~server$へ向かうことを意味し， “外方” は`~UA$へ向かうことを意味する。 ◎ The terms "upstream" and "downstream" are used to describe directional requirements in relation to the message flow: all messages flow from upstream to downstream. The terms "inbound" and "outbound" are used to describe directional requirements in relation to the request route: "inbound" means toward the origin server and "outbound" means toward the user agent.

`~proxy@ は、［ 何らかの型の絶対~URIへ向けた要請を受信したときには、［ ~HTTP~interfaceを通した翻訳 ］を介して，その要請を充足しようと試みる ］ような，~message回送~agentであり、通例的に，`~client$の局所的な環境設定~規則を介して，~clientにより選定される。 翻訳には、［ "`http$c" ~URIへ向けた~proxy要請のような必要最小限なもの ］もある一方，［ 全面的に異なる~app~levelの~protocolへの／からの翻訳を要する要請 ］もあり得る。 `~proxy$は、［ ~security, ~annotation~service†, 共用~caching ］の~~目的で，［ 組織~内の~HTTP要請を，共通な`中継者$を通して~group分けする ］ために利用されることが多い。 一部の`~proxy$は、~messageを回送する際に，［ 選定された ~message／`~payload$ に`形式変換$を適用する ］ように設計されている。 ◎ A "proxy" is a message-forwarding agent that is selected by the client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary for the sake of security, annotation services, or shared caching. Some proxies are designed to apply transformations to selected messages or payloads while they are being forwarded, as described in Section 5.7.2.

【† 元の~dataに追加的な情報 — “~~注釈（ annotation ）” — を付加するような~serviceを意味するとみられる（例えば，用語に~linkを補完するなど）。 】

`生成元~server$に適用-可能な，すべての~HTTP要件は、`~gateway$の`外方$への通信にも適用される。 `~gateway$は、自身が欲する任意の~protocol — この仕様の対象外である，~HTTPに対する私的~拡張も含む — を利用して`内方$`~server$と通信する。 しかしながら、第三者-主体の~HTTP~serverと相互運用したいと望む HTTP-to-HTTP `~gateway$は、［ ~gatewayの`内方$への接続 ］に課される`~UA$要件にも適合する~OUGHT。 ◎ All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers ought to conform to user agent requirements on the gateway's inbound connection.

`~tunnel@ は、~messageを変更することなく， 2 つの接続の間を盲目的に中継するように動作する。 いったん作動中になった~tunnelは、それが~HTTP要請により起動されたとしても，~HTTP通信の主体とは見なされない。 ~tunnelが存在し得るのは、［ 中継された接続の両~端 ］が~closeされるまでである。 ~tunnelは、［ 共用~firewall~proxyを通した機密的~通信 ］を確立するために， TLS（ Transport Layer Security, `5246$R）が利用されるときなど、［ `中継者$を通した仮想~接続 ］を拡張するために利用される。 ◎ A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as when Transport Layer Security (TLS, [RFC5246]) is used to establish confidential communication through a shared firewall proxy.

上の`中継者$の類別は、［ ~HTTP通信における参加者 ］として動作しているもののみが考慮される。 中継者には、［ ~network~protocol~stackの より低~層 ］で動作して，［ ~message送信者についての知識や許可 ］なしに［ ~HTTP流通を~filterしたり~redirectする ］ものもある。 ~network中継者は，（~protocol~levelでは）中間者~攻撃かどうか判別できないので、［ ~HTTP意味論を誤解して違反することに因る，~securityの欠陥や相互運用能の問題 ］が導入されることも多い。 ◎ The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the knowledge or permission of message senders. Network intermediaries are indistinguishable (at a protocol level) from a man-in-the-middle attack, often introducing security flaws or interoperability problems due to mistakenly violating HTTP semantics.

例えば， “~interception~proxy” `3040$R （ “透過的~proxy” `1919$R や “~captive~portal” としても周知）は、~clientにより選定されるものではない点で，~HTTP`~proxy$とは相違する。 代わりに，~interception~proxyは、［ 外向けの~TCP~port 80 ~packet ］を（ときには他の共通的な~port上の流通も），~filterしたり~redirectする。 ~interception~proxyは、［［ 公共~network~access~pointにて，局所的でない~Internet~serviceの利用を許容する ］に先立って，~account~subscriptionを施行する手段 ］として, あるいは［ ~network利用e施策を施行する企業~firewall ］の中で，共通的に見出される。 ◎ For example, an "interception proxy" [RFC3040] (also commonly known as a "transparent proxy" [RFC1919] or "captive portal") differs from an HTTP proxy because it is not selected by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies.

~HTTPは、 `~stateless@ な~protocolとして定義されている — すなわち、各~要請~messageは，互いに隔離されても解せることを意味する。 多くの実装は、［ ~proxyされた接続を再利用したり， 複数の~serverにまたがって要請を動的に負荷分散する ］ときに，［ ~HTTPの~statelessな設計 ］に依存する。 よって，`~server$は、［ 同じ接続~上の 2 つの要請 ］を，同じ`~UA$からのものと見做してはナラナイ — その接続が［ ~secure化されていて，その~UAに特有である ］のでない限り。 一部の非~標準~HTTP拡張（例： `4559$R）は、この要件に違反していることが既知であり、~securityの および相互運用能の問題を起こす。 ◎ HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers. Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent. Some non-standard HTTP extensions (e.g., [RFC4559]) have been known to violate this requirement, resulting in security and interoperability problems.

2.4. ~cache

`~cache@ とは、［ 以前に受け取った応答~messageの局所的な格納域 ］であり，それらの~messageの［ ~storage, 検索取得, 削除 ］を制御する下位~systemである。 `~cache$は、`~cache可能$な応答を，［ 未来の, 等価な要請 ］に要する［ 応答~時間や, ~network帯域幅 消費量 ］を抑制するために格納する。 どの［ `~client$／`~server$ ］も，`~cache$を使役してヨイ — `~tunnel$として動作している~serverは，~cacheを利用し得ないが。 ◎ A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server MAY employ a cache, though a cache cannot be used by a server while it is acting as a tunnel.

`~cache$による効果は、［ 要請／応答 ］の連鎖が — ［ `連鎖$沿いにある いずれかの参加者 ］が［ その要請に適用-可能な ~cache済み応答 ］を持つときには — 短縮されることである。 次の図に、ある要請に対し， `B^var が~cache済み複製を持っている — それは［ ~~以前に 【ある~UAによる，その要請と等価な要請に対し】 `O^var から（ `C^var を介して）受信した応答 ］の複製であり，［ `UA^var や `A^var には まだ~cacheされていない ］とする — ときの結果を示す： ◎ The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from O (via C) for a request that has not been cached by UA or A.

          >             >
     `UA^var =========== `A^var =========== `B^var - - - - - - `C^var - - - - - - `O^var
                <             <

応答~messageは、［ 後続な要請に対する回答に利用するためとして，複製を`~cache$に格納することが許容される ］とき， `~cache可能@ であるという。 応答が~cache可能であるとしても、［ 特定0の要請に対し，~cache済み応答が いつ利用できるか ］について，［ `~client$や`生成元~server$により，追加的な拘束が設置される ］こともある。 ［ `~cache$の挙動, および ~cache可能な応答 ］に課される~HTTP要件は、 `7234-2$rfc にて定義される。 ◎ A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in Section 2 of [RFC7234].

World Wide Webや, 巨大な組織の内側にまたがって配備されている`~cache$には、多種多様な~architectureや環境設定がある。 これらには、次のものも含まれる：［ 大陸間~帯域幅を節約するための，~proxy~cacheの国別~階層 ］, ［ ~cache~entryを~broadcastしたり~multicastする，協調的な~system ］, ［ ~off-line／高遅延 環境の下で利用するために， 事前fetchされた~cache~entryの~archive ］, 等々。 ◎ There is a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large organizations. These include national hierarchies of proxy caches to save transoceanic bandwidth, collaborative systems that broadcast or multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments, and so on.

2.5. 適合性, および~errorの取扱い

また，［ 単独の通信の視野を超えて適用される ］ときには、追加的な（~social）要件が，［ 実装／資源~所有者／~protocol要素~登録 ］に設置されることもある。 ◎ Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication.

要件の中で，［ ~protocol要素を作成すること ］を，［ 受信された要素を 単に`下流$へ回送すること ］から相違化して記す所では、前者に対し，動詞 “`生成する@” が， “送信する” に代わって利用される。 ◎ The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream.

実装は、［ ~HTTPにおいて自身が受け持つ各 `役割$に結付けられる，すべての要件 ］に準拠するならば、適合すると見なされる。 ◎ An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes in HTTP.

~HTTPにおける多くの~protocol要素は，特定の長さ制限を設けていない — 何故なら，［ 適切になるであろう長さ ］は、実装の［ 配備~文脈や目的 ］に依存して，多岐に渡るので。 よって，［ `送信者$と`受信者$との間の相互運用能 ］は、［ 各種~protocol要素に見合う長さに関して，共有されている期待 ］に依存する。 更には，一部の~protocol要素に対しては、［ それに見合う長さであると共通的に解されているもの ］は，過去 20 年に渡る~HTTP利用に伴って変遷しており、また，今後も変わり続けるものと予期されている。 ◎ HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore, what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past two decades of HTTP use and is expected to continue changing in the future.

`受信者$は、最小限，［［ 他の~message内の同じ~protocol要素 ］に対し，自身が`生成し$得る値の長さ ］以上の長さの~protocol要素を，構文解析して処理できなければナラナイ。 例えば，［ 自前の`資源$に 長大な~URI参照を公表する`生成元~server$ ］は、［ `要請~target$として受信された，同じ参照 ］を構文解析して処理できる必要がある。 ◎ At a minimum, a recipient MUST be able to parse and process protocol element lengths that are at least as long as the values that it generates for those same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own resources needs to be able to parse and process those same references when received as a request target.

`受信者$は、受信された~protocol要素を，［ この仕様がそれに定義する意味論 — この仕様に対する拡張も含む ］に則って解釈しなければナラナイ — ただし、受信者が［ 送信者が，それらの意味論に含意されるものを不正に実装している ］ものと，（経験または環境設定を通して）決定できたときは除く。 例えば，`生成元~server$は、［ `User-Agent$h ~headerの検分 ］から，［［ ある種の`内容~符号法$の受領に際し失敗する ］と既知である，特定の実装~version ］が指示されたときには、［ 受信された `Accept-Encoding$h ~headerの内容 ］を無視rするであろう。 ◎ A recipient MUST interpret a received protocol element according to the semantics defined for it by this specification, including extensions to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly implements what is implied by those semantics. For example, an origin server might disregard the contents of a received Accept-Encoding header field if inspection of the User-Agent header field indicates a specific implementation version that is known to fail on receipt of certain content codings.

他が注記されない限り，`受信者$は、妥当でない構成子から，利用~可能な~protocol要素を回復しようと試みてヨイ。 ~HTTPは、［ ~securityへの直接的な影響iがある ］ときを除いて，［ ~errorを取扱う特定の仕組み ］を定義しない — ~errorを取扱うに際し要求される策は、~protocolの~appごとに異なるので。 例えば、~Web~browserは，［ 応答の `Location$h ~headerが~ABNFに則って構文解析できない ］ときに 透過的な回復を望むかもしれないが、~system制御~clientは，いかなる形の~error回復も 危険と見なすかもしれない。 ◎ Unless noted otherwise, a recipient MAY attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous.

2.6. ~protocolの~version付け

~HTTPは、~protocolの各 `~version^dfn を指示するために， "<`major^var>.<`minor^var>" による付番方式を利用する。 この仕様が定義する`~version番号$は， "`1.1^c" である。 ~protocol~versionは、それ一体として，［［ その~versionに対応する~HTTPの仕様 ］にて挙げられた要件の集合 ］に，`送信者$が適合していることを指示する。 ◎ HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. This specification defines version "1.1". The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's corresponding specification of HTTP.

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

`HTTP-version@p
	= `HTTP-name$p "/" `DIGIT$P "." `DIGIT$P
`HTTP-name@p
	= %x48.54.54.50 ; "HTTP", case-sensitive

~versionが［ ~HTTP10 `1945$R あるいは未知 ］の`受信者$に向けて送信される`~HTTP11$~messageは、［ より新たな特能すべてが無視されたなら，妥当な~HTTP10~messageとして解釈できる ］ように構築される。 この仕様は、一部の新たな特能に対し，次が守られるように［ 受信者~versionの要件 ］を設置する： `送信者$は、自身が当の特能に適合するとしても，［ 環境設定や, ~messageの受領を通して，受信者が~HTTP11を~supportする ］ことを決定するまでは、互換な特能のみを利用する。 ◎ When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] 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.

`~header$の解釈は、［ 同じ`~major$ ~HTTP~version下の`~minor~version$間 ］では，変わらない — ［ そのような~headerが無い下での，`受信者$の既定の挙動 ］は，変わり得るが。 他から指定されない限り，［ `~HTTP11$にて定義される~header ］は，すべての［ ~HTTP1x~version† ］に対しても定義される。 特に，［ `Host$h ／ `Connection$h ］~headerは、［ ~HTTP11への適合性を広告するかどうか ］に関わらず，すべての［ ~HTTP1x実装† ］にて実装される~OUGHT。 【† ~HTTP10も含まれることになる】 ◎ The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default behavior of a recipient in the absence of such a field can change. Unless specified otherwise, header fields defined in HTTP/1.1 are defined for all versions of HTTP/1.x. In particular, the Host and Connection header fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1.

新たな`~header$を，［ ~protocol~versionを変更する ］ことなく，導入できる — ［ それに定義される意味論 ］において，［ それを認識しない`受信者$が，それを安全に無視する ］ことが許容されるならば。 ~headerの拡張能は `3.2.1$sec にて論じられる。 ◎ New header fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them. Header field extensibility is discussed in Section 3.2.1.

~HTTP~messageを処理する`中継者$（すなわち，`~tunnel$として動作するもの以外のすべての`中継者$）は、自身が回送する~message内に，［ 自前の `HTTP-version$p ］を送信しなければナラナイ。 言い換えれば，`中継者$には、~messageの［ 受信, 送信 ］の両者において，［ その~message内の~protocol~versionが，自身が適合する~versionに合致する ］ことが確保されない限り、［ ~HTTP~messageの最初の行lを盲目的に回送する ］ことは，許容されない。 仮に， `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. In other words, they are not allowed to blindly forward the first line of an HTTP message 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.

`~client$は、［ ~serverが~HTTP仕様を不正に実装している ］ことが既知である場合，［ より低い~versionによる要請 ］を送信してヨイ — ただし，それは、~clientが，少なくとも 1 回は通常の要請を試みて，［ `応答~状態s~code$や`~header$（例： `Server$h ） ］から［ ~serverが より高い要請~versionを不適正に取扱う ］ことを決定できた後に限られる。 ◎ A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions.

2.7. URI

~HTTP~~全体に渡り、 `~URI^dfn （ Uniform Resource Identifiers `3986$R — 統一的~資源~識別子）が，［ `資源$を識別するための手段 ］に利用される。 ~URI参照は、［ 要請を~targetにするため ／ ~redirectを指示するため ／ 関係性を定義する ］ために利用される。 ◎ Uniform Resource Identifiers (URIs) [RFC3986] are used throughout HTTP as the means for identifying resources (Section 2 of [RFC7231]). URI references are used to target requests, indicate redirects, and define relationships.

下に挙げる各種~定義は、~URIの汎用~構文から採用されている： 【 ";" 以下の~commentは訳者補足】 ◎ ↓

`URI-reference@p
	= <URI-reference, `3986-4.1$rfc> ; `~URI参照^com
`absolute-URI@p
	= <absolute-URI, `3986-4.3$rfc> ; `絶対~URI^com
`relative-part@p
	= <relative-part, `3986-4.2$rfc> ; `相対~URI（~query以下を除く）^com
`scheme@p
	= <scheme, `3986-3.1$rfc> ; `~URI~scheme^com
`authority@p
	= <authority, `3986-3.2$rfc> ; `権限^com
`uri-host@p
	= <`host@p, `3986-3.2.2$rfc> ; `~host^com
`port@p
	= <port, `3986-3.2.3$rfc> ; `~port^com
`path-abempty@p
	= <path-abempty, `3986-3.3$rfc> ; `~path（空もあり）^com
`segment@p
	= <segment, `3986-3.3$rfc> ; `~pathの一階層^com
`query@p
	= <query, `3986-3.4$rfc> ; `~query^com
`fragment@p
	= <fragment, `3986-3.5$rfc> ; `素片~識別子^com

加えて，次の規則も定義される： ◎ ↓

`absolute-path@p
	= 1*( "/" `segment$p )
`partial-URI@p
	= `relative-part$p [ "?" `query$p ]

`http-URI@p
	= "http:" "//" `authority$p `path-abempty$p [ "?" `query$p ]
	  [ "#" `fragment$p ]

`https-URI@p
	= "https:" "//" `authority$p `path-abempty$p [ "?" `query$p ]
	  [ "#" `fragment$p ]

http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html

3.1. `start-line^p

理論~上は、`~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, but, 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.

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

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

`request-line@p
	= `method$p `SP$P `request-target$p `SP$P `HTTP-version$p `CRLF$P

`method@p
	= `token$p

`status-line@p
	= `HTTP-version$p `SP$P `status-code$p `SP$P `reason-phrase$p `CRLF$P

`status-code@p
	= 3`DIGIT$P

`reason-phrase@p
	= *( `HTAB$P / `SP$P / `VCHAR$P / `obs-text$p )

3.2. ~header（ ~header~field ）

【 この訳に現れる語 “~header” は、 “`~header節$” を除き，ほぼすべて “~header~field” の略記である。 】

各 ~header （ `header-field^p ）の構文は、次で与えられる： ◎ Each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field value, and optional trailing whitespace.

`header-field@p
	= `field-name$p ":" `OWS$p `field-value$p `OWS$p

`field-name@p
	= `token$p
`field-value@p
	= *( `field-content$p / `obs-fold$p )
`field-content@p
	= `field-vchar$p [ 1*( `SP$P / `HTAB$P ) `field-vchar$p ]
`field-vchar@p
	= `VCHAR$P
	/ `obs-text$p

`obs-fold@p
	= `CRLF$P 1*( `SP$P / `HTAB$P )
	; 廃用にされた行l折返し — `3.2.4$secを見よ

【 `4189$errataによる~~修正あり（ Held for Document Update: 2015-04-22 ）（詳細は参照先に）： 】

`field-name$p は、文字大小無視であり，`~header$の名前 — `~header名@ — を与える。 `field-value$p は、その~headerの値 — `~header値@ — を与える。 ◎ ↑

`field-name$p ~tokenは、対応ng `field-value$p を，［ その名前の~headerにより定義される意味論 ］を有するものと定める。 例えば， `Date$h ~headerは、［ それが出現する~messageの，出生時の時刻印 ］を包含しているものと定義される。 ◎ The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, the Date header field is defined in Section 7.1.1.2 of [RFC7231] as containing the origination timestamp for the message in which it appears.

`OWS$p
	= *( `SP$P / `HTAB$P )
	; `省略可能な空白^com
`RWS$p
	= 1*( `SP$P / `HTAB$P )
	; `要求される空白^com
`BWS$p
	= `OWS$p
	; `“不良” 空白^com

`token@p
	= 1*`tchar$p

`tchar@p
	= "!"
	/ "#"
	/ "$"
	/ "%"
	/ "&"
	/ "'"
	/ "*"
	/ "+"
	/ "-"
	/ "."
	/ "^"
	/ "_"
	/ "`"
	/ "|"
	/ "~"
	/ `DIGIT$P
	/ `ALPHA$P
	; 区切子を除く，任意の `VCHAR$P

`quoted-string@p
	= `DQUOTE$P *( `qdtext$p / `quoted-pair$p ) `DQUOTE$P
`qdtext@p
	= `HTAB$P
	/ `SP$P
	/ %x21
	/ %x23-5B
	/ %x5D-7E
	/ `obs-text$p
`obs-text@p
	= %x80-FF

`comment@p
	= "(" *( `ctext$p / `quoted-pair$p / `comment$p ) ")"
`ctext@p
	= `HTAB$P
	/ `SP$P
	/ %x21-27
	/ %x2A-5B
	/ %x5D-7E
	/ `obs-text$p

`quoted-pair@p
	= "\" ( `HTAB$P / `SP$P / `VCHAR$P / `obs-text$p )

3.3. ~message本体

~HTTP~messageの~message本体（もし在れば）は、［ その要請／応答の， `~payload本体@ ］を運ぶために，利用される。 `転送~符号法$が適用されて（`3.3.1$sec）いない限り、~message本体は，~payload本体と~~同じになる。 ◎ The message body (if any) of an HTTP message is used to carry the payload body of that request or response. The message body is identical to the payload body unless a transfer coding has been applied, as described in Section 3.3.1.

【 すなわち、~message本体は，~messageに埋め込まれた~dataそのままを意味し、~payload本体は，`転送~符号法$による符号化は［ 施されていない／復号された ］~dataを意味する（端点からの視点では、~payload本体は，［ 中継者を透過的な~~存在と見なした下で，実質的にやりとりされる本体~data ］と捉えられる）。 この仕様の以前の版も含め、~payload本体は， “entity body（実体~本体）” と称されることもある。 】

`message-body@p
	= *`OCTET$P

［ ~message内にいつ~message本体が許容されるか ］の規則は、要請と応答で相違する。 ◎ The rules for when a message body is allowed in a message differ for requests and responses.

要請に~message本体が在ることは、［ `Content-Length$h または`Transfer-Encoding$h ］~headerにより通達され、その~message~frame法が，`~method$の意味論に依存することはない — ~methodが，~message本体の利用について何も定義していなくても。 ◎ The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field. Request message framing is independent of method semantics, even if the method does not define any use for a message body.

`Transfer-Encoding@p
	= 1#`transfer-coding$p

Transfer-Encoding: gzip, chunked

`Content-Length@p
	= 1*`DIGIT$P

Content-Length: 3495

3.4. 不完全な~messageの取扱い

`不完全$な要請~messageを受信した`~server$は、接続を~closeするに先立って，~error応答を送信してヨイ。 そのような要請は、通例的に［ 要請が取消されたり，制限時間による例外が誘発された ］ことに因る。 ◎ A server that receives an incomplete request message, usually due to a canceled request or a triggered timeout exception, MAY send an error response prior to closing the connection.

`不完全$な応答~messageを受信した`~client$は、その~messageを不完全なものと記録しなければナラナイ。 そのような応答は、接続が尚早に~closeされたときや, `~chunked転送~符号法$と思しきものの復号に失敗したときに，生じ得る。 不完全な応答に対する`~cache$についての要件は、`7234-3$rfcにて定義される。 ◎ A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding a supposedly chunked transfer coding fails, MUST record the message as incomplete. Cache requirements for incomplete responses are defined in Section 3 of [RFC7234].

応答が［ `~header節$の中途で（すなわち，`空~行l$が受信される前に）終了した ］かつ［ その`状態s~code$は、応答の全部的な意味を，~headerに依拠して伝達する可能性がある ］場合、`~client$は，その意味が伝達されたものと見做せないので、次にとる動作を決定するために，要請を繰返す必要が~~生じ得る。 ◎ If a response terminates in the middle of the header section (before the empty line is received) and the status code might rely on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed; the client might need to repeat the request in order to determine what action to take next.

`~chunked転送~符号法$も `Content-Length$h も持たない応答は，［ 接続の~closure ］により終了されるので、［ `~header節$は全て受信された ］限りにおいて，［ 受信された~message本体の~octet数 ］に関わらず 完全と見なされる。 ◎ A response that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection and, thus, is considered complete regardless of the number of message body octets received, provided that the header section was received intact.

3.5. ~message構文解析の堅牢性

早期の~server~appには，［ `CRLF$P で終了されていない`~message本体$ ］の内容を読取るのに失敗するものもあるため、古い~HTTP10~UA実装は，その対処法として， `POST$m 要請の後に余分な `CRLF$P を送信することがある。 `~HTTP11$`~UA$は、要請の前後に `CRLF$P を付け足してはナラナイ。 `~UA$は、要請~message本体を `CRLF$P で終了させたいときには，その `CRLF$P の分も`~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$ ］に対する行l終了子は， `CRLF$P ~octet並びであるが、`受信者$は，［ 1 個の `LF$P ~octet ］を行l終了子として認識して, 先行する `CR$P を無視してヨイ。 ◎ Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.

文法~規則 `request-line$p, `status-line$p は，［ 各種~成分~要素どうしが 1 個の `SP$P ~octetで分離される ］ことを要求しているが、`受信者$は，代わりに 空白で区切られる単語~境界を構文解析した上で，終了子の `CRLF$P は別として，頭部／尾部の空白は無視しつつ, 任意の形による空白を `SP$P 分離子と扱ってヨイ — そのような空白は、 1 個~以上の，次の~octetからなり得る：［ `SP$P, `HTAB$P, `VT^P (%x0B), `FF^P (%x0C), ［ `CRLF$P の一部でない `CR$P ］］。 しかしながら、寛容な構文解析-法は，［ ~messageに対し複数の`受信者$が居て，それぞれの堅牢性のための解釈が互いに異なる ］場合に，~securityの脆弱性になり得る（`9.5$secを見よ）。 ◎ Although the request-line and status-line grammar rules require that each of the component elements be separated by a single SP octet, recipients MAY instead parse on whitespace-delimited word boundaries and, aside from the CRLF terminator, treat any form of whitespace as the SP separator while ignoring preceding or trailing whitespace; such whitespace includes one or more of the following octets: SP, HTAB, VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can result in security vulnerabilities if there are multiple recipients of the message and each has its own unique interpretation of robustness (see Section 9.5).

`~server$は、［ ~HTTP要請~messageのみを~listenしている ］とき, あるいは［［ `start-line$p から出現するものが，~HTTP要請~messageになるかどうか ］を処理している ］ときに，［ `HTTP-message$p 文法に合致しない~octet列 ］を受信したときには、上に挙げた堅牢性の例外を除き，［ `400$st 応答 ］で応答するベキである。 ◎ 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.

4.1. ~chunked転送~符号法

`chunked-body@p
	= *`chunk$p
	  `last-chunk$p
	  `trailer-part$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列

`chunk-size$p ~fieldは、［ ~octet数による `chunk-data$p の~size ］を指示する，［ いくつかの~hex桁からなる文字列 ］である。 ~chunked転送~符号法が完了するのは、［ `chunk-size$p ~zeroの~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, and finally terminated by an empty line.

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

`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-part@p
	= *( `header-field$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 decoded-body
   length := length + chunk-size
   read chunk-size, chunk-ext (if any), and CRLF
}
read trailer field
while (trailer field is not empty) {
   if (trailer field is allowed to be sent in a trailer) {
       append trailer field to existing header fields
   }
   read trailer-field
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
Remove Trailer from existing header fields

4.2. 圧縮~符号法

~messageの`~payload$を圧縮するときには、以下に定義される各種 `圧縮~符号法^dfn を利用できる。 ◎ The codings defined below can be used to compress the payload of a message.

4.3. `TE^h

`TE$h `~header値$は、~commaで分離された~listであり，その各要素は［ `転送~符号法~名$ ／ ~keyword "`trailers$c"† ］を与える — 各 転送~符号法~名には、 0 個以上の~parameter（ `4$sec を見よ）も許容される。 `~client$は、`TE$h 内に，`転送~符号法~名$として "`chunked$c" を送信してはナラナイ — `~HTTP11$`受信者$に対しては、`~chunked$は常に受容-可能なので。 【† 構文上は、複数個の "`trailers^c" も（余計であるが）許容されている。】 ◎ The TE field-value consists of a comma-separated list of transfer coding names, each allowing for optional parameters (as described in Section 4), and/or the keyword "trailers". A client MUST NOT send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.

`TE@p
	= #`t-codings$p
`t-codings@p
	= "`trailers$c" / ( `transfer-coding$p [ `t-ranking$p ] )
`t-ranking@p
	= `OWS$p ";" `OWS$p "q=" `rank$p
`rank@p
	= ( "0" [ "." 0*3`DIGIT$P ] )
	/ ( "1" [ "." 0*3("0") ] )

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

［ `TE$h の`~header値$が空または， `TE$h ~headerが無い ］場合に受容-可能な`転送~符号法$は、"`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.

`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 6.1) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics.

4.4. `Trailer^h

`送信者$は、［ `~chunked転送~符号法$により符号化された`~message本体$ ］を内包する~messageの末尾に，［［ いくつかの`~trailer~field$ ］から形成される~metadata ］も送信したいと欲するときには、本体の前に［ どの`~trailer~field$が`~trailer節$内に在るか ］を指示する `Trailer$h ~headerを`生成する$ベキである。 これにより、`受信者$は，［ 本体の処理を開始する前に，その~metadataの受領を準備する ］ことが可能になる。 これは、［ ~messageが~stream化されていて ］, かつ［ 受信者が，完全性~検査をその場その場で確認することが望ましい ］場合に有用になる。 ◎ When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in the form of trailer fields at the end of the message, the sender SHOULD generate a Trailer header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed and the recipient wishes to confirm an integrity check on the fly.

`Trailer@p
	= 1#`field-name$p

5.1. ~target資源の識別-法

~HTTPは、一般用~computerから家電までに渡る，多種多様な~appで利用される。 一部の事例では、通信~optionは，~clientの環境設定~内に~~直に~code化されている。 しかしながら，大多数の~HTTP~clientは、一般用 ~Web~browserと同じ［ `資源$を識別するための仕組みと, 環境設定~技法 ］に依拠する。 ◎ HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases, communication options are hard-coded in a client's configuration. However, most HTTP clients rely on the same resource identification mechanism and configuration techniques as general-purpose Web browsers.

~HTTP通信は、何らかの目的で`~UA$から起動される。 その目的は、`要請の意味論$と, それらの意味論が適用される `~target資源^dfn との組合nである。 `~target資源$の識別子には、概して，`~URI$参照が利用される — `~UA$は、 `~target~URI@ を得するために，それを `absolute-form$p に解決することになる。 参照~内の `fragment$p 成分については、もし在れば，~target~URIからは除外される — `fragment$p 識別子は、`~client$側の処理 （`3986-3.5$rfc ）に予約されているので。 ◎ HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which are defined in [RFC7231], and a target resource upon which to apply those semantics. A URI reference (Section 2.7) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order to obtain the "target URI". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side processing ([RFC3986], Section 3.5).

5.2. 内方への接続-法

`~target~URI$が決定されたなら、`~client$は，［ 欲されている意味論を成遂げるためには，~network要請が必要yであるかどうか ］, および［ 必要yなら，その要請をどこへ~directするか ］を裁定する必要がある。 ◎ Once the target URI is determined, a client needs to decide whether a network request is necessary to accomplish the desired semantics and, if so, where that request is to be directed.

`~client$が`~cache$ `7234$R を備えていて, かつ それにより要請を充足できる場合、要請は，通例的に，最初にそこへ~directされる。 ◎ If the client has a cache [RFC7234] and the request can be satisfied by it, then the request is usually directed there first.

代表的な`~client$は、［ 要請が`~cache$により充足できない ］場合に［ 要請を充足するために利用される`~proxy$があるかどうか ］を決定するため，自身の環境設定を検査することになる。 ~proxy環境設定は，実装~依存であるが，［ URI 接頭辞の照合, 選択的な権限の照合, または その両者 ］に基づくことが多く、~proxy自身は，通例的に［ "`http$c" ／ "`https$c" ］~URIにより識別される。 適用-可能な`~proxy$がある場合、~clientは，［ その~proxyへの接続を確立する（または再利用する） ］ことにより，`内方$へ接続する。 ◎ If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching, selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy.

適用-可能な`~proxy$はない場合、代表的な`~client$は，［ `~target資源$に対する権限へ直に接続する ］ために，［ 通例的に`~target~URI$の `scheme$p ごとに特有な，~handler~routine ］を呼出すことになる。 これが どう成遂げられるかは、~target~URIの `scheme$p に依存し，それを~~規定する仕様により定義される — この仕様が，［［ "`http$c" ／ "`https$c" ］`scheme$p を解決するために，`生成元~server$~accessを どのように定義しているか ］に類似な。 ◎ If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification, similar to how this specification defines origin server access for resolution of the "http" (Section 2.7.1) and "https" (Section 2.7.2) schemes.

接続の管理に関する~HTTP要件は、`6$secにて定義される。 ◎ HTTP requirements regarding connection management are defined in Section 6.

5.3. 要請~target

`内方$への接続を得したなら、`~client$は，送信する~HTTP要請`~message$に［ `~target~URI$から導出された `要請~target^dfn（ `request-target$p ） ］を伴わせる。 `要請~target$には、［ 要請されている~method, および 要請が`~proxy$へ向けたものかどうか ］の両者に依存して， 4 種の別個な形式がある： ◎ Once an inbound connection is obtained, the client sends an HTTP request message (Section 3) with a request-target derived from the 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

`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
	= `authority$p

CONNECT www.example.com:80 HTTP/1.1

`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

5.4. `Host^h

要請~内の `Host^h ~headerは、［ `~target~URI$からの［ `host$p ＆ `port$p 情報 ］］を供して、`生成元~server$が，［ 単独の~IP~address上にて複数の~host名に対する要請 ］を~serviceしている間でも，`資源$を互いに判別できるようにする： ◎ The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple host names on a single IP address.

`Host@p
	= `uri-host$p [ ":" `port$p ] ; `2.7.1$sec

`Host$h `~header値$は，要請を取扱うときに決定的な情報なので、`~UA$は `Host$h を，［ `request-line$p に後続する最初の~header ］として`生成する$ベキである。 ◎ Since the Host field-value is critical information for handling a request, a user agent SHOULD generate Host as the first header field following the request-line.

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

`~client$は、 `request-target$p が `absolute-form$p であっても， `~HTTP11$要請~内に `Host$h ~headerを送信しなければナラナイ。 これにより、 `Host$h 情報を［ `Host$h が実装されていない古代の~HTTP10~proxy ］を通して回送することも可能になるので。 ◎ A client MUST send a Host header field in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the Host information to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.

`Host$h ~headerは，［ ~app~levelの経路制御の仕組み ］として動作するので、~malwareにとっては，`共用~cache$を汚染したり, 要請を意図されていない`~server$へ~redirectさせる，格好の~targetになる。 ~interception`~proxy$は、特に，［ 要請を内部~serverへ~redirectしたり, `共用~cache$内の~cache~keyとして利用する ］ときに `Host$h `~header値$に依拠していて，［ ~interceptされた接続が，~hostに対する妥当な~IP~addressを~targetしているかどうか ］を最初に検証yしていない場合に、脆弱になる。 ◎ Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.

5.5. 実効~要請~URI

`~UA$にとっては、`実効~要請~URI$が，`~target~URI$になる。 ◎ For a user agent, the effective request URI is the target URI.

`request-target$p は `absolute-form$p であるならば： `実効~要請~URI$は， `request-target$p と同じである。 ◎ If the request-target is in absolute-form, the effective request URI is the same as the request-target. Otherwise, the effective request URI is constructed as follows:

他の場合、`実効~要請~URI$は，次の様に構築される：

1. `実効~要請~URI$ に利用される `scheme$p は：

   1. ~serverの環境設定（または`外方$`~gateway$）にて，固定的な~URI `scheme$p が供されているならば： その `scheme$p 。
   2. 他の場合，［ 要請は TLS で~secure化された~TCP接続~越しに受信された ］ならば： "`https$c" 。
   3. 他の場合： "`http$c" 。
   ◎ If the server's configuration (or outbound gateway) provides a fixed URI scheme, that scheme is used for the effective request URI. Otherwise, if the request is received over a TLS-secured TCP connection, the effective request URI's scheme is "https"; if not, the scheme is "http".

2. `実効~要請~URI$ の `authority$p 成分は：

   1. ~serverの環境設定（または`外方$`~gateway$）にて，固定的な~URI `authority$p 成分を供しているならば： その `authority$p 。
   2. 他の場合，［ `request-target$p は `authority-form$p である ］ならば： `request-target$p と同じ。
   3. 他の場合，［ `Host$h ~headerが給されていて，その`~header値$が空でない ］ならば： `Host$h `~header値$と同じ。
   4. 他の場合： ~serverに環境設定された既定の名前 — 更に，［ 接続の入力用~TCP~port番号が［ `実効~要請~URI$の `scheme$p に対する既定の~port ］と相違する場合は，［ ~colon （"`:^c"）, および（~decimal形による）その入力用~port番号 ］も付加する。
   ◎ If the server's configuration (or outbound gateway) provides a fixed URI authority component, that authority is used for the effective request URI. If not, then if the request-target is in authority-form, the effective request URI's authority component is the same as the request-target. If not, then if a Host header field is supplied with a non-empty field-value, the authority component is the same as the Host field-value. Otherwise, the authority component is assigned the default name configured for the server and, if the connection's incoming TCP port number differs from the default port for the effective request URI's scheme, then a colon (":") and the incoming port number (in decimal form) are appended to the authority component.

3. `実効~要請~URI$の［ 結合された `path$p ＆ `query$p 成分 ］は、 `request-target$p の形式に応じて，次で与えられる：

   `authority-form$p

   `asterisk-form$p

   空。

   `origin-form$p

   `request-target$p と同じ。

   ◎ If the request-target is in authority-form or asterisk-form, the effective request URI's combined path and query component is empty. Otherwise, the combined path and query component is the same as the request-target.

4. `実効~要請~URI$は、［ 上述の様に決定された各~成分, および 文字列 "`://^c" ］を，次の順で連結した結果の `absolute-URI$p 形 【 `absolute-form$p 】 になる：

   1. `scheme$p
   2. "`://^c"
   3. `authority$p
   4. 結合された `path$p ＆ `query$p 成分
   ◎ The components of the effective request URI, once determined as above, can be combined 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:8080

http://www.example.org:8080/pub/WWW/TheProject.html

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

https://www.example.org

［ `Host$h ~headerを欠如する~HTTP10要請 ］の`受信者$は、［ `実効~要請~URI$の `authority$p 成分 ］を推測するために，経験則（例： 特定0の~hostに一意な何かに対する，~URI~pathの審査）の利用が必要になることもある。 ◎ Recipients of an HTTP/1.0 request that lacks a Host header field might need to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess the effective request URI's authority component.

5.6. 応答から要請への結付法

~HTTPには、［ 所与の要請~message ］を［ 1 個~以上の，対応ng応答~message ］に結付けるような要請~識別子は，ない。 よって，その結付けは［ 同じ接続~上で要請が為された順序が，応答が到着した順序に正確に対応する ］ことに依拠する。 1 個の要請に対し複数個の応答~messageが生じるのは、［ 同じ要請に対する最終~応答に， 1 個~以上の `1xx$st 応答が先行する ］ときに限られる。 ◎ HTTP 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 6.2 of [RFC7231]) precede a final response to the same request.

`~client$は、接続~上に， `応答待ち要請@ — まだ最終（非 `1xx$st ）応答が受信されていない要請 — が複数個あるときには、［ それらの要請からなる，送信した順序による~list ］を保守し、［ その接続~上で応答~messageが受信された ］ときには，［ ~listから~~先頭の要請を抜き取って，受信した応答に結付ける ］ことが`要求される^2119。 ◎ 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 highest ordered request that has not yet received a final (non-1xx) response.

5.7. ~messageの回送

`2.3$sec にて述べたように，`中継者$は、［ ~HTTP要請＆応答の処理 ］に際して，種々の`役割$に基いて~serveし得る。 `中継者$には、［ 処理能や可用性を改善する ］ために利用されるものもあれば，［ ~access制御~用／内容を~filterするため ］に利用されるものもある。 ~HTTP~streamは，［ ~pipe＆~filter ~architecture ］に類似な特性を有するので、~streamのいずれの方向についても，`中継者$が増強-（または干渉-）し得る限度に，内来的な制限はない。 ◎ As described in Section 2.3, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can enhance (or interfere) with either direction of the stream.

`~tunnel$として動作しない`中継者$は、`6.1$secによる指定-に従って， `Connection$h ~headerを実装しなければナラナイ — 加えて、一連の~headerを回送する際には，［ 自身宛の接続のみに意図されているもの ］を除外しなければナラナイ。 ◎ An intermediary not acting as a tunnel MUST implement the Connection header field, as specified in Section 6.1, and exclude fields from being forwarded that are only intended for the incoming connection.

`中継者$は、自身宛の~messageを回送してはナラナイ — それが，無限~要請~loopから保護されていない限り【？】 。 一般に，`中継者$は、自前の~server名 — ［ 別名, 局所的な変名, ~literal~IP~address ］も含む — を認識して，そのような要請に対し直に応答する~OUGHT。 ◎ An intermediary MUST NOT forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly.

`Via@p
	= 1#( `received-protocol$p `RWS$p `received-by$p [ `RWS$p `comment$p ] )

`received-protocol@p
	= [ `protocol-name$p "/" ] `protocol-version$p
`received-by@p
	= ( `uri-host$p [ ":" `port$p ] ) / `pseudonym$p
`pseudonym@p
	= `token$p

Via: 1.0 fred, 1.1 p.example.net

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

6.1. `Connection^h

`Connection$h ~headerにより、`送信者$は，［ 現在の接続に欲される制御~option ］を指示できるようになる。 `~proxy$／`~gateway$ は、`下流$の`受信者$たちが混同しないように，~messageを回送する前に，［ 受信されたどの接続~option ］も【以下に述べる様に】 除去する, もしくは置換しなければナラナイ。 ◎ The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message.

すなわち， `Connection$h ~headerは、［ 直接の`受信者$のみに意図された `隣点間~header@ ］と,［ `連鎖$上のすべての`受信者$に意図された `端点間~header@ ］を判別できるようにする，宣言的な仕方を供する — それは、~messageを自己-記述的にすることで，［ 古い`中継者$により盲目的に回送されるおそれ ］なく，［ 接続ごとに特有な，将来の拡張 ］を配備できるようにする。 ◎ Hence, the Connection header field provides a declarative way of distinguishing header fields that are only intended for the immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they will be blindly forwarded by older intermediaries.

`Connection$h ~header値の文法は、次で与えられる： ◎ The Connection header field's value has the following grammar:

`Connection@p
	= 1#`connection-option$p
`connection-option@p
	= `token$p

`connection-option$p が各 `接続~option@ を与える。 それは、文字大小無視である。 ◎ Connection options are case-insensitive.

`送信者$は、［ `~payload$を受け取るすべての`受信者$向けに意図された~header ］に対応するような`接続~option$を，送信してはナラナイ。 例えば， `Cache-Control$h は、接続~optionとしては，決して適切にならない。 ◎ A sender MUST NOT send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, Cache-Control is never appropriate as a connection option (Section 5.2 of [RFC7234]).

`接続~option$は，常に［ ~message内に在る~header ］に対応するとは限らない — 結付けられる~parameterがない接続~optionに対しては、［ 接続ごとに特有な~header ］は不要になり得るので。 対照的に，［ 対応する接続~optionを伴わずに受信された， 接続ごとに特有な~header ］は、通例的に［ ~headerが`中継者$により不適正に回送された ］ことを指示するので，`受信者$は無視する~OUGHT。 ◎ The connection options do not always correspond to a header field present in the message, since a connection-specific header field might not be needed if there are no parameters associated with a connection option. In contrast, a connection-specific header field that is received without a corresponding connection option usually indicates that the field has been improperly forwarded by an intermediary and ought to be ignored by the recipient.

仕様~策定者が，新たな`接続~option$を定義するときは、既存の`~header名$を調べて，［ 新たな接続~optionが，すでに配備されている~headerと同じ名前を共有しない ］ことを確保する~OUGHT。 新たな接続~optionを定義することは、本質的に，その`~header名$を［ 接続~optionに関係する追加的な情報 ］を運ぶために予約することを~~意味し、送信者にとっては，その`~header名$を他の何かに利用することが無分別になるので。 ◎ When defining new connection options, specification authors ought to survey existing header field names and ensure that the new connection option does not share the same name as an already deployed header field. Defining a new connection option essentially reserves that potential field-name for carrying additional information related to the connection option, since it would be unwise for senders to use that field-name for anything else.

`~close_接続~option@ は、`送信者$が，［ この接続が，応答の完了の後に~closeされる ］ことを他へ通達するためのものとして，定義される。 例えば： ◎ The "close" connection option is defined for a sender to signal that this connection will be closed after completion of the response. For example,

Connection: close

要請, 応答のいずれにおいても、この~headerは，［ `送信者$が，現在の［ 要請／応答 ］が完了した（`6.6$sec）後に，接続を~closeしようとしている ］ことを指示する。 ◎ in either the request or the response header fields indicates that the sender is going to close the connection after the current request/response is complete (Section 6.6).

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

［ `持続的な接続$を~supportしない`~server$ ］は、［ 状態s~codeが `1xx$st でない ］ような毎~応答~messageごとに，`~close_接続~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.

6.2. 確立法

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

6.3. 持続性

`~HTTP11$では、 `持続的な接続^dfn は，既定で利用できる — これは、単独の接続~越しに，複数の［ 要請や応答 ］を運べるようにする。 `~close_接続~option$は、［ 接続が現在の［ 要請／応答 ］の後に持続しない ］ことを通達するために利用される。 ~HTTP実装は、`持続的な接続$を~supportするベキである。 ◎ HTTP/1.1 defaults to the use of "persistent connections", allowing multiple requests and responses to be carried over a single connection. The "close" connection option is used to signal that a connection will not persist after the current request/response. HTTP implementations SHOULD support persistent connections.

`受信者$は、［ 最も近過去に受信された~message ］の［ `~protocol~version$と `Connection$h ~header（もし在れば) ］に基づいて，［ 接続が現在の応答の後にも持続することになるかどうか ］を決定する： ◎ A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version and Connection header field (if any):

1. `~close_接続~option$が在るならば、持続しない。 ◎ • If the "close" connection option is present, 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は`~proxy$宛の要請ではない。†
   • 受信者は［ ~HTTP10 による "`keep-alive$c" の仕組み ］を望んで尊守する。

   【† `4205$errataによる~~修正（ Verified: 2014-12-25）： , the recipient is not a proxy in a message that is not a request to a proxy 】

   ◎ • If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, the recipient is not a proxy, 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.

`~client$は、自身が，［ `~close_接続~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自身により定義される必要がある（ `3.3$sec — すなわち，長さは接続の~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 3.3. A server MUST read the entire request message body or close the connection after sending its response, since 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に伴われる問題の，情報と論点については、 `2068-19.7.1$rfcを見よ）。 ◎ A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).

~HTTP10~clientに対する後方~互換性についての更なる情報は、 `付録 A.1.2＠#appendix-A.1.2$ に。 ◎ See Appendix A.1.2 for more information on backwards compatibility with HTTP/1.0 clients.

6.4. 同時並行性

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

~HTTPの以前の改訂では、接続~数に特定の~~上限を設けていたが、これは，多くの~appにとり実用的でないことが判っている。 そのため，この仕様は、特定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” 問題 — ［ `~server$側に重い処理を要したり, 巨大な`~payload$を持つ ］ような要請が、同じ接続~上の後続な要請を阻むこと — を避けるために利用される。 しかしながら、接続のそれぞれは，~server資源を消費する。 更には、複数の接続が利用された場合，混雑した~networkに，望ましくない副作用をもたらし得る。 ◎ Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant server-side processing and/or has a large payload blocks subsequent requests on the same connection. However, each connection consumes server resources. Furthermore, using multiple connections can cause undesirable side effects in congested networks.

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

6.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混雑を悪化させ得るので。 ◎ 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.

［ `~message本体$を送信している`~client$ ］は、要請を伝送している間，［ ~network接続における~error応答 ］を監視するベキである。 ~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.

6.6. 解体

`Connection$h ~headerは、`~close_接続~option$を供する — それは、`送信者$が［［ 現在の［ 要請/応答 ］~pair ］の後に，接続を~closeしたいと望む ］ときに送信されるベキである。 ◎ The Connection header field (Section 6.1) provides a "close" connection option that a sender SHOULD send when it wishes to close the connection after the current request/response pair.

`~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構文解析器が，入力~bufferを読取って解釈する ］前に，~clientから承認されないまま，~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 that was 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.

6.7. `Upgrade^h

`Upgrade$h ~headerは、［［ ある接続~上で，`~HTTP11$から 何らかの他の~protocolへ移行する ］ための単純な仕組み ］を意図して供されている。 `~client$は、［［ `~server$が最終~応答を送信する ］前に，［ 1 個~以上の他の~protocol ］に切替えてもらうよう，~serverを招く ］ために，［ 要請の `Upgrade$h ~header ］内に，［ 選好順による，~protocolの~list ］を送信してヨイ。 `~server$は、その接続~上で，現在の~protocolを利用し続けたいと望むならば，［ 受信された `Upgrade$h ~header ］を無視してヨイ。 `Upgrade$h を利用して，~protocol変更を強要することはできない。 ◎ The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol on the same connection. A client MAY send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols, in order of descending preference, before sending the final response. A server MAY ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection. Upgrade cannot be used to insist on a protocol change.

`Upgrade@p
	= 1#`protocol$p

`protocol@p
	= `protocol-name$p ["/" `protocol-version$p]
`protocol-name@p
	= `token$p
`protocol-version@p
	= `token$p

`~server$は：

• `426$st 応答を送信するときは、［ 受容-可能な~protocolを指示する ］ために，［ 選好順による， `Upgrade$h ~header ］を送信しなければナラナイ。 ◎ A server that sends a 426 (Upgrade Required) response MUST send an Upgrade header field to indicate the acceptable protocols, in order of descending preference.
• 他の応答においても、未来の要請~用に適切になるときは，［ 選好順による， `Upgrade$h ~header ］を送信して，［ 自身が［ ~listされた~protocolに昇格するための~support ］を実装している ］ことを広告してヨイ。 ◎ A server MAY send an Upgrade header field in any other response to advertise that it implements support for upgrading to the listed protocols, in order of descending preference, when appropriate for a future request.

GET /hello.txt HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

~protocol変更~後の［ ~app~levelの通信の能力や資質 ］は、［ 選択される新たな~protocol（たち） ］に全面的に依存する。 しかしながら，`~server$は、 `101$st 応答を送信した直後に［ 新たな~protocolの中で 元の要請に等価なものを受信した ］かのように，応答を継続するものと期待されている（すなわち、~protocolが変更された後であっても，~serverは依然として［ まだ充足するべき`応答待ち要請$ ］を持ち，［ 要請の繰返し ］を要求することなく，そうするものと期待されている）。 ◎ The capabilities and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol(s) chosen. However, immediately after sending the 101 (Switching Protocols) response, the server is expected to continue responding to the original request as if it had received its equivalent within the new protocol (i.e., the server still has an outstanding request to satisfy after the protocol has been changed, and is expected to do so without requiring the request to be repeated).

例えば，~serverが、［ `GET$m 要請にて `Upgrade$h ~headerが受信された ］下で，~protocolを切替えるものと裁定した場合には、まず［ HTTP/1.1 `101$st ~message ］で応答した直ぐ後に，［ 新たな~protocolにおける［ `~target資源$上の `GET$m に対する応答 ］に等価なもの ］が後続する。 これにより、追加的な往復による待時間~costなしに，［ ~HTTPと同じ意味論を有する~protocol ］へ接続を昇格できるようになる。 `~server$は、新たな~protocolが［ 受信された~message意味論 ］を尊守し得ない場合は，~protocolを切替えてはナラナイ — `OPTIONS$m 要請は，どの~protocolからも尊守し得る。 ◎ For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, it first responds with a 101 (Switching Protocols) message in HTTP/1.1 and then immediately follows that with the new protocol's equivalent of a response to a GET on the target resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of an additional round trip. A server MUST NOT switch protocols unless the received message semantics can be honored by the new protocol; an OPTIONS request can be honored by any protocol.

HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: HTTP/2.0

[…… "`GET /hello.txt^c" 要請に対し，適切な応答により~data~streamを
HTTP/2.0 に切替える（その新たな~protocolによる定義に従って）…… ]
◎
[... data stream switches to HTTP/2.0 with an appropriate response
(as defined by new protocol) to the "GET /hello.txt" request ...]

`Upgrade$h を送信する`送信者$は、［ `Upgrade$h が［ ~listされた~protocolを実装していない`中継者$ ］により不用意に回送される ］ことを防ぐために，［ "`upgrade^c" `接続~option$を包含する `Connection$h ~header ］も送信しなければナラナイ。 `~server$は、［ ~HTTP10要請にて受信された `Upgrade$h ~header ］を無視しなければナラナイ。 ◎ When Upgrade is sent, the sender MUST also send a Connection header field (Section 6.1) that contains an "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries that might not implement the listed protocols. A server MUST ignore an Upgrade header field that is received in an HTTP/1.0 request.

`~client$は、［ 要請~messageを完全に送信し終える ］まで，接続~上にて昇格された~protocolの利用を~~開始できない（すなわち、~clientは，~messageの中途で［ 送信している~protocol ］を変更できない）。 `~server$が， `Upgrade$h と［ `~100cont 期待$を伴う `Expect$h ~header ］の両者を受信したときは、 `101$st 応答を送信する前に， `100$st 応答を送信しなければナラナイ。 ◎ A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e., the client can't change the protocol it is sending in the middle of a message). If a server receives both an Upgrade and an Expect header field with the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the server MUST send a 100 (Continue) response before sending a 101 (Switching Protocols) response.

`Upgrade$h ~headerは，［ 既存の接続の上層にある~protocolの切替 ］にのみ適用される。 それは［ 下層~接続の（~transport）~protocolの切替 ］, あるいは［ 既存の通信を異なる接続に切替えること ］には利用し得ない。 その種の目的には、 `3xx$st 応答の利用が，より適切である。 ◎ The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those purposes, it is more appropriate to use a 3xx (Redirection) response (Section 6.4 of [RFC7231]).

この仕様は、［ ~HTTP`~version$規則, および この仕様に対する将来の更新 ］に定義されるように，［ Hypertext Transfer Protocol 族 ］に利用するための ~protocol名として， "`HTTP^c" のみを定義する。 追加的な~tokenは， `8.6$sec にて定義される登録~手続-を利用して ~IANAにより登録される~OUGHT。 ◎ This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined by the HTTP version rules of Section 2.6 and future updates to this specification. Additional tokens ought to be registered with IANA using the registration procedure defined in Section 8.6.

8.1. ~headerの登録

~HTTP~headerは、 `Message Headers ~registry＠~IANA-a/message-headers/$ にて保守され，登録される。 ◎ HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.

この文書は、次の各種~HTTP~headerを定義する。 それに伴い， "Permanent Message Header Field Names" ~registryは更新された（`BCP90$r を見よ）。 ◎ This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).

   +-------------------+----------+----------+---------------+
   | Header Field Name | Protocol | Status   | Reference     |
   +-------------------+----------+----------+---------------+
   | Connection        | http     | standard | Section 6.1   |
   | Content-Length    | http     | standard | Section 3.3.2 |
   | Host              | http     | standard | Section 5.4   |
   | TE                | http     | standard | Section 4.3   |
   | Trailer           | http     | standard | Section 4.4   |
   | Transfer-Encoding | http     | standard | Section 3.3.1 |
   | Upgrade           | http     | standard | Section 6.7   |
   | Via               | http     | standard | Section 5.7.1 |
   +-------------------+----------+----------+---------------+

更には、 `~header名$ `Close^h が "reserved" として登録された — ［ その名前を~HTTP~headerとして利用する ］ことは、［ `Connection$h ~headerの `~close_接続~option$ ］と競合するかもしれないので。 ◎ Furthermore, the header field-name "Close" has been registered as "reserved", since using that name as an HTTP header field might conflict with the "close" connection option of the Connection header field (Section 6.1).

   +-------------------+----------+----------+-------------+
   | Header Field Name | Protocol | Status   | Reference   |
   +-------------------+----------+----------+-------------+
   | Close             | http     | reserved | Section 8.1 |
   +-------------------+----------+----------+-------------+

変更~制御者は~IETF-orgである。 ◎ The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".

8.2. ~URI~schemeの登録

~IANAは、 `URI Schemes ~registry＠~IANA-a/uri-schemes/$ `BCP115$r を保守する。 ◎ IANA maintains the registry of URI Schemes [BCP115] at <http://www.iana.org/assignments/uri-schemes/>.

この文書は、次の~URI~schemeを定義する。 それに伴い、 "Permanent URI Schemes" ~registryは，更新された。 ◎ This document defines the following URI schemes, so the "Permanent URI Schemes" registry has been updated accordingly.

   +------------+------------------------------------+---------------+
   | URI Scheme | Description                        | Reference     |
   +------------+------------------------------------+---------------+
   | http       | Hypertext Transfer Protocol        | Section 2.7.1 |
   | https      | Hypertext Transfer Protocol Secure | Section 2.7.2 |
   +------------+------------------------------------+---------------+

8.3. ~MIME型の登録

~IANAは、 `~MIME型~registry＠~IANA-a/media-types$ `BCP13$r を保守する。 ◎ IANA maintains the registry of Internet media types [BCP13] at <http://www.iana.org/assignments/media-types>.

この文書は、~MIME型［ `message/http$c, `application/http$c ］用の仕様として~serveする。 次のものが~IANAにより登録された。 ◎ This document serves as the specification for the Internet media types "message/http" and "application/http". The following has been registered with IANA.

8.4. 転送~符号法~registry

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

   +------------+--------------------------------------+---------------+
   | Name       | Description                          | Reference     |
   +------------+--------------------------------------+---------------+
   | chunked    | Transfer in a series of chunks       | Section 4.1   |
   | compress   | UNIX "compress" data format [Welch]  | Section 4.2.1 |
   | deflate    | "deflate" compressed data            | Section 4.2.2 |
   |            | ([RFC1951]) inside the "zlib" data   |               |
   |            | format ([RFC1950])                   |               |
   | gzip       | GZIP file format [RFC1952]           | Section 4.2.3 |
   | x-compress | Deprecated (alias for compress)      | Section 4.2.1 |
   | x-gzip     | Deprecated (alias for gzip)          | Section 4.2.3 |
   +------------+--------------------------------------+---------------+

8.5. 内容~符号法~登録

~IANAは、 `HTTP Content Coding Registry＠~IANA-a/http-parameters$ を保守する。 ◎ IANA maintains the "HTTP Content Coding Registry" at <http://www.iana.org/assignments/http-parameters>.

"HTTP Content Coding Registry" は、以下の登録により更新された： ◎ The "HTTP Content Coding Registry" has been updated with the registrations below:

   +------------+--------------------------------------+---------------+
   | Name       | Description                          | Reference     |
   +------------+--------------------------------------+---------------+
   | compress   | UNIX "compress" data format [Welch]  | Section 4.2.1 |
   | deflate    | "deflate" compressed data            | Section 4.2.2 |
   |            | ([RFC1951]) inside the "zlib" data   |               |
   |            | format ([RFC1950])                   |               |
   | gzip       | GZIP file format [RFC1952]           | Section 4.2.3 |
   | x-compress | Deprecated (alias for compress)      | Section 4.2.1 |
   | x-gzip     | Deprecated (alias for gzip)          | Section 4.2.3 |
   +------------+--------------------------------------+---------------+

8.6. `Upgrade^h ~token~registry

［ `Upgrade$h ~header内の~protocolを識別するために利用される， `protocol-name$p ~token ］用の名前空間は、 `Hypertext Transfer Protocol (HTTP) Upgrade Token Registry＠~IANA-a/http-upgrade-tokens$ （ HTTP `Upgrade^h ~token~registry）にて保守され，定義される。 ◎ The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" defines the namespace for protocol-name tokens used to identify protocols in the Upgrade header field. The registry is maintained at <http://www.iana.org/assignments/http-upgrade-tokens>.

   +-------+----------------------+----------------------+-------------+
   | Value | Description          | Expected Version     | Reference   |
   |       |                      | Tokens               |             |
   +-------+----------------------+----------------------+-------------+
   | HTTP  | Hypertext Transfer   | any DIGIT.DIGIT      | Section 2.6 |
   |       | Protocol             | (e.g, "2.0")         |             |
   +-------+----------------------+----------------------+-------------+

9.1. 権限の確立

~HTTPは、 `権限的~応答@ の~~概念（ notion ）に依拠する： それは、［ 応答~messageの出生時における`~target資源$の状態 ］が与えられた下で — 要請に対する，最も適切な応答になるように — `~target~URI$の中で識別される権限（ `authority$p ）により決定される（または, ~directされる）応答である。 ［ `共用~cache$などの非~権限的な~sourceから，応答を供すること ］は，［ 処理能や可用性の向上に有用になる ］ことが多いが、安全に利用できるのは，~sourceが信用できる限度までであり、さもなければ応答は信用できないものになる。 ◎ HTTP relies on the notion of an authoritative response: a response that has been determined by (or at the direction of) the authority identified within the target URI to be the most appropriate response for that request given the state of the target resource at the time of response message origination. Providing a response from a non-authoritative source, such as a shared cache, is often useful to improve performance and availability, but only to the extent that the source can be trusted or the distrusted response can be safely used.

登録-済みな名前が `authority$p 成分~内に利用されるとき、 "`http$c" ~URI~schemeは，［ `権限的~応答$がどこで見出せるかを決定する ］ときに［ 利用者に局所的な名前~解決~service ］に依拠する。 これは、利用者の［ ~network~host~table ／ ~cacheされている名前 ／ 名前~解決~library ］に対するどの攻撃も，権限の確立に対する攻撃に繋がることを意味する。 同様に、［ 利用者が~DNS（ Domain Name Service ）用に選択した~server ］, および［ 解決の結果を得するときに用いた，~server階層 ］は，［ ~address対応付けの真正性 ］にも影響iし得る — 真正性を改善する仕方の一つには、 DNS Security Extensions（ DNSSEC, `4033$R ）がある。 ◎ When a registered name is used in the authority component, the "http" URI scheme (Section 2.7.1) relies on the user's local name resolution service to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority. Likewise, the user's choice of server for Domain Name Service (DNS), and the hierarchy of servers from which it obtains resolution results, could impact the authenticity of address mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to improve authenticity.

更には、~IP~addressが得された後の，［ "`http$c" ~URI に対する権限の確立 ］は、［ Internet Protocol 経路制御に対する攻撃 ］に脆弱である。 ◎ Furthermore, after an IP address is obtained, establishing authority for an "http" URI is vulnerable to attacks on Internet Protocol routing.

9.2. 中継者の~risk

~HTTP`中継者$は，本質的に中間者であり、従って［ 中間者~攻撃の機会 ］を表現する。 ［ 中継者が稼働する~system ］が弱体化されると、深刻な［ ~security／~privacy ］問題になり得る。 中継者は，［［ ~securityに関係する情報 ］,［ 個々の［ 利用者／組織 ］についての個人-情報 ］,［ 利用者と内容~providerに所属している~proprietary情報 ］］へも~accessし得るかもしれない。 弱体化された, もしくは［ ~securityや~privacyへの考慮点 ］に目を向けずに［ 実装された／環境設定された ］中継者は、その引き換えに広範な攻撃に晒され得る。 ◎ By their very nature, HTTP intermediaries are men-in-the-middle and, thus, represent an opportunity for man-in-the-middle attacks. Compromise of the systems on which the intermediaries run can result in serious security and privacy problems. Intermediaries might have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers. A compromised intermediary, or an intermediary implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.

［ `共用~cache$を包含する`中継者$ ］は、`7234-8$rfc にて述べられるように，~cache汚染~攻撃に とりわけ脆弱である。 ◎ Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks, as described in Section 8 of [RFC7234].

実装者たちは、［ 設計と coding に際しての裁定, および 運用者に供する環境設定~option（とりわけ，既定の環境設定） ］による，~privacyや~securityに対する含意を考慮する必要がある。 ◎ Implementers need to consider the privacy and security implications of their design and coding decisions, and of the configuration options they provide to operators (especially the default configuration).

利用者は、`中継者$が，それらを稼働させている~~人々以上に信用に価するものにはならないことを意識しておく必要がある — ~HTTP自身は、この問題を解決sできない。 ◎ Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve this problem.

9.3. ~protocol要素の長さを介した攻撃

~HTTPは，大方，文字で区切られる~textな~header利用するので、構文解析器は，［ 長大な（または とても遅い）~data~streamの送信に基づく攻撃 ］に脆弱になることが多い — 特に，実装が［ 定義済み長さがない~protocol要素 ］を予期している所では。 ◎ Because HTTP uses mostly textual, character-delimited fields, parsers are often vulnerable to attacks based on sending very long (or very slow) streams of data, particularly where an implementation is expecting a protocol element with no predefined length.

相互運用能を促進するため、 `request-line$p, および各種`~header$には，最低限の~size制限についての 特定の推奨が為される。 これらは、［［ 資源が制限された実装でも~support可能になる ］ような最低限の推奨になる ］ように選択されている — ほとんどの実装は，相当に高い制限を選択することになると予期されている。 ◎ To promote interoperability, specific recommendations are made for minimum size limits on request-line (Section 3.1.1) and header fields (Section 3.2). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected that most implementations will choose substantially higher limits.

`~server$は［ `request-target$p が長過ぎる（`7231-6.5.12$rfc）, あるいは 要請~payloadが巨大~過ぎる（`7231-6.5.11$rfc） ］ような~messageを却下できる。 ［ 容量~制限に関係する追加的な状態s~code ］が，~HTTPの拡張 `6585$R により定義されている。 ◎ A server can reject a message that has a request-target that is too long (Section 6.5.12 of [RFC7231]) or a request payload that is too large (Section 6.5.11 of [RFC7231]). Additional status codes related to capacity limits have been defined by extensions to HTTP [RFC6585].

`受信者$は、［ 自身が処理する他の~protocol要素の限度 ］を注意深く制限する~OUGHT。 それらの一部には、次も含まれる：［ `要請~method$, 応答~状態s句 【 `reason-phrase$p, `事由~句$ 】, `~header値$, 数的な値, 本体~chunk ］。 そのような処理における制限の失敗は、~buffer~overflowや算術的な桁溢れ, あるいは~DoS攻撃への脆弱性を高める結果になり得る。 ◎ Recipients ought to carefully limit the extent to which they process other protocol elements, including (but not limited to) request methods, response status phrases, header field-names, numeric values, and body chunks. Failure to limit such processing can result in buffer overflows, arithmetic overflows, or increased vulnerability to denial-of-service attacks.

9.4. 応答~分割

`応答~分割^dfn （いわゆる `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$における脆弱性（通例的に~app~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 ］は、［ ~app~serverにより読取られ, ~redirectの中で再利用される ］結果、同じ~parameterが応答の `Location$h ~header内に復唱され得る。 ~parameterが［ ~appにより復号され，応答~header内に置かれる ］ときに，適正に符号化されない下では、攻撃者は、［ 符号化-済みな `CRLF$P ~octetその他の内容 ］を送信して，~appの単独の応答を 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するものであるが、それは［ ~app~serverが~URIの復号しか遂行していない ］ことを前提にしている — より見え難い~data形式変換：［ ~charset符号変換, ~XML実体~翻訳, base64 復号, sprintf 再整形, 等々 ］は~~考慮されていない。 それより，［ ~serverの中核~protocol~library ］以外のどこであれ，［ `~header節$の中に `CR$P や `LF$P を送信する ］ことを防ぐ方が、効果的な軽減策になる — それは、~headerの出力を［ 不良~octetを~filterする~API ］に制約して，［ ~app~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.

9.5. 要請~密入

要請~密入（`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~frame法に関して，［ 要請の構文解析に課される新たな要件（`3.3.3$sec） ］を導入した。 ◎ This specification has introduced new requirements on request parsing, particularly with regard to message framing in Section 3.3.3, to reduce the effectiveness of request smuggling.

9.6. ~messageの完全性

~HTTPは、［［ ~messageの完全性を確保する ］ための特定の仕組み ］を定義しない。 代わりに［ 下層~transport~protocolの~error検出~能 ］, および［［ 完全かどうかを検出する ］ための［ 長さや, ~chunkで区切られる~frame法 ］の利用 ］に依拠する。 ［ ~hash関数や, 内容に適用される~digital署名 ］などの［ 完全性のための追加的な仕組み ］は、各種［ 拡張-可能な~metadata~header ］を介して，選択的に，~messageに追加できる。 歴史的に、［ 単一の，完全性の仕組み ］の欠如は，［ ほとんどの~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. Additional integrity mechanisms, such as hash functions or digital signatures applied to the content, can be selectively added to messages via extensible metadata header fields. 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.

`~UA$には、［ 完全性が必要な環境~下でも、環境設定により，~messageの完全性の失敗を検出して報告できる ］ようにする手段を実装することが奨励される。 例えば，［ 医療~履歴や薬剤相互作用についての情報 ］を視るために利用されている~browserは、［ そのような情報が転送の間に［ 不完全である／失効した／破損した ］ことが~protocolにより検出された ］ことを，利用者に指示できることが必要yである。 そのような仕組みは，［ ~UA拡張や, 応答に~message完全性~metadataが在ること ］を介して選択的に可能化できるであろう。 `~UA$は、そのような検証yが欲されるときは、最小限，［ 応答~messageは完全か`不完全$かを，利用者が判別できる ］ような，何らかの指示を供する~OUGHT。 ◎ User agents are encouraged to implement configurable means for detecting and reporting failures of message integrity such that those means can be enabled within environments for which integrity is necessary. 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. At a minimum, user agents ought to provide some indication that allows a user to distinguish between a complete and incomplete response message (Section 3.4) when such verification is desired.

9.7. ~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 different 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^p を利用できる。 ◎ The "https" scheme can be used to identify resources that require a confidential connection, as described in Section 2.7.2.

9.8. ~server~log情報の~privacy

`~server$は、［ 期間に渡る利用者の要請についての個人-~data ］を保存する立場にあり，［ 利用者の行動様式や関心事 ］も識別し得る。 特に，［ `中継者$に集められた~log情報 ］は、［ 不特定多数の~siteにまたがる，~UA との相互通信の履歴 ］を包含することが多く，個々の利用者を~traceし得る。 ◎ A server is in the position to save personal data about a user's requests over time, which might identify their reading patterns or subjects of interest. In particular, log information gathered at an intermediary often contains a history of user agent interaction, across a multitude of sites, that can be traced to individual users.

~HTTP~log情報は，その資質からして機密的なので、その取扱いは，法律や規制により拘束されることが多い。 ~log情報は、~secureに格納された上で，その分析に際しては適切な指針に従う必要がある。 ［ 個々の~entryの中の個人-情報の匿名化 ］も補助になるが、一般に，本物の~log~traceから［ 他の~access特性による相関 ］に基づいて再~識別されることを防ぐには十分でない。 そのようなわけで、［ 特定の`~client$に対し~keyされる~access~trace ］の流出は，~keyが疑似匿名であっても安全とは言えない。 ◎ HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within individual entries helps, but it is generally not sufficient to prevent real log traces from being re-identified based on correlation with other access characteristics. As such, access traces that are keyed to a specific client are unsafe to publish even if the key is pseudonymous.

盗聴や不用意な流出の~riskを最小限にするためには、個人識別可能な情報 — ［ 利用者~識別子, ~IP~address, 利用者が供した `query$p ~parameter ］なども含む — は，［ ~security／ auditing【監査】／ fraud control【不正行為の~~規制】 などの，運用~上の必要性を~supportする ］ことが必要yでなくなり次第，~log情報から一掃される~OUGHT。 ◎ To minimize the risk of theft or accidental publication, log information ought to be purged of personally identifiable information, including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary to support operational needs for security, auditing, or fraud control.

A.1. ~HTTP10からの変更点

この節では、［ ~HTTP10, ~HTTP11 ］`~version$間の~~主要な相違点を要約する。 ◎ This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.

A.2. RFC 2616 からの変更点

• ~HTTPによる~error取扱いの~approachが説明された。 （`2.5$sec） ◎ HTTP's approach to error handling has been explained. (Section 2.5)
• `HTTP-version$p ~ABNF生成規則は、文字大小区別であると明確化された。 加えて、`~version番号$は， 1 桁に制約された — いくつもの実装が，複数~桁による~version番号を不正に取扱う事実が既知なので。 （`2.6$sec） ◎ The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers have been restricted to single digits, due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (Section 2.6)
• `userinfo$p （すなわち， `username^p と `password^p ）は、~HTTP／~HTTPS ~URIには許容されなくされた — 伝送路~上のそれらの伝送に関係する ~securityの課題があるので。 （`2.7.1$sec） ◎ Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their transmission on the wire. (Section 2.7.1)
• ~HTTPS~URI~schemeは、今や，この仕様により定義される — 以前には， `2818-2.4$rfc にて定義されていた。 更には、`端点間$の~securityも含意する（`2.7.2$sec）。 ◎ The HTTPS URI scheme is now defined by this specification; previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it implies end-to-end security. (Section 2.7.2)
• ~HTTP~messageは、実装により~bufferし得る／されることも多く，~streamとして可用にされることもあるが、 ~HTTPは，根本的に~message指向な~protocolである。 相互運用能を向上するため、様々な~protocol要素に対し，~supportされる最小~sizeが示唆されている。 （`3$sec） ◎ HTTP messages can be (and often are) buffered by implementations; despite it sometimes being available as a stream, HTTP is fundamentally a message-oriented protocol. Minimum supported sizes for various protocol elements have been suggested, to improve interoperability. (Section 3)
• ［ `field-name$p の前後の妥当でない空白 ］は、今や，却下されることが要求される。 それを受容することは、~securityの脆弱性を表現するので。 `~header$を定義している ~ABNF生成規則は、今や，`~header値$を~listするのみである。 （`3.2$sec） ◎ Invalid whitespace around field-names is now required to be rejected, because accepting it represents a security vulnerability. The ABNF productions defining header fields now only list the field value. (Section 3.2)
• ［ ある種の文法~生成規則の合間の暗黙的な空白列 ］についての規則は、除去された — 今や，`空白$は、~ABNF内で特に定義されている所でのみ許容される。 （`3.2.3$sec） ◎ Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed where specifically defined in the ABNF. (Section 3.2.3)
• 複数~行lに~~渡る（“行l折返し”）~headerは、非推奨にされた。 （`3.2.4$sec） ◎ Header fields that span multiple lines ("line folding") are deprecated. (Section 3.2.4)

• ［ `comment$p ／ `quoted-string$p ］~text内では、 `NUL^P ~octetは もはや許容されず，~backslash~escapeの取扱いが明確化された。 `HTAB$P 以外の制御~文字の~escapingに対する `quoted-pair$p 規則は、 もはや許容されない。 ［ ~header†／`事由~句$ ］内の非~US-ASCII内容は、廃用にされ，不透明にされた（ `TEXT^t 規則は除去された）。 （`3.2.6$sec）

  【† `4779$errataによる~~修正あり（ Held for Document Update: 2016-10-07 ）： “~header” → “~header値” 】

  ◎ The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been clarified. The quoted-pair rule no longer allows escaping control characters other than HTAB. Non-US-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (Section 3.2.6)
• ［ 不法な `Content-Length$h ~header ］は、今や，受信者により，~errorとして取扱われることが要求される。 （`3.3.2$sec） ◎ Bogus Content-Length header fields are now required to be handled as errors by recipients. (Section 3.3.2)
• ［ `~message本体~長さ$を決定するための~algo ］は、［ それが影響する，すべての特別~事例（例： ~methodや`状態s~code$により駆動されるもの） ］を指示し、［ 新たな~protocol要素は，そのような特別~事例を定義できない ］ことが、明確化された。 `CONNECT$m は、~message本体~長さを決定する際の，新たな特別~事例になる。 "`multipart/byteranges^c" は、 もはや，~message本体~長さを決定する検出-法にならない。 （`3.3.3$sec） ◎ The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven by methods or status codes) that affect it, and that new protocol elements cannot define such special cases. CONNECT is a new, special case in determining message body length. "multipart/byteranges" is no longer a way of determining message body length detection. (Section 3.3.3)
• "`identity^c" `転送~符号法$ ~tokenは、除去された。 （`3.3$sec, `4$sec） ◎ The "identity" transfer coding token has been removed. (Sections 3.3 and 4)
• ~chunk長さは、［ ~chunk~headerと`~trailer節$ ］内の~octet数を含まない。 `~chunk拡張$における行l折返しは、許容されない。 （`4.1$sec） ◎ Chunk length does not include the count of the octets in the chunk header and trailer. Line folding in chunk extensions is disallowed. (Section 4.1)
• "`deflate$c" 内容~符号法の意味が，明確化された。 （`4.2.2$sec） ◎ The meaning of the "deflate" content coding has been clarified. (Section 4.2.2)
• `request-target$p を定義するためとして， RFC 1808 による `abs_path^c に代わって， RFC 3986 の `segment$p ＆ `query$p 成分が利用された。 `asterisk-form$p による `request-target$p は， `OPTIONS$m ~methodでのみ許容される。 （`5.3$sec） ◎ The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808. The asterisk-form of the request-target is only allowed with the OPTIONS method. (Section 5.3)
• 用語 “`実効~要請~URI$” が導入された。 （`5.5$sec） ◎ The term "Effective Request URI" has been introduced. (Section 5.5)
• `~gateway$は、もう `Via$h ~headerを`生成する$必要はなくなった。 （`5.7.1$sec） ◎ Gateways do not need to generate Via header fields anymore. (Section 5.7.1)
• 正確にいつ，`~close_接続~option$を送信する必要があるのかが、明確化された。 また、 `Connection$h ~header内には，`隣点間~header$のみが出現することが要求される — この仕様にて`隣点間~header$として定義されたからといって，それが免除される 【それらの~header名を `Connection^h ~header内では省略できる】 わけではない。 （`6.1$sec） ◎ Exactly when "close" connection options have to be sent has been clarified. Also, "hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop in this specification doesn't exempt them. (Section 6.1)
• 接続~数を`~server$あたり 2 個までにしていた制限は、除去された。 `冪等$な一連の要請を再試行することは、 もはや，要求されない。 ~serverが尚早に接続を~closeするような ある種の状況下で，要請を再試行する要件は、除去された。 また、［ ~serverが接続を尚早に~closeすることが，いつ許容されるか ］についての，一部の~~余計な要件は、除去された。 （`6.3$sec） ◎ The limit of two connections per server has been removed. An idempotent sequence of requests is no longer required to be retried. The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. Also, some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (Section 6.3)
• `Upgrade$h ~headerの意味論は、今や，どの応答にも — `101$st でない応答にも — 定義される（これは `2817$R を組入れている）。 更には、`~header値$の順序は，今や有意である。 （`6.7$sec） ◎ The semantics of the Upgrade header field is now defined in responses other than 101 (this was incorporated from [RFC2817]). Furthermore, the ordering in the field value is now significant. (Section 6.7)
• ~list生成規則~内の空~list要素（例： "`, ,^c" を包含している~list~header）は、非推奨にされた。 （`7$sec） ◎ Empty list elements in list productions (e.g., a list header field containing ", ,") have been deprecated. (Section 7)
• `転送~符号法$の登録は、今や，`~IETFによる考査$を要する。 （`8.4$sec） ◎ Registration of Transfer Codings now requires IETF Review (Section 8.4)
• 以前に `2817-7.2$rfc にて定義されていた Upgrade Token Registry は、今や，この仕様が定義する。 （`8.6$sec） ◎ This specification now defines the Upgrade Token Registry, previously defined in Section 7.2 of [RFC2817]. (Section 8.6)
• ~HTTP09要請を~supportする期待は除去された。 （ `付録 A＠#appendix-A$ ） ◎ The expectation to support HTTP/0.9 requests has been removed. (Appendix A)
• 要請における `Keep-Alive$h および `Proxy-Connection^h ~headerについての課題, および，後者は全く利用しないことが奨励されることを指摘。 （ `付録 A.1.2＠#appendix-A.1.2$ ） ◎ Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged altogether. (Appendix A.1.2)