HTTP に基づくプロトコルの築き方

1.1. 表記規約

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

2.1. 非~HTTP~protocol

~HTTPに依拠する応用には、［ 上で定義した，~HTTPを利用するための判定基準 ］を満たさないものもあり得る。 例えば，ある応用は、 ~message形式を成す各部を指定し直すのは避けたいが，［ ~protocolの運用を成す他の側面を変更するよう望む／ 応用に特有な`~method$を利用するよう求める ］かもしれない。 ◎ An application can rely upon HTTP without meeting the criteria for using it as defined above. For example, an application might wish to avoid re-specifying parts of the message format but might change other aspects of the protocol's operation, or it might want to use application-specific methods.

そうすることは，~protocolの運用を改変する自由度をさらに許可するが、 少なくとも，`3§ に要旨される便益を成す一部分は失われる — ほとんどの~HTTP実装は、 そのような変更を容易には採用-可能ではないので。 ~~認識共有（ `mindshare^en ）による便益も，失われることになる。 ◎ Doing so permits more freedom to modify protocol operations, but at least a portion of the benefits outlined in Section 3 are lost as most HTTP implementations won't be easily adaptable to these changes. The benefit of mindshare will also be lost.

そのような仕様は、 ~HTTPの［ ~URI~scheme／ ~transport用の~port／ ~ALPN~protocol~ID／ ~IANA~registry ］を利用してはナラナイ — それらには、 自前のものを確立することが奨励される。 ◎ Such specifications MUST NOT use HTTP's URI schemes, transport ports, ALPN protocol IDs, or IANA registries; rather, they are encouraged to establish their own.

3.1. 汎用な意味論

~HTTPの価値の多くは、 その汎用な意味論が占める — すなわち，~HTTPにより定義される~protocol要素は、 どの`資源$にも適用-可能になり得る — 特定0の文脈に特有ではなく。 応用に特有な意味論は、 `~message$の［ `内容$内／`~header$ ］に表出されるのが最善である — ［ `状態s~code$／`~method$ ］ではなく （これらにも，応用の状態に関係する汎用な意味論はあるが）。 ◎ Much of the value of HTTP is in its generic semantics -- that is, the protocol elements defined by HTTP are potentially applicable to every resource and are not specific to a particular context. Application-specific semantics are best expressed in message content and header fields, not status codes or methods (although status codes and methods do have generic semantics that relate to application state).

このように［ 汎用なもの, 応用に特有なもの ］に分かつことは、 共通な~software （例： ~HTTP［ `~server$／`媒介者$／`~client$ ］の実装, および`~cache$）が［ 利用-中にある応用を解することなく， ~HTTP`~message$を取扱う ］ことを許容する。 それはまた、 人々が［ 特定0の応用に特化された知識を必要とすることなく， ~HTTP意味論に関する自身の知識を活用する ］ことも許容する。 ◎ This split between generic and application-specific semantics allows an HTTP message to be handled by common software (e.g., HTTP servers, intermediaries, client implementations, and caches) without requiring those implementations to understand the application in use. It also allows people to leverage their knowledge of HTTP semantics without needing specialised knowledge of a particular application.

したがって，~HTTPを利用する応用は、 汎用な~protocol要素 — `~method$, `状態s~code$, 既存の`~header$, など — の意味論を定義し直したり, 精緻化したり, その上に層を重ねてはナラナイ。 代わりに，応用は、 自身の仕様において，自身に特有な~protocol要素 — ~~具体的には，自身の~HTTP`資源$ — に対し注力するべきである。 ◎ Therefore, applications that use HTTP MUST NOT redefine, refine, or overlay the semantics of generic protocol elements such as methods, status codes, or existing header fields. Instead, they should focus their specifications on protocol elements that are specific to that application -- namely, their HTTP resources.

仕様を書くときは、 ~HTTPが正確にどう［ 実装され, ~supportされ, 利用されるか ］を指定しがちである。 しかしながら，これは、 意図されない［ ~HTTPの挙動を成す~profile ］へ容易に導く。 例えば、 次の様な文言が記された仕様は，共通的に見かける ⇒ `POST^m 要請による結果は `201$st 応答でなければナラナイ ◎ When writing a specification, it's often tempting to specify exactly how HTTP is to be implemented, supported, and used. However, this can easily lead to an unintended profile of HTTP behaviour. For example, it's common to see specifications with language like this: • A POST request MUST result in a 201 (Created) response.

これは，［ `~client$において，応答は常に `201$st になる ］という期待を形成する — 現実の配備において`状態s~code$が なぜ相違し得るかには，いくつか理由があるにもかかわらず： 例えば，［ 認証を要求する`~proxy$／~server側の~error【 `5xx$st0 】／~redirection【 `3xx$st0 】 ］があるかもしれない。 `~client$が これを見越さない場合、 応用の配備は不安定になる。 ◎ This forms an expectation in the client that the response will always be 201 (Created) when in fact there are a number of reasons why the status code might differ in a real deployment; for example, there might be a proxy that requires authentication, or a server-side error, or a redirection. If the client does not anticipate this, the application's deployment is brittle.

より詳細は、 `4.2§ を見よ。 ◎ See Section 4.2 for more details.

3.2. ~link

別の共通的な実施は、 ~HTTP`~server$の名前空間（または，その一部分）を［ 単独の応用の利用~用に排他的である ］と見做すことである。 これは，実質的に、 その空間の上に特別な，応用に特有な意味論の層を重ねる — その結果，他の応用がそれを利用するのを予め除外する。 ◎ Another common practice is assuming that the HTTP server's namespace (or a portion thereof) is exclusively for the use of a single application. This effectively overlays special, application-specific semantics onto that space and precludes other applications from using it.

`BCP190$r にて説明されるとおり，［ ある標準による，~URL空間の一部に対する そのような “独り占め” ］は、 `~server$の自前の`資源$に対する権限を強奪する — したがって，配備における課題をもたらし得る — ので，標準における不良な実施である。 ◎ As explained in [BCP190], such "squatting" on a part of the URL space by a standard usurps the server's authority over its own resources, can cause deployment issues, and is therefore bad practice in standards.

~HTTPを利用している応用には、 ~pathの様な~URI成分を静的に定義する代わりに，［ 配備における柔軟性を許容するよう，`~link$ `WEB-LINKING$r を定義して利用する ］ことが`推奨される^2119。 ◎ Instead of statically defining URI components like paths, it is RECOMMENDED that applications using HTTP define and use links [WEB-LINKING] to allow flexibility in deployment.

この流儀で稼働時の~linkを利用することには、 他にも便益がいくつかある — とりわけ，応用に複数の実装や配備があるときに （該当する事例は、 標準~化されたものにも多い）。 ◎ Using runtime links in this fashion has a number of other benefits -- especially when an application is to have multiple implementations and/or deployments (as is often the case for those that are standardised).

例えば，~linkで~navigateすることは、 要請が［ ~redirectionの~overheadを伴わずに，異なる`~server$へ~routeされる ］ことを許容する — それにより、 複数の~machineにまたがる配備も，きちんと~supportする。 ◎ For example, navigating with a link allows a request to be routed to a different server without the overhead of a redirection, thereby supporting deployment across machines well.

