HTTP 意味論（共通基盤）

1.1. 目的

~HTTP（ `Hypertext Transfer Protocol^en ）は、 `~stateless$な応用~levelの［ 要請／応答 ］~protocolたちが成す族である — それらは、［ ~networkに基づく，~hypertext情報~system ］と柔軟にヤリトリするために［ 汎用な~interface, 拡張-可能な意味論, `自己-記述的$な~message ］を共有する。 ◎ The Hypertext Transfer Protocol (HTTP) is a family of stateless, application-level, request/response protocols that share a generic interface, extensible semantics, and self-descriptive messages to enable flexible interaction with network-based hypertext information systems.

~HTTPは、 `~client$向けに［ 供される`資源$の型に依存しない，統一的な~interface ］を呈示することにより，~serviceがどう実装されるかについての詳細を隠す。 同様に、 `~server$も，各~clientの目的について自覚する必要はない — 要請は、［ 特定の型の~client／予め決定された手続きを適用すること ］に結付けられずに，他から隔離して考慮できる。 このことは、 次を許容する ⇒＃ 多くの異なる文脈で一般用~実装を効果的に利用する／ 相互作用による複階性を抑制する／ 時と伴に独立な発展を可能化する ◎ HTTP hides the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do not need to be aware of each client's purpose: a request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. This allows＼ general-purpose implementations to be used effectively in many different contexts,＼ reduces interaction complexity,＼ and enables independent evolution over time.

~HTTPはまた、 中間~protocolとしての利用-用にも設計されている — `~proxy$や`~gateway$が，非~HTTP情報~systemを より汎用な~interfaceの中へ翻訳できるような。 ◎ HTTP is also designed for use as an intermediation protocol, wherein proxies and gateways can translate non-HTTP information systems into a more generic interface.

1.2. 歴史と発展

~HTTPは、 1990 年の導入~以来， World Wide Web 用の首な情報~転送~protocolであり続けている。 それは、［ 所与の~pathnameで識別され，予め~hypertext文書と見做される資源 ］の転送を要請するために， 単独の~method（ `GET$m ）を伴う低-待時間な要請~用の些細な仕組みとして始まった。 ~Webが成長する伴い、 ~HTTPは次を行えるよう拡張され， 最終的には~HTTP09, ~HTTP10として定義された （ `HTTP/1.0$r を見よ） ⇒＃ ~messageの中に要請や応答を封入する／ ~MIMEの様な~media型【`~MIME型$】を利用して，任意な~data形式を転送する／ `媒介者$を通して要請を~routeする ◎ HTTP has been the primary information transfer protocol for the World Wide Web since its introduction in 1990. It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname. As the Web grew, HTTP was extended to＼ enclose requests and responses within messages,＼ transfer arbitrary data formats using MIME-like media types,＼ and route requests through intermediaries.＼ These protocols were eventually defined as HTTP/0.9 and HTTP/1.0 (see [HTTP/1.0]).

~HTTP11は、 既存の［ ~textに基づく~message法~構文 ］との互換性は維持しながら，~protocolの各種~特能を精緻化して、 ~Internetにまたがる その［ 相互運用能, ~scale能, 堅牢性 ］を改善するべく設計された。 これには、 次に挙げるものが含められた： ◎ HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging syntax, improving its interoperability, scalability, and robustness across the Internet. This included＼

• ［ 固定的な／（~chunkedによる）動的な ］`内容$用の長さに基づく~data区切子 ◎ length-based data delimiters for both fixed and dynamic (chunked) content,＼
• `内容~折衝$用の一貫した~framework ◎ a consistent framework for content negotiation,＼
• `条件付き要請$~用の不透明な`検証子$ ◎ opaque validators for conditional requests,＼
• ~cacheの一貫性をより良くするための~cache制御 ◎ cache controls for better cache consistency,＼
• 部分的な更新~用の`範囲~要請$ ◎ range requests for partial updates,＼
• 既定の持続的な接続 ◎ and default persistent connections.＼

~HTTP11は、 1995 年に導入された — それは ⇒＃ 1997 年には `Standards Track^en にて `RFC2068$r として公表され, 1999 年には `RFC2616$r に改訂され, 2014 年には `RFC7230$r 〜 `RFC7235$r に再び改訂された ◎ HTTP/1.1 was introduced in 1995 and published on the Standards Track in 1997 [RFC2068], revised in 1999 [RFC2616], and revised again in 2014 ([RFC7230] through [RFC7235]).

~HTTP2（ `HTTP/2$r ）は、 複数の~HTTP~messageを同時並行に交換するため，既存の［ ~TLS, ~TCP ］~protocolの上層に多重化された~session層を導入した — 効率的な~field圧縮と~server~pushも伴って。 ~HTTP3（ `HTTP/3$r ）は、 ~QUICを［ ~TCP越しに代えて，~UDP越しの~secureな多重化された~transport ］として利用することにより，同時並行な~message用に より高い独立性を供する。 ◎ HTTP/2 ([HTTP/2]) introduced a multiplexed session layer on top of the existing TLS and TCP protocols for exchanging concurrent HTTP messages with efficient field compression and server push. HTTP/3 ([HTTP/3]) provides greater independence for concurrent messages by using QUIC as a secure multiplexed transport over UDP instead of TCP.

これら~HTTPの 3 つの`~major~version$は、 この文書に定義される意味論に依拠する。 それらは、 互いに他を廃用にすることはない — それぞれには、 利用される文脈に依存して，特有な便益や制限があるので。 実装には、 自身の特定0の文脈~用に最も適切な［ ~transport, ~message法~構文 ］を選ぶことが期待される。 ◎ All three major versions of HTTP rely on the semantics defined by this document. They have not obsoleted each other because each one has specific benefits and limitations depending on the context of use. Implementations are expected to choose the most appropriate transport and messaging syntax for their particular context.

~HTTPのこの改訂は、 現在の~HTTP11の~message法~構文（ `HTTP/1.1$r ）から［ 意味論の定義（この文書）と~cache法（ `CACHING$r ） ］を分離して，~majorな各~protocol~versionが［ 同じ中核~意味論を参照rしながら，独立に進展する ］ことを許容する。 ◎ This revision of HTTP separates the definition of semantics (this document) and caching ([CACHING]) from the current HTTP/1.1 messaging syntax ([HTTP/1.1]) to allow each major protocol version to progress independently while referring to the same core semantics.

1.3. 中核~意味論

~HTTPは、 `資源$とヤリトリするための統一的な~interfaceを — 資源の［ 型, 資質, 実装 ］を問わず — 当の資源の`表現$を［ 操作する／転送する ］~messageを送信することにより供する。 ◎ HTTP provides a uniform interface for interacting with a resource (Section 3.1) -- regardless of its type, nature, or implementation -- by sending messages that manipulate or transfer representations (Section 3.2).

1.4. この文書により廃用にされる仕様

この文書により廃用にされる仕様は （括弧内に挙げる変更点も見よ） ⇒＃ `HTTP Over TLS^cite `RFC2818$r（ `B.1§ ）, `HTTP/1.1 Message Syntax and Routing^cite `RFC7230$r（ `B.2§ ）~FN, `HTTP/1.1 Semantics and Content^cite `RFC7231$r（ `B.3§ ）, `HTTP/1.1 Conditional Requests^cite `RFC7232$r（ `B.4§ ）, `HTTP/1.1 Range Requests^cite `RFC7233$r（ `B.5§ ）, `HTTP/1.1 Authentication^cite `RFC7235$r（ `B.6§ ）, `HTTP Status Code 308 (Permanent Redirect)^cite `RFC7538$r（ `B.7§ ）, `HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields^cite `RFC7615$r（ `B.8§ ）, `HTTP Client-Initiated Content-Encoding^cite `RFC7694$r（ `B.9§ ）, ◎ Table 1 Title Reference See HTTP Over TLS｜[RFC2818]｜B.1 HTTP/1.1 Message Syntax and Routing [*]｜[RFC7230]｜B.2 HTTP/1.1 Semantics and Content｜[RFC7231]｜B.3 HTTP/1.1 Conditional Requests｜[RFC7232]｜B.4 HTTP/1.1 Range Requests｜[RFC7233]｜B.5 HTTP/1.1 Authentication｜[RFC7235]｜B.6 HTTP Status Code 308 (Permanent Redirect)｜[RFC7538]｜B.7 HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields｜[RFC7615]｜B.8 HTTP Client-Initiated Content-Encoding｜[RFC7694]｜B.9

~FN この文書が廃用にするのは、 `RFC7230$r を成す，~HTTP11の［ ~message法~構文／接続~管理 ］に依存しない部位に限られる。 `RFC7230$r を成す他の部分は、 `HTTP/1.1$r により廃用にされた。 ◎ [*] This document only obsoletes the portions of RFC 7230 that are independent of the HTTP/1.1 messaging syntax and connection management; the remaining bits of RFC 7230 are obsoleted by "HTTP/1.1" [HTTP/1.1].

2.1. 構文の表記法

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

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

`5.6§ にて、 `~field値$用の汎用な構文-成分をいくつか定義する。 ◎ Section 5.6 defines some generic syntactic components for field values. ◎ This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in [RFC6365].

2.2. 要件の表記法

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

この仕様は、 ~HTTP通信における参加者の `役割@ （ `role^en ） に則って，適合性の判定基準を~~適用する。 よって，要件は、 それにより拘束される挙動に依存して，次に挙げる`役割$に設置される ⇒＃ `送信者$, `受信者$, `~client$, `~server$, `~UA$, `媒介者$, `生成元~server$, `~proxy$, `~gateway$, `~cache$ ◎ This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, or caches, depending on what behavior is being constrained by the requirement.＼

また，［ 単独の通信の視野を超えて適用される ］ときには、 追加的な要件が，［ 実装／資源~所有者／~protocol要素~登録 ］に設置されることもある。 ◎ Additional 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 applies only to implementations that create the protocol element, rather than an implementation that forwards 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.

`送信者$は、［ 対応する~ABNF規則により定義される文法に合致しない~protocol要素 ］を`生成-$してはナラナイ。 `送信者$は、 ~messageの中に［ 他の`役割$（すなわち，当の~messageに対し送信者が受け持たない`役割$）を受け持つ参加者にしか`生成-$することが許容されていない［ ~protocol要素／構文~代替 ］］を`生成-$してはナラナイ。 ◎ A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules.＼ Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message).

~HTTPへの適合性は、［ 利用-中にある`~protocol~version$の特定0の~message法~構文への適合性 ］, ［ 送信される~protocol要素の意味論への適合性 ］どちらも含む。 例えば，~HTTP11への適合性を主張する`~client$は、［ ~HTTP11受信者に要求される特能を認識する ］ことに失敗した場合，［ そのような主張に則って自身の応答を調整する`~server$と相互運用する ］ことに失敗することになる。 利用者の選択を反映する特能 — `内容~折衝$や利用者が選定した拡張など — は、［ ~protocol~streamを超える，応用の挙動 ］に影響iし得る。 利用者の選択を正確aに反映しない~protocol要素を送信すると、［ 利用者を惑わす／選択を妨げる ］ことになる。 ◎ Conformance to HTTP includes both conformance to the particular messaging syntax of the protocol version in use and conformance to the semantics of protocol elements sent. For example, a client that claims conformance to HTTP/1.1 but fails to recognize the features required of HTTP/1.1 recipients will fail to interoperate with servers that adjust their responses in accordance with those claims. Features that reflect user choices, such as content negotiation and user-selected extensions, can impact application behavior beyond the protocol stream; sending protocol elements that inaccurately reflect a user's choices will confuse the user and inhibit choice.

ある実装が意味論上の適合性に失敗するとき、 その実装の~messageの受信者たちは，ゆくゆくは［ それに則って，自身の挙動を調整するような対処法 ］を開発することになる。 `受信者$は、 そのような対処法を — 該当する実装に制限する, かつ この~protocolの他の適合性に反しない限り — 使役してもヨイ。 例えば，［ `~server$／`~UA$ ］は、［ 既知な~bugや拙く選ばれた既定に関して，自前の挙動を調整する ］ために［ `User-Agent$h ／ `Server$h ］`~field値$の~~各部を走査することが多い。 ◎ When an implementation fails semantic conformance, recipients of that implementation's messages will eventually develop workarounds to adjust their behavior accordingly. A recipient MAY employ such workarounds while remaining conformant to this protocol if the workarounds are limited to the implementations at fault. For example, servers often scan portions of the User-Agent field value, and user agents often scan the Server field value, to adjust their own behavior with respect to known bugs or poorly chosen defaults.

2.3. 長さ要件

`受信者$は、 受信した~protocol要素を防御的に — すなわち，当の要素が［ ~ABNF文法に適合する, かつ 適度な~buffer~sizeの中に収まる ］こと以外は期待しない下で — 構文解析するベキである。 ◎ A recipient SHOULD parse a received protocol element defensively, with only marginal expectations that the element will conform to its ABNF grammar and fit within a reasonable buffer size.

~HTTPにおける多くの~protocol要素は，特定の長さ制限を設けていない — 何故なら，［ 適切になるであろう長さ ］は、 実装の［ 配備~文脈や目的 ］に依存して，~~多岐に~~渡るので。 よって，［ `送信者$と`受信者$との間の相互運用能 ］は、［ 各種~protocol要素に見合う長さに関して，共有されている期待 ］に依存する。 更には，一部の~protocol要素に対しては、［ 何が，それに見合う長さになるものと共通して理解されているか ］は，過去 30 年にわたる~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 three decades of HTTP use and is expected to continue changing in the future.

`受信者$は、 最小でも［［ 他の~message内の同じ~protocol要素 ］に対し，自身が`生成-$し得る値の長さ ］以上の長さの~protocol要素を，構文解析して処理できなければナラナイ。 例えば，`生成元~server$は、［ 自前の`資源$に対し，~~長大な`~URI参照$を公表する ］ならば，［ `~target~URI$として受信した，同じ参照 ］を構文解析して処理できる必要がある。 ◎ 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 target URI.

受信される多くの~protocol要素は、 それを識別して`下流$へ回送するために必要yな所までに限り，構文解析される。 例えば，`媒介者$は、 受信した各`~field$を［ `~field名$, `~field値$ ］成分までは構文解析しつつ，`~field値$の内側までは構文解析することなく回送することもある。 ◎ Many received protocol elements are only parsed to the extent necessary to identify and forward that element downstream. For example, an intermediary might parse a received field into its field name and field value components, but then forward the field without further parsing inside the field value.

2.4. ~errorの取扱い

`受信者$は、 受信した~protocol要素を［ この仕様がそれ用に定義する意味論 ］に則って解釈しなければナラナイ — この仕様に対する拡張【による~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の応用ごとに異なり得るので。 例えば、 ~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.

一部の要請は、 下層の接続が失敗した所で，~clientにより自動的に再試行され得る — `冪等~method§にて述べられるとおり。 ◎ Some requests can be automatically retried by a client in the event of an underlying connection failure, as described in Section 9.2.2.

2.5. ~protocol~version

~HTTPの中核を成す意味論は，［ ~protocol~version間で変化しないが， それらが “伝送路~上” でどう表出されるかは変化し得る ］ので、 伝送路~形式に対し互換でない変更が為されたときには，~HTTP~version番号は変化する。 加えて，~HTTPは、 定義-済みな拡張~地点（ `16§ ）の利用を通して， ~protocolに対し［ ~versionを変更することなく，増分的に後方-互換な変更を為す ］ことを許容する。 ◎ While HTTP's core semantics don't change between protocol versions, their expression "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire format. Additionally, HTTP allows incremental, backwards-compatible changes to be made to the protocol without changing its version through the use of defined extension points (Section 16).

~protocol~versionは、 それ一体【`~major~version$, `~minor~version$が成す組み】として，［［ その~versionに対応する各~仕様 ］にて挙げられた要件たちが成す集合に，`送信者$が適合している ］ことを指示する。 例えば，~version "`HTTP/1.1^c" は、［ この文書, `CACHING$r, `HTTP/1.1$r ］を組合せた仕様により定義される。 ◎ The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's corresponding specification(s). For example, the version "HTTP/1.1" is defined by the combined specifications of this document, "HTTP Caching" [CACHING], and "HTTP/1.1" [HTTP/1.1].

