RFC 9205 — Building Protocols with HTTP（日本語訳）

◎要約

応用は、~HTTPに基づく~APIを作成するときに，~HTTPを基底層として利用することが多い。この文書は、［ ~HTTPを利用して新たな応用~protocolを定義する仕様］を書くための最善な実施（ `best practice^en ）を指定する。この文書は、首に［ ~Internetへの配備~用に，~HTTP利用して応用~protocolを定義する］ための~IETFによる労を手引きするために書かれたが，他の状況にも適用-可能かもしれない。 ◎ Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations.

この文書は `RFC3205$r を廃用にする。 ◎ This document obsoletes RFC3205.

1. 序論

~Web閲覧~以外の応用は、 ~HTTP `HTTP$r をその基底層として利用することが多い — そのような実施は、［ “~HTTPに基づく~API” ／ “~REST~API” ／単に “~HTTP~API” ］を作成すること，と称されることもある。これが行われるのには、多様な理由がある — ~HTTPは、例えば： ◎ Applications other than Web browsing often use HTTP [HTTP] as a substrate, a practice sometimes referred to as creating "HTTP-based APIs", "REST APIs", or just "HTTP APIs". This is done for a variety of reasons, including:

［実装者, 仕様策定者, 管理者, 開発者, 利用者］に馴染みである ◎ familiarity by implementers, specifiers, administrators, developers, and users;
多様な［ `~client$, `~server$, `~proxy$ ］実装が可用である ◎ availability of a variety of client, server, and proxy implementations;
容易に利用できる ◎ ease of use;
~Web~browserにて可用である ◎ availability of Web browsers;
既存の仕組み — 認証や暗号化など — を再利用できる ◎ reuse of existing mechanisms like authentication and encryption;
~target配備に~HTTP［ `~server$, `~client$ ］が在る ◎ presence of HTTP servers and clients in target deployments; and
~firewallを横断する能がある ◎ its ability to traverse firewalls.

そのような応用~protocolは、［少数の`~server$による配備, 限定的な`~client$による消費］用にしか意図されず，場当的になることが多い。その結果、上に挙げた条件を優遇するような［ ~HTTPに基づく~API ］を定義することに伴い，その周りに［実施／~tool ］の体を成すものたちが発生した。 ◎ These protocols are often ad hoc, intended for only deployment by one or a few servers and consumption by a limited set of clients. As a result, a body of practices and tools has arisen around defining HTTP-based APIs that favour these conditions.

しかしながら、そのような応用に複数の別々な実装があって，互いに協調しない複数の`~server$で配備され，多岐な`~client$により消費されるとき（該当する事例は、標準~化への労により定義される~HTTP~APIにも多い）、限定的な配備~用に意図される［実施／~tool ］は，相応でないものになり得る。 ◎ However, when such an application has multiple, separate implementations, is deployed on multiple uncoordinated servers, and is consumed by diverse clients (as is often the case for HTTP APIs defined by standards efforts), tools and practices intended for limited deployment can become unsuitable.

その大きな~~理由は、各［ `~client$／`~server$ ］が【応用を】実装して発展する歩調がそれぞれに異なる結果，［特能や~version ］が異なる配備どうしを共存させる必要に迫られるからである。したがって，そのような配備に意図される［ ~HTTPに基づく~API ］の設計者は、【当の~APIにおいて】［当の~serviceの拡張能がどう取扱われるか／異なる各~配備~要件がどう収容されるか］について，もっと注意深く考慮する必要がある。 ◎ This mismatch is largely because the API's clients and servers will implement and evolve at different paces, leading to a need for deployments with different features and versions to coexist. As a result, the designers of HTTP-based APIs intended for such deployments need to more carefully consider how extensibility of the service will be handled and how different deployment requirements will be accommodated.

より一般には、 ~HTTPを利用している応用~protocolは，その設計にあたっていくつかの裁定に直面する — 次に挙げるものなど： ◎ More generally, an application protocol using HTTP faces a number of design decisions, including:

新たな~URI~schemeを定義するべきか？新たな~portを利用するか？ ◎ Should it define a new URI scheme? Use new ports?
標準な~HTTP［ `~method$／`状態s~code$ ］を利用するべきか？新たなそれを定義するべきか？ ◎ Should it use standard HTTP methods and status codes or define new ones?
~HTTPの利用から，最大な価値をどう抽出できるか？ ◎ How can the maximum value be extracted from the use of HTTP?
~HTTPの他の利用 — とりわけ~Web閲覧 — とどう共存するか？ ◎ How does it coexist with other uses of HTTP -- especially Web browsing?
相互運用能の問題と “~protocolの行詰まり” をどう避けれるか？ ◎ How can interoperability problems and "protocol dead ends" be avoided?

`2§ は、この文書がいつ適用されるかを定義する。 `3§ は、 ~HTTPに備わる特質のうち，保全することが重要なものについて調査する。 `4§ は、 ~HTTPを利用する応用の仕様~用の最善な実施を包含する。 ◎ Section 2 defines when this document applies, Section 3 surveys the properties of HTTP that are important to preserve, and Section 4 contains best practices for the specification of applications that use HTTP.

この文書は、首に，~IETFによる労 — ~Internetへの配備~用に［ ~HTTPを利用している応用~protocol ］を定義する労 — を手引きするために書かれたが，他の状況においても適用-可能かもしれない。ここに与える要件は、汎用な~HTTP拡張の開発には，適用されるとは限らないことに注意。 ◎ It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. Note that the requirements herein do not necessarily apply to the development of generic HTTP extensions.

この文書は、 `RFC3205$r を — その当時からこれまでの~HTTPに関する経験と開発を反映するため — 廃用にする。 ◎ This document obsoletes [RFC3205] to reflect the experience and developments regarding HTTP in the intervening time.

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. ~HTTPは利用されているか？

応用が~HTTPを利用する目標は、それぞれに異なる。この文書における推奨は、仕様が［次のいずれかに該当する応用］を定義するときに適用される： ◎ Different applications have different goals when using HTTP. The recommendations in this document apply when a specification defines an application that:

~transport~portに［ 80 ／ 443 ］【すなわち， `http$c ／ `https$c 用の既定の~port番号】を利用するもの。 ◎ uses the transport port 80 or 443, or
~URI~schemeに［ "`http$c" ／ "`https$c" ］を利用するもの。 ◎ uses the URI scheme "http" or "https", or
~HTTPを汎用に識別する， ~ALPN~protocol~ID `RFC7301$r （例： "`http/1.1^c", "`h2^c", "`h3^c" ）を利用するもの。 ◎ uses an ALPN protocol ID [RFC7301] that generically identifies HTTP (e.g., "http/1.1", "h2", "h3"), or
~HTTP用に定義される~IANA~registryに［登録／全般的な改変］を為すもの。 ◎ makes registrations in or overall modifications to the IANA registries defined for HTTP.

加えて，仕様が~HTTPを利用する所では、［ ~HTTP~protocol一式を成す，すべての要件］が強制される（特に `HTTP$r が挙げられるが、他の仕様 — 利用-中にある［特定の~versionの~HTTP／拡張］など — も）。 ◎ Additionally, when a specification is using HTTP, all of the requirements of the HTTP protocol suite are in force ([HTTP] in particular but also other specifications such as the specific version of HTTP in use and any extensions in use).

この文書は、応用に適用するものと意図されることに注意 — ~HTTPに対する汎用な拡張ではなく。この文書はまた，~IETFにより仕様~化される応用~用に意図されるが、他の組織による標準も，この文書の要件を固守することが奨励される。 ◎ Note that this document is intended to apply to applications, not generic extensions to HTTP. Furthermore, while it is intended for IETF-specified applications, other standards organisations are encouraged to adhere to its requirements.

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. ~HTTPについて何が重要か

この節では、 ~HTTPを成す特性のうち，［ ~HTTPを利用している応用~protocolを定義するにあたって，何を考慮するのが重要か］を精査する。 ◎ This section examines the characteristics of HTTP that are important to consider when using HTTP to define an application protocol.

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. ~HTTPの利用を指定するための最善な実施

この節は、応用による~HTTPの利用を指定するための最善な実施を述べる【！包含する】 — 特定の~HTTP~protocol要素~用の実施を含め。 ◎ This section contains best practices for specifying the use of HTTP by applications, including practices for specific HTTP protocol elements.

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].＼

例えば： ◎ For example:

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.

例えば、応用は，次を指定するかもしれない： ◎ For example, an application might specify:

`資源$のうち`~link関係~型$ "`example-widget^c" を伴って~linkされたものは、 ~Widgetである。 ~Widgetの状態は、 "`application/example-widget+json^c" 形式において，~fetchでき，同じ~linkへ向けた `PUT$m で更新できる。 ~Widget資源は、削除できる。 ◎ Resources linked to with the "example-widget" link relation type are Widgets. The state of a Widget can be fetched in the "application/example-widget+json" format, and can be updated by PUT to the same link. Widget resources can be deleted.

~Widget表現に対する `Example-Count^h 応答~headerは、 `送信者$が~Widgetをいくつ保持するかを指示する。 ◎ The Example-Count response header field on Widget representations indicates how many Widgets are held by the sender.

"`application/example-widget+json^c" 形式は、 ~JSON `RFC8259^r 形式であり，~Widgetの状態を表現する。それは、関係する情報への~linkを， `Link$h ~headerの`~field値$の［ `~link関係~型$ "`example-other-info^c" で指示される~link ］内に包含する。 ◎ The "application/example-widget+json" format is a JSON [RFC8259] format representing the state of a Widget. It contains links to related information in the link indicated by the Link header field value with the "example-other-info" link relation type.

応用は、 `~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.

したがって，仕様の書き手は、［ `~client$が応用の~URLを発見する］ことを許容するための何らかの仕組みが必要になる。加えて、［応用に利用されるべき~URL~scheme（たち）］および［応用は［専用な~port, ~HTTP用の既定の~port【！reuse HTTP's port(s)】］どちらを利用するか］も指定する必要がある。 ◎ Therefore, the specification writer needs some mechanism to allow clients to discover an application's URLs. Additionally, they need to specify which URL scheme(s) the application should be used with and whether to use a dedicated port or to reuse HTTP's port(s).

4.4.1. 応用の~URLの発見-法

一般に，`~client$は、所与の応用で`~server$とヤリトリし始める前に，［応用の特定0の配備についての情報を包含する，初期~文書］を要請することになる — それには、関連な他の`資源$への~linkも含まれ得る。そうすることは、［配備がアリな限り柔軟になること（複数の~serverにもまたがり得る）, 発展を許容すること］を確保することに加え， ~client向けの “発見~文書” を誂える機会も応用に与える。 ◎ Generally, a client will begin interacting with a given application server by requesting an initial document that contains information about that particular deployment, potentially including links to other relevant resources. Doing so ensures that the deployment is as flexible as possible (potentially spanning multiple servers), allows evolution, and also gives the application the opportunity to tailor the "discovery document" to the client.

初期~URLを発見するための少数の共通的な~patternがある。 ◎ There are a few common patterns for discovering that initial URL.

~URL発見~用の最も単直な仕組みは、 `~client$を全部的な~URLで環境設定する（あるいは，それを~clientに伝達する）ことである。これは、ある環境設定~文書~内で，あるいは別の発見の仕組みを通して行われることもあろう。 ◎ The most straightforward mechanism for URL discovery is to configure the client with (or otherwise convey to it) a full URL. This might be done in a configuration document or through another discovery mechanism.

しかしながら，`~client$が`~server$の~hostnameと応用の識別情報しか知らない場合、その情報から初期~URLを導出する何らかの仕方が必要になる。 ◎ However, if the client only knows the server's hostname and the identity of the application, there needs to be some way to derive the initial URL from that information.

応用は、自身の~URL~path用に固定的な接頭辞を定義することはできない — `BCP190$r を見よ。代わりに，そのような応用~用の仕様は、次に挙げる策のうちいずれかを利用できる： ◎ An application cannot define a fixed prefix for its URL paths; see [BCP190]. Instead, a specification for such an application can use one of the following strategies:

応用~用の入口として`周知な~URI^cite【 "`/.well-known/^c" 】（ `well-known URI^en ） `WELL-KNOWN-URI$r を登録する。これは、その応用を配備し得るどの`~server$に対しても，他の応用と衝突しない固定的な~pathを供する。 ◎ Register a well-known URI [WELL-KNOWN-URI] as an entry point for that application. This provides a fixed path on every potential server that will not collide with other applications.
入口~用に~URLを`生成-$するための［ `~URI~template^cite `URI-TEMPLATE$r または類似な仕組み］を伝達するような~server権限を可能化する。これは、例えば［環境設定~文書／他の産物］内で行われることもあろう。 ◎ Enable the server authority to convey a URI Template [URI-TEMPLATE] or similar mechanism for generating a URL for an entry point. For example, this might be done in a configuration document or other artefact.