~linkを利用することで、［ 同じ`~server$上で異なる複数の応用を “引き合わせる” ］こともアリになる。 また，~linkの利用は、［ 拡張能, ~version付け, 能力 ］の管理~用に自然な仕組みを提供する — 当の~linkを包含している文書【`内容$】は、 その~targetについての情報も包含できるので。 ◎ By using links, it also becomes possible to "mix and match" different applications on the same server. The use of links also offers a natural mechanism for extensibility, versioning, and capability management because the document containing the links can also contain information about their targets.

また，~linkを利用することは、 ~Webにて見かける形の［ ~cacheの無効化 ］を提供する。 ある`資源$の状態が変化したとき、 応用は，影響される~linkを — 常に新鮮な複製が~fetchされるよう — 変更できる。 ◎ Using links also offers a form of cache invalidation that's seen on the Web; when a resource's state changes, the application can change the affected links so that a fresh copy is always fetched.

より詳細は `4.4§ を見よ。 ◎ See Section 4.4 for more details.

3.3. 多彩な機能性

~HTTPは、 いくつかの特能 — 次に挙げるものなど — を応用に提供する： ◎ HTTP offers a number of features to applications, such as:

• ~message~frame法 ◎ Message framing
• 多重化-法 （~HTTP2 `HTTP/2$r ／ ~HTTP3 `HTTP/3$r における） ◎ Multiplexing (in HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3])
• ~TLSとの統合 ◎ Integration with TLS
• `媒介者$ （`~proxy$, `~gateway$, ~CDN（ `content delivery network^en ）） 用の~support ◎ Support for intermediaries (proxies, gateways, content delivery networks (CDNs))
• ~client認証 ◎ Client authentication
• ［ 形式, 言語, その他 ］の特能~用の`内容~折衝$ ◎ Content negotiation for format, language, and other features
• ［ ~serverの~scale能, 待時間と帯域幅の抑制, 信頼性 ］を得るための~caching ◎ Caching for server scalability, latency and bandwidth reduction, and reliability
• ~access制御の粒度（~URLの多彩な空間の利用を通して） ◎ Granularity of access control (through use of a rich space of URLs)
• 応答【の`表現~data$】の一部を選択的に要請するための，部分的な内容【`範囲~要請$】 ◎ Partial content to selectively request part of a response
• 応用が~Web~browserを利用して容易にヤリトリする能 ◎ The ability to interact with the application easily using a Web browser

~HTTPを利用する応用には、 ~HTTPが提供する様々な特能を用立てることが奨励される — ［ その利用者が，それらの特能から最大な便益を受取れる ］よう，および［ 応用を多様な状況において配備できる ］よう。 この文書は、 特定の特能を利用するよう要求することはない — 設計における適切な~trade-offは、 所与の状況に特有なので。 しかしながら、 `4§ に与える実施に従うことは，良い出発点になる。 ◎ An application that uses HTTP is encouraged to utilise the various features that the protocol offers so that its users receive the maximum benefit from those features and so that the application can be deployed in a variety of situations. This document does not require specific features to be used since the appropriate design trade-offs are highly specific to a given situation. However, following the practices in Section 4 is a good starting point.

4.1. ~HTTPの利用の指定-法

応用の仕様は、 `HTTP$r を~HTTP用の首な参照として利用するべきである。 応用は、 特有な理由が無い限り（例：特定0の特能を呼び出すなど），［ ~HTTP一式を成す すべての仕様 ］を参照することは必要yでない。 ◎ Specifications should use [HTTP] as the primary reference for HTTP; it is not necessary to reference all of the specifications in the HTTP suite unless there are specific reasons to do so (e.g., a particular feature is called out).

~HTTPは`隣点間$な~protocolなので、 その接続は，当の応用により制御されない実装 — 例： `~proxy$, ~CDN, ~firewall, 等々 — からも取扱われ得る。 ~HTTPの特定0の~versionを要求することは、 これらの状況における利用を困難にすることに加え，相互運用能を害する。 したがって，~HTTPを利用している応用は、 利用する~HTTPの最低~versionを指定しないことが`推奨される^2119。 ◎ Because HTTP is a hop-by-hop protocol, a connection can be handled by implementations that are not controlled by the application; for example, proxies, CDNs, firewalls, and so on. Requiring a particular version of HTTP makes it difficult to use in these situations and harms interoperability. Therefore, it is NOT RECOMMENDED that applications using HTTP specify a minimum version of HTTP to be used.

しかしながら， 応用の配備が特定0の~HTTP~versionの利用から便益を得ることになる場合 （例：~HTTP2による多重化-法）、 それについて注記される~OUGHT。 ◎ However, if an application's deployment would benefit from the use of a particular version of HTTP (for example, HTTP/2's multiplexing), this ought be noted.

~HTTPが発展する能を保全するため、 ~HTTPを利用している応用は，最高~versionを指定してはナラナイ。 ◎ Applications using HTTP MUST NOT specify a maximum version, to preserve the protocol's ability to evolve.

応用は、 ~protocolにおけるヤリトリの例を指定するときは，［ 要請, 応答 ］両~messageとも［ 完全な`~header節$を伴うように文書化する ］べきである — そうするときは、 ~HTTP11形式 `HTTP/1.1$r が好ましい。 ◎ When specifying examples of protocol interactions, applications should document both the request and response messages with complete header sections, preferably in HTTP/1.1 format [HTTP/1.1].＼

GET /thing HTTP/1.1
Host: example.com
Accept: application/things+json
User-Agent: Foo/1.0

HTTP/1.1 200 OK
Content-Type: application/things+json
Content-Length: 500
Server: Bar/2.2

[内容]

4.2. ~serverの挙動の指定-法

応用の`~server$側における~HTTPの挙動を指定するためには、 次に挙げる~protocol要素を定義するのが最も効果的になる： ◎ The server-side behaviours of an application are most effectively specified by defining the following protocol elements:

• `~MIME型$ `RFC6838$r — ~JSON `JSON$r などの形式~規約に基づくものが多い。 ◎ Media types [RFC6838], often based upon a format convention such as JSON [JSON];
• ~HTTP~header — `4.7§ に従って。 ◎ HTTP header fields, per Section 4.7; and
• `~link関係$ `WEB-LINKING$r により識別される`資源$の挙動。 ◎ The behaviour of resources, as identified by link relations [WEB-LINKING].