`~major~version$番号は、［ 互換でない~message構文が導入される場合 ］に増やされる。 `~minor~version$番号は、［ ~protocolに為された変更により［ ~message意味論が追加される／`送信者$に追加的な能力が含意される ］場合 ］に増やされる。 ◎ HTTP's major version number is incremented when an incompatible message syntax is introduced. The minor number is incremented when changes made to the protocol have the effect of adding to the message semantics or implying additional capabilities of the sender.

`~minor~version$は、 `送信者$が まだ［ 当の~protocolを成す後方-互換な下位集合 ］しか利用していないときでも，送信者の通信~能力を広告する — それにより、［［ （`~server$による）応答／（`~client$による）未来の要請 ］において，より先進的な特能も利用できる ］ことを受信者に知らせる。 ◎ The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients).

~HTTPの`~major~version$が`~minor~version$を定義しない場合、 その暗黙な`~minor~version$は， "`0^c" とする。 "`0^c" は、［ ~minor~version識別子が要求される~protocol要素 ］の中で，そのような~protocolを参照rするために利用される。 ◎ When a major version of HTTP does not define any minor versions, the minor version "0" is implied. The "0" is used when referring to that protocol within elements that require a minor version identifier.

3.1. 資源

~HTTP要請の~targetは、 `資源@ （ `resource^en ）と呼ばれる。 ~HTTPは、 資源の資質を制限しない — 単に，資源とヤリトリするために利用できる~interfaceを定義するに過ぎない。 ほとんどの資源は、 `~URI$により識別される。 ◎ The target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Most resources are identified by a Uniform Resource Identifier (URI), as described in Section 4.

~HTTPの設計~目標の一つは、 `資源$の識別を要請の意味論から分離することである — それは、 要請の意味論を［ `要請~method$, および 要請を改変する少数の要請~header ］に~~帰属させることにより，アリになる。 資源は、 要請を その~methodの意味論と整合でない方式で扱うことはできない。 例えば，資源の`~URI$が安全でない意味論を含意していたとしても、 `~client$は，［ 当の資源に対し，`安全$な~methodを伴う要請が処理されるときは、 安全でない動作は避けられる ］ものと期待できる（ `9.2.1§ 【の最後の段落】を見よ） ◎ One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (Section 9) and a few request-modifying header fields. A resource cannot treat a request in a manner inconsistent with the semantics of the method of the request. For example, though the URI of a resource might imply semantics that are not safe, a client can expect the resource to avoid actions that are unsafe when processing a request with a safe method (see Section 9.2.1).

~HTTPは、［ `~target資源$, 資源~間の関係性 ］を指示するために， ~URI標準 `URI$r に依拠する。 ◎ HTTP relies upon the Uniform Resource Identifier (URI) standard [URI] to indicate the target resource (Section 7.1) and relationships between resources.

3.2. 表現

`表現@ （ `representation^en ）とは、［ 所与の`資源$の［ 過去の／現在の／欲される ］状態を反映する ］よう意図された［ ~protocolを介して通信するに~~適した形式 ］による情報である。 各`表現$は、 次の 2 つからなる ⇒＃ `表現~metadata$たちが成す集合, `表現~data$を成す~stream（際限なく続くものにもなり得る） ◎ A "representation" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol. A representation consists of a set of representation metadata and a potentially unbounded stream of representation data (Section 8).

~HTTPは、 統一的な~interfaceの背後に “情報を隠す” ことを許容する — `資源$自体を転送するのではなく，通信を［ 当の資源の状態を成す転送-可能な表現 ］に関するよう定義することにより。 これは、［ どんなものでも，~URIにより識別される資源になり得る ］ことを許容する — “富士山における現在の天気” の様な，［ ~messageが`生成-$された時点に，その資源を表現する情報 ］を供する時間的な関数も含めて。 `REST$r ◎ HTTP allows "information hiding" behind its uniform interface by defining communication with respect to a transferable representation of the resource state, rather than transferring the resource itself. This allows the resource identified by a URI to be anything, including temporal functions like "the current weather in Laguna Beach", while potentially providing information that represents that resource at the time a message is generated [REST].

統一的な~interfaceは、 窓のようなものである — ［ その窓の向こう側で独立に動作する者 ］と~messageを通信することを通してのみ， 何かモノを観測して, 動作できるような。 通信において［ 現在の状態【すなわち，`応答$】, 欲される状態【すなわち，`要請$】 ］を表現する（ “その場を占める” ）ためには、 共有される抽象-化が必要になる。 表現が~hypertextであるならば、 それは，［ 資源~状態を成す表現, 未来における受信者とのヤリトリを手引きするような処理命令 ］どちらも供し得る。 ◎ The uniform interface is similar to a window through which one can observe and act upon a thing only through the communication of messages to an independent actor on the other side. A shared abstraction is needed to represent ("take the place of") the current or desired state of that thing in our communications. When a representation is hypertext, it can provide both a representation of the resource state and processing instructions that help guide the recipient's future interactions.

`~target資源$は、 複数の表現 — それぞれが，当の`資源$の現在の状態を反映するよう意図されたそれら — を［ 伴って供される／`生成-$する能力を有する ］こともある。 それらの表現のうち，所与の要請に最も適用-可能な一つを選定するため、 ある~algoが利用される — 通例的に，`内容~折衝$に基づくような。 そのように一つに `選定された表現@ （ `selected representation^en ）が、 次を行うための［ ~data, ~metadata ］を供するために利用される： ◎ A target resource might be provided with, or be capable of generating, multiple representations that are each intended to reflect the resource's current state. An algorithm, usually based on content negotiation (Section 12), would be used to select one of those representations as being most applicable to a given request. This "selected representation" provides the data and metadata for＼

• `条件付き要請$を評価する ◎ evaluating conditional requests (Section 13) and＼
• `GET$m に対する［ `200$st ／ `206$st ／ `304$st ］応答の`内容$を構築する ◎ constructing the content for 200 (OK), 206 (Partial Content), and 304 (Not Modified) responses to GET (Section 9.3.1).

3.3. 接続, ~client, ~server

~HTTPは、 依拠-可能な［ ~transport層または~session層 ］の `接続@ （ `connection^en ）越しに運用される［ `~client$／`~server$ ］~protocolである。 ◎ HTTP is a client/server protocol that operates over a reliable transport- or session-layer "connection".

~HTTP `~client@ （ `client^en ）とは、 1 個~以上の~HTTP要請を送信する目的で，`~server$への接続を確立する~programである。 ◎ An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests.＼

~HTTP `~server@ （ `server^en ）とは、 ~HTTP要請に対し，その接続を受容し、 `~client$への~serviceとして，~HTTP応答を送信する~programである。 ◎ An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.

用語［ `~client$／`~server$ ］が指すのは、［ 特定0の接続~用に，これらの~programが遂行する`役割$ ］に限られる。 同じ~programが、 ある接続~上では~clientになると~~同時に， 他の接続~上では~serverとして動作し得る。 ◎ The terms client and server refer only to the roles that these programs perform for a particular connection. The same program might act as a client on some connections and a server on others.

【 接続は、 ~messageの経路~全体（接続の`連鎖$）ではなく， 隣接する ある 2 つの参加者（連鎖に属する~node）間の接続を指すことに注意 （個々の参加者から直に見えるのは，隣の参加者だけなので）。 】

~HTTPは、 `~stateless@ （ `stateless^en ）な~protocolとして定義されている — すなわち、［ 各`要請~message$の意味論は，互いに隔離されても解せる【`自己-記述的$である】 ］かつ［ 各~接続と接続~上の各~messageとの関係性は、 ~messageの解釈には影響iしない ］ことを意味する。 例えば，［ `CONNECT$m 要請, `Upgrade$h ~headerを伴う要請 ］どちらも、 接続~上の最初の~messageに限らず，いつでも生じ得る。 多くの実装は、［ ~proxyされた接続を再利用する／ 複数の~serverにまたがって，要請たちを動的に負荷分散する ］ときに，［ ~HTTPの~statelessな設計 ］に依存する。 ◎ HTTP is defined as a stateless protocol, meaning that each request message's semantics can be understood in isolation, and that the relationship between connections and messages on them has no impact on the interpretation of those messages. For example, a CONNECT request (Section 9.3.6) or a request with the Upgrade header field (Section 7.8) can occur at any time, not just in the first message on a connection. Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers.

よって，`~server$は、［ 同じ接続~上の 2 つの要請 ］を同じ`~UA$から来たものと見做してはナラナイ — その接続が［ `~secure化$されていて，その~UAに特有である ］場合を除き。 一部の非~標準な~HTTP拡張（例： `RFC4559$r）は、 この要件に違反していることが既知であり， ~security, および相互運用能の問題を起こす。 ◎ As a result, 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.

3.4. ~message

~HTTPは、 接続にまたがって `~message$ を交換するための，`~stateless$な［ 要請, 応答 ］~protocolである。 ◎ HTTP is a stateless request/response protocol for exchanging "messages" across a connection.＼

用語［ `送信者@ （ `sender^en ）／ `受信者@ （ `recipient^en ） ］は、 所与の~messageを［ 送信する／受信する ］任意の実装を指す。 ◎ The terms "sender" and "recipient" refer to any implementation that sends or receives a given message, respectively.

3.5. ~UA

用語 `~UA@ （ `user agent^en ）は、［ 要請を起動する任意の`~client$~program ］を指す ◎ The term "user agent" refers to any of the various client programs that initiate a request.

最も馴染みな~UAは，一般用~Web~browserであるが、 そのような形をとる実装は，一握りに限られる。 共通的な~UAには、 他にも次に挙げるものがある ⇒＃ ~spider（~webを辿っている~robot）, ~command-line~tool, 広告塔, 家電, 計測機器, 電球, ~firmware更新~script, ~mobile~app, ~sizeや形状が様々な通信~機器, ◎ The most familiar form of user agent is the general-purpose Web browser, but that's only a small percentage of implementations. Other common user agents include spiders (web-traversing robots), command-line tools, billboard screens, household appliances, scales, light bulbs, firmware update scripts, mobile apps, and communication devices in a multitude of shapes and sizes.

~UAであることは、 要請の時点に［ ~software~agentと直にヤリトリしているヒト利用者が居る ］ことを含意するわけではない。 多くの事例で、 ~UAは~backgroundにて稼働するよう［ ~installされて／環境設定されて ］いて，その結果を （あるいは、 その中の［ 関心がある部分や誤りがありそうな部分 ］に限り） 今後の検分~用に保存する。 例えば，~spiderは、 概して，［ 所与の~URIから開始して、 ~Webを~hypertext~graphとして巡る間，一定の挙動に従う ］よう環境設定される。 ◎ Being a 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.

多くの~UAは、［ 利用者に向けて何かをヤリトリありに示唆する／ ~securityや~privacyに関する懸念のために必要十分な警告を供する ］ことはできないか，それをしないことを選ぶ。 この仕様が［ 利用者~向けに~errorを報告する ］ことを要求する，少数の事例では、 そのような報告が［ ~error~consoleや~log~fileに限り，観測-可能になる ］ことも受容-可能である。 同様に，自動化された動作についても、［ 続行する前に利用者による確認を要する ］ような要件は，［ ~~事前の環境設定の選択, 稼働時~option, 安全でない動作に対する単純な回避法 ］などを介して~~満たされ得る — 確認は、 利用者がすでにその選択を済ませていた場合には，いかなる［ 特定の利用者~interface／通常~処理の中断 ］も含意しない。 ◎ Many user agents cannot, or choose not to, 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.

3.6. 生成元~server

用語 `生成元~server@ （ `origin server^en ）は、［ 所与の`~target資源$に対する`権限的な応答$ ］を出生できる~programを指す。 ◎ The term "origin server" refers to a program that can originate authoritative responses for a given target resource.

最も馴染みな生成元~serverは、 巨大な公共~web~siteの形をとる。 ~UAが~browserと等しくみなされがちなのと同様、 すべての生成元~serverは，そのような~siteである考えに囚われがちだが、 生成元~serverには，次に挙げるものも共通的にある ⇒＃ 住宅用自動化設備, 環境設定-可能な~network用~component, 事務機械, 自律的な~robot, ~news-feed, 交通camera, ~real-time広告選定器, 動画配信~platform ◎ The most familiar form of origin server are large public websites. However, like user agents being equated with browsers, it is easy to be misled into thinking that all origin servers are alike. Common origin servers also include home automation units, configurable networking components, office machines, autonomous robots, news feeds, traffic cameras, real-time ad selectors, and video-on-demand platforms.

ほとんどの~HTTP通信は、［ `~URI$により識別される何らかの`資源$ ］の`表現$に対する，検索取得 要請（ `GET$m ）からなる。 最も単純な事例では、 これは，［ `~UA$（ %UA ）と`生成元~server$（ %O ）の間の，単独の双方向-接続（ `===^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 ======================================= %O
                              <   応答

3.7. 媒介者

~HTTPは、 要請が接続の `連鎖@ （ `chain^en ）を通り抜けられるようにするため， `媒介者@ （ `intermediary^en ）の利用も可能化する。 ~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 =========== %A =========== %B =========== %C =========== %O
             <             <             <             <

用語 `上流@ （ `upstream^en ）／ `下流@ （ `downstream^en ）は、［ ~messageが流れる方向 ］に関係して，要件を述べるときに利用される — すべての~messageは、 上流から下流へ流れる。 用語 `内方@ （ `inbound^en ）／ `外方@ （ `outbound^en ）は、［ 要請が~routeされる方向 ］に関係して，要件を述べるときに利用される — 内方は “`生成元~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", whereas outbound means "toward the user agent".

【 ~messageが応答ならば［ 上流／下流 ］は［ 内方／外方 ］と同義になり、 要請ならば，その逆になる。 】

`~proxy@ （ `proxy^en ）は、［ 何らかの型の絶対~URIへ向けた要請を受信したときには、［ ~HTTP~interfaceを通した翻訳 ］を介して，その要請を満足しようと試みる ］ような，~message回送~agentであり、 通例的に，`~client$により — ~clientの局所的な環境設定~規則を介して — 選ばれる。 翻訳には、［ "`http$c" ~URIへ向けた~proxy要請のような必要最小限なもの ］もある一方，［ 全面的に異なる［ 応用~levelの~protocol ］への／からの翻訳を要する要請 ］もあり得る。 `~proxy$は、［ ~security~service／注釈~service~FN／共用~caching ］の~~目的で，［ ある組織の~HTTP要請たちを共通な`媒介者$を通して~group化する ］ために利用されることが多い。 一部の`~proxy$は、 ~messageを回送する際に，選定された［ ~message／`内容$ ］に`形式変換$を適用するよう設計されている。 ◎ A "proxy" is a message-forwarding agent that is chosen 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 services, annotation services, or shared caching. Some proxies are designed to apply transformations to selected messages or content while they are being forwarded, as described in Section 7.7.

【 語 “~proxy” は、 以下に述べる他種の~proxyも含めた総称として利用されることもあり，多義性を孕む。 それらと区別するため、 上で述べた種別の~proxyは， `回送-~proxy@ （ `forward proxy^en ）と呼ばれることもある （この~RFCには現れないが）。 】【~FN 元の~dataに~~注釈情報（ `annotation^en ）を付加する（例：用語に~linkを補完する）ような~serviceを意味すると思われる。 】

`生成元~server$に適用-可能な，すべての~HTTP要件は、 `~gateway$の`外方$への通信にも適用される。 `~gateway$は、 自身が欲する任意の~protocol — この仕様の視野から外れる，~HTTPに対する私的~拡張も含む — を利用して，`内方$にある`~server$と通信する。 しかしながら，［ 第三者-主体の~HTTP~serverと相互運用するよう望む~HTTP-to-HTTP`~gateway$ ］は、［ ~gatewayの`内方$への接続 ］に課される`~UA$要件にも適合する必要がある。 ◎ 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 needs to conform to user agent requirements on the gateway's inbound connection.

`~tunnel@ （ `tunnel^en ）は、 ~messageを変更することなく， 2 つの接続の間を盲目的に中継するように動作する。 いったん作動中になった~tunnelは、 それが~HTTP要請により起動されたとしても，~HTTP通信の主体とは見なされない。 ~tunnelが存在し得るのは、［ 中継された接続の両~端 ］が~closeされるまでである。 ~tunnelは、 `媒介者$を通した仮想~接続を拡張するために利用される — 共用~firewall~proxyを通した機密的な通信を確立するために， ~TLS（ `Transport Layer Security^en, `TLS13$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, [TLS13]) is used to establish confidential communication through a shared firewall proxy.