発見~文書の所在が得られたなら、それを~fetchでき，（その~metadataにより許容されるなら）後で再利用するために~cacheでき，応用に関連な他の`資源$の所在を得るために利用できる — ［全部的な~URI／ `~URI~template^cite `URI-TEMPLATE$r ］を利用して。 ◎ Once the discovery document is located, it can be fetched, cached for later reuse (if allowed by its metadata), and used to locate other resources that are relevant to the application, using full URIs or URL Templates.

応用は、一部の事例では，そのような発見~文書を利用するよう望まないこともあろう — 例えば、通信は，【発見~文書を介するのは大袈裟か不便になるほどに】ごく概略的であるとき／待時間の懸念から，発見~文書の利用は予め除外されるとき。これらの状況は、［応用の`資源$を成すすべてを周知な所在【 "`/.well-known/^c" 】の下に配置する］ことにより取組める。 ◎ In some cases, an application may not wish to use such a discovery document -- for example, when communication is very brief or when the latency concerns of doing so preclude the use of a discovery document. These situations can be addressed by placing all of the application's resources under a well-known location.

4.4.2. ~URI~schemeを考慮するとき

~HTTPを利用する応用は、概して，~URI~schemeに［ "`http^c" ／ "`https^c" ］を使役することになる。［認証, 完全性, 機密性］を供する, および大規模な監視~攻撃を軽減するには、 "`https^c" が`推奨される^2119 `RFC7258$r 。 ◎ Applications that use HTTP will typically employ the "http" and/or "https" URI schemes. "https" is RECOMMENDED to provide authentication, integrity, and confidentiality, as well as to mitigate pervasive monitoring attacks [RFC7258].

しかしながら、応用に特有な~schemeも定義できる。 ~HTTPを利用している応用~用に~URI~schemeを定義するときには、いくつかの~trade-offと注意事項を念頭に置くべきである： ◎ However, application-specific schemes can also be defined. When defining a URI scheme for an application using HTTP, there are a number of trade-offs and caveats to keep in mind:

~Web~browserは、改変されない限り，新たな~schemeを~supportしない。 ~Web~browserで新たな~URI~schemeを登録することはアリであるが（例：`HTML$r における `registerProtocolHandler()^c, あるいはいくつかの~proprietaryな~approachで）、これらの仕組み用の~supportは、すべての~browserから共有されるとは限らず，それらの能力は~browserごとに変わり得る。 ◎ Unmodified Web browsers will not support the new scheme. While it is possible to register new URI schemes with Web browsers (e.g. registerProtocolHandler() in [HTML], as well as several proprietary approaches), support for these mechanisms is not shared by all browsers, and their capabilities vary.
既存の［非~browser`~client$, `媒介者$, `~server$ ］, およびこれらに結付けられる~softwareは、新たな~schemeを認識しないことになる。例えば ⇒＃ある~client~libraryは、要請を配送するのに失敗するかもしれない／ある`~cache$は、応答を格納するのを拒否するかもしれない／ある`~proxy$は、要請を回送するのに失敗するかもしれない ◎ Existing non-browser clients, intermediaries, servers, and associated software will not recognise the new scheme. For example, a client library might fail to dispatch the request, a cache might refuse to store the response, and a proxy might fail to forward the request.
~URLは、 ~HTTPによる産物~内で共通的に生じることに加え，自動的に（例： `Location$h 応答~header内で）`生成-$されることが多いので、新たな~schemeが一貫して利用されることを確保するのは，困難にもなり得る。 ◎ Because URLs commonly occur in HTTP artefacts and are often generated automatically (e.g., in the Location response header field), it can be difficult to ensure that the new scheme is used consistently.
新たな~schemeにより識別される`資源$であっても、［ "`http^c" ／ "`https^c" ］~URLを利用して可用になる。それらの~URLは、［ ~security／運用能］の課題が在り得るような利用に “漏洩し得る”。例えば，新たな~schemeを利用しても、［要請が “通常の” ~Web~siteへは送信されない］ことを確保するのは，失敗する見込みが高い。 ◎ The resources identified by the new scheme will still be available using "http" and/or "https" URLs. Those URLs can "leak" into use, which can present security and operability issues. For example, using a new scheme to ensure that requests don't get sent to a "normal" Web site is likely to fail.
~URLの生成元 `RFC6454$r に依拠する特能 — ~Webの同一-生成元~施策など — は、 ~schemeの変更に影響iされることになる。 ◎ Features that rely upon the URL's origin [RFC6454], such as the Web's same-origin policy, will be impacted by a change of scheme.
~HTTPに特有な特能 — ［ ~cookie `COOKIES$r ／認証 `HTTP$r ／ ~cache法 `HTTP-CACHING$r ／ ~HSTS（ `HTTP Strict Transport Security^en ） `RFC6797$r ／ ~CORS（ `Cross-Origin Resource Sharing^en ） `FETCH$r ］など — が正しく働くかどうかは、それらがどう定義され, どう実装されるかに依存する。一般に，それらは、 ~URLは常に［ "`http^c" ／ "`https^c" ］であると見做す下で設計され, 実装される。 ◎ HTTP-specific features such as cookies [COOKIES], authentication [HTTP], caching [HTTP-CACHING], HTTP Strict Transport Security (HSTS) [RFC6797], and Cross-Origin Resource Sharing (CORS) [FETCH] might or might not work correctly, depending on how they are defined and implemented. Generally, they are designed and implemented with an assumption that the URL will always be "http" or "https".g
~web特能のうち，`~secureな文脈$ `SECCTXT$r を要求するものは、新たな~schemeを~secureでないものと扱う見込みが高い。 ◎ Web features that require a secure context [SECCTXT] will likely treat a new scheme as insecure.