応用は、［ `~link関係$により識別され，指定された挙動を実装する`資源$ ］たちが成す集合を［ これらの~protocol要素で構成して定義する ］ことにより，自身の運用を定義できる — 次に挙げるものを含め： ◎ An application can define its operation by composing these protocol elements to define a set of resources that are identified by link relations and that implement specified behaviours, including:

• `GET$m 要請を利用して，資源の状態を［ `~MIME型$により識別される， 1 つ以上の形式 ］で検索取得する。 ◎ retrieval of resource state using GET in one or more formats identified by media type;
• ［ `POST$m ／ `PUT$m ］要請を［ その`内容$の形式が適切に識別される ］ように利用して，資源を作成したり更新する。 ◎ resource creation or update using POST or PUT, with an appropriately identified request content format;
• `POST$m 要請と対する応答, および［ それらの`内容$に対し識別される形式 ］を利用して，~dataを処理する。 ◎ data processing using POST and identified request and response content format(s); and
• `DELETE$m 要請を利用して，資源を削除する。 ◎ Resource deletion using DELETE.

応用は、 `~URI~template^cite `URI-TEMPLATE$r の利用も指定できる — それは、［ `~client$が，稼働時の~dataに基づいて~URLを`生成-$する ］ことを許容する。 ◎ Applications can also specify the use of URI Templates [URI-TEMPLATE] to allow clients to generate URLs based upon runtime data.

4.3. ~clientの挙動の指定-法

利用-時における相互運用能の課題を避けるため、 応用が`~client$に期待する挙動は，~Web~browserの挙動に近いものに揃える~OUGHT。 ◎ An application's expectations for client behaviour ought to be closely aligned with those of Web browsers to avoid interoperability issues when they are used.

これを行う仕方の一つは、 `FETCH$r の用語でそれを定義することである — それが、 ~browserが~HTTP用に利用する抽象-化なので。 ◎ One way to do this is to define it in terms of [FETCH] since that is the abstraction that browsers use for HTTP.

［ `~client$の挙動（例： 自動的な~redirectの取扱い）／ 拡張（例： ~cookie） ］のうち一部のものは、 ~HTTPには要求されないが，それでも ごく共通にある。 ~HTTPを利用している応用が，それらの利用を明示的に指定していない場合、［ ~clientを惑わす問題／相互運用能の問題 ］が生じ得る。 ~HTTPを利用している応用は、 特に： ◎ Some client behaviours (e.g., automatic redirect handling) and extensions (e.g., cookies) are not required by HTTP but nevertheless have become very common. If their use is not explicitly specified by applications using HTTP, there may be confusion and interoperability problems. In particular:

• ~redirectの取扱い ⇒ ~redirectを どう取扱うよう期待するかを指定する必要がある — `4.6.1§ を見よ。 ◎ Redirect handling: • Applications need to specify how redirects are expected to be handled; see Section 4.6.1.
• ~cookie ⇒ 要求される場合には、 ~cookie仕様 `COOKIES$r を明示的に参照するべきである。 ◎ Cookies: • Applications using HTTP should explicitly reference the Cookie specification [COOKIES] if they are required.
• 証明書 ⇒ ~HTTPSを利用する場合、［ `HTTP$r `証明書の検証y＠~HTTPinfra#https.verify§ に則って，~TLS証明書が検査されること ］を指定するべきである。 ◎ Certificates: • Applications using HTTP should specify that TLS certificates are to be checked according to Section 4.3.4 of [HTTP] when HTTPS is used.

~HTTPを利用している応用は、［ ~HTTP特能のうち，通例的に折衝されることになるもの ］を`~client$が静的に~supportするよう要求するべきではない。 例えば、 ~clientに対し，ある種の`内容~符号法$（ `Content-Encoding$h ）を伴う応答を［ そのために（ `Accept-Encoding$h により）折衝することなく，~supportするよう要求する ］ことは、 他では適合tな~clientが当の応用と相互運用できなくなることを意味する。 応用は、 そのような特能の実装を奨励することはできるが。 ◎ Applications using HTTP should not require that clients statically support HTTP features that are usually negotiated. For example, requiring that clients support responses with a certain content coding ([HTTP], Section 8.4.1) instead of negotiating for it ([HTTP], Section 12.5.3) means that otherwise conformant clients cannot interoperate with the application. Applications can encourage the implementation of such features, though.

4.4. ~URLの指定-法

~HTTPにおいては、 `~client$がヤリトリする`資源$は，~URL `URL$r で識別される。 `BCP190$r にて説明されるとおり，~URLの各部は、 配備における柔軟性を`~server$に与えるため， 当の~serverの所有者の制御~下にあるよう設計されている （~serverの “権限（ `authority^en ）” としても知られる）。 ◎ In HTTP, the resources that clients interact with are identified with URLs [URL]. As [BCP190] explains, parts of the URL are designed to be under the control of the owner (also known as the "authority") of that server to give them the flexibility in deployment.

このことは、 ほとんどの事例では，［ ~HTTPを利用する応用~用の仕様は、 固定的な［ 応用の~URL／応用の~path ］を包含しない ］ことを意味する。 ある単独~配備な~API用の ある仕様が（例えば）~path接頭辞 "`/app/v1^c" を指定するような実施は共通的にあるが、 ~IETF仕様において そうすることは，不適切である。 ◎ This means that in most cases, specifications for applications that use HTTP won't contain fixed application URLs or paths; while it is common practice for a specification of a single-deployment API to specify the path prefix "/app/v1" (for example), doing so in an IETF specification is inappropriate.

したがって，仕様の書き手は、 次を指定する必要がある： ◎ Therefore, the specification writer needs＼

• 応用の~URLを発見することを`~client$に許容するための，何らかの仕組み ◎ some mechanism to allow clients to discover an application's URLs.＼
• 応用に利用されるべき~URL~scheme（たち） ◎ Additionally, they need to specify which URL scheme(s) the application should be used with＼
• 応用は［ 専用な~port, ~HTTP用の既定の~port【！reuse HTTP's port(s)】 ］どちらを利用するか ◎ and whether to use a dedicated port or to reuse HTTP's port(s).

4.5. ~HTTP~methodの利用-法

~HTTPを利用する応用は、 利用する~HTTP`~method$を登録-済みなものに限定しなければナラナイ — 次に挙げるものなど ⇒ `GET$m, `POST$m, `PUT$m, `DELETE$m, `PATCH$m ◎ Applications that use HTTP MUST confine themselves to using registered HTTP methods such as GET, POST, PUT, DELETE, and PATCH.

新たな~HTTP~methodは稀である。 それらは、 `~IETFによる考査$の下で `~HTTP~method~registry$cite 内に登録することが要求され （ `HTTP$r `~method~registry＠~HTTPinfra#method.registry§）， 汎用であることも要求される。 すなわち，`~method$は、 一つの応用における`資源$のみならず，すべての資源に適用-可能になり得る必要がある。 ◎ New HTTP methods are rare; they are required to be registered in the "HTTP Method Registry" with IETF Review (see [HTTP]) and are also required to be generic. That means that they need to be potentially applicable to all resources, not just those of one application.

歴史的に，一部の応用（例： `RFC4791$r ）は自身に特有な~methodを定義したが、 `HTTP$r は，今やこれを禁止する。 ◎ While historically some applications (e.g., [RFC4791]) have defined application-specific methods, [HTTP] now forbids this.

策定者は，新たな`~method$が要求されると予見するときは、 ~~早期から~HTTP~communityに携わって （例： mailto:ietf-http-wg@w3.org ~mailing-list）， 自身による提案を — 応用の仕様を成す一部としてではなく — 別々な~HTTP拡張として文書化することが奨励される。 ◎ When authors believe that a new method is required, they are encouraged to engage with the HTTP community early (e.g., on the <mailto:ietf-http-wg@w3.org> mailing list) and document their proposal as a separate HTTP extension rather than as part of an application's specification.