上述した`媒介者$用の類別は、［ ~HTTP通信における参加者 ］として動作しているものしか考慮しない。 媒介者には、［ ~network~protocol~stackを成す より低~層 ］で動作して，［ ~message送信者についての知識や許可 ］を伴わずに［ ~HTTP流通を~filterしたり~redirectする ］ものもある。 ~network媒介者は，（~protocol~levelでは）経路上の攻撃者~FN かどうか判別-不能なので、［ ~HTTP意味論を誤認して違反することに因る，~securityの欠陥や相互運用能の問題 ］が導入されることも多い。 【~FN `on-path attacker^en — 旧称 `man-in-the-middle^en （~~中間者）】 ◎ 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 an on-path attacker, often introducing security flaws or interoperability problems due to mistakenly violating HTTP semantics.

例えば， `横取n~proxy@ （ `interception proxy^en ） `RFC3040$r （ `透過的~proxy@ （ `transparent proxy^en ） `RFC1919$r としても共通的に知られる） は、 ~clientにより選ばれるものではない点で，~HTTP`~proxy$とは相違する。 代わりに，横取n~proxyは、［ 外向けの~TCP~port 80 ~packet ］を（ときには、他の共通的な~port上の流通も），~filterしたり~redirectする。 横取n~proxyは、 公共~network~access~pointで［ 局所的でない~Internet~serviceの利用を許容するに先立って， ~account~subscriptionを施行するための手段 ］として, あるいは企業~firewallの中で［ ~network用法~施策を施行するため ］として，共通的に見出される ◎ For example, an "interception proxy" [RFC3040] (also commonly known as a "transparent proxy" [RFC1919]) differs from an HTTP proxy because it is not chosen 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.

3.8. ~cache

`~cache@ （ `cache^en ）とは、 以前に受信した`応答~message$たちが成す局所的な格納域であり，それらの~messageの［ ~storage, 検索取得, 削除 ］を制御する下位~systemである。 ~cacheは、 `~cache可能$な応答を，未来の等価な要請に要する［ 応答~時間／~network帯域幅の消費 ］を抑制するために格納する。 どの［ `~client$／`~server$ ］も，~cacheを使役してヨイ — `~tunnel$として動作している間は、 ~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 while acting as a tunnel.

~cacheによる効果は、［ 要請／応答 ］の連鎖が — ［ `連鎖$沿いにある いずれかの参加者 ］が［ その要請に適用-可能な ~cache済み応答 ］を有するときには — 短縮されることである。 次の図に、 ある要請に対し，参加者 %B が~cache済み複製 — それは［ ~~以前に 【ある~UAによる，その要請と等価な要請に対し，生成元~server】 %O から（ %C を介して）返された応答 ］の複製であり，［ %UA や %A には まだ~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 =========== %A =========== %B - - - - - - %C - - - - - - %O
                <             <

`応答~message$は、［ 後続な要請に対する回答に利用するためとして，複製を~cacheに格納することが許容される ］とき， `~cache可能@ （ `cacheable^en ）であるという。 応答が~cache可能であるとしても、［ 特定0の要請に対し，~cache済み応答が いつ利用できるか ］について，［ `~client$や`生成元~server$により，追加的な拘束が設置される ］こともある。 ［ ~cacheの挙動, および ~cache可能な応答 ］に課される~HTTP要件は、 `CACHING$r にて定義される。 ◎ 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 [CACHING].

World Wide Webや, 巨大な組織の内側にまたがって配備されている~cacheには、 多種多様な~architectureや環境設定がある。 これらには、 次に挙げるものなども含まれる ⇒＃ 帯域幅を節約して待時間を抑制するための，~proxy~cacheの国別~階層／ ~gateway~cache法を利用して人気~siteの局地的, および大域的な配布を最適化する，~CDN（ `content delivery network^en（内容~送達~network））／ ~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 bandwidth and reduce latency, content delivery networks that use gateway caching to optimize regional and global distribution of popular sites, 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.

3.9. ~message交換の例

GET /hello.txt HTTP/1.1
User-Agent: curl/7.64.1
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 content includes a trailing CRLF.

4.1. ~URI参照

`~URI参照@ （ `URI-reference$p ）は、［ `要請~target$を与える／~redirectを指示する／関係性を定義する ］ために利用される。 ◎ URI references are used to target requests, indicate redirects, and define relationships.

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

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

すべての［ `送信者$／`受信者$ ］は、 ~protocol要素の長さにおいて， 最小でも 8000 個以上の~octetからなる~URIを~supportすることが`推奨される^2119。 このことは、 次が必要yなことを含意することに注意 ⇒ 一部の事例では、 何らかの構造と その伝送路~上の表現 （例えば、 ~HTTP11における `request-line＠~HTTPv1#p.request-line$p ） をより大きくする ◎ It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements. Note that this implies some structures and on-wire representations (for example, the request line in HTTP/1.1) will necessarily be larger in some cases.

4.2. ~HTTPに関係する~URI~scheme

~IANAは、 `~URI~scheme~registry$cite `BCP35$r を保守する。 どの~URI`~scheme$も`要請~target$を成し得るが、 次に挙げる~schemeは，~HTTP~serverに内来的である ⇒＃ `http$c, `https$c ◎ IANA maintains the registry of URI Schemes [BCP35] at <https://www.iana.org/assignments/uri-schemes/>. Although requests might target any URI scheme, the following schemes are inherent to HTTP servers: ◎ ↓ § 18.2 Table 2 URI Scheme｜Description｜Section http｜Hypertext Transfer Protocol｜4.2.1 https｜Hypertext Transfer Protocol Secure｜4.2.2

［ "`http$c" ／ "`https$c" ］~URIが在ることが［ ~URIで識別される`生成元$に，接続を~listenしている~HTTP`~server$が常に在る ］ことを含意することにはならないことに注意。 ［ ~serverが存在するかどうか, ~serverが現在 その識別子をある資源に対応付けているかどうか ］を問わず、 ~URIは誰もが創出できる。 登録-済みな名前と~IP~addressは、 委任される資質があり，連合された名前空間を作成する — そこに~HTTP~serverが在ろうが無かろうが。 ◎ Note that the presence of an "http" or "https" URI does not imply that there is always an HTTP server at the identified origin listening for connections. Anyone can mint a URI, whether or not a server exists and whether or not that server currently maps that identifier to a resource. The delegated nature of registered names and IP addresses creates a federated namespace whether or not an HTTP server is present.

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

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

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

4.3. 権限的な~access

権限的（ `authoritative^en ）な~accessとは、 所与の識別子【~URI】による参照を解く（ `dereference^en する）こと — ［ それにより識別される資源への~access ］を得るために，［ その~accessは権限的である【~accessする権限がある】 （その可否は、 当の資源の所有者により制御される） と`~client$が予見する仕方 ］で解くこと — を指す。 その~accessが是認されるか否かを決定するための処理nは、 当の~URI~schemeにより定義され，~URI成分の中の~data — 汎用~構文が利用されるときの `authority$p 成分など — を利用することが多い。 しかしながら、 権限的な~accessは，【~schemeにより】識別される仕組みに制限されない。 ◎ Authoritative access refers to dereferencing a given identifier, for the sake of access to the identified resource, in a way that the client believes is authoritative (controlled by the resource owner). The process for determining whether access is granted is defined by the URI scheme and often uses data within the URI components, such as the authority component when the generic syntax is used. However, authoritative access is not limited to the identified mechanism.

`4.3.1§ は、 そのような【~access可否を決定するための】利用を援助するため，`生成元$の概念を定義する。 後続な下位節は、［ `peer^en【相手の`端点$】が，生成元を表現する権限を有する ］ことを確立する方法を説明する。 ◎ Section 4.3.1 defines the concept of an origin as an aid to such uses, and the subsequent subsections explain how to establish that a peer has the authority to represent an origin.

権限の確立-法に関係する~securityの考慮点は、 `17.1§ を見よ。 ◎ See Section 17.1 for security considerations related to establishing authority.

5.1. ~field名

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

`field-name@p
	= `token$p

`~field名$は文字大小無視であり、 `~HTTP~field名~registry$cite の中に登録される~OUGHT。 `16.3.1§ を見よ。 ◎ Field names are case-insensitive and ought to be registered within the "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see Section 16.3.1.

【 参考：［ ~HTTP2, ~HTTP3 ］においては、 `~field名$は，送信する前に小文字~化される。 】

`~field$の解釈は、［ 同じ~HTTP`~major~version$の下での，`~minor~version$どうし ］では，変化しない — そのような~fieldが無い下では、 `受信者$の既定の挙動は，変化し得るが。 他が指定されない限り、 ~fieldは，すべての~versionの~HTTP用に定義される。 特に，［ `Host$h ／ `Connection$h ］~fieldは、 ~HTTP11への適合性を広告するかどうかに関わらず， すべての~HTTP実装から認識される~OUGHT。 ◎ The interpretation of a 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, fields are defined for all versions of HTTP. In particular, the Host and Connection fields ought to be recognized by all HTTP implementations whether or not they advertise conformance with HTTP/1.1.

新たな`~field$を、 `~protocol~version$を変更することなく，導入できる — ［ それに定義される意味論 ］において，［ それを認識しない`受信者$が，それを安全に無視する ］ことが許容されるならば。 `16.3§ を見よ。 ◎ New 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; see Section 16.3.

5.2. ~field行lと結合-済みな~field値

各 `~field節@ （ `field section^en, 略して `section^en ）は、 任意個数の `~field行l@ （ `field line^en ）から構成される。 各`~field行l$は、 当の`~field$を識別する `~field名$ （ `field name^en ）, および 当の`~field$の その~instance用の~dataを伝達する `~field行l値@ （ `field line value^en ）を伴う。 ◎ Field sections are composed of any number of "field lines", each with a "field name" (see Section 5.1) identifying the field, and a "field line value" that conveys data for that instance of the field.

【 `~field節$は、［ `~header節$／`~trailer節$ ］の総称になる。 】

所与の`~field名$に対しては、 各`~field節$ごとに，その名前の~field用の`結合-$済みな `~field値@ （ `field value^en ）が定義される。 それは、［ `~field節$内に在る`~field行l$のうち，その`~field名$を伴うもの ］すべての`~field行l値$を，~commaで分離して順に連結した結果になる。 ◎ When a field name is only present once in a section, the combined "field value" for that field consists of the corresponding field line value. When a field name is repeated within a section, its combined field value consists of the list of corresponding field line values within that section, concatenated in order, with each field line value separated by a comma.

Example-Field: Foo, Bar
Example-Field: Baz

5.3. ~fieldの順序

`受信者$は、 ~messageの意味論を変更することなく，同じ`~field節$の中の［ 同じ`~field名$を伴う複数個の`~field行l$ ］を 1 個の`~field行l$に `結合-@ （ `combine^en ）してもヨイ — それらのうち［ 最初の`~field行l$の`~field値$ ］に，後続な各`~field行l値$を［ 現れた順に、［ 1 個の~commaと その前後の省略可能な空白（ `OWS$p ） ］で分離した上で，付加する ］ことにより。 一貫性を得るためには、［ ~comma, `SP$P ］並びを利用すること。 ◎ A recipient MAY combine multiple field lines within a field section that have the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma (",") and optional whitespace (OWS, defined in Section 5.6.3). For consistency, use comma SP.

したがって、［ 同じ`~field名$を伴う複数個の`~field行l$ ］が受信される順序は，［ 結合された`~field値$の解釈 ］において有意になる — `~proxy$は、 ~messageを回送するときに，これらの`~field行l値$の順序を変更してはナラナイ。 ◎ The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a proxy MUST NOT change the order of these field line values when forwarding a message.

すなわち、 周知な例外（下に注記される）は別として，および［ 当の~fieldの定義にて，（同じ`~field節$内にある）［ 同じ`~field名$を伴う複数個の`~field行l$を`結合-$し直す ］ことが許容されている場合 （すなわち、 当の`~field値$の定義を成す ある構文-代替が — ~ABNF規則 #(`values^p) などとして — ~commaで分離された~list（ `5.6.1§ ）を許容している場合） ］を除き、 `送信者$は，同じ~message【`~field節$】内に ⇒＃ 同じ`~field名$を伴う複数個の`~field行l$を`生成-$してはナラナイ／ すでに存在する`~field行l$と同じ`~field名$を伴う`~field行l$を付加してはナラナイ ◎ This means that, aside from the well-known exception noted below, a sender MUST NOT generate multiple field lines with the same name in a message (whether in the headers or trailers) or append a field line when a field line of the same name already exists in the message, unless that field's definition allows multiple field line values to be recombined as a comma-separated list (i.e., at least one alternative of the field's definition allows a comma-separated list, such as an ABNF rule of #(values) defined in Section 5.6.1).

【 ~messageを回送するときなど，~field行lを生成しない場合の取扱いは — 同じ~field名を伴う~field行lが複数個あっても — この要件から外されているが、 それらのうちいずれかの`~field行l値$を改変する動作は， 当の~field行lを生成した（または除去してから付加し直した）ものと見なされ， この要件の対象にされよう。 】

注記： `Set-Cookie^h ~header `COOKIE$r は，~list構文を利用せず、 実施においては，同じ`応答~message$内に複数個の`~field行l$にわたって出現することが多い。 すなわち，［ 同じ`~field名$を伴う複数個の`~field行l$に課される，上の要件 ］に違反している。 それは， 1 個の `~field値$に結合できないので、 `受信者$は，~fieldたちを処理する際に `Set-Cookie$h を特別~事例として取扱う~OUGHT （詳細は `Kri2001$r `付録 A.2.3＠http://arxiv.org/abs/cs.SE/0105018#appendix-A.2.3$ を見よ）。 ◎ Note: In practice, the "Set-Cookie" header field ([COOKIE]) often appears in a response message across multiple field lines and does not use the list syntax, violating the above requirements on multiple field lines with the same field name. Since it cannot be combined into a single field value, recipients ought to handle "Set-Cookie" as a special case while processing fields. (See Appendix A.2.3 of [Kri2001] for details.)

`~field節$内で`~field行l$が受信される順序は、 `~field名$が相違するものどうしでは，有意でない。 しかしながら、［ 要請における `Host$h, 応答における `Date$h などの，追加的な制御~dataを包含する~header ］を最初に送信することは，良い実施とされる — 実装は、 より早く，~messageを取扱うかどうか裁定できるようになるので。 ◎ The order in which field lines with differing field names are received in a section is not significant. However, it is good practice to send header fields that contain additional control data first, such as Host on requests and Date on responses, so that implementations can decide when not to handle a message as early as possible.

`~server$は、 要請の`~header節$全体を受信するまでは， 要請をその`~target資源$に適用してはナラナイ — 後に続く~header`~field行l$は、 要請~処理に影響iするような［ `条件付き要請$ ／ 認証~用の`資格証$ ／ 故意に誤誘導するように重複された~header ］を内包することもあるので。 ◎ A server MUST NOT apply a request to the target resource until it receives the entire request header section, since later header field lines might include conditionals, authentication credentials, or deliberately misleading duplicate header fields that could impact request processing.

5.4. ~fieldの長さ制限s