新たな~URI~schemeの創出-法についての，さらなる情報は、 `RFC7595$r を見よ。 ◎ See [RFC7595] for more information about minting new URI schemes.

4.4.3. ~transport用の~portを選ぶとき

応用は、適用-可能な既定の~port（~HTTP 用には 80, ~HTTPS用には 443 ）を利用できる — あるいは、他の~portにも配備できる。この裁定は、配備~時点に下されることもあれば，応用の仕様により奨励されることもあろう（例：ある~portを，その応用~用として登録することにより）。 ◎ Applications can use the applicable default port (80 for HTTP, 443 for HTTPS), or they can be deployed upon other ports. This decision can be made at deployment time or might be encouraged by the application's specification (e.g., by registering a port for that application).

既定でない~portが利用される場合、その`資源$用のすべての~URLの権限【 `authority$p 】内に反映される必要がある。既定の~portを変更するための仕組みは、 ~URI~schemeを変更する他にない（ `4.4.2§ を見よ）。 ◎ If a non-default port is used, it needs to be reflected in the authority of all URLs for that resource; the only mechanism for changing a default port is changing the URI scheme (see Section 4.4.2).

既定でない~portを利用することには、 ~privacyの含意がある（すなわち、当の~protocolは他の流通から判別できるようになる）ことに加え，運用能の懸念がある（一部の~networkは、そのような~portを阻止したり干渉することもあるので）。 ~privacyの含意（この判別-能に起因するものも含む）は、 “§ ~securityの考慮点” にて文書化されるべきである。 ◎ Using a port other than the default has privacy implications (i.e., the protocol can now be distinguished from other traffic), as well as operability concerns (as some networks might block or otherwise interfere with it). Privacy implications (including those stemming from this distinguishability) should be documented in Security Considerations.

更なる指導は、 `RFC7605$r を見よ。 ◎ See [RFC7605] for further guidance.

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.5.1. `GET^m

`GET$m は、最も［共通的な, かつ有用な］~HTTP~methodである。その検索取得の意味論は、［ ~caching, 副作用が無い~link法］を許容する — ~HTTPを利用する便益の多くは、それが~~下層にある。 ◎ GET is the most common and useful HTTP method; its retrieval semantics allow caching and side-effect free linking and underlie many of the benefits of using HTTP.

~queryは、 `GET$m で遂行され得る — それは、 ~URLの~query成分を利用することが多い。これは，~Web閲覧において馴染みな~patternであり、その結果は~cacheできるので，高価になることが多い処理nの効率を改善する。しかしながら，~URIの構文は制限されているので、 `GET$m で~queryを表出するのは手に余る事例もあるかもしれない — 特に、 ~queryを成すある項が~binary~dataで形成される場合， ~URI構文に適合するよう符号化する必要がある。 ◎ Queries can be performed with GET, often using the query component of the URL; this is a familiar pattern from Web browsing, and the results can be cached, improving the efficiency of an often expensive process.＼ In some cases, however, GET might be unwieldy for expressing queries because of the limited syntax of the URI; in particular, if binary data forms part of the query terms, it needs to be encoded to conform to the URI syntax.

これは，~queryが短いならば課題にならないが、［巨大な~query項がある／~~高頻度な要請を支え続ける必要がある］場合，そうなり得る。加えて，一部の~HTTP実装は、 ~supportする~URLの~sizeを制限する — 現代の~HTTP~softwareにおける制限sは、以前よりはずっと間口が広いが（ `HTTP$r により 8000 ~octet以上が要求され、概して，それをかなり超える）。 ◎ While this is not an issue for short queries, it can become one for larger query terms or those that need to sustain a high rate of requests. Additionally, some HTTP implementations limit the size of URLs they support, although modern HTTP software has much more generous limits than previously (typically, considerably more than 8000 octets, as required by [HTTP]).

これらの事例では、 ~HTTPを利用している応用は，［ `POST$m を利用して，要請の`内容$内で~queryを表出する］ことを考慮するかもしれない — そうすれば、［符号化法の~overhead／実装における~URL長さ制限s ］は，避けれる。しかしながら，そうすると、 `GET$m の便益 — ~queryの結果を~cacheしたり，~linkするなど — も失われることにも注意。したがって、［ ~HTTPを利用している応用のうち， `POST$m による~queryの~supportを要求するもの］は，どちらの~methodも許容することを考慮する~OUGHT。 ◎ In these cases, an application using HTTP might consider using POST to express queries in the request's content; doing so avoids encoding overhead and URL length limits in implementations. However, in doing so, it should be noted that the benefits of GET such as caching and linking to query results are lost. Therefore, applications using HTTP that require support for POST queries ought to consider allowing both methods.

`GET$m 要請の処理により，当の応用の状態が変更される, その他の［ `~client$にとって有意になり得る副作用］は生じるべきでない — 実装は、失敗した `GET$m 要請を再試行でき，それを行うので。さらには、 ~TLS早期~dataにより保護される一部の `GET$m 要請は，再現-攻撃に脆弱かもしれない（ `RFC8470$r を見よ）。これは、 ~log取りやそれに類似な機能は含まないことに注意 — `安全$な~methodを見よ。 ◎ Processing of GET requests should not change the application's state or have other side effects that might be significant to the client since implementations can and do retry HTTP GET requests that fail. Furthermore, some GET requests protected by TLS early data might be vulnerable to replay attacks (see [RFC8470]). Note that this does not include logging and similar functions; see [HTTP], Section 9.2.1.

最後に、汎用な~HTTP構文は `GET$m 要請~messageにおいても`内容$を許容するが，その目的は［ ~message構文解析器が汎用であることを許容するため］でしかないことに注意。 `HTTP$r によれば、 `GET$m における`内容$は推奨されず，その意味は無い — 汎用な~HTTP~software（`媒介者$, `~cache$, `~server$, ~client~libraryなど）は、それを無視するか却下することになる。 ◎ Finally, note that while the generic HTTP syntax allows a GET request message to contain content, the purpose is to allow message parsers to be generic; per [HTTP], Section 9.3.1, content in a GET is not recommended, has no meaning, and will be either ignored or rejected by generic HTTP software (such as intermediaries, caches, servers, and client libraries).