4.6. ~HTTP状態s~codeの利用-法

`状態s~code$は、［ 汎用な~HTTP~component — `~cache$, `媒介者$, `~client$など — および，応用~自身 ］の便益のために意味論を伝達する。 しかしながら、 それらの利用にあたっては，応用が遭遇し得る陥穽もいくつかある。 ◎ HTTP status codes convey semantics both for the benefit of generic HTTP components -- such as caches, intermediaries, and clients -- and applications themselves. However, applications can encounter a number of pitfalls in their use.

まず、 `状態s~code$は，応用~自身~以外の~componentにより`生成-$されることが多い。 これが起こり得るのは、 例えば［ ~network~errorに遭遇した／ ［ `captive portal^en 【`横取n~proxy$】／`~proxy$／~CDN ］が在る ／ ~serverが［ 過負荷になった／攻撃に晒されている ］と~~判断した ］ときが挙げられる。 それらは、 汎用な~client~softwareにより — ある種の~error条件に遭遇したとき — `生成-$されることすらある。 その結果、 ある応用が，そのような状態s~codeに自身に特有な意味論をアテガった場合、 `~client$は，応用の状態について誤った方へ導かれ得る — 当の状態s~codeを`生成-$したのは、 応用ではなく，ある汎用な~componentなので。 ◎ First, status codes are often generated by components other than the application itself. This can happen, for example, when network errors are encountered; when a captive portal, proxy, or content delivery network is present; or when a server is overloaded or thinks it is under attack. They can even be generated by generic client software when certain error conditions are encountered. As a result, if an application assigns specific semantics to one of these status codes, a client can be misled about its state because the status code was generated by a generic component, not the application itself.