`適合性§にて述べたとおり、 ~HTTPは、 各［ `~field行l$／ `~field値$／ 一体としての`~header節$／ 一体としての`~trailer節$ ］の長さに，定義済みな制限-を設置しない。 実施においては、 個々の長さには，［ 特定の~fieldの意味論に依存して、 様々な場当的な制限が見出される ］ことも多い。 ◎ HTTP does not place a predefined limit on the length of each field line, field value, or on the length of a header or trailer section as a whole, as described in Section 2. Various ad hoc limitations on individual lengths are found in practice, often depending on the specific field's semantics.

`~server$は、 要請にて受信した~header［ `~field行l$／`~field値$／`~field$たちが成す集合 ］が［ 自身が望んで処理する大きさ ］を超える場合には，［ 適切な `4xx$st 状態s~code ］で応答しなければナラナイ。 そのような~headerを【代わりに】無視することは、 `要請~密入~攻撃$ `HTTP/1.1$r に対する~serverの脆弱性を高めることになる。 ◎ A server that receives a request header field line, field value, or set of fields larger than it wishes to process MUST respond with an appropriate 4xx (Client Error) status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks (Section 11.2 of [HTTP/1.1]).

`~client$は、 応答にて受信した `~field行l$のうち［ 自身が望んで処理する大きさ ］を超えるものに対しては、 その`~field$の意味論にて［ その値（たち）が落とされても，［ ~message~frame法や, 応答の意味論 ］を変更することなく安全に無視できる ］ならば，それらを破棄するか, 切落しても~FN ヨイ。 ◎ A client MAY discard or truncate received field lines that are larger than the client wishes to process if the field semantics are such that the dropped value(s) can be safely ignored without changing the message framing or response semantics.

【~FN `~listに基づく~field$の場合に，一部の~memberを破棄することに思われるが、 不可分な~protocol要素（例： `comment$p ）の一部を破棄することも含まれるかもしれない。 】

5.5. ~field値

~HTTP`~field値$は、 当の`~field$の文法により定義される形式による一連の文字からなる。 各~fieldの文法は、 通例的に~ABNF `RFC5234$r を利用して定義される。 ◎ HTTP field values consist of a sequence of characters in a format defined by the field's grammar. Each field's grammar is usually defined using ABNF ([RFC5234]).

`field-value@p
	= *`field-content$p
`field-content@p
	= `field-vchar$p
	  [ 1*( `SP$P / `HTAB$P / `field-vchar$p ) `field-vchar$p ]
`field-vchar@p
	= `VCHAR$P / `obs-text$p
`obs-text@p
	= `80-FF^X

`~field値$は、［ 頭部／尾部 ］に`空白$を内包しない。 ~HTTPの特定の~versionにおいて， そのような空白が~message内に出現することが許容されるときは、 ~fieldを構文解析する実装は， 当の~field値を評価するに先立ってそのような空白を除外しなければナラナイ。 ◎ A field value does not include leading or trailing whitespace. When a specific version of HTTP allows such whitespace to appear in a message, a field parsing implementation MUST exclude such whitespace prior to evaluating the field value.

`~field値$は、 通例的に，~US-ASCII文字 `USASCII$r の範囲に拘束される。 より広~範囲な文字を必要とする`~field$は、 符号化法 — `RFC8187$r にて定義されるものなど — を利用できる。 歴史的に、 ~HTTPが `field-content$p 【！field content】に許容していたのは， ISO-8859-1 ~charset `ISO-8859-1$r による~textであり、 他の~charsetの~supportは， `RFC2047$r 符号化法の利用を通してのみ許容してきた。 新たに定義される`~field$用の仕様は、 その`~field値$を［ `VCHAR$P（可視な~US-ASCII~octet）, `SP$P, `HTAB$P ］に制限するベキである。 `受信者$は、 `field-content$p 【！field content】内で許容される他の~octet（すなわち `obs-text$p ）を不透明な~dataとして扱うベキである。 ◎ Field values are usually constrained to the range of US-ASCII characters [USASCII]. Fields needing a greater range of characters can use an encoding, such as the one defined in [RFC8187]. Historically, HTTP allowed field content with text in the ISO-8859-1 charset [ISO-8859-1], supporting other charsets only through use of [RFC2047] encoding. Specifications for newly defined fields SHOULD limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB. A recipient SHOULD treat other allowed octets in field content (i.e., obs-text) as opaque data.

［ `CR$P ／ `LF$P ／ `NUL^P ］文字を包含している`~field値$は、 妥当でない — 加えて、［ それらの文字を構文解析して解釈する仕方は、 実装に応じて変わるかもしれない ］ことに因り，危険でもある。 そのような~field値の`受信者$は、 当の~messageを却下するか，~messageを［ 処理する／回送する ］前に~field値の中にある各［ `CR^P ／ `LF^P ／ `NUL^P ］を `SP$P に置換しなければナラナイ。 他の `CTL$P 文字を包含している`~field値$も，妥当でない — しかしながら，`受信者$は、 堅牢性を得るためとして， そのような文字が安全な文脈の中で出現したときは維持してもヨイ （例：`下流$にある どの~HTTP構文解析器も処理しない，応用に特有な `quoted-string$p の中）。 ◎ Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message. Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake of robustness when they appear within a safe context (e.g., an application-specific quoted string that will not be processed by any downstream HTTP parser).

`~field$のうち，その`~field値$として 1 個の~memberしか見越さないもの~FN を指して、 `単数~field@ （ `singleton field^en ）という。 ◎ Fields that only anticipate a single member as the field value are referred to as "singleton fields".

【~FN 見越さないとしても、 下に述べるように，`~field値$は “~listに基づいている” かのように出現し得る。 】

`~field$のうち，その`~field値$として複数個の~memberを許容するものを指して、 `~listに基づく~field@ （ `list-based field^en ）という。 複数個の~memberを包含し得る~field値を定義するための共通な記法として， `5.6.1§ に与える~list演算子~拡張が利用される。 ◎ Fields that allow multiple members as the field value are referred to as "list-based fields". The list operator extension of Section 5.6.1 is used as a common notation for defining field values that can contain multiple members.

~comma（ "`,^c" ）は、 ~member間の区切子として利用されるので， 各~memberの中の~dataとして許容される場合には~careの下で扱う必要がある。 このことは、 ~listに基づく~fieldのみならず，`単数~field$にも該当する — `単数~field$は，誤って複数個の~memberを伴って送信されるかもしれず、 そのような~errorを検出することで相互運用能は改善されるので。 `HTTP-date$p や `URI-reference$p 要素の中など，［ ~memberの中に~commaを包含する要素 ］を期待する~fieldは、［ ~list分離子が在ったとしても，要素の中の~commaと判別できる ］よう，当の要素の前後を【~comma以外の】区切子で括るように定義される~OUGHT。 ◎ Because commas (",") are used as the delimiter between members, they need to be treated with care if they are allowed as data within a member. This is true for both list-based and singleton fields, since a singleton field might be erroneously sent with multiple members and detecting such errors improves interoperability. Fields that expect to contain a comma within a member, such as within an HTTP-date or URI-reference element, ought to be defined with delimiters around that element to distinguish any comma within that data from potential list separators.

Example-URIs: "http://example.com/a.html,foo", "http://without-a-comma.example.com/"
Example-Dates: "Sat, 04 May 1996", "Wed, 14 Sep 2005"

区切子としての二重引用符（ `DQUOTE$P ）は、 ほぼ常に， `quoted-string$p 生成規則と伴に利用されることに注意 — 二重引用符の内側で他の構文を利用した場合、 不必要な混同の原因になる見込みが高くなる。 ◎ Note that double-quote delimiters are almost always used with the quoted-string production (Section 5.6.4); using a different syntax inside double-quotes will likely cause unnecessary confusion.

多くの`~field$（ `Content-Type$h など）は、 `~parameter$用に共通な構文を利用する — それは、 ~parameter値（ `parameter-value$p ）用の構文に引用符［ 無し（ `token$p ）と有り（ `quoted-string$p ） ］どちらも許容する。 共通な構文を利用すれば、 `受信者$は，既存の構文解析器を再利用できるようになる。 両~形とも許容するときは、 どちらの形で受信しようが，~parameter値の意味は同じになる~OUGHT。 ◎ Many fields (such as Content-Type, defined in Section 8.3) use a common syntax for parameters that allows both unquoted (token) and quoted (quoted-string) syntax for a parameter value (Section 5.6.6). Use of common syntax allows recipients to reuse existing parser components. When allowing both forms, the meaning of a parameter value ought to be the same whether it was received as a token or a quoted string.

注記： この仕様が`~field値$の構文を定義する所では、 当の~field名の後に有名~ABNF規則を利用して，当の`~field$の値 （下層の~message法~構文から抽出され，複数個の~instanceが~listに結合された後の値） に許容される文法を定義する。 ◎ Note: For defining field value syntax, this specification uses an ABNF rule named after the field name to define the allowed grammar for that field's value (after said value has been extracted from the underlying messaging syntax and multiple instances combined into a list).

5.6. ~field値を定義するための共通な規則

1#%element => %element *( `OWS$p "," `OWS$p %element )

#%element => [ 1#%element ]

<%n>#<%m>%element => %element <%n-1>*<%m-1>( `OWS$p "," `OWS$p %element )

#%element => [ %element ] *( `OWS$p "," `OWS$p [ %element ] )

`example-list@p
	= 1#`example-list-elmt$p
`example-list-elmt@p
	= `token$p【！4.4.1.1】

"foo,bar"
"foo ,bar,"
"foo , ,bar,charlie"

""
","
",   ,"

`token@p
	= 1*`tchar$p

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

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

`quoted-string@p
	= `DQUOTE$P *( `qdtext$p / `quoted-pair$p ) `DQUOTE$P
`qdtext@p
	= `HTAB$P
	/ `SP$P
	/ `21^X
	/ `23-5B^X
	/ `5D-7E^X
	/ `obs-text$p

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

`comment@p
	= "(" *( `ctext$p / `quoted-pair$p / `comment$p ) ")"