4.5.2. `OPTIONS^m

`OPTIONS$m ~methodは、 ~metadataの検索取得~用に定義され， ~WebDAV（ `Web Distributed Authoring and Versioning^en ） `RFC4918$r, ~CORS `FETCH$r どちらからも利用される。 ~HTTPに基づく~APIは，`資源$についての~metadataを検索取得する必要があることが多いので、 `OPTIONS^m は，そのような~APIの利用-用と見なされることが多い。 ◎ The OPTIONS method was defined for metadata retrieval and is used both by Web Distributed Authoring and Versioning (WebDAV) [RFC4918] and CORS [FETCH]. Because HTTP-based APIs often need to retrieve metadata about resources, it is often considered for their use.

しかしながら、 `OPTIONS$m には有意な制限がある： ◎ However, OPTIONS does have significant limitations:

単純な~URLで~metadataへ~linkすることはアリでない — `OPTIONS$m は、 “既定の~method” ではないので。 ◎ It isn't possible to link to the metadata with a simple URL, because OPTIONS is not the default method.
`OPTIONS$m に対する応答は、 `~cache可能$でない — ~HTTP`~cache$が演算する対象は、 `資源$の`表現$（すなわち， `GET$m ／ `HEAD$m ）なので。 `OPTIONS$m に対する応答を【~HTTP~cacheとは】別々に~cacheする場合、 ~HTTP~cacheにおける［失効, 副次的な~key, その他の仕組み］との相互作用を考慮する必要がある。 ◎ OPTIONS responses are not cacheable because HTTP caches operate on representations of the resource (i.e., GET and HEAD). If OPTIONS responses are cached separately, their interactions with the HTTP cache expiry, secondary keys, and other mechanisms need to be considered.
`OPTIONS$m は “~chat的” である — ~metadataを別々に要請すると、応用とヤリトリするために必要な要請の個数は増える。 ◎ OPTIONS is "chatty" -- requesting metadata separately increases the number of requests needed to interact with the application.
`OPTIONS$m 用の実装~supportは、普遍的ではない — 一部の`~server$は、有意な労なくしては， `OPTIONS$m 要請に対し応答する能を公開しない。 ◎ Implementation support for OPTIONS is not universal; some servers do not expose the ability to respond to OPTIONS requests without significant effort.

`OPTIONS$m に代えて，より適切になる代替な~approachとしては、次が挙げられよう： ◎ Instead of OPTIONS, one of these alternative approaches might be more appropriate:

~server-wide~metadata用に、 `周知な~URI^cite【 "`/.well-known/^c" 】 `WELL-KNOWN-URI$r を作成するか，適切になるなら既存のものを利用する（例： host-meta `RFC6415$r ）。 ◎ For server-wide metadata, create a well-known URI [WELL-KNOWN-URI] or use an already existing one if appropriate (e.g., host-meta [RFC6415]).
特定の`資源$についての~metadata用には、別々な資源を作成した上で，［ `Link$h 応答~header／応答の`内容$の中］に直列化された~linkを利用して，そこへ~linkする。 `WEB-LINKING$r を見よ。 `Link$h ~headerは、 `HEAD$m 応答においても可用なことに注意 — それは、 `~client$が［ `資源$とヤリトリする前に，その能力を発見する］よう求める場合に有用になる。 ◎ For metadata about a specific resource, create a separate resource and link to it using a Link response header field or a link serialised into the response's content. See [WEB-LINKING]. Note that the Link header field is available on HEAD responses, which is useful if the client wants to discover a resource's capabilities before they interact with it.

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.6.1. ~redirection

`3xx$st0 番台の`状態s~code$は、当の要請を満足するため，別の`資源$へ~UAを~directする。最も共通的なものは，［ `301$st0, `302$st0, `307$st0, `308$st0 ］であり、いずれも， `Location$h 応答~headerを利用して［ `~client$は、要請をどこへ送信し直すべきか］を指示する。 ◎ The 3xx series of status codes specified in Section 15.4 of [HTTP] directs the user agent to another resource to satisfy the request. The most common of these are 301, 302, 307, and 308, all of which use the Location response header field to indicate where the client should resend the request.

これら一群の`状態s~code$どうしは、次の二点で相違する： ◎ There are two ways that the members of this group of status codes differ:

［恒久的, 一時的］どちらなのか。恒久的な~redirectは、 `~client$内に格納された~link（例：~bookmark）を更新するために利用できる一方で，一時的なものはできない。これによる~HTTP~cache法に対する効果は無いことに注意 — それは、完全に別々である。 ◎ Whether they are permanent or temporary. Permanent redirects can be used to update links stored in the client (e.g., bookmarks), whereas temporary ones cannot. Note that this has no effect on HTTP caching; it is completely separate.
~redirectされた要請の~methodを `POST$m から `GET$m に変更するのを許容するかどうか。 ~Web~browserは、一般に，［ `301$st0, `302$st0 ］に対しては `POST$m を `GET$m に変更する。そのことから、 ~methodを変更しない~redirectionを許容するために［ `308$st0, `307$st0 ］が作成された。 ◎ Whether they allow the redirected request to change the request method from POST to GET. Web browsers generally do change POST to GET for 301 and 302; therefore, 308 and 307 were created to allow redirection without changing the method.

次の表tに、これらの関係性を要約する： ◎ This table summarises their relationships:

	恒久的	一時的
`POST^m から `GET^m への変更を許容する	`301^st0	`302^st0
`POST^m から `GET^m への変更を許容しない	`308^st0	`307^st0

◎ ｜Permanent｜Temporary Allows change of the request method from POST to GET｜301｜302 Does not allow change of the request method｜308｜307

状態s~code `303$st は、［演算の結果は、異なる所在にて `GET$m を利用して可用である］ことを~clientに伝えるために利用できる。 ◎ The 303 (See Other) status code can be used to inform the client that the result of an operation is available at a different location using GET.

`HTTP$r `3xx§st0 に述べられるとおり、 ~UAには， `Location$h 応答~headerを伴う `3xx^st0 ~redirectを — 特定の`状態s~code$の意味論を解さない場合でも — 自動的に追従することが許容される。しかしながら，そうするよう要求されてはいないので、 ~HTTPを利用している応用は，~redirectを自動的に追従するよう欲する場合には，どの状況下でそれが要求されるかを明示的に指定する必要がある。 ◎ As noted in [HTTP], a user agent is allowed to automatically follow a 3xx redirect that has a Location response header field, even if they don't understand the semantics of the specific status code. However, they aren't required to do so; therefore, if an application using HTTP desires redirects to be automatically followed, it needs to explicitly specify the circumstances when this is required.

