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§ ）†, `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

† この文書が廃用にするのは、 `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†／共用~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には現れないが）。 】【† 元の~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では）経路上の攻撃者†かどうか判別-不能なので、［ ~HTTP意味論を誤解して違反することに因る，~securityの欠陥や相互運用能の問題 ］が導入されることも多い。 【† `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利用e~施策を施行するため ］として，共通的に見出される ◎ 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法や, 応答の意味論 ］を変更することなく安全に無視できる ］ならば，それらを破棄するか, 切落して†もヨイ。 ◎ 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.

【† `~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しか見越さないもの†を指して、 `単数~field@ （ `singleton field^en ）という。 ◎ Fields that only anticipate a single member as the field value are referred to as "singleton fields".

【† 見越さないとしても、 下に述べるように，`~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 ）† は、 `~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.

【† この訳では、 一律に，略称（俗称）である “~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