`ctext@p
	= `HTAB$P
	/ `SP$P
	/ `21-27^X
	/ `2A-5B^X
	/ `5D-7E^X
	/ `obs-text$p

`parameters@p
	= *( `OWS$p ";" `OWS$p [ `parameter$p ] )
`parameter@p
	= `parameter-name$p "=" `parameter-value$p
`parameter-name@p
	= `token$p
`parameter-value@p
	= ( `token$p / `quoted-string$p )

`HTTP-date@p
	= `IMF-fixdate$p
	/ `obs-date$p

Sun, 06 Nov 1994 08:49:37 GMT    ; `IMF-fixdate^p

Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format

`IMF-fixdate@p
	= `day-name$p "," SP `date1$p SP `time-of-day$p SP `GMT$p
	; 
固定的な［ 長さ／時間帯／~~大文字頭字 ］による下位集合が成す形式
— `5322/3.3$rfc を見よ
◎
fixed length/zone/capitalization subset of the format; see Section 3.3 of [RFC5322]


`day-name@p
	= ~Ps"Mon"
	/ ~Ps"Tue"
	/ ~Ps"Wed"
	/ ~Ps"Thu"
	/ ~Ps"Fri"
	/ ~Ps"Sat"
	/ ~Ps"Sun"

`date1@p
	= `day$p SP `month$p SP `year$p
	; `例：^com 02 Jun 1982

`day@p
	= 2`DIGIT$P
`month@p
	= ~Ps"Jan"
	/ ~Ps"Feb"
	/ ~Ps"Mar"
	/ ~Ps"Apr"
	/ ~Ps"May"
	/ ~Ps"Jun"
	/ ~Ps"Jul"
	/ ~Ps"Aug"
	/ ~Ps"Sep"
	/ ~Ps"Oct"
	/ ~Ps"Nov"
	/ ~Ps"Dec"
`year@p
	= 4`DIGIT$P

`GMT@p
	= ~Ps"GMT"

`time-of-day@p
	= `hour$p ":" `minute$p ":" `second$p
	; 00:00:00 - 23:59:60 `（うるう秒（ leap second ））^com

`hour@p
	= 2`DIGIT$P
`minute@p
	= 2`DIGIT$P
`second@p
	= 2`DIGIT$P

`obs-date@p
	= `rfc850-date$p
	/ `asctime-date$p

`rfc850-date@p
	= `day-name-l$p "," `SP$P `date2$p `SP$P `time-of-day$p `SP$P GMT
`date2@p
	= `day$p "-" `month$p "-" 2`DIGIT$P
	; `例：^com 02-Jun-82

`day-name-l@p
	= ~Ps"Monday"
	/ ~Ps"Tuesday"
	/ ~Ps"Wednesday"
	/ ~Ps"Thursday"
	/ ~Ps"Friday"
	/ ~Ps"Saturday"
	/ ~Ps"Sunday"

`asctime-date@p
	= `day-name$p `SP$P `date3$p `SP$P `time-of-day$p `SP$P `year$p
`date3@p
	= `month$p `SP$P ( 2`DIGIT$P / ( `SP$P 1`DIGIT$P ))
	; `例：^com Jun  2

6.1. ~frame法と完全さ

~message~frame法は、 各~messageが — 同じ接続~上の他の~messageや~noiseと判別できるよう — どう始まり, どう終端するかを指示する。 ~HTTPの各`~major~version$は、 自前の~frame法の仕組みを定義する。 ◎ Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection. Each major version of HTTP defines its own framing mechanism.

~HTTP09および ~HTTP10の早期の配備は、 下層の接続の~closureを利用して，応答を終端していた。 後方-互換性を得るため、 この暗黙的な~frame法は~HTTP11においても許容される。 しかしながら，当の接続が早く~closeされた場合、 暗黙的な~frame法では，不完全な応答と判別するのに失敗し得る。 この理由から，現代のほぼすべての実装は、 長さで区切られた~message~data列の形で，明示的な~frame法を利用する。 ◎ HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end a response. For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early. For that reason, almost all modern implementations use explicit framing in the form of length-delimited sequences of message data.

~messageは、 その~frame法により指示される すべての~octetが可用になったとき， `完全@ （ `complete^en ）であると見なされる。 明示的な~frame法が利用されていない場合、 下層の接続の~closeにより終端された`応答~message$は — 不完全な応答と判別-不能であろうが， ~transport~levelの~errorにより完全でないものと指示されない限り — `完全$と見なされることに注意。 ◎ A message is considered "complete" when all of the octets indicated by its framing are available. Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete.

6.2. 制御~data

~HTTP11 `HTTP/1.1$r までの~versionにおいては、 制御~dataは，~messageの最初の行l【 `start-line＠~HTTPv1#p.start-line$p 】として送信される。 ［ ~HTTP2 `HTTP/2$r ／ ~HTTP3 `HTTP/3$r ］においては、 制御~dataは，予約-済みな名前~接頭辞を伴う疑似-~header（例： "`authority^ph" ）として送信される。 ◎ In HTTP/1.1 ([HTTP/1.1]) and earlier, control data is sent as the first line of a message. In HTTP/2 ([HTTP/2]) and HTTP/3 ([HTTP/3]), control data is sent as pseudo-header fields with a reserved name prefix (e.g., ":authority").

どの~HTTP~messageも，`~protocol~version$を伴う。 ~versionは、 利用-中にある~versionに依存して，［ ~messageの中で明示的に識別される ］ことも［ 当の~messageが受信された`接続$により推定される ］こともある。 `受信者$は、 その~version情報を利用して，その送信者との今後の通信~用に［ 制限／~~可能性 ］を決定する。 ◎ Every HTTP message has a protocol version. Depending on the version in use, it might be identified within the message explicitly or inferred by the connection over which the message is received. Recipients use that version information to determine limitations or potential for later communication with that sender.

~messageの`~protocol~version$は、 媒介者により~messageが回送されるとき，その媒介者が利用する~versionを反映するように更新される。 `Via$h ~headerは、 回送する~messageの中に`上流$からの~protocol情報を通信するために利用される。 ◎ When a message is forwarded by an intermediary, the protocol version is updated to reflect the version used by that intermediary. The Via header field (Section 7.6.3) is used to communicate upstream protocol information within a forwarded message.

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

6.3. ~header

`~header@ （ `header field^en ／ 俗に `header^en ）は、 `~field$のうち，`内容$より前に［ 送信される／受信される ］ものを指す。 ◎ Fields (Section 5) that are sent or received before the content are referred to as "header fields" (or just "headers", colloquially).

【 この訳では、 一律に，略称（俗称）である “~header” で表記することにする。 】

~messageの `~header節@ （ `header section^en, 略して `headers^en ）は、 一連の~header`~field行l$からなる`~field節$である。 各~headerは、 次を行い得る ⇒＃ ~messageの意味論を改変するか拡張する／ `送信者$について述べる／ `内容$を定義する／ 追加的な文脈を供する ◎ The "header section" of a message consists of a sequence of header field lines. Each header field might modify or extend message semantics, describe the sender, define the content, or provide additional context.

注記： 【~field定義における語】`~header$は、［ 有名~fieldのうち，`~header節$内に限り送信することが許容されるもの ］を特定的に指す。 ◎ Note: We refer to named fields specifically as a "header field" when they are only allowed to be sent in the header section.

6.4. 内容

~HTTP~messageは、［ `完全$／`部分的$ ］な`表現$を，その `内容@ （ `message content^en, 略して `content^en ）として転送することが多い — それは、 ~message~frame法により他と線引きされ， `~header節$の後に送信される~octetの~streamである。 ◎ HTTP messages often transfer a complete or partial representation as the message "content": a stream of octets sent after the header section, as delineated by the message framing.

【 ~messageの`内容$は、 この仕様が改訂した `RFC7231$r においては， “`payload body^en” （~payload本体, 略して `payload^en ）と称されていた。 より過去の仕様 — 特に， `RFC2616$r 世代の~RFCなど — では “`entity body^en” （実体~本体）と称されていた。 （ “内容” という語は汎用に過ぎるので、 この訳では，~messageの`内容$を意味する “内容” には， 可能な限り ここを指す~linkをあてがっている。） 】

この抽象的な［ `内容$の定義 ］は、 ~message~frame法から抽出された後の~dataを反映する。 例えば、 ~HTTP11の`~message本体$は， `chunked$c `転送~符号法$で符号化された~dataの~stream — 一連の~data~chunk, 【その終端を指示する】 1 個の長さ 0 の~chunk, `~trailer節$ — からなることもある。 一方で，同じ~messageの`内容$は、 `転送~符号法$を復号した後の~data~streamのみを内包する — それは、［ ~chunk長さ, `chunked$c ~frame法の構文, `~trailer$ ］は内包しない。 ◎ This abstract definition of content reflects the data after it has been extracted from the message framing. For example, an HTTP/1.1 message body (Section 6 of [HTTP/1.1]) might consist of a stream of data encoded with the chunked transfer coding -- a sequence of data chunks, one zero-length chunk, and a trailer section -- whereas the content of that same message includes only the data stream after the transfer coding has been decoded; it does not include the chunk lengths, chunked framing syntax, nor the trailer fields (Section 6.5).

注記： 一部の~field名は、 "`Content-^c" 接頭辞を伴う。 これは、 非正式な規約である — これらの~fieldのうち一部は，上で定義したように~messageの`内容$を参照rするが、 他のものは，`選定される表現$を視野に入れる。 どちらなのかは、 個々の~fieldの定義を見よ。 ◎ Note: Some field names have a "Content-" prefix. This is an informal convention; while some of these fields refer to the content of the message, as defined above, others are scoped to the selected representation (Section 3.2). See the individual field's definition to disambiguate.

6.5. ~trailer

`~trailer@ （ `trailer field^en ／ 俗に `trailer^en ）~FN は、 `~field$のうち， `~trailer節@ （ `trailer section^en, 略して `trailers^en ）の中に所在するものを指す。 ~trailerは、 ~messageの［ 完全性~検査／~digital署名／送達~計量／後処理~状態s情報 ］を給するために有用になり得る。 ◎ Fields (Section 5) that are located within a "trailer section" are referred to as "trailer fields" (or just "trailers", colloquially). Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post-processing status information.

【~FN この訳では、 一律に，略称（俗称）である “~trailer” で表記することにする。 】

`~trailer$は、［ `~header節$が完了した時点で既知になった~message意味論 ］に矛盾するのを避けるため，`~header節$内の`~field$とは別々に処理され, 格納される~OUGHT。 ある種の~headerの有無は、［ `~trailer$を受信する前に，一体としての~messageを［ ~routeする／処理する ］ために為される選択 ］に影響iするかもしれない — そのような選択は、 後から`~trailer$が発見されても，くつがえせない。 ◎ Trailer fields ought to be processed and stored separately from the fields in the header section to avoid contradicting message semantics known at the time the header section was complete. The presence or absence of certain header fields might impact choices made for the routing or processing of the message as a whole before the trailers are received; those choices cannot be unmade by the later discovery of trailer fields.

6.6. ~message~metadata

各種`~field$のうち，当の`~message$自身を述べるもの — ~messageが［ いつ／どう ］`生成-$されたかなど — は、 要請, 応答どちらにも出現し得る。 ◎ Fields that describe the message itself, such as when and how the message has been generated, can appear in both requests and responses.

`Date@p
	= `HTTP-date$p

Date: Tue, 15 Nov 1994 08:12:31 GMT

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

16.1. ~methodの拡張能

16.2. 状態s~codeの拡張能

16.3. ~fieldの拡張能

~HTTPの拡張能を成す地点として最も広く利用されているのは、 新たな［ ~header／~trailer ］の定義である。 ◎ HTTP's most widely used extensibility point is the definition of new header and trailer fields.

しかしながら，ある~fieldを定義しても、 その［ 配備／受信者による認識 ］は保証されない。 ほとんどの~fieldは、 受信者が認識しない~fieldを安全に無視できる（が`下流$へ回送する）とする期待の下で設計される。 他にも、 所与の~fieldを解する送信者の能が，それに先立つ通信により指示される事例もある — たぶん，先立つ~message内に送信者が送信した［ ~protocol~version／~fieldたち ］により、 あるいは，特定の~MIME型の利用により。 同様に，~support有無の直な検分は、［ `OPTIONS$m 要請を通して／ 定義-済みな周知な~URI【 `/.well-known/^c 】 `RFC8615$r とヤリトリすることにより ］アリかもしれない — そのような検分が，当の~fieldを導入するに伴って定義された場合には。 ◎ However, defining a field doesn't guarantee its deployment or recognition by recipients.＼ Most fields are designed with the expectation that a recipient can safely ignore (but forward downstream) any field not recognized.＼ In other cases, the sender's ability to understand a given field might be indicated by its prior communication, perhaps in the protocol version or fields that it sent in prior messages, or its use of a specific media type.＼ Likewise, direct inspection of support might be possible through an OPTIONS request or by interacting with a defined well-known URI [RFC8615] if such inspection is defined along with the field being introduced.

16.4. 認証~schemeの拡張能

16.5. 範囲~単位の拡張能

16.6. 内容~符号法の拡張能

16.7. `Upgrade^h ~token~registry

［ `Upgrade$h ~header内の~protocolを識別するために利用される， `protocol-name$p ~token ］用の名前空間は、 `~HTTP~Upgrade~token~registry$cite にて保守され，定義される。 ◎ 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 <https://www.iana.org/assignments/http-upgrade-tokens>.

登録された各~protocol名には、 連絡~先~情報に加えて，省略可能な［ 接続は、 昇格された後 どう処理されるか ］について詳細を述べる仕様たちが成す集合が結付けられる。 ◎ Each registered protocol name is associated with contact information and an optional set of specifications that details how the connection will be processed after it has been upgraded.

登録は、 “~~申請順（ `First Come First Served^en ）” （ `8126/4.4$rfc ） に基づいて行われ，次の規則の~subjectになる： ◎ Registrations happen on a "First Come First Served" basis (see Section 4.4 of [RFC8126]) and are subject to the following rules:

1. 一度~登録された `protocol-name$p ~tokenは、 登録されたまま~~恒久的に居残る。 ◎ A protocol-name token, once registered, stays registered forever.
2. `protocol-name$p ~tokenは文字大小無視であるが、 送信者が`生成-$するときは，登録された文字大小が選好される。 ◎ A protocol-name token is case-insensitive and registered with the preferred case to be generated by senders.
3. 登録は、 登録に対する責任-主体を命名しなければナラナイ。 ◎ The registration MUST name a responsible party for the registration.
4. 登録は、 連絡~窓口を命名しなければナラナイ。 ◎ The registration MUST name a point of contact.
5. 登録は、［ その~tokenに結付けられる仕様たちが成す集合 ］を命名してもヨイ。 そのような仕様は、 公に可用になる必要はない。 ◎ The registration MAY name a set of specifications associated with that token. Such specifications need not be publicly available.
6. 登録は、［ 登録の時点でその~tokenに結付けられる［ 期待される "`protocol-version$p" ~tokenからなる集合 ］］を命名するベキである。 ◎ The registration SHOULD name a set of expected "protocol-version" tokens associated with that token at the time of registration.
7. 責任-主体は、 いつでも登録を変更してもヨイ。 ~IANAは、 そのような変更~すべての記録-を保って， 要請に応じて，それらを可用にすることになる。 ◎ The responsible party MAY change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
8. IESG は、 `protocol$p ~tokenに対する責任-主体を他にアテガってもヨイ。 これは、 通常は，責任-主体に連絡できなくなったときに限られる。 ◎ The IESG MAY reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot be contacted.

17.1. 権限の確立-法

~HTTPは、 `権限的な応答@ （ `authoritative response^en ）の観念に依拠する。 それは、［ `応答~message$の出生時における`~target資源$の状態 ］が与えられた下で［ 要請に対する，最も適切な応答になる ］ものとして，［ `~target~URI$の中で識別される`生成元~server$ ］により（または，の~directionの下で）決定される応答である。 ◎ HTTP relies on the notion of an "authoritative response": a response that has been determined by (or at the direction of) the origin server 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.

ある登録-済みな名前が `authority$p 成分~内に利用されるとき、 "`http$c" ~URI`~scheme$は，［ `権限的な応答$がどこで見出せるかを決定する ］ときに［ 利用者に局所的な名前~解決~service ］に依拠する。 これは、 利用者の［ ~network~host~table／ ~cacheされる名前／ 名前~解決~library ］に対するどの攻撃も， "`http$c" ~URI用に権限を確立する際の攻撃に繋がることを意味する。 同様に，［ 利用者が~DNS（ `Domain Name Service^en ）用に選んだ~server ］, および［ 解決の結果を得するときに用いた，~server階層 ］は、［ ~address対応付けの真正性 ］に影響iし得る — 真正性を改善する仕方の一つには， DNSSEC（ `DNS Security Extensions^en, `RFC4033$r ）があり、 より~secureな転送~protocol越しに~DNS要請を為すための様々な仕組みもある。 ◎ When a registered name is used in the authority component, the "http" URI scheme (Section 4.2.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 for "http" URIs. 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, as are the various mechanisms for making DNS requests over more secure transfer protocols.

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

所与の`生成元~server$用の権限は、 ~protocol拡張 — 例えば， `ALTSVC$r — を通して委任できる。 同様に、 `RFC8336$r の様な~protocol拡張により，［ ある接続に対し権限的と見なされる~server ］たちが成す集合を変更できる。 ◎ Authority for a given origin server can be delegated through protocol extensions; for example, [ALTSVC]. Likewise, the set of servers for which a connection is considered authoritative can be changed with a protocol extension like [RFC8336].

応答を［ 共用~proxy~cacheなどの権限的でない~source ］から供することは、［ 処理能や可用性を改善するために有用になる ］ことが多いが，［ 当の~sourceを信用できるか、 信用できない応答でも安全に利用できる ］場合までに限られる。 ◎ Providing a response from a non-authoritative source, such as a shared proxy 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.

17.2. 媒介者の~risk

~HTTP`媒介者$は、 内来的に，経路上の攻撃を成せる立場にある。 媒介者が稼働する~systemが弱体化されると、 深刻な［ ~security／~privacy ］問題になり得る。 媒介者は，［ ~securityに関係する情報／ 個々の［ 利用者や組織 ］についての個人-情報／ 利用者と内容~providerに所属している~proprietary情報 ］へも~accessし得るかもしれない。 弱体化された媒介者, あるいは［ ~securityや~privacy ］の考慮点に~~無関心に［ 実装された／環境設定された ］媒介者は、 その引き換えに広範な攻撃に晒され得る。 ◎ HTTP intermediaries are inherently situated for on-path 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$を包含する`媒介者$は — `CACHING$r `~securityの考慮点＠~HTTPcache#security.considerations§ にて述べられるとおり — ~cache汚染~攻撃に，とりわけ脆弱である。 ◎ Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks, as described in Section 7 of [CACHING].

実装者は、［ 設計と その~code化にあたっての裁定／ 運用者に供する環境設定~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できない。 ◎ Intermediaries are no more trustworthy than the people and policies under which they operate; HTTP cannot solve this problem.

17.3. ~file名や~path名に基づく攻撃

`生成元~server$は、［ `~target~URI$から資源~表現への対応付け ］を管理するために，自身の局所的な~file~systemを用立てることが多い。 ほとんどの~file~systemは、 悪意的な［ ~file／~path ］名から保護されるように設計されていない。 したがって，生成元~serverは、 `~target資源$を［ ~file／~folder／~directory ］に対応付けるときに，［ ~systemにおいて特別な有意性がある名前 ］への~accessを避ける必要がある。 ◎ Origin servers frequently make use of their local file system to manage the mapping from target URI to resource representations. Most file systems are not designed to protect against malicious file or path names. Therefore, an origin server needs to avoid accessing names that have a special significance to the system when mapping the target resource to files, folders, or directories.

例えば［ ~UNIX, Microsoft Windows, その他の~OS ］は、 "`..^c" を［ 現在の~levelより一つ上の~directoryを指示する，~path成分 ］として利用することに加え，特別に命名された［ ~path／~file ］名を［ ~dataを~system機器へ送信する ］ために利用する。 類似な命名~慣行は、 他の型の~storage~systemにも存在し得る。 同様に，局所的な~storage~systemは、 次を取扱うときに，~securityよりも利用者への親切さを選好する厄介な傾向がある ⇒＃ 妥当でない文字／ 期待されない文字／ 分解された文字の再組成／ 文字大小無視な名前に対する 文字大小の正規化 ◎ For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one, and they use specially named paths or file names to send data to system devices. Similar naming conventions might exist within other types of storage systems. Likewise, local storage systems have an annoying tendency to prefer user-friendliness over security when handling invalid or unexpected characters, recomposition of decomposed characters, and case-normalization of case-insensitive names.

そのような特別な名前に基づく攻撃は、［ ~DoS （例： ~serverに COM ~portから読取るように~~仕向ける） ］や［ ~serve用に意味されていない，環境設定や~source~fileの開示 ］に力点を置く傾向にある。 ◎ Attacks based on such special names tend to focus on either denial-of-service (e.g., telling the server to read from a COM port) or disclosure of configuration and source files that are not meant to be served.

17.4. ~command／~code／~query の注入に基づく攻撃

`生成元~server$は、 `~URI$の中の~parameterを，［ ~system~serviceを識別する／ ~database~entryを選定する／ ~data~sourceを選ぶ ］ための手段として利用することが多い。 しかしながら、 要請~内に受信される~dataは，信用できない。 攻撃者は、［［ ~command呼出n／言語~解釈器／~database~interface ］を通して渡されたときに［ ~command／~code／~query ］として誤解釈され得る ］ような~dataを包含させるために，どのような要請~data要素（~method, `~target~URI$, `~header$, `内容$）も構築できる。 ◎ Origin servers often use parameters within the URI as a means of identifying system services, selecting database entries, or choosing a data source. However, data received in a request cannot be trusted. An attacker could construct any of the request data elements (method, target URI, header fields, or content) to contain data that might be misinterpreted as a command, code, or query when passed through a command invocation, language interpreter, or database interface.

共通的にある攻撃として，例えば~SQL注入は、［ `~target~URI$または~header（例： `Host$h, `Referer$h, 等々）のある部分 ］の中に，追加的な~query言語を挿入する。 受信した~dataが SELECT 文0の中で直に利用された場合、 ~query言語は，~database~commandとして解釈され得る — 単純な文字列~値としてではなく。 実装における この型の脆弱性は、 防止するのは容易にもかかわらず，ごく ありふれている。 ◎ For example, SQL injection is a common attack wherein additional query language is inserted within some part of the target URI or header fields (e.g., Host, Referer, etc.). If the received data is used directly within a SELECT statement, the query language might be interpreted as a database command instead of a simple string value. This type of implementation vulnerability is extremely common, in spite of being easy to prevent.

一般に，資源の実装は、［ 指示命令として［ 処理される／解釈される ］ような文脈 ］においては，要請~dataの利用を避ける~OUGHT。 要請~dataの~parameterは、 固定的な文字列と比較された上で，その比較の結果として動作する~OUGHT — ［ 信用できない~data用に準備されたものではない~interface ］を通して渡されるのではなく。 受信した~dataが固定的な~parameterに基づかない場合、 誤解釈を避けるため，注意深く［ ~filterする／符号化する ］~OUGHT。 ◎ In general, resource implementations ought to avoid use of request data in contexts that are processed or interpreted as instructions. Parameters ought to be compared to fixed strings and acted upon as a result of that comparison, rather than passed through an interface that is not prepared for untrusted data. Received data that isn't based on fixed parameters ought to be carefully filtered or encoded to avoid being misinterpreted.

類似な考慮点は、［ いったん格納され，後で処理される ］ような要請~dataにも適用される — ［ ~log~fileの中／ 監視-用~tool／ 埋込d~scriptも許容する~data形式の中に内包されるとき ］など。 ◎ Similar considerations apply to request data when it is stored and later processed, such as within log files, monitoring tools, or when included within a data format that allows embedded scripts.

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

~HTTPは，大方，文字で区切られる~textな~fieldを利用するので、 構文解析器は，［ ~~長大な（または とても遅い）~data~streamの送信に基づく攻撃 ］に脆弱になることが多い — 特に，実装が［ 定義済みな長さ（ `2.3§ ）がない~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 (Section 2.3).

相互運用能を促進するため、 各種`~field$には，最小な~size上限について特定の推奨が為される（ `5.4§ ）。 これらは、［ 資源が制限された実装でも~support可能になるような，最小 ］を与える推奨になるように選ばれている — ほとんどの実装は，相当に高い上限を選ぶことになると期待されている。 ◎ To promote interoperability, specific recommendations are made for minimum size limits on fields (Section 5.4). 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$は、 ~messageの［ `~target~URI$が~~長過ぎる／要請の`内容$が巨大~過ぎる ］場合には，（ `414$st ／ `413$st で）却下できる。 ~HTTPの拡張 `RFC6585$r にも，［ 容量~制限に関係する追加的な`状態s~code$ ］が定義されている。 ◎ A server can reject a message that has a target URI that is too long (Section 15.5.15) or request content that is too large (Section 15.5.14). Additional status codes related to capacity limits have been defined by extensions to HTTP [RFC6585].

`受信者$は、［ 自身が処理する他の~protocol要素の限度 ］を注意深く制限する~OUGHT。 それらには、［ `要請~method$, 応答`事由~句$【！状態s句】, `~field名$, 数量-値, ~chunkの長さ ］も含まれる。 そのような処理における制限の失敗は、 ~buffer~overflowや算術的な桁溢れに因る任意な~code実行, および ~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, field names, numeric values, and chunk lengths. Failure to limit such processing can result in arbitrary code execution due to buffer or arithmetic overflows, and increased vulnerability to denial-of-service attacks.

17.6. 辞書を共有している圧縮を利用する攻撃

暗号化された~protocolに対する攻撃には、 動的な圧縮により作成される~sizeの相違を利用して，機密的な情報を露呈するものもある — 例えば `BREACH$r 。 攻撃者が制御する内容と機密的な情報に同じ辞書を利用している動的な圧縮~algoは、 前者の内容が後者の内容の一部に合致する場合，より効率的に圧縮することになる — これらの攻撃は、 そのような冗長性を作成することに依拠する。 ◎ Some attacks on encrypted protocols use the differences in size created by dynamic compression to reveal confidential information; for example, [BREACH]. These attacks rely on creating a redundancy between attacker-controlled content and the confidential information, such that a dynamic compression algorithm using the same dictionary for both content will compress more efficiently when the attacker-controlled content matches parts of the confidential content.

~HTTP~messageは、 圧縮され得る — その仕方には、 いくつかあり，次の利用も含まれる ⇒＃ ~TLS圧縮, `内容~符号法$, `転送~符号法$, 拡張や~versionに特有な他の仕組み ◎ HTTP messages can be compressed in a number of ways, including using TLS compression, content codings, transfer codings, and other extension or version-specific mechanisms.

この~riskに対する最も効果的な軽減策は、［ 敏感な~dataに対しては圧縮を不能化する ］か［ 敏感な~dataを攻撃者が制御する~dataから厳密に分離して， それらが同じ圧縮~辞書を共有し得ないようにする ］ことである。 注意深い設計の下では、 圧縮~schemeは，［ 制限された利用事例においては，悪用-可能とは見なされない ］ような仕方で設計できる — ~HPACK `HPACK$r など。 ◎ The most effective mitigation for this risk is to disable compression on sensitive data, or to strictly separate sensitive data from attacker-controlled data so that they cannot share the same compression dictionary. With careful design, a compression scheme can be designed in a way that is not considered exploitable in limited use cases, such as HPACK ([HPACK]).

17.7. 個人-情報の開示

17.8. ~server~log情報の~privacy

`~server$は、［ 期間に渡る利用者の要請についての個人-~data ］を保存する立場にあり，利用者の［ 行動様式／関心事 ］も識別し得る。 特に，［ `媒介者$に集められた~log情報 ］は、［ 不特定多数の~siteにまたがる，~UAとのヤリトリの履歴 ］を包含することが多く，個々の利用者を追跡し得る。 ◎ 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追跡から［ 他の~access特性との相関 ］に基づいて識別し直されるのを防ぐには十分でない。 そのようなわけで、［ 特定の`~client$に対し~keyされた~access追跡 ］の流出は，当の~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^en ）／ 不正行為の~~規制（ `fraud control^en ） などの，運用~上の必要性を~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.

17.9. ~URI内の敏感な情報の開示

`~URI$は、 ~secureな資源を識別するものであっても，［ 共有され, ~secure化されないもの ］になるように意図されている。 ~URIは、［ ~displayに示される／ ~pageの印刷-時に各用紙に刷られる／ 様々な未保護な~bookmark~list内に格納される ］ことが多い。 多くの［ ~server／~proxy／~UA ］は、 `~target~URI$を［ 第三者-主体から可視になり得る所 ］に，~logしたり, 表示する。 したがって，［ 敏感な ／ 個人識別可能な ／ 開示される~riskがある ］情報を~URIに内包することは、 賢明でない。 【とは言え、`能力~URL$のような用法はある。】 ◎ URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added to templates when a page is printed, and stored in a variety of unprotected bookmark lists. Many servers, proxies, and user agents log or display the target URI in places where it might be visible to third parties. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose.

応用が［ 利用者が供した情報から`~target~URI$を構築するような，~client側の仕組み ］ — `GET$m を利用している~formの~query~fieldなど — を利用している場合、 ~URIの中に開示するには適切にならない，敏感になり得る~dataが供されるかもしれない。 そのような事例では、 `POST$m が選好されることが多い — それは通例的に、 ~URIは構築しない代わりに， 敏感になり得る~dataを~formの `POST$m 要請の`内容$内に伝送するので。 しかしながら，これは、 ~cachingを邪魔することに加え， 他であれば`安全$になる要請に安全でない~methodを利用する。 代替な対処法として、［ ~URIを構築するに先立って，利用者が供した~dataを形式変換する／ 敏感でない 共通的な値に限り内包するよう，当の~dataを~filterする ］などが挙げられる。 同様に【その上で？】，~queryの結果を（~serverが`生成-$した）異なる~URIへ~redirectすれば、 後の~linkから敏感になり得る~dataを除去して，後で再利用できる`~cache可能$な応答を供し得る。 ◎ When an application uses client-side mechanisms to construct a target URI out of user-provided information, such as the query fields of a form using GET, potentially sensitive data might be provided that would not be appropriate for disclosure within a URI. POST is often preferred in such cases because it usually doesn't construct a URI; instead, POST of a form transmits the potentially sensitive data in the request content. However, this hinders caching and uses an unsafe method for what would otherwise be a safe request. Alternative workarounds include transforming the user-provided data prior to constructing the URI or filtering the data to only include common values that are not sensitive. Likewise, redirecting the result of a query to a different (server-generated) URI can remove potentially sensitive data from later links and provide a cacheable response for later reuse.

`Referer$h ~headerは，要請を~~生じさせた文脈について ~target~siteに~~伝えるので、 参照元~資源の~URI内に見出され得るような［ 利用者の直前の閲覧~履歴についての情報, その他の個人-情報 ］を露呈する~~可能性がある。 `Referer$h ~headerに対する制限は、 その定義に述べたように，その~securityの考慮点の一部に取組む。 ◎ Since the Referer header field tells a target site about the context that resulted in a request, it has the potential to reveal information about the user's immediate browsing history and any personal information that might be found in the referring resource's URI. Limitations on the Referer header field are described in Section 10.1.3 to address some of its security considerations.

17.10. 応用による~field名の取扱い

`~server$は、［ 受信した要請を処理して 応答~用に内容を生産する ］ときに，非~HTTPな［ ~gateway~interfaceや~framework ］を利用することが多い。 歴史的な理由から，そのような~interfaceは、 受信した`~field名$を — 環境~変数~用に相応しい名前への対応付けを利用して — 外部~変数~名として渡すことが多い。 ◎ Servers often use non-HTTP gateway interfaces and frameworks to process a received request and produce content for the response. For historical reasons, such interfaces often pass received field names as external variable names, using a name mapping suitable for environment variables.

例えば、 `3875/4.1.18$rfc により定義される［ ~CGI（ `Common Gateway Interface^en, 共通~gateway~interface ）における， ~protocolに特有な~meta-変数（ `meta-variable^en ）用の対応付け ］は、［ 受信した~headerのうち，~CGIの標準~変数に対応しないもの ］に適用される — その対応付けでは、 各~名前に対し【まず大文字~化してから】 "`HTTP_^c" を前付加して， すべての~hyphen（ "`-^c" ）を~underscore（ "`_^c" ）に置換する【！変更する】。 同じ対応付けは、 他の多くの応用~frameworkにも継承されている — 応用を ある~platformから `the next^en【次の~version？他の~platform？】へ移動するのを単純~化するために。 ◎ For example, the Common Gateway Interface (CGI) mapping of protocol-specific meta-variables, defined by Section 4.1.18 of [RFC3875], is applied to received header fields that do not correspond to one of CGI's standard variables; the mapping consists of prepending "HTTP_" to each name and changing all instances of hyphen ("-") to underscore ("_"). This same mapping has been inherited by many other application frameworks in order to simplify moving applications from one platform to the next.

~CGIにおいては、 受信した `Content-Length$h ~fieldは， ~meta-変数 `CONTENT_LENGTH^c として — 受信した`~field値$に合致する文字列~値を伴わせて — 渡されることになる。 対照的に，受信した `Content_Length^h ~headerは、 当の~protocolに特有な~meta-変数 `HTTP_CONTENT_LENGTH^c として渡されることになる — それは、 ある応用を［ 既定の~meta-変数ではなく，当の~protocolに特有な~meta-変数に誤認して読取る ］ような混同へ導くかもしれない。 （ `16.3.2.1§ にて［ ~underscoreを包含する新たな~field名の作成が忌避される ］わけは、 この歴史的な実施による。） ◎ In CGI, a received Content-Length field would be passed as the meta-variable "CONTENT_LENGTH" with a string value matching the received field's value. In contrast, a received "Content_Length" header field would be passed as the protocol-specific meta-variable "HTTP_CONTENT_LENGTH", which might lead to some confusion if an application mistakenly reads the protocol-specific meta-variable instead of the default one. (This historical practice is why Section 16.3.2.1 discourages the creation of new field names that contain an underscore.)

あいにく，`~field名$から~interface名への対応付けは、［ 不完全／多義的 ］な場合，~securityの脆弱性へ導き得る。 例えば，攻撃者が "`Transfer_Encoding^c" と命名された~fieldを送信した場合、 素朴な~interfaceは `Transfer-Encoding^h ~fieldと同じ変数~名へ対応付けるかもしれず、 その結果，`要請~密入~攻撃$ `HTTP/1.1$r に対する脆弱性になる~~可能性がある。 ◎ Unfortunately, mapping field names to different interface names can lead to security vulnerabilities if the mapping is incomplete or ambiguous. For example, if an attacker were to send a field named "Transfer_Encoding", a naive interface might map that to the same variable name as the "Transfer-Encoding" field, resulting in a potential request smuggling vulnerability (Section 11.2 of [HTTP/1.1]).

そのような対応付けを遂行する実装は、 それにつきまとう~riskを軽減するため， 名前として受信される~~可能性がある 全-範囲の~octetに対し （忌避されるものや, ~HTTP文法により禁止されるものも含む）， 対応付けが一義的かつ完全になるようにすることを勧める。 例えば，ある~fieldが通例的でない名前~文字を伴う場合、［ 当の要請が阻止されたり， 特定の~fieldが除去されたり， 当の名前に — 他の~fieldと判別できるよう — 他と異なる接頭辞が付与された上で渡される ］結果になるかもしれない。 ◎ To mitigate the associated risks, implementations that perform such mappings are advised to make the mapping unambiguous and complete for the full range of potential octets received as a name (including those that are discouraged or forbidden by the HTTP grammar). For example, a field with an unusual name character might result in the request being blocked, the specific field being removed, or the name being passed with a different prefix to distinguish it from other fields.

17.11. ~redirect後の素片の開示

`~URI参照$の中で利用される素片~識別子は，要請~内には送信されないが、 実装者は，［ それらが、 応答の結果として，~UA, および稼働している どの［ 拡張／~script ］からも可視になる ］ことを自覚しておく~OUGHT。 特に，［ ~redirectが生じて，元の要請の素片~識別子が `Location$h 内の新たな参照に継承される ］とき、 これには，［ ある~siteの素片を別の~siteに開示する ］かもしれない効果がある。 最初の~siteが `fragment$p 内に個人-情報を利用している場合、 他の~siteへの~redirectに際しては，［ 【最初の `fragment^p と無関係な】（場合によっては空な） `fragment^p 成分を内包することにより，その継承を阻止する ］ことを確保する~OUGHT。 ◎ Although fragment identifiers used within URI references are not sent in requests, implementers ought to be aware that they will be visible to the user agent and any extensions or scripts running as a result of the response. In particular, when a redirect occurs and the original request's fragment identifier is inherited by the new reference in Location (Section 10.2.2), this might have the effect of disclosing one site's fragment to another site. If the first site uses personal information in fragments, it ought to ensure that redirects to other sites include a (possibly empty) fragment component in order to block that inheritance.

17.12. 製品~情報の開示

［ `User-Agent$h ／ `Via$h ／ `Server$h ］~headerは、［ 当の`送信者$の~software~systemについての情報 ］を露呈することが多い。 これは，理論においては、 攻撃者が既知な~securityの穴を悪用し易くし得る — 実施においては、 攻撃者は，［ 利用されている ~~見かけの~software~version ］に関わらず，~~可能性がある すべての穴を試行する傾向にあるが。 ◎ The User-Agent (Section 10.1.5), Via (Section 7.6.3), and Server (Section 10.2.4) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the apparent software versions being used.

［ ~network~firewallを通る~portalとして~serveする`~proxy$ ］は、［ ~firewallの背後の~hostを識別し得るような ~header情報 ］の転送に関して，特別な予防策を~~講じる~OUGHT。 `Via$h ~headerは、［ 敏感な~machine名を `pseudonym$p に置換する ］ことを`媒介者$に許容する。 ◎ Proxies that serve as a portal through a network firewall ought to take special precautions regarding the transfer of header information that might identify hosts behind the firewall. The Via header field allows intermediaries to replace sensitive machine names with pseudonyms.

17.13. ~browser指紋収集

~browser指紋収集（ `fingerprinting^en ）は、［ 一意な［ ~UAの各種~特性からなる集合 ］を通して，特定の~UAを時間~越しに識別する ］ための，様々な技法の~~総称である。 これらの特性には、［ ~UAが下層の~transport~protocolをどう利用するか, ~UAに備わる特能, ~UAの~scripting環境 ］に関係する情報も含まれ得る — 特に関心を引くものは、［ ~HTTPを介して通信され得る，一意な【個別の~UAを一意に~~特定するような】特性たちが成す集合 ］である。 指紋収集は，［ ~UAの挙動を時間~越しに追跡すること `Bujlow$r ］を — 利用者が，他の形の~data~collection（例：~cookie）に対しては持ち得るような、 対応する制御なしに — 可能化するので、 ~privacy懸念と見なされる。 多くの一般用~UA（すなわち，~web~browser）は、 指紋収集を抑制する手続きを踏んでいる。 ◎ Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics. These characteristics might include information related to how it uses the underlying transport protocol, feature capabilities, and scripting environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP. Fingerprinting is considered a privacy concern because it enables tracking of a user agent's behavior over time ([Bujlow]) without the corresponding controls that the user might have over other forms of data collection (e.g., cookies). Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints.

いくつもの要請~headerが、 一意に足る指紋収集を可能化するような情報を，~serverに露呈し得る。 最も明白なのは `From$h ~headerである — それは、［ 利用者から，自己の識別が欲されている ］ときに限り，送信されるものと期待されているが。 同様に， `Cookie$h ~headerは、［ 再~識別を可能化するよう，故意に設計されている ］ので，指紋収集の懸念が適用されるのは［ ~UAの環境設定により，~cookieが不能化-または制約されている状況 ］に限られる。 ◎ There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable fingerprinting. The From header field is the most obvious, though it is expected that From will only be sent when self-identification is desired by the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so fingerprinting concerns only apply to situations where cookies are disabled or restricted by the user agent's configuration.

`User-Agent$h ~headerは、 特に`~UA$が［ 利用者の~systemや拡張についての過度な詳細 ］を送信した場合に，［ 通例的に，他の特性と組合されたとき、 特定の機器を一意に識別するに十分な情報 ］を包含し得る。 しかしながら，それよりも［ 利用者が まず予期しないであろう，一意な情報の~source ］を成すものは、 `~proactive折衝~header$であり，次が含まれる ⇒＃ `Accept$h, `Accept-Charset$h, `Accept-Encoding$h, `Accept-Language$h ◎ The User-Agent header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique information that is least expected by users is proactive negotiation (Section 12.1), including the Accept, Accept-Charset, Accept-Encoding, and Accept-Language header fields.

指紋収集の懸念に加えて，［ `Accept-Language$h ~headerの詳細な利用 ］は、［ 利用者が私的な資質と見なし得る情報 ］を露呈し得る。 例えば，［ 所与の言語~集合を解すること ］は、［ 特定0の民族の成員であること ］に強く相関し得る。 ~UAがとり得る，そのような~privacyの損失を制限する~approachとしては、 明示的に許可された~siteを除き， `Accept-Language$h の送信を省略することが挙げられる — たぶん，［ 言語~折衝を指示する `Vary$h ~header ］を検出した後のやりとりを介することが、 有用になり得る。 ◎ In addition to the fingerprinting concern, detailed use of the Accept-Language header field can reveal information the user might consider to be of a private nature. For example, understanding a given language set might be strongly correlated to membership in a particular ethnic group. An approach that limits such loss of privacy would be for a user agent to omit the sending of Accept-Language except for sites that have been explicitly permitted, perhaps via interaction after detecting a Vary header field that indicates language negotiation might be useful.

~privacyを強化するために`~proxy$が利用される環境においては、 `~UA$は［ `~proactive折衝~header$の送信 ］に保守的になる~OUGHT。 ~headerの~~高度な環境設定-能を供する一般用`~UA$は、［ 詳細が供され過ぎる結果，~privacyの損失に繋がり得る ］ことについて，利用者に伝える~OUGHT。 ~~究極の~privacy~~保護措置として、 ~proxyは，中継される要請~内の`~proactive折衝~header$を~filterできる。 ◎ In environments where proxies are used to enhance privacy, user agents ought to be conservative in sending proactive negotiation header fields. General-purpose user agents that provide a high degree of header field configurability ought to inform users about the loss of privacy that might result if too much detail is provided. As an extreme privacy measure, proxies could filter the proactive negotiation header fields in relayed requests.

17.14. 検証子の維持

この仕様により定義される検証子は、［ `表現$の妥当性を確保する／ 悪意的な変更に抗して防護する／ 経路上の攻撃を検出する ］ものとして意図されてはいない。 それらは~~最善でも、 すべての参加者が~~順調に挙動する下で［ より効率的な~cache更新を可能化する／同時並行な書込nをより~~適化する ］だけである。 ~~最悪でも、 条件は失敗し，~clientは［［ 条件付き~でない要請による~HTTP交換 ］以上に有害にはならない，応答 ］を受信するだけである。 ◎ The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious changes, or detect on-path attacks. At best, they enable more efficient cache updates and optimistic concurrent writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response that is no more harmful than an HTTP exchange without conditional requests.

`実体~tag$は、 ~privacy~riskを高める仕方で濫用され得る。 例えば、 ある~siteが，［ 利用者／~UA ］を識別し直す手段として、 意味論的に妥当でない`実体~tag$を［ 利用者／~UA ］間で一意になるよう故意に構築して，それを［ `~cache可能$かつ`鮮度~維持期間$が長い，応答 ］内に送信した上で，［ 今後の`条件付き要請$からその`実体~tag$を読取る ］こともあり得る。 そのような識別-用の~tagは、［ ~UAが元の~cache~entryを維持する限り，持続する ］ような識別子になるであろう。 `表現$を~cacheする~UAは、 利用者が~privacyを保守する動作を遂行したとき — ［ 格納された~cookieを~clearする／私的~閲覧~modeに変える ］など — には，その~cacheが［ ~clearされる／置換される ］ことを確保する~OUGHT。 ◎ An entity tag can be abused in ways that create privacy risks. For example, a site might deliberately construct a semantically invalid entity tag that is unique to the user or user agent, send it in a cacheable response with a long freshness time, and then read that entity tag in later conditional requests as a means of re-identifying that user or user agent. Such an identifying tag would become a persistent identifier for as long as the user agent retained the original cache entry. User agents that cache representations ought to ensure that the cache is cleared or replaced whenever the user performs privacy-maintaining actions, such as clearing stored cookies or changing to a private browsing mode.

17.15. 範囲を利用する~DoS攻撃

拘束されない複数~範囲の要請は、 ~DoS攻撃に~~感受性が~~高い — 重合する多数の範囲を要請する労力は、 要請された~dataを多数の部位tで~serveしようとするときに消費される［ 時間, ~memory, 帯域幅 ］に比較して僅かなので。 `~server$は、 ~~甚しい`範囲~要請$ — 3 個~以上が重合したり, 多数に細切れにされた範囲たちに対する要請 — を［ 無視する／ 合体する／ 却下する ］~OUGHT — 特に，それらの範囲が~~明らかな理由なしに順不同で要請されたとき。 複-部位tな範囲~要請は、 ~random~accessを~supportするように設計されていない。 ◎ Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts. Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason. Multipart range requests are not designed to support random access.

17.16. 認証の考慮点

~HTTP認証の論題については何もかも~securityの考慮点になるので、 以下に挙げる考慮点は，網羅的ではない。 更には、［ 一般的な，認証~frameworkに関する~securityの考慮点 ］に制限されている — 特定の`認証~scheme$について，~~可能性がある考慮点~すべてを論じるのではなく （それらは，各~schemeを定義する仕様にて文書化される~OUGHT）。 様々な組織が，~Web応用の~securityについての時事的な情報や現在の事実調査への~linkを保守する （例： `OWASP$r ） — 実施において見出される`認証~scheme$を［ 実装する／利用する ］際に共通的な罠など。 ◎ Everything about the topic of HTTP authentication is a security consideration, so the list of considerations below is not exhaustive. Furthermore, it is limited to security considerations regarding the authentication framework, in general, rather than discussing all of the potential considerations for specific authentication schemes (which ought to be documented in the specifications that define those schemes). Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]), including common pitfalls for implementing and using the authentication schemes found in practice.

18.1. ~URI~schemeの登録

~IANAは、 `~URI~scheme~registry$cite （ `Uniform Resource Identifier (URI) Schemes^en ） `BCP35$r を更新した — `4.2§に挙げられた恒久的な~schemeを伴うよう： ◎ IANA has updated the "Uniform Resource Identifier (URI) Schemes" registry [BCP35] at <https://www.iana.org/assignments/uri-schemes/> with the permanent schemes listed in Table 2 in Section 4.2.

【 この表tは，原文では `4.2＠#uri.scheme.table§ に在るが、 一貫させるため，ここに与えることにする。 】

18.2. ~methodの登録

~IANAは、 `~HTTP~method~registry$cite （ `Hypertext Transfer Protocol (HTTP) Method Registry^en ） を更新した — `16.1.1§ の登録~手続-に従って， 次の表tに要約される~method名を伴うよう： ◎ IANA has updated the "Hypertext Transfer Protocol (HTTP) Method Registry" at <https://www.iana.org/assignments/http-methods> with the registration procedure of Section 16.1.1 and the method names summarized in the following table.

~method名 "`*^m" は、 予約される — ~method名として "`*^m" を利用すると、 一部の~field （例： `Access-Control-Request-Method$h ） における `wildcard^p としての "`*^c" の用法と競合することになるので。 ◎ The method name "*" is reserved because using "*" as a method name would conflict with its usage as a wildcard in some fields (e.g., "Access-Control-Request-Method").

18.3. 状態s~codeの登録

~IANAは、 `~HTTP状態s~code~registry$cite （ `Hypertext Transfer Protocol (HTTP) Status Code Registry^en ） を更新した — `16.2.1§ の登録~手続-に従って， 次の表tに要約される状態s~code値を伴うよう： ◎ IANA has updated the "Hypertext Transfer Protocol (HTTP) Status Code Registry" at <https://www.iana.org/assignments/http-status-codes> with the registration procedure of Section 16.2.1 and the status code values summarized in the following table.

18.4. ~field名の登録

この仕様は、［ `RFC3864$r にて定義された，~message~header~field用の既存の登録~手続- ］の［ ~HTTPに関係する側面 ］を更新する。 それは、［ 新たな登録~手続-を定義して， ~HTTP~field定義を別々な~registryの中へ移動する ］ことにより，~HTTPに関係する旧-手続-を置換する。 ◎ This specification updates the HTTP-related aspects of the existing registration procedures for message header fields defined in [RFC3864]. It replaces the old procedures as they relate to HTTP by defining a new registration procedure and moving HTTP field definitions into a separate registry.

~IANAは、 `~HTTP~field名~registry$cite と称される新たな~registryを， `16.3.1§ にて要旨されるとおりに作成した。 ◎ IANA has created a new registry titled "Hypertext Transfer Protocol (HTTP) Field Name Registry" as outlined in Section 16.3.1.

~IANAは、 `~message~header＠~IANA-a/message-headers/$cite （ `Message Headers^en ） ~registry内の［ 恒久的~message~header名, 暫定的~message~header名 ］~registry内に在った~entryのうち［ ~protocol `http^c を伴うものすべて ］を，この~registryに移動した — 加えて、 次に挙げる変更を適用した： ◎ IANA has moved all entries in the "Permanent Message Header Field Names" and "Provisional Message Header Field Names" registries (see <https://www.iana.org/assignments/message-headers/>) with the protocol 'http' to this registry and has applied the following changes:

1. “適用-可能な~protocol” ~fieldは、 省略した。 ◎ The 'Applicable Protocol' field has been omitted.
2. 位置付け［ `standard^en ／ `experimental^en ／ `reserved^en ／ `informational^en ］【 “標準” ／ “試験的” ／ “予約-済み” ／ “参考” 】 を伴っていた~entryには、 位置付け `恒久的^i を伴わせた。 ◎ Entries that had a status of 'standard', 'experimental', 'reserved', or 'informational' have been made to have a status of 'permanent'.
3. 位置付けを伴っていなかった暫定的な~entryには、 位置付け `暫定的^i を伴わせた。 ◎ Provisional entries without a status have been made to have a status of 'provisional'.
4. 位置付けを伴っていなかった恒久的な~entry （確認~後に，それを登録した文書が定義していなかったもの） には、 位置付け `暫定的^i を伴わせた。 専門家（たち）は、 別の位置付けの方が適切とする根拠があるならば， 当の~entryの位置付けを更新することを選べる。 ◎ Permanent entries without a status (after confirmation that the registration document did not define one) have been made to have a status of 'provisional'. The expert(s) can choose to update the entries' status if there is evidence that another is more appropriate.

~IANAは、［ 恒久的~message~header名, 暫定的~message~header名 ］~registryに対し，［ ~HTTP~field名の登録は移動されたこと ］を指示する次の注記（ `Note^en ）で注釈した ⇒ HTTP field name registrations have been moved to [https://www.iana.org/assignments/http-fields] per [RFC9110]. 【 “~HTTP~field名の登録は、`RFC9110^r に従って， `~HTTP~field名~registry$cite へ移動された。” 】 ◎ IANA has annotated the "Permanent Message Header Field Names" and "Provisional Message Header Field Names" registries with the following note to indicate that HTTP field name registrations have moved: ◎ Note • HTTP field name registrations have been moved to [https://www.iana.org/assignments/http-fields] per [RFC9110].

~IANAは、 `~HTTP~field名~registry$cite （ `Hypertext Transfer Protocol (HTTP) Field Name Registry^en ） を更新した — 次の表tに挙げる~field名を伴うよう： ◎ IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name Registry" with the field names listed in the following table.

~field名 "`*@h" は、 予約される — その名前は、 `Vary$h ~headerにおいて特別な意味論があり， ~HTTP~headerとして利用すると競合するかもしれないので。 ◎ The field name "*" is reserved because using that name as an HTTP header field might conflict with its special semantics in the Vary header field (Section 12.5.5).

~IANAは、 新たな~registryにおける "`Content-MD5^h" ~entryの位置付けを `廃用d^i に更新した — 次への参照も伴わせた上で ⇒＃ （この~fieldを定義した） `2616/14.15$rfc, （その定義を除去した） `RFC7231$r `B＠~RFC7231#appendix-B§ ◎ IANA has updated the "Content-MD5" entry in the new registry to have a status of 'obsoleted' with references to Section 14.15 of [RFC2616] (for the definition of the header field) and Appendix B of [RFC7231] (which removed the field definition from the updated specification).

18.5. 認証~schemeの登録

~IANAは、 `~HTTP認証~scheme~registry$cite （ `Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry^en ） を `16.4.1§ の登録~手続-に従って更新した — この文書~内に定義される認証~schemeは無い。 ◎ IANA has updated the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" at <https://www.iana.org/assignments/http-authschemes> with the registration procedure of Section 16.4.1. No authentication schemes are defined in this document.

18.6. 内容~符号法の登録

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

18.7. 範囲~単位の登録

~IANAは、 `~HTTP範囲~単位~registry＠~IANA-a/http-parameters/$cite （ `HTTP Range Unit Registry^en ） を更新した — `16.5.1§ の登録~手続-に従って， 次の表tに要約される範囲~単位~名を伴うよう： ◎ IANA has updated the "HTTP Range Unit Registry" at <https://www.iana.org/assignments/http-parameters/> with the registration procedure of Section 16.5.1 and the range unit names summarized in the table below.

18.8. ~MIME型の登録

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

~IANAは、 "`q$c" ~parameterについての~registry注記を， この文書の `Accept§h への~linkを伴うよう更新した。 ◎ IANA has updated the registry note about "q" parameters with a link to Section 12.5.1 of this document.

18.9. ~portの登録

~IANAは、［ ~UDP ／ ~TCP ］を利用する~port［ 80, 443 ］上の~service用に， `~service名と~transport~protocol~port番号~registry$cite （ `Service Name and Transport Protocol Port Number Registry^en ） を次のように更新した： ◎ IANA has updated the "Service Name and Transport Protocol Port Number Registry" at <https://www.iana.org/assignments/service-names-port-numbers/> for the services on ports 80 and 443 that use UDP or TCP to:

• この文書を “参照” として利用する ◎ use this document as "Reference", and
• 現在~未指定であった［ “`Assignee^en” は "IESG", “`Contact^en” は "IETF_Chair" ］に設定する。 ◎ when currently unspecified, set "Assignee" to "IESG" and "Contact" to "IETF_Chair".

18.10. `Upgrade^h ~tokenの登録

~IANAは、 `~HTTP~Upgrade~token~registry$cite （ `Hypertext Transfer Protocol (HTTP) Upgrade Token Registry^en ） を更新した — `16.7§ に述べた登録~手続-に従って， 次の表tに要約される `Upgrade$h ~token名を伴うよう： ◎ IANA has updated the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" at <https://www.iana.org/assignments/http-upgrade-tokens> with the registration procedure described in Section 16.7 and the upgrade token names summarized in the following table.

B.1. RFC 2818 からの変更点

無い。 ◎ None.

【 `7105$errata（Verified）： ~CN-IDの利用は非推奨にされた。 （ `4.3.4§ ） 】

B.2. RFC 7230 からの変更点

~HTTPの［ 設計~目標, 歴史, ~architecture, 適合性の判定基準, ~protocol~version法, ~URI, ~message~route法, `~header$ ］を導入している各~節は、 ここに移動された。 ◎ The sections introducing HTTP's design goals, history, architecture, conformance criteria, protocol versioning, URIs, message routing, and header fields have been moved here.

意味論上の適合性に対する要件は、 実装に特有な失敗［ を無視する／に対処する ］ことの許可に置換された。 （ `2.2§ ） ◎ The requirement on semantic conformance has been replaced with permission to ignore or work around implementation-specific failures. (Section 2.2)

［ `生成元$, および`生成元~server$への権限的な~access ］についての記述は、 ~TCPに基づくとは限らない［ 代替な~service／~secure化された接続 ］も織り込むため，［ "`http^c", "`https^c" ］両~URI用に拡張された。 （ `http§c, `https§c, `4.3.1§, `7.3.3§ ） ◎ The description of an origin and authoritative access to origin servers has been extended for both "http" and "https" URIs to account for alternative services and secured connections that are not necessarily based on TCP. (Sections 4.2.1, 4.2.2, 4.3.1, and 7.3.3)

［ `~target~URI$の~schemeの意味論を検査して、 それに結付けられた要件を満たさない要請は，却下する ］とする，明示的な要件を追加した。 （ `7.4§ ） ◎ Explicit requirements have been added to check the target URI scheme's semantics and reject requests that don't meet any associated requirements. (Section 7.4)

［ `media-type$p ／ `media-range$p ／ `expectation$p ］内の `parameters$p は、 尾部にある 1 個以上の~semicolonを介して空になり得る。 （ `5.6.6§ ） ◎ Parameters in media type, media range, and expectation can be empty via one or more trailing semicolons. (Section 5.6.6)

`~field値$は、 今や複数個の~field行lの値を~commaで結合した後の値を指す — それが他よりずっと共通的な利用なので。 単独の`~field行l$【！~header行l】【！`6.3§】の値を指すときは、 `~field行l値$を利用すること。 ◎ "Field value" now refers to the value after multiple field lines are combined with commas -- by far the most common use. To refer to a single header line's value, use "field line value". (Section 6.3)

`~trailer$の意味論は、 今や `chunked$c `転送~符号法$に特有なそれを超越している （ `6.5.1§ ）： ◎ Trailer field semantics now transcend the specifics of chunked transfer coding.＼

• `~trailer$の利用は、 更に制限された： ◎ The use of trailer fields has been further limited＼

  • `~trailer$としての生成は、 送信者が［ 当の`~field$は、 そのような用法を定義している ］ことを知っているときに限り許容される。 ◎ to allow generation as a trailer field only when the sender knows the field defines that usage and＼
  • `~trailer$を`~header節$の中に併合することは、 受信者が［ 対応する~field定義は、 そうすることを許可していて，そうする方法を定義する ］ことを知っている場合に限り，許容される。 ◎ to allow merging into the header section only if the recipient knows the corresponding field definition permits and defines how to merge.＼
• 他のすべての事例では、 実装には、 `~trailer$を併合する代わりに，別々に格納するか破棄することが奨励される。 ◎ In all other cases, implementations are encouraged either to store the trailer fields separately or to discard them instead of merging. (Section 6.5.1)

`絶対~形$による要請~URIの優先度を — ~proxyの取扱いに揃えるため — 明示的に，`生成元~server$による `Host^h ~headerよりも高くした。 （ `Host§h ） ◎ The priority of the absolute form of the request URI over the Host header field by origin servers has been made explicit to align with proxy handling. (Section 7.2)

`Via^h ~fieldの `received-by$p 用の文法~定義は、［ ~URI文法における `host$p に対する変更 `URI$r ］に因り `RFC7230$r において拡げられたが， `Via^h 用には望ましくない。 単純にするため， `received-by$p 生成規則から `uri-host$p を除去した — それは、 既存の `pseudonym$p 用の文法により包摂できるので。 特に，この変更により、［ `received-by$p において~host名に許容される文字たちが成す集合 ］から，~commaが除去された。 （ `Via§h ） ◎ The grammar definition for the Via field's "received-by" was expanded in RFC 7230 due to changes in the URI grammar for host [URI] that are not desirable for Via. For simplicity, we have removed uri-host from the received-by production because it can be encompassed by the existing grammar for pseudonym. In particular, this change removed comma from the allowed set of characters for a host name in received-by. (Section 7.6.3)

B.3. RFC 7231 からの変更点

実装が~supportすることになる最小な~URI長さは、 今や推奨される。 （ `4.1§ ） ◎ Minimum URI lengths to be supported by implementations are now recommended. (Section 4.1)

［ `media-type$p ／ `media-range$p ／ `expectation$p ］内の `parameters$p は、 尾部にある 1 個以上の~semicolonを介して空になり得る。 （ `5.6.6§ ） ◎ Parameters in media type, media range, and expectation can be empty via one or more trailing semicolons. (Section 5.6.6)

~messageを成す各種~成分と それらの意味論を複数の~HTTP~versionにまたがる抽象-化として定義するため、 ~HTTP~message用の抽象-~data型を導入した — `HTTP/1.1$r における~HTTP11に特有な構文の形によらない, かつ~messageを構文解析した後の内容を反映するよう。 これは、 `内容$に対する要件（何が伝達されるか）と~message法~構文に対する要件（どう伝達されるか）を より判別し易くすることに加え， 早期の`~protocol~version$における制限を将来の~HTTPの中に焼付けることを避ける。 （ `6§ ） ◎ An abstract data type for HTTP messages has been introduced to define the components of a message and their semantics as an abstraction across multiple HTTP versions, rather than in terms of the specific syntax form of HTTP/1.1 in [HTTP/1.1], and reflect the contents after the message is parsed. This makes it easier to distinguish between requirements on the content (what is conveyed) versus requirements on the messaging syntax (how it is conveyed) and avoids baking limitations of early protocol versions into the future of HTTP. (Section 6)

用語［ “~payload”, “~payload本体” ］を “`内容$” に置換した — 他所における（例：`~field名$における）その用法に もっと良く揃えるため，および［ ~HTTP2／~HTTP3 ］における~frame~payloadとの混同を避けるため。 （ `6.4§ ） ◎ The terms "payload" and "payload body" have been replaced with "content", to better align with its usage elsewhere (e.g., in field names) and to avoid confusion with frame payloads in HTTP/2 and HTTP/3. (Section 6.4)

用語 “実効~要請~URI” を “`~target~URI$” に置換した。 （ `7.1§ ） ◎ The term "effective request URI" has been replaced with "target URI". (Section 7.1)

~clientによる再試行に対する制約を実装の挙動を反映するよう~~緩めた。 （ `9.2.2§ ） ◎ Restrictions on client retries have been loosened to reflect implementation behavior. (Section 9.2.2)

［ `GET^m ／ `HEAD^m ／ `DELETE^m ］要請~内の`内容$【！本体】は相互運用可能でない事実を明確化した。 （ `GET§m ／ `HEAD§m ／ `DELETE§m ） ◎ The fact that request bodies on GET, HEAD, and DELETE are not interoperable has been clarified. (Sections 9.3.1, 9.3.2, and 9.3.5)

`Content-Range$h ~headerを `PUT^m 要請に対する改変子として利用することを許容した。 （ `PUT§m ） ◎ The use of the Content-Range header field (Section 14.4) as a request modifier on PUT is allowed. (Section 9.3.4)

`OPTIONS^m ~methodの記述から `Content-Length$h の設定についての過剰な要件を除去した。 （ `OPTIONS§m ） ◎ A superfluous requirement about setting Content-Length has been removed from the description of the OPTIONS method. (Section 9.3.7)

［ `TRACE$m 応答~内には~MIME型 `message/http＠~HTTPv1#media.type.message.http$c を利用する ］とする規範的な要件を除去した。 （ `TRACE§m ） ◎ The normative requirement to use the "message/http" media type in TRACE responses has been removed. (Section 9.3.8)

RFC 2616 との互換性を得るため、 `Expect^h 用に，~listに基づく文法を復旧した（ `Expect§h ） ◎ List-based grammar for Expect has been restored for compatibility with RFC 2616. (Section 10.1.1)

`応答~message$内にも［ `Accept$h ／ `Accept-Encoding$h ］を許容した — 後者は `RFC7694$r により導入された。 （ `12.3§ ） ◎ Accept and Accept-Encoding are allowed in response messages; the latter was introduced by [RFC7694]. (Section 12.3)

`Accept^h ~fieldの定義から［ `accept-params^p, `accept-ext^p ］~ABNF生成規則を【その `weight^p のみを残して】除去した。 （ `Accept§h ） ◎ "Accept Parameters" (accept-params and accept-ext ABNF production) have been removed from the definition of the Accept field. (Section 12.5.1)

`Accept-Charset^h ~fieldは、 今や非推奨にされた。 （ `Accept-Charset§h ） ◎ The Accept-Charset field is now deprecated. (Section 12.5.2)

`Vary^h ~header内に［ "`*^c" が他の値とともに在るとき ］の意味論を明確化した。 （ `Vary§h ） ◎ The semantics of "*" in the Vary header field when other values are present was clarified. (Section 12.5.5)

`範囲~単位$は、 文字大小無視で比較するものとした。 （ `14.1§ ） ◎ Range units are compared in a case-insensitive fashion. (Section 14.1)

`Accept-Ranges^h ~fieldの利用は、 `生成元~server$のみに制約されないとした。 （ `Accept-Ranges§h ） ◎ The use of the Accept-Ranges field is not restricted to origin servers. (Section 14.3)

~redirectされた要請【に対し，送信し直す要請】を作成する処理nを明確化した。 （ `3xx§st0 ） ◎ The process of creating a redirected request has been clarified. (Section 15.4)

状態s~code `308^st0 を追加した（以前は `RFC7538$r にて定義されていた） — 状態s~code `301$st0, `302$st0, `307$st0 の近くに定義されるよう。 （ `308§st0 ） ◎ Status code 308 (previously defined in [RFC7538]) has been added so that it's defined closer to status codes 301, 302, and 307. (Section 15.4.9)

状態s~code `421^st0 を追加した（以前は `7540/9.1.2$rfc にて定義されていた） — それには、 一般的な適用能があるので。 `421^st0 は、 もはや`経験的に~cache可能$であるものとは定義されない — 当の応答は、 （`~target資源$ではなく）当の接続に特有~なので（ `421§st0 ） ◎ Status code 421 (previously defined in Section 9.1.2 of [RFC7540]) has been added because of its general applicability. 421 is no longer defined as heuristically cacheable since the response is specific to the connection (not the target resource). (Section 15.5.20)

状態s~code `422^st0 を追加した（以前は `WEBDAV$r `11.2＠~RFCx/rfc4918#section-11.2§ にて定義されていた） — それには、 一般的な適用能があるので。 （ `422§st0 ） ◎ Status code 422 (previously defined in Section 11.2 of [WEBDAV]) has been added because of its general applicability. (Section 15.5.21)

B.4. RFC 7232 からの変更点

~HTTPの以前の改訂では、［ `Last-Modified$h が強い検証子を与えているかどうかの決定 ］に［ 恣意的な上限 60 秒 ］を課していた — `Date$h 値と `Last-Modified$h 値が［ 異なる`時計$から`生成-$されるアリ性, あるいは 応答を準備する間に時刻がずれること ］に抗して防護するために。 この仕様は、 適度な裁量を許容するよう，それを緩めた。 （ `8.8.2.2§ ） ◎ Previous revisions of HTTP imposed an arbitrary 60-second limit on the determination of whether Last-Modified was a strong validator to guard against the possibility that the Date and Last-Modified values are generated from different clocks or at somewhat different times during the preparation of the response. This specification has relaxed that to allow reasonable discretion. (Section 8.8.2.2)

［ `If-Match^h ／ `If-Unmodified-Since^h ］に対する際どい事例における要件を除去した — それは、 当の変更~要請が すでに適用-済みであったため，検証に失敗したときには、 `2xx$st0 応答~内に検証子を送信しないことを要求していた。 （ `If-Match§h, `If-Unmodified-Since§h ） ◎ An edge-case requirement on If-Match and If-Unmodified-Since has been removed that required a validator not to be sent in a 2xx response if validation fails because the change request has already been applied. (Sections 13.1.1 and 13.1.4)

`If-Unmodified-Since^h は、 改変~時刻の概念が無い資源には，適用されない事実を明確化した。 （ `If-Unmodified-Since§h ） 【が、該当する記述は，後の更新により削除された。】 ◎ The fact that If-Unmodified-Since does not apply to a resource without a concept of modification time has been clarified. (Section 13.1.4)

`事前条件$は，今や、 要請の`内容$が処理される前に — 処理した結果，成功裡な応答になるかどうか待機することなく — 評価され得る。 （ `13.2§ ） ◎ Preconditions can now be evaluated before the request content is processed rather than waiting until the response would otherwise be successful. (Section 13.2)

B.5. RFC 7233 からの変更点

［ `range-unit$p, `ranges-specifier$p ］文法を~~再構成して、 `bytes$c と他の（拡張）範囲~単位との間の人為的な区別を単純~化し，抑制した — `範囲~単位$を汎用な `token$p として定義して，拡張（ `other-range$p ）を `range-spec$p の視野の中に置くことにより、 `other-range-unit^p の重合している文法は除去された。 これは，拡張~範囲~単位を含む すべての範囲~集合において、 ~list構文（~comma）の役割を — 複数個の範囲の `range-set$p を指示するよう — 一義化する。 拡張~文法を範囲~指定子の中に移動することは、 `~byte範囲$に特有な~protocolを別々に指定することも許容する。 ◎ Refactored the range-unit and ranges-specifier grammars to simplify and reduce artificial distinctions between bytes and other (extension) range units, removing the overlapping grammar of other-range-unit by defining range units generically as a token and placing extensions within the scope of a range-spec (other-range). This disambiguates the role of list syntax (commas) in all range sets, including extension range units, for indicating a range-set of more than one range. Moving the extension grammar into range specifiers also allows protocol specific to byte ranges to be specified separately.

今や，拡張~methodに対しても`範囲~要請$の取扱いを定義することをアリにした。 （ `Range§h ） ◎ It is now possible to define Range handling on extension methods. (Section 14.2)

`Content-Range$h ~headerを `PUT$m 要請に対する改変子として利用して，部分的な `PUT$m を遂行することについて述べた。 （ `14.5§ ） ◎ Described use of the Content-Range header field (Section 14.4) as a request modifier to perform a partial PUT. (Section 14.5)

B.6. RFC 7235 からの変更点

無い。 ◎ None.

B.7. RFC 7538 からの変更点

無い。 ◎ None.

B.8. RFC 7615 からの変更点

無い。 ◎ None.

B.9. RFC 7694 からの変更点

この仕様は、 `RFC7694$r により定義された拡張を含む — その［ § 例, § 配備~上の考慮点 ］は、 割愛するが。 ◎ This specification includes the extension defined in [RFC7694] but leaves out examples and deployment considerations.