~redirectは、（適切な~cache指令が在るときは）~cacheされ得るが，それを超えて “へばりつく” ことはない — すなわち，~URIの~redirectionは、類似な~URI（例：~query~parameterだけ異なるなど）に対しても~clientを~redirectするものとは見做されない。 ◎ Redirects can be cached (when appropriate cache directives are present), but beyond that, they are not "sticky" -- i.e., redirection of a URI will not result in the client assuming that similar URIs (e.g., with different query parameters) will also be redirected.

~HTTPを利用している応用は、 ~browserと互換になるよう，［ `301$st0 ／ `302$st0 ］応答に対する後続な要請~methodを `POST$m から `GET$m （他の~methodは不可）へ変更するよう指定することが奨励される。 ◎ Applications using HTTP are encouraged to specify that 301 and 302 responses change the subsequent request method from POST (but no other method) to GET to be compatible with browsers.＼

一般に，~redirectされた要請が為されるとき、その各~headerは，元の要請から複製される。しかしながら、それらは，様々な仕組みにより改変され得る。例えば，送信される［ `Authorization$h ／ `Cookie$h ］~headerは、要請【`要請~target$】の生成元（および, ときには~path）が変更された場合には変化することになる。 ~HTTPを利用している応用は、自身が定義する各~要請~headerに対し，~redirectに際してそれを［改変する／除去する］必要があるかどうかを指定するべきである。しかしながら、この挙動には依拠し得ない — （~browserの様な）汎用な`~client$は、そのような要件を自覚しないので。 ◎ Generally, when a redirected request is made, its header fields are copied from the original request. However, they can be modified by various mechanisms; e.g., sent Authorization ([HTTP], Section 11) and Cookie ([COOKIES]) header fields will change if the origin (and sometimes path) of the request changes. An application using HTTP should specify if any request header fields that it defines need to be modified or removed upon a redirect; however, this behaviour cannot be relied upon since a generic client (like a browser) will be unaware of such requirements.

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).

4.9.1. 鮮度

`鮮度~維持期間$をアテガうことは、それが短くても（例： 5 秒），［複数の`~client$からの要請を満足するために応答を再利用すること／単独の~clientが同じ要請を繰返に為すこと］を許容する。一般に，再利用しても安全な何かに対しては、鮮度~維持期間をアテガうことを考慮すること。 ◎ Assigning even a short freshness lifetime ([HTTP-CACHING], Section 4.2) -- e.g., 5 seconds -- allows a response to be reused to satisfy multiple clients and/or a single client making the same request repeatedly. In general, if it is safe to reuse something, consider assigning a freshness lifetime.

鮮度を指定するための最も共通的な手法は、 `max-age$sdir 応答~指令である。 `Expires$h ~headerも利用できるが、それは必要yでない — 現代の~cache実装は，どれも `Cache-Control$h ~headerを~supportすることに加え、鮮度を差分【 `delta-seconds$p 】として指定する方が，通例的にはより簡便かつ誤り難くなるので。 ◎ The most common method for specifying freshness is the max-age response directive ([HTTP-CACHING], Section 5.2.2.1). The Expires header field ([HTTP-CACHING], Section 5.3) can also be used, but it is not necessary; all modern cache implementations support the Cache-Control header field, and specifying freshness as a delta is usually more convenient and less error-prone.

ほとんどの応答に対しては、それを~cacheするために `public$sdir 応答~指令を追加することは，必要yでない — 必要yであるのは、［認証された応答を格納するのが望ましいとき／応答の`状態s~code$は~cacheにより解されない, かつ明示的な鮮度~情報は可用でないとき］に限られる。 ◎ It is not necessary to add the public response directive ([HTTP-CACHING], Section 5.2.2.9) to cache most responses; it is only necessary when it's desirable to store an authenticated response, or when the status code isn't understood by the cache and there isn't explicit freshness information available.

一部の状況では、明示的な［鮮度~用の~cache指令］を伴わない応答は，［経験的な`鮮度~維持期間$を利用して格納された上で~serveされる］ことになる — `HTTP-CACHING$r `鮮度の経験的な計算-法＠~HTTPcache#heuristic.freshness§を見よ。応用は，経験的なそれを制御できないので、一般に，［明示的な`鮮度~維持期間$を設定するか，応答を明示的に~cache不能にする］方が好ましい。 ◎ In some situations, responses without explicit cache freshness directives will be stored and served using a heuristic freshness lifetime; see [HTTP-CACHING], Section 4.2.2. As the heuristic is not under the control of the application, it is generally preferable to set an explicit freshness lifetime or make the response explicitly uncacheable.

応答の~cachingが欲されない場合に適切になる応答~cache指令は、 `no-store$sdir である。他の指令は必要yでないことに加え、 `no-store$sdir を送信する必要があるのは，応答が~cacheされ得る状況に限られる — `HTTP-CACHING$r `~cache内への応答の格納-法＠~HTTPcache#response.cacheability§を見よ。その一方， `no-cache$sdir 指令は、応答を格納すること自体は許容することに注意 — それは、 ~cacheが検証を伴わずに応答を再利用することを許容しないだけであり，（その名に反して）~cachingを防止しない。 ◎ If caching of a response is not desired, the appropriate cache response directive is no-store. Other directives are not necessary, and no-store only needs to be sent in situations where the response might be cached; see [HTTP-CACHING], Section 3. Note that the no-cache directive allows a response to be stored, just not reused by a cache without validation; it does not prevent caching (despite its name).

例えば、 `~cache$は，次の応答を［格納できない／再利用できない］： ◎ For example, this response cannot be stored or reused by a cache:

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

[内容]

4.9.2. 非新鮮な応答

策定者は、［ `~cache$は、 `生成元~server$から切断されたときには，`非新鮮$な応答（例： `Cache-Control$h: `max-age$sdir=0 を伴うもの）を再利用できる］ことを理解するべきである。それは、 ~networkの課題を取扱うために有用になり得る。 ◎ Authors should understand that stale responses (e.g., with Cache-Control: max-age=0) can be reused by caches when disconnected from the origin server; this can be useful for handling network issues.