更には，応用が自身の~errorを個々の`状態s~code$に一対一に対応付けた場合、 適用-可能な状態s~codeの有限な空間が枯渇する状況に至ることが多い。 これは転じて，例えば次のような不良な実施へ導く ⇒＃ 新たな，応用に特有な状態s~codeを創出する／ 既存の状態s~codeを，その意味論と当の応用の意味論との~~関連性が希薄でしかないのに利用する ◎ Furthermore, mapping application errors to individual HTTP status codes one-to-one often leads to a situation where the finite space of applicable HTTP status codes is exhausted. This, in turn, leads to a number of bad practices -- including minting new, application-specific status codes or using existing status codes even though the link between their semantics and the application's is tenuous at best.

代わりに，~HTTPを利用している応用は、 自身の~errorを最も適用-可能な`状態s~code$を利用するように定義するべきである — 疑わしいときは、 一般~用の状態s~code（ `200$st0, `400$st0, `500$st0 ）の間口が広い利用を為すようにして。 要は、 応用は — 上に要旨した枯渇の課題を避けるよう — 状態s~codeと応用の~errorの間に一対一な関係性を指定しないべきである。 ◎ Instead, applications using HTTP should define their errors to use the most applicable status code, making generous use of the general status codes (200, 400, and 500) when in doubt. Importantly, they should not specify a one-to-one relationship between status codes and application errors, thereby avoiding the exhaustion issue outlined above.

複数の~error条件が同じ`状態s~code$に対応付けられる場合に それらを判別するため， および上に要旨した誤った帰属の課題を避けるため、 ~HTTPを利用している応用は，より木目細かな~error情報を応答の［ `内容$／`~header$ ］内に伝達するべきである。 `PROBLEM-DETAILS$r は、 そうするための仕方の一つを供する。 ◎ To distinguish between multiple error conditions that are mapped to the same status code and to avoid the misattribution issue outlined above, applications using HTTP should convey finer-grained error information in the response's message content and/or header fields. [PROBLEM-DETAILS] provides one way to do so.

登録-済みな`状態s~code$たちが成す集合は，拡げられ得るので、 ~HTTPを利用している応用は，［ `~client$は、 適用-可能なすべての状態s~codeを，上品に取扱える†~OUGHT ］ことを明示的に指摘するべきである （† すなわち、 所与の状態s~codeの意味論は汎用な `n00^st0 に~fall-backする — 例えば `499^st0 を認識しない`~client$は、 それを `400$st として安全に取扱える）。 これは、 あり得る状態s~codeの “~~対処~list（ `laundry list^en ）” を作成するよりも好ましい — そのような~listが，いつの日か完全になる見通しは立たないので。 ◎ Because the set of registered HTTP status codes can expand, applications using HTTP should explicitly point out that clients ought to be able to handle all applicable status codes gracefully (i.e., falling back to the generic n00 semantics of a given status code; e.g., 499 can be safely handled as 400 (Bad Request) by clients that don't recognise it). This is preferable to creating a "laundry list" of potential status codes since such a list won't be complete in the foreseeable future.

~HTTPを利用している応用は、 `状態s~code$の意味論を指定し直してはナラナイ — それらの定義をただ複製するだけであっても。 応用には、 特有な`事由~句$を利用するよう要求しないことが`推奨される^2119 — ~HTTPにおいては，事由~句の機能は無いので、 実装が それを保全することは保証されないことに加え、 ~HTTP2 `HTTP/2$r の~message形式においては，まったく運ばれない。 ◎ Applications using HTTP MUST NOT re-specify the semantics of HTTP status codes, even if it is only by copying their definition. It is NOT RECOMMENDED they require specific reason phrases to be used; the reason phrase has no function in HTTP, is not guaranteed to be preserved by implementations, and is not carried at all in the HTTP/2 [HTTP/2] message format.

`~method$と同じく、 応用は，利用する`状態s~code$を登録-済みなものに限らなければナラナイ。 新たな状態s~codeは稀であり、 `~IETFによる考査$の下で登録することが （ `HTTP$r により）要求される。 `状態s~code$も類似に汎用であり、 一つの応用のみならず，すべての`資源$に適用-可能になり得ることが （ `HTTP$r により）要求される。 ◎ Applications MUST only use registered HTTP status codes. As with methods, new HTTP status codes are rare and required (by [HTTP]) to be registered with IETF Review. Similarly, HTTP status codes are generic; they are required (by [HTTP]) to be potentially applicable to all resources, not just to those of one application.

新たな状態s~codeが要求されると予見する策定者は、 ~~早期から~HTTP~communityに携わって （例： mailto:ietf-http-wg@w3.org ~mailing-list）， 自身の提案を — 応用の仕様の一部としてではなく — 別々な~HTTP拡張として文書化することが奨励される。 ◎ When authors believe that a new status code is required, they are encouraged to engage with the HTTP community early (e.g., on the <mailto:ietf-http-wg@w3.org> mailing list) and document their proposal as a separate HTTP extension, rather than as part of an application's specification.

4.7. ~HTTP~headerの指定-法

応用は、 新たな~HTTP~headerを定義することが多い。 新たな~HTTP~headerの利用は、 概して，次に挙げるような少数の状況において適切になる： ◎ Applications often define new HTTP header fields. Typically, using HTTP header fields is appropriate in a few different situations:

• 当の~fieldは、 `媒介者$にとって有用である （媒介者は、 `内容$の構文解析を避けたいと望むことが多い）。 ◎ The field is useful to intermediaries (who often wish to avoid parsing message content), and/or
• 当の~fieldは、 汎用な~HTTP~software（例： `~client$, `~server$）にとって有用である。 ◎ The field is useful to generic HTTP software (e.g., clients, servers), and/or
• その値を~messageの`内容$内に含めるのはアリでない （通例的には、 その形式がそれを許容しないため）。 ◎ It is not possible to include their values in the message content (usually because a format does not allow it).

上のどの条件にも該当しないときは、 応用に特有な情報を他の場所 — 例：~messageの`内容$や~URL~query文字列 — で伝達する方が，通例的には良い。 ◎ When the conditions above are not met, it is usually better to convey application-specific information in other places -- e.g., the message content or the URL query string.

新たな~headerは、 `HTTP$r `~fieldの拡張能＠~HTTPinfra#fields.extensibility§に従って登録されなければナラナイ。 ◎ New header fields MUST be registered, per Section 16.3 of [HTTP].

新たな~headerを創出するときに考慮する指針は、 `HTTP$r `新たな~fieldに対する考慮点＠~HTTPinfra#considerations.for.new.fields§を見よ。 `有構造~header$ `STRUCTURED-FIELDS$r は、 新たな~header用の共通な構造を供して，それらの構文解析と取扱いにおける多くの課題を避ける — 新たな~headerは、 それを利用することが`推奨される^2119。 ◎ See Section 16.3.2 of [HTTP] for guidelines to consider when minting new header fields. [STRUCTURED-FIELDS] provides a common structure for new header fields and avoids many issues in their parsing and handling; it is RECOMMENDED that new header fields use it.

~headerの名前は、 短くしつつ （~field圧縮が利用されていても、 そこには~overheadがある），［ 適切な，より特定な名前 ］にすることが`推奨される^2119。 特に，ある~headerが応用に特有な場合、 その応用~用の識別子は，~headerの名前を成す［ ~hyphenで分離された接頭辞 ］を形成し得る。 ◎ It is RECOMMENDED that header field names be short (even when field compression is used, there is an overhead) but appropriately specific. In particular, if a header field is specific to an application, an identifier for that application can form a prefix to the header field name, separated by a hyphen.

例えば，ある “example” と称される応用が 3 個の~headerを作成する必要がある場合、［ `example-foo^h, `example-bar^h, `example-baz^h ］のようにもなろう。 ここでの首な動機は、［ 名前空間のある部位を応用~用に予約すること ］ではなく，［ より汎用な`~field名$を消費するのを避けること ］なのに注意。 関係する考慮点については `RFC6648$r を見よ。 ◎ For example, if the "example" application needs to create three header fields, they might be called "example-foo", "example-bar", and "example-baz". Note that the primary motivation here is to avoid consuming more generic field names, not to reserve a portion of the namespace for the application; see [RFC6648] for related considerations.

既存の~HTTP~headerの意味論を，［ その登録を更新する／ それに対する拡張を定義する ］（かつ，それが許容される）ことなく定義し直してはナラナイ。 例えば，~HTTPを利用している応用は、 `Location$h ~headerを［ ある種の文脈においては、 特別な意味がある ］ものとは指定できない。 ◎ The semantics of existing HTTP header fields MUST NOT be redefined without updating their registration or defining an extension to them (if allowed). For example, an application using HTTP cannot specify that the Location header field has a special meaning in a certain context.

~headerと~HTTP~cache法の相互作用については、 `4.9§ を見よ。 特に，［ 要請~headerのうち，応答を （ `HTTP-CACHING$r `Vary ~headerによる~cache~keyの計算-法＠~HTTPcache#caching.negotiated.responses§に則って） 選ぶために利用されるもの ］は、 それに影響iがあり，注意深く考慮する必要がある。 ◎ See Section 4.9 for the interaction between header fields and HTTP caching; in particular, request header fields that are used to choose (per Section 4.1 of [HTTP-CACHING]) a response have impact there and need to be carefully considered.

~headerのうち，応用の状態を運ぶもの（例：`Cookie$h ）に関する考慮点は、 `4.10§を見よ。 ◎ See Section 4.10 for considerations regarding header fields that carry application state (e.g., Cookie).

4.8. ~message内容の定義-法

~message`内容$用の共通的な構文-規約には、［ ~JSON `JSON$r, ~XML `XML$r, ~CBOR（ `Concise Binary Object Representation^en ） `RFC8949$r ］が挙げられる。 これらを利用する場合の最善な実施は、 この文書の視野から外れる。 ◎ Common syntactic conventions for message contents include JSON [JSON], XML [XML], and Concise Binary Object Representation (CBOR) [RFC8949]. Best practices for their use are out of scope for this document.

応用は、 自身が定義する各~形式ごとに，別個な`~MIME型$を登録するべきである。 そうすれば、 それらは一義的に識別され，それらを利用するために折衝することもアリになる。 更なる情報は、 `RFC6838$r を見よ。 ◎ Applications should register distinct media types for each format they define; this makes it possible to identify them unambiguously and negotiate for their use. See [RFC6838] for more information.

4.9. ~HTTP~cache法の活用-法

~HTTP~cache法 `HTTP-CACHING$r は、 応用にとって~HTTPを利用する首な便益の一つであり，［ ~scale能を供する／ 待時間を抑制する／ 信頼性を改善する ］。 更には，~HTTP`~cache$は、 次に挙げる所でも すでに可用である ⇒＃ ~browserその他の`~client$／ `回送-~proxy$や`逆~proxy$としての~network／ ~CDN／ ~server~softwareの一部として ◎ HTTP caching [HTTP-CACHING] is one of the primary benefits of using HTTP for applications; it provides scalability, reduces latency, and improves reliability. Furthermore, HTTP caches are readily available in browsers and other clients, networks as forward and reverse proxies, content delivery networks, and as part of server software.

~HTTPを利用している応用は、 ~cache法の利点をとるよう設計されていないときでも、 `~cache$が応答をどう取扱うかを考慮する必要はある — （~network, `~server$, `~client$, 介在している基盤の）どこかに~cachingが差し挟まれても，正しい挙動を保全するため。 ◎ Even when an application using HTTP isn't designed to take advantage of caching, it needs to consider how caches will handle its responses, to preserve correct behaviour when one is interposed (whether in the network, server, client, or intervening infrastructure).

HTTP/1.1 200 OK
Content-Type: application/example+xml
Cache-Control: no-store

[内容]

HTTP/1.1 200 OK
Content-Type: application/example+xml
Cache-Control: max-age=60
ETag: "sa0f8wf20fs0f"
Vary: Accept-Encoding

[内容]

4.10. 応用~状態の取扱い

応用は、［ `~client$を識別する／ 要請を ある文脈~下に置くよう，~clientに特有な~dataを格納する ］ためとして，~statefulな~cookie `COOKIES$r を利用できる。 ◎ Applications can use stateful cookies [COOKIES] to identify a client and/or store client-specific data to contextualise requests.

~cookieを利用するときは、 その視野-法と利用を注意深く指定することが重要になる。 応用が敏感な~dataや能力を公開した場合、 悪用sがアリになる（例：~ambient権限として動作することにより）。 その軽減策としては、 要請に特有な~tokenを利用して`~client$の意図を確保することが挙げられる。 ◎ When used, it is important to carefully specify the scoping and use of cookies; if the application exposes sensitive data or capabilities (e.g., by acting as an ambient authority), exploits are possible. Mitigations include using a request-specific token to ensure the intent of the client.

4.11. 複数の要請を為すとき

`~client$は、 ある~taskを遂行するために複数個の要請を送信する必要があることが多い。 ◎ Clients often need to send multiple requests to perform a task.

並列的な要請は、 ~HTTP1 `HTTP/1.1$r においては， 複数個の接続を~openすることで~supportされることが最も多い。 同時に利用される接続が多過ぎる場合、 応用の処理能に影響iし得る — それらの接続の輻輳~制御は協調されないので。 さらには，応用にとっては、 所与の要請を［ いつ発行するか／どの接続を それ用に利用するか ］裁定することは困難なこともあり，それも処理能に影響iする。 ◎ In HTTP/1 [HTTP/1.1], parallel requests are most often supported by opening multiple connections. Application performance can be impacted when too many simultaneous connections are used because connections' congestion control will not be coordinated. Furthermore, it can be difficult for applications to decide when to issue and which connection to use for a given request, further impacting performance.

［ ~HTTP2 `HTTP/2$r ／~HTTP3 `HTTP/3$r ］は、 応用に多重化-法を提供して，複数個の接続を利用する必要を除去する。 しかしながら，それでも、 応用の処理能は，~serverが応答の優先度をどう選ぶかに有意に影響され得る。 ［ 応答の優先度を~serverが決定する／ ~clientが応答の優先度について~serverに~hintする ］のうち，どちらが最善になるかは、 応用に依存する （例： `HTTP-PRIORITY$r を見よ）。 ◎ HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3] offer multiplexing to applications, removing the need to use multiple connections. However, application performance can still be significantly affected by how the server chooses to prioritize responses. Depending on the application, it might be best for the server to determine the priority of responses or for the client to hint its priorities to the server (see, e.g., [HTTP-PRIORITY]).

~HTTP~versionを問わず、 各~要請は，独立に為される — 複数個の要請の相対-順序に依拠して，処理~順序を保証することはできない。 何故なら、 それらは［ `媒介者$により多重化された~protocol越しに送信される／ 異なる`生成元~server$へ送信される ］こともあり， 当の~serverは異なる順序で処理することすらあるかもしれないので。 2 個の要請に対し厳密な順序付けが必要な場合に， その成り行きを確保するための依拠-可能な仕方は、 1 個目の要請に対する`最終-応答$が始まってから， 2 個目の要請を発行する他にない。 ◎ In all versions of HTTP, requests are made independently -- you can't rely on the relative order of two requests to guarantee their processing order. This is because they might be sent over a multiplexed protocol by an intermediary or sent to different origin servers, or the server might even perform processing in a different order. If two requests need strict ordering, the only reliable way to ensure the outcome is to issue the second request when the final response to the first has begun.

応用は、［ 同じ~transport接続~上の別々な要請に対し，何か関係性がある ］と見做してはナラナイ。 そうすることは、 ~HTTPの`~stateless$な~protocolとしての前提の多くを覆すことに加え，［ 相互運用能／~security／運用能／発展 ］における問題の原因になるので。 ◎ Applications MUST NOT make assumptions about the relationship between separate requests on a single transport connection; doing so breaks many of the assumptions of HTTP as a stateless protocol and will cause problems in interoperability, security, operability, and evolution.

4.12. ~client認証

応用は、 `HTTP$r `~HTTP認証＠~HTTPsem#authentication§を利用して，`~client$を識別できる。 ~Basic認証~schemeは、 `RFC7617$r により，［ 敏感／脆弱 ］な情報を保護するには相応しくない — 当の~channelが~secureである（例： `https$c ~URI~schemeを利用している）場合を除き。 同様に，~Digest認証~schemeは、 `RFC7616$r により，~secureな~channel越しに利用することが要求される。 ◎ Applications can use HTTP authentication (Section 11 of [HTTP]) to identify clients. Per [RFC7617], the Basic authentication scheme is not suitable for protecting sensitive or valuable information unless the channel is secure (e.g., using the "https" URI scheme). Likewise, [RFC7616] requires the Digest authentication scheme to be used over a secure channel.

~HTTPSでは， `~client$は証明書 `RFC8446$r を利用して認証されることもあるが、 そのような認証が内在的に視野に入れるのは， 下層の~transport接続であることに注意。 その結果，`~client$には［ 当の応答を準備するとき，認証された状態sは利用されたかどうか ］を知る仕方は無く （ "`Vary$h: *" や `private$sdir `~cache指令$は、 部分的な指示を供し得るが）、 特定的に未認証な応答を得する仕方は， 新たな接続を~openする他に無い。 ◎ With HTTPS, clients might also be authenticated using certificates [RFC8446], but note that such authentication is intrinsically scoped to the underlying transport connection. As a result, a client has no way of knowing whether the authenticated status was used in preparing the response (though Vary: * and/or the private cache directive can provide a partial indication), and the only way to obtain a specifically unauthenticated response is to open a new connection.

認証が利用されるときは、 その視野-法と利用を注意深く指定することが重要になる。 応用が敏感な~dataや能力を公開した場合、 悪用sがアリになるので （例：~ambient権限として動作することにより — `RFC6454$r `~ambient権限＠~RFC6454#section-8.3§を見よ）。 軽減策として、 要請に特有な~tokenを利用して`~client$の意図を確保することが挙げられる。 ◎ When used, it is important to carefully specify the scoping and use of authentication; if the application exposes sensitive data or capabilities (e.g., by acting as an ambient authority; see Section 8.3 of [RFC6454]), exploits are possible. Mitigations include using a request-specific token to ensure the intent of the client.

4.13. ~web閲覧との共存-法

応用には~Web~browserから利用される意図は無いとしても、 その`資源$は，~browserその他の~HTTP`~client$に可用であり続けることになる。 このことは、 そのような［ ~HTTPを利用する応用 ］はすべて，［ ~browserが，応用と どうヤリトリすることになるか ］を — 特に~securityに関して — 考慮する必要があることを意味する。 ◎ Even if there is not an intent for an application to be used with a Web browser, its resources will remain available to browsers and other HTTP clients.＼ This means that all such applications that use HTTP need to consider how browsers will interact with them, particularly regarding security.

例えば，応用の状態を `POST$m 要請を利用して変更できる場合、 ~Web~browserは，任意な~Web~siteからの~CSRF（ `cross-site request forgery^en ）へ容易に誘い込まれ得る。 ◎ For example, if an application's state can be changed using a POST request, a Web browser can easily be coaxed into cross-site request forgery (CSRF) from arbitrary Web sites.

あるいは，攻撃者が［ 応用の`資源$から返される内容に対する制御 ］を利得した場合 （例： 要請の一部が応答~内に反映される場合／ 応答が攻撃者が変更できる外部な情報を包含する場合）、 攻撃者は，［ 何らかの~codeを~browserの中へ注入して，［ その~codeは当の資源の生成元に属していた ］かのように~dataや能力に~accessできる ］ことになる — この技法は、 ~XSS（ `cross-site scripting^en ）攻撃として知られる。 ◎ Or, if an attacker gains control of content returned from the application's resources (for example, part of the request is reflected in the response, or the response contains external information that the attacker can change), they can inject code into the browser and access data and capabilities as if they were the origin -- a technique known as a cross-site scripting (XSS) attack.

これは、 ~HTTPを利用している応用が考慮しなければならない課題のうち，一握りの種類でしかない。 一般に，最善な~approachは、 当の応用は~Web応用であると実際に見なす下で， その~secureな開発~用の最善な実施に従うことである。 ◎ This is only a small sample of the kinds of issues that applications using HTTP must consider. Generally, the best approach is to actually consider the application as a Web application, and to follow best practices for their secure development.

そのような実施の完全な列挙は，この文書の視野から外れるが、 次に挙げる考慮点が含まれる： ◎ A complete enumeration of such practices is out of scope for this document, but some considerations include:

• `Content-Type$h ~header内で，応用に特有な`~MIME型$を利用するよう~~定めた上で、 利用されていない場合には失敗するよう，`~client$に要求する。 ◎ Using an application-specific media type in the Content-Type header field, and requiring clients to fail if it is not used.
• `X-Content-Type-Options$h: `nosniff^v `FETCH$r を利用して、 攻撃者の制御-下にある内容は［ 能動的な内容として解釈するよう~Web~browserを誘い込むもの ］にはなり得ないことを確保する。 ◎ Using X-Content-Type-Options: nosniff [FETCH] to ensure that content under attacker control can't be coaxed into a form that is interpreted as active content by a Web browser.
• `Content-Security-Policy$h `CSP$r を利用して，能動的な内容 （すなわち、 ~HTML `HTML$r や~PDFなどで実行できる~script） の能力を拘束して、 それにより~XSS攻撃を軽減する。 ◎ Using Content-Security-Policy [CSP] to constrain the capabilities of active content (i.e., that which can execute scripts, such as HTML [HTML] and PDF), thereby mitigating XSS attacks.
• `Referrer-Policy$h `REFERRER-POLICY$r を利用して， ~URL内の敏感な~dataが `Referer$h 要請~header内に漏洩されるのを防止する。 ◎ Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data in URLs from being leaked in the Referer request header field.
• ~cookieに対し `HttpOnly$c 属性【！flag】 `COOKIES$r を利用して，~cookieは~browserの~scriptには公開されないことを確保する。 ◎ Using the 'HttpOnly' flag on Cookies to ensure that cookies are not exposed to browser scripting languages [COOKIES].
• 敏感な情報（例： 認証~token, ~password）に対しては、 圧縮の利用を避ける。 ~Web~browserが提供する~scripting環境は、 圧縮~空間【圧縮~用の辞書】を繰返に探査することを攻撃者に許容する — 攻撃者が通信の~network経路への~accessを有する場合、 この能力を利用して，その情報を回復できるので。 ◎ Avoiding use of compression on any sensitive information (e.g., authentication tokens, passwords), as the scripting environment offered by Web browsers allows an attacker to repeatedly probe the compression space; if the attacker has access to the network path of the communication, they can use this capability to recover that information.

~HTTPを利用している応用~用の仕様は、 どう配備されるものと意図されるかに依存して，［ これらの仕組みを自身に特有な仕方で利用するよう要求する ］こともあれば［ “§ ~securityの考慮点” において単に指摘するだけ ］かもしれない。 ◎ Depending on how they are intended to be deployed, specifications for applications using HTTP might require the use of these mechanisms in specific ways or might merely point them out in Security Considerations.

HTTP/1.1 200 OK
Content-Type: application/example+json
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'
Cache-Control: max-age=3600
Referrer-Policy: no-referrer

[内容]

~browserとの互換性を目標に置く応用は、 `~client$とのヤリトリを `FETCH$r の用語で定義する~OUGHT — それが、 ~browserが~HTTP用に利用する抽象-化であり， これらの最善な実施の多くを施行するので。 ◎ If an application has browser compatibility as a goal, client interaction ought to be defined in terms of [FETCH] since that is the abstraction that browsers use for HTTP; it enforces many of these best practices.

4.14. 応用~境界の保守-法

多くの~HTTP能力は，その視野が当の生成元 `RFC6454$r に絞られるので、 応用は，自身の配備が同じ`生成元~server$に属する他の応用（~Web閲覧も含む）とどう相互作用し得るか考慮する必要もある。 ◎ Because many HTTP capabilities are scoped to the origin [RFC6454], applications also need to consider how deployments might interact with other applications (including Web browsing) that use the same origin server.

例えば，応用の状態が `Cookie$h `COOKIES$r を利用して運ばれる場合、 その~cookieは， （~pathにより視野が絞られていない限り） 当の生成元へ送信される どの要請にも伴われることになり、 応用は，当の`生成元~server$に属する他の応用からも~cookieを受信するかもしれない。 これは、 ~securityの課題に加え，~cookie名の衝突も導き得る。 ◎ For example, if cookies [COOKIES] are used to carry application state, they will be sent with all requests to the origin by default (unless scoped by path), and the application might receive cookies from other applications on the origin server. This can lead to security issues as well as collision in cookie names.

これらの課題に対する解決策の一つは、 応用に対し専用な~hostnameを要求して， 応用が一意な生成元に属するようにすることである。 しかしながら，［ 単独の~hostnameに対し，複数の応用を配備する ］ことを許容する方が望ましいことも多い — そうすることは、 配備における柔軟性を最も供することに加え， それらの “混ぜ合わせ” を可能化する （詳細は `BCP190$r を見よ）。 ◎ One solution to these issues is to require a dedicated hostname for the application so that it has a unique origin. However, it is often desirable to allow multiple applications to be deployed on a single hostname; doing so provides the most deployment flexibility and enables them to be "mixed" together (see [BCP190] for details).

したがって，~HTTPを利用している応用は、 複数の応用が同じ生成元に属することを許容するよう，努めるべきである — 特定的には ⇒ ［ `Cookie$h や~HTTP認証~realm `HTTP$r その他の，生成元~~全般な~HTTPの仕組み ］の利用を指定するときには、［ 特定0の名前の利用を義務付ける ］べきではなく［ 代わりに，各~配備に応用を環境設定してもらうようにする ］べきであり，［ 応用に指定された仕組みを利用して，応用の視野を当の生成元の一部に絞ること ］に関する考慮点を与えるべきである。 ◎ Therefore, applications using HTTP should strive to allow multiple applications on an origin. Specifically, when specifying the use of Cookies, HTTP authentication realms [HTTP], or other origin-wide HTTP mechanisms, applications using HTTP should not mandate the use of a particular name but instead let deployments configure them. Consideration should be given to scoping them to part of the origin, using their specified mechanisms for doing so.

現代の~Web~browserは、 私用な情報が漏洩されるのを避けるため， ある生成元に属する内容が別の生成元に属する`資源$へ~accessする能を拘束する。 したがって，非同一-生成元な~dataを~browserに公開するよう望む応用は、 `~CORS~protocol$ `FETCH$r を実装する必要がある。 ◎ Modern Web browsers constrain the ability of content from one origin to access resources from another to avoid leaking private information. As a result, applications that wish to expose cross-origin data to browsers will need to implement the CORS protocol; see [FETCH].

4.15. ~server~pushの利用-法

~HTTP2 `HTTP/2$r は、 その`~server~push＠~RFC9113#name-server-push§にて， `~server$が ( 要請 / 応答 ) ~pairを`~client$に “~pushする” 能を追加した。 ~server~pushは、 多くの共通的な応用~意味論（例： “拡散” や ~publish/~subscribe）に自然に収まる様に見受けられるが，少数の注意事項がある： ◎ HTTP/2 added the ability for servers to "push" request/response pairs to clients in [HTTP/2], Section 8.4. While server push seems like a natural fit for many common application semantics (e.g., "fanout" and publish/subscribe), a few caveats should be noted:

• ~server~pushは`隣点間$であり、 `媒介者$は，それを自動的に回送しない。 その結果、［ `~proxy$／`逆~proxy$／~CDN ］がある下では容易に（あるいは まったく）働かないかもしれない。 ◎ Server push is hop by hop; that is, it is not automatically forwarded by intermediaries. As a result, it might not work easily (or at all) with proxies, reverse proxies, and content delivery networks.
• ~server~pushは、 不正に利用されると，~HTTPにおける処理能に負な影響iをもたらし得る — 特に，`~client$から実際に要請された`資源$において競合がある場合。 ◎ Server push can have a negative performance impact on HTTP when used incorrectly, particularly if there is contention with resources that have actually been requested by the client.
• `~client$における~server~pushの実装は、 ~clientに応じて — とりわけ、 ~HTTP~cache法との相互作用に関して — 異なり，その能力も変わるかもしれない。 ◎ Server push is implemented differently in different clients, especially regarding interaction with HTTP caching, and capabilities might vary.
• 現時点では，~server~push用の~APIは、 一部の実装では可用でなく，他の実装においても~~多岐に渡る。 特に，現在の~browserには、 そのような~APIは無い。 ◎ APIs for server push are currently unavailable in some implementations and vary widely in others. In particular, there is no current browser API for it.
• ~server~pushは、［ ~HTTP11／~HTTP10 ］においては~supportされない。 ◎ Server push is not supported in HTTP/1.1 or HTTP/1.0.
• ~server~pushは、 ~HTTP “中核” 意味論の一部を形成しないので， ~HTTPの将来~versionにおいては~supportされないかもしれない。 ◎ Server push does not form part of the "core" semantics of HTTP and therefore might not be supported by future versions of the protocol.

応用は、 `~client$が［ 要請に関係する作業 ］を［ 応答が全部的に可用になる前 ］に遂行できる事例 （例：【応答の】中に包含されると見込まれるもの用に~linkを~fetchするなど） を最適化するよう望むなら， 状態s~code `103$st を利用することで便益を得られるかもしれない — `RFC8297$r を見よ。 ◎ Applications wishing to optimise cases where the client can perform work related to requests before the full response is available (e.g., fetching links for things likely to be contained within) might benefit from using the 103 (Early Hints) status code; see [RFC8297].

~server~pushを直に利用している応用は、 非同一-生成元~push攻撃を避けるため， `HTTP/2$r `~server~push＠~RFC9113#name-server-push§における権限に関する要件を施行する必要がある。 ◎ Applications using server push directly need to enforce the requirements regarding authority in [HTTP/2], Section 8.4, to avoid cross-origin push attacks.

4.16. ~version付けと発展の許容-法

［ 応用~protocolの中に新たな特能を導入して，既存の特能を変更する ］ことが必要yなことは多い。 ◎ It's often necessary to introduce new features into application protocols and change existing ones.

~HTTPにおいては、 後方-互換でない変更は，次に挙げる仕組みなどを利用して為され得る： ◎ In HTTP, backwards-incompatible changes can be made using mechanisms such as:

• 別個な`~link関係~型$ `WEB-LINKING$r を利用して，新たな機能性を実装する`資源$用の~URLを識別する。 ◎ Using a distinct link relation type [WEB-LINKING] to identify a URL for a resource that implements the new functionality.
• 別個な`~MIME型$ `RFC6838$r を利用して，新たな機能性を可能化する形式を識別する。 ◎ Using a distinct media type [RFC6838] to identify formats that enable the new functionality.
• 別個な~HTTP~headerを利用して，~messageの`内容$の外側に新たな機能性を実装する。 ◎ Using a distinct HTTP header field to implement new functionality outside the message content.