所与の応答に対し，そうするのは相応でない場合、 `生成元~server$【！~the生成元】は， `must-revalidate$sdir `~cache指令$を送信するべきである。 `HTTP-CACHING$r `非新鮮な応答の~serve法＠~HTTPcache#serving.stale.responses§を見よ。また、 `非新鮮$な内容に対する追加的な制御は `RFC5861$r を見よ。 ◎ If doing so is not suitable for a given response, the origin should send the must-revalidate cache directive. See Section 4.2.4 of [HTTP-CACHING] and also [RFC5861] for additional controls over stale content.

`非新鮮$な応答は、 `検証子$をアテガうことにより新鮮化できる — そうすれば、巨大な応答に対し，転送~帯域幅も待時間も節約する。 `HTTP$r `条件付き要請＠~HTTPsem#conditional.requests§を見よ。 ◎ Stale responses can be refreshed by assigning a validator, saving both transfer bandwidth and latency for large responses; see Section 13 of [HTTP].

4.9.3. ~cachingと応用の意味論

応用が［ `鮮度~維持期間$とは別々な維持期間］を表出する必要がある場合、それは，応答の［ `内容$／別々な`~header$ ］内に別々に伝達されるべきである。これが起きるときは、［そのような維持期間と~HTTP~cache法との関係性］を注意深く考慮する必要がある — 応答は、［ `新鮮$であると見なされる限り，再利用される【！利用される】］ことになるので。 ◎ When an application has a need to express a lifetime that's separate from the freshness lifetime, this should be conveyed separately, either in the response's content or in a separate header field. When this happens, the relationship between HTTP caching and that lifetime needs to be carefully considered since the response will be used as long as it is considered fresh.

特に，応用の策定者は、［ある応答が`生成元~server$から`新鮮$に得されたものでない場合に，それをどう取扱うべきか］を考慮する必要がある — それに有効期間の様な概念がある場合、応答の齢（ `HTTP-CACHING$r `齢の計算-法＠~HTTPcache#age.calculations§を見よ）を考慮する下で計算する必要がある。 ◎ In particular, application authors need to consider how responses that are not freshly obtained from the origin server should be handled; if they have a concept like a validity period, this will need to be calculated considering the age of the response (see [HTTP-CACHING], Section 4.2.3).

これに取組む仕方の一つは、［応答は、利用する際には`新鮮$である必要がある］ものと明示的に指定することである。 ◎ One way to address this is to explicitly specify that responses need to be fresh upon use.

4.9.4. 内容を要請に基づいて変えるとき

ある応用が，ある要請~headerを応答の［ `~header$／`内容$ ］を変更するために利用する場合、策定者は，［それには，~cache法に対する含意がある］ことを指摘するべきである、一般に，そのような`資源$からの応答に対しては、次のいずれかが必要になる： ◎ If an application uses a request header field to change the response's header fields or content, authors should point out that this has implications for caching; in general, such resources need to either＼

~cache不能にする（例： `no-store$sdir `~cache指令$） ◎ make their responses uncacheable (e.g., with the no-store cache directive defined in [HTTP-CACHING], Section 5.2.2.5) or＼
すべて（ “既定の” 応答も含む）に `Vary$h 応答~headerを伴わせて送信する ◎ send the Vary response header field ([HTTP], Section 12.5.5) on all responses from that resource (including the "default" response).

例えば、次の応答は： ◎ For example, this response:

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

[内容]

…は ⇒＃ ~cacheにより【！`私用~cache$, `共用~cache$どちらも】 60 秒は格納できる／ `If-None-Match$h で再検証できる／【その`内容~符号法$は】要請の `Accept-Encoding$h ~headerに応じて変わる ◎ can be stored for 60 seconds by both private and shared caches, can be revalidated with If-None-Match, and varies on the Accept-Encoding request header field.

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応答が［その`内容$は~browserからは能動的なものと扱われる］ものと意図されない例は、次の様な見かけになろう： ◎ An example of an HTTP response from an application that does not intend for its content to be treated as active by browsers might look like this:

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の仕組み］の利用を指定するときには，~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.

5. ~IANA考慮点

特になし。 ◎ This document has no IANA actions.

6. ~securityの考慮点

~HTTPを利用している応用は、［ ~HTTP自身, そこで利用される拡張］に対する~security考慮点の~subjectになる — 中でも `HTTP$r, `HTTP-CACHING$r, `WEB-LINKING$r が関連することが多い。 ◎ Applications using HTTP are subject to the security considerations of HTTP itself and any extensions used; [HTTP], [HTTP-CACHING], and [WEB-LINKING] are often relevant, amongst others.

`4.4.2§は、［認証, 完全性, 機密性］を供するため, および大規模な監視~攻撃を軽減するため、 `https$c ~URL用の~supportを推奨することに加え， `http$c ~URLの利用を忌避する。 ~HTTPを利用している多くの応用が、 `bearer^en ~token（例： ~session~cookie）†で認証と権限付与を遂行する。 ~transportが暗号化されていない場合、 ~HTTP通信を［盗聴-／改変- ］できる攻撃者は，`資源$に対する演算を遂行する特権を~~拡大できることが多い。 ◎ Section 4.4.2 recommends support for "https" URLs and discourages the use of "http" URLs to provide authentication, integrity, and confidentiality, as well as to mitigate pervasive monitoring attacks. Many applications using HTTP perform authentication and authorization with bearer tokens (e.g., in session cookies). If the transport is unencrypted, an attacker that can eavesdrop upon or modify HTTP communications can often escalate their privilege to perform operations on resources.

【† 当の~tokenを持参した者が~access権を得るような~token （`参考＠https://ja.wikipedia.org/wiki/Bearer%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3$）。 ~session~cookieの他にも，`能力~URL$が挙げられよう。】

`4.9.3§ は、 ~HTTP~cache法と［応用に特有な応答の格納-法やその中の情報］が合致しない可能性について特にとりあげる。 ◎ Section 4.9.3 highlights the potential for mismatch between HTTP caching and application-specific storage of responses or information therein.

`4.10§ は、 ~HTTPにおいて~statefulな仕組みを~ambient権限として利用することによる影響iを論じることに加え，それに対する軽減策を示唆する。 ◎ Section 4.10 discusses the impact of using stateful mechanisms in the protocol as ambient authority and suggests a mitigation.

`4.13§ は、 ~HTTPを利用する応用に対する~Web~browserの能力による含意を特にとりあげる。 ◎ Section 4.13 highlights the implications of Web browsers' capabilities on applications that use HTTP.

`4.14§ は、応用が~Web~site（および他の応用）と同じ生成元~上で配備されるときに発生する課題について論じる。 ◎ Section 4.14 discusses the issues that arise when applications are deployed on the same origin as websites (and other applications).

`4.15§ は、 ~HTTP2~server~pushを指定された以外の方式で利用することによる~riskを特にとりあげる。 ◎ Section 4.15 highlights risks of using HTTP/2 server push in a manner other than that specified.

応用が，実装の改変を孕む方式で~HTTPを利用する場合 — 例えば、［新たな~URI~scheme／標準でない`~method$ ］用の~supportを要求するなど — それらの実装が親~HTTP実装から “~~枝分かれ（ `fork^en ）” する結果，［上流に組入れられた~patchその他による，~securityの改善］から便益を得られなくなるなどの~riskがある。 ◎ Applications that use HTTP in a manner that involves modification of implementations -- for example, requiring support for a new URI scheme, or a non-standard method -- risk having those implementations "fork" from their parent HTTP implementations, with the possible result that they do not benefit from patches and other security improvements incorporated upstream.

6.1. ~privacyの考慮点

~HTTP`~client$は、多様な情報を`~server$に公開し得る。応用の運用の一部として明示的に送信される情報（例えば、利用者が手入力した，名前~その他の~data）, および “伝送路~上の” 情報（それが、 `4.4.2§ にて `https^c が推奨される理由の一つである）は別として、他の情報も~~明白でない手段（利用者が接続する活動を，時間~越しに収集するものが多い）を通して集められ得る。 ◎ HTTP clients can expose a variety of information to servers. Besides information that's explicitly sent as part of an application's operation (for example, names and other user-entered data) and "on the wire" (which is one of the reasons "https" is recommended in Section 4.4.2), other information can be gathered through less obvious means -- often by connecting activities of a user over time.

これには、［ ~session情報, 指紋収集を通した`~client$の追跡, ~code実行］も含まれる。 ◎ This includes session information, tracking the client through fingerprinting, and code execution.

~session情報は、［ `~client$の~IP~addressの様なもの, ~TLS~session~ticket, ~cookie, ~clientの~cache内に格納された `ETag$h, その他の~statefulな仕組み］を含む。応用は、運用にあたって［避けれない／必要yな］場合を除き， ~sessionの仕組みを利用するのは避けるよう勧める — そのような事例では、これらの~riskが文書化される必要がある。それらが利用されたときは、［そのような状態を~clearすることを許容する］よう，実装に奨励するべきである。 ◎ Session information includes things like the IP address of the client, TLS session tickets, Cookies, ETags stored in the client's cache, and other stateful mechanisms. Applications are advised to avoid using session mechanisms unless they are unavoidable or necessary for operation, in which case these risks need to be documented. When they are used, implementations should be encouraged to allow clearing such state.

指紋収集は、［ `~client$からの~message, ~clientの挙動］における一意な側面を利用して，異質な［要請どうし, 接続どうし］を~~関連付ける。例えば，［ `User-Agent$h ／ `Accept-Language$h ］要請~headerは、［実装に特有な情報／利用者が選好する言語］を伝達する。そのような~~指標のうちいくつかの組合nは、 ~clientを一意に識別するために利用され得る — それは、その【何の？】~dataに対するその制御に影響iがある。したがって，応用には、［ ~clientが要請~内に発する情報は、応用が機能するために必要なものに限るべきである］ものと指定するよう勧める。 ◎ Fingerprinting uses unique aspects of a client's messages and behaviours to connect disparate requests and connections. For example, the User-Agent request header field conveys specific information about the implementation; the Accept-Language request header field conveys the users' preferred language. In combination, a number of these markers can be used to uniquely identify a client, impacting its control over its data. As a result, applications are advised to specify that clients should only emit the information they need to function in requests.

最後に，ある応用が~codeを実行する能を公開する場合、多大な~careが必要になる — その環境を観測するどの能も，［ `~client$を指紋収集する, および私用な~data（~session情報も含む）を［得する／操作する］］ために利用され得る機会を与えるので。例えば，高-分解能な~timerへの~accessは（間接的であっても）、［下層の~hardwareを~profileする／当の~system用に一意な識別子を作成する］ために利用され得る。応用には、アリな所では［ ~mobile~code†の利用を許容するのを避ける］よう勧める — 避けれない場合、結果の~systemに備わる~securityの特質を，注意深く綿密に調べる必要がある††。 ◎ Finally, if an application exposes the ability to execute code, great care needs to be taken since any ability to observe its environment can be used as an opportunity to both fingerprint the client and to obtain and manipulate private data (including session information). For example, access to high-resolution timers (even indirectly) can be used to profile the underlying hardware, creating a unique identifier for the system. Applications are advised to avoid allowing the use of mobile code where possible; when it cannot be avoided, the resulting system's security properties need be carefully scrutinised.

【† “移動-可能な~code” — ~web~platformにおける~JSなど，他所から~downloadして実行-可能な~program。】【†† ~web~platformに関わるほぼすべての仕様に［ ~security／~privacy ］の考慮点がついてくるのは、このことが理由に挙げられよう。】

付録 A. ~RFC 3205 からの変更点

`RFC3205$r は、 2000 年代初頭に~protocol設計者が直面していた懸念に基づいて，その時点における現在の最善な実施を捕捉した。 ~HTTPの利用は，その頃からかなり変化したため、この文書は著しく異なる結果になった。その帰結として、変更点は，個別に挙げるにはあまりに多過ぎる。 ◎ [RFC3205] captured the Best Current Practice in the early 2000s based on the concerns facing protocol designers at the time. Use of HTTP has changed considerably since then; as a result, this document is substantially different. Consequently, the changes are too numerous to list individually.

このメモの位置付け

著作権の告知