[要約] RFC 9205は、HTTPを使用して新しいアプリケーションプロトコルを定義する際のベストプラクティスを示し、IETFの取り組みを指導するために書かれました。RFC 3205を置き換えるものであり、インターネット上で展開するためのHTTPベースのAPIを作成するアプリケーションに役立ちます。
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 9205 June 2022
BCP: 56
Obsoletes: 3205
Category: Best Current Practice
ISSN: 2070-1721
Building Protocols with HTTP
HTTPを使用したプロトコルの構築
Abstract
概要
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.
アプリケーションは、多くの場合、HTTPを基板として使用してHTTPベースのAPIを作成します。このドキュメントは、HTTPを使用して新しいアプリケーションプロトコルを定義する仕様を作成するためのベストプラクティスを指定しています。これは主に、インターネット上での展開のためにHTTPを使用してアプリケーションプロトコルを定義するためのIETFの取り組みを導くために書かれていますが、他の状況では適用できます。
This document obsoletes RFC 3205.
このドキュメントは、RFC 3205を廃止します。
Status of This Memo
本文書の位置付け
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPの詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9205.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9205で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Notational Conventions
2. Is HTTP Being Used?
2.1. Non-HTTP Protocols
3. What's Important About HTTP
3.1. Generic Semantics
3.2. Links
3.3. Rich Functionality
4. Best Practices for Specifying the Use of HTTP
4.1. Specifying the Use of HTTP
4.2. Specifying Server Behaviour
4.3. Specifying Client Behaviour
4.4. Specifying URLs
4.4.1. Discovering an Application's URLs
4.4.2. Considering URI Schemes
4.4.3. Choosing Transport Ports
4.5. Using HTTP Methods
4.5.1. GET
4.5.2. OPTIONS
4.6. Using HTTP Status Codes
4.6.1. Redirection
4.7. Specifying HTTP Header Fields
4.8. Defining Message Content
4.9. Leveraging HTTP Caching
4.9.1. Freshness
4.9.2. Stale Responses
4.9.3. Caching and Application Semantics
4.9.4. Varying Content Based Upon the Request
4.10. Handling Application State
4.11. Making Multiple Requests
4.12. Client Authentication
4.13. Coexisting with Web Browsing
4.14. Maintaining Application Boundaries
4.15. Using Server Push
4.16. Allowing Versioning and Evolution
5. IANA Considerations
6. Security Considerations
6.1. Privacy Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Changes from RFC 3205
Author's Address
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:
Webブラウジング以外のアプリケーションは、http [http]を基質として使用することがよくあります。これは、「HTTPベースのAPI」、「REST API」、または「HTTP API」の作成と呼ばれる場合もあります。これは、次のようなさまざまな理由で行われます。
* familiarity by implementers, specifiers, administrators, developers, and users;
* 実装者、仕様、管理者、開発者、およびユーザーによる親しみやすさ。
* availability of a variety of client, server, and proxy implementations;
* さまざまなクライアント、サーバー、およびプロキシの実装の可用性。
* ease of use;
* 使いやすさ;
* availability of Web browsers;
* Webブラウザの可用性。
* reuse of existing mechanisms like authentication and encryption;
* 認証や暗号化などの既存のメカニズムの再利用。
* presence of HTTP servers and clients in target deployments; and
* ターゲットの展開におけるHTTPサーバーとクライアントの存在。と
* its ability to traverse firewalls.
* ファイアウォールを通過する能力。
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.
これらのプロトコルは、多くの場合、1つまたは数のサーバーによる展開のみを目的とし、限られたクライアントのセットによる消費を目的としています。その結果、これらの条件を支持するHTTPベースのAPIの定義を中心に、さまざまな実践とツールが生じています。
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.
ただし、そのようなアプリケーションに複数の個別の実装があり、複数の非調整されていないサーバーに展開され、多様なクライアントによって消費される場合（標準努力によって定義されるHTTP APIの場合によくあるように）、展開の限られたツールとプラクティスは不適切になる可能性があります。
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.
このミスマッチは、主にAPIのクライアントとサーバーがさまざまなペースで実装および進化し、さまざまな機能とバージョンを共存する展開が必要になるためです。その結果、このような展開を目的としたHTTPベースのAPIの設計者は、サービスの拡張性がどのように処理され、さまざまな展開要件がどのように対応するかをより慎重に検討する必要があります。
More generally, an application protocol using HTTP faces a number of design decisions, including:
より一般的には、HTTPを使用したアプリケーションプロトコルは、以下を含む多くの設計上の決定に直面しています。
* Should it define a new URI scheme? Use new ports?
* 新しいURIスキームを定義する必要がありますか？新しいポートを使用しますか？
* 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の使用から最大値を抽出するにはどうすればよいですか？
* How does it coexist with other uses of HTTP -- especially Web browsing?
* HTTPの他の使用、特にWebブラウジングとどのように共存しますか？
* How can interoperability problems and "protocol dead ends" be avoided?
* 相互運用性の問題と「プロトコルの行き止まり」をどのように回避できますか？
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.
セクション2では、このドキュメントが適用される時期を定義し、セクション3では保存することが重要なHTTPのプロパティを調査し、セクション4には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.
これは主に、インターネット上での展開のためにHTTPを使用してアプリケーションプロトコルを定義するためのIETFの取り組みを導くために書かれていますが、他の状況では適用できます。ここの要件は、一般的なHTTP拡張機能の開発に必ずしも適用されないことに注意してください。
This document obsoletes [RFC3205] to reflect the experience and developments regarding HTTP in the intervening time.
この文書は、介入時間のHTTPに関する経験と開発を反映するために[RFC3205]を廃止します。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Different applications have different goals when using HTTP. The recommendations in this document apply when a specification defines an application that:
HTTPを使用すると、アプリケーションが異なる場合は異なる目標を持っています。このドキュメントの推奨事項は、仕様が次のアプリケーションを定義している場合に適用されます。
* uses the transport port 80 or 443, or
* 輸送ポート80または443を使用します
* uses the URI scheme "http" or "https", or
* URIスキーム「HTTP」または「HTTPS」、または
* uses an ALPN protocol ID [RFC7301] that generically identifies HTTP (e.g., "http/1.1", "h2", "h3"), or
* HTTP（「HTTP/1.1」、「H2」、「H3」など、一般的に識別するALPNプロトコルID [RFC7301]を使用します。
* makes registrations in or overall modifications to the IANA registries defined for HTTP.
* HTTP用に定義されたIANAレジストリへの登録または全体的な変更を行います。
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を使用している場合、HTTPプロトコルスイートのすべての要件が有効です（特に[HTTP]だけでなく、使用中のHTTPの特定のバージョンや使用中の拡張などの他の仕様もあります）。
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.
このドキュメントは、HTTPへの一般的な拡張機能ではなく、アプリケーションに適用することを目的としていることに注意してください。さらに、IETF指定のアプリケーションを対象としていますが、他の標準組織はその要件を遵守することが奨励されています。
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.
アプリケーションは、上記のように使用するための基準を満たすことなく、HTTPに依存できます。たとえば、アプリケーションは、メッセージ形式の部分を再特定することを避けたいが、プロトコルの操作の他の側面を変更したり、アプリケーション固有の方法を使用したりする場合がある場合があります。
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実装はこれらの変更に簡単に適応できないため、セクション3で概説されている利点の少なくとも一部は失われます。MindShareの利点も失われます。
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.
このような仕様は、HTTPのURIスキーム、輸送ポート、ALPNプロトコルID、またはIANAレジストリを使用してはなりません。むしろ、彼らは彼ら自身を確立することを奨励されています。
This section examines the characteristics of HTTP that are important to consider when using HTTP to define an application protocol.
このセクションでは、HTTPを使用してアプリケーションプロトコルを定義する際に考慮することが重要なHTTPの特性を調べます。
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).
HTTPの値の多くは、その一般的なセマンティクスにあります。つまり、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メッセージを一般的なソフトウェア（HTTPサーバー、仲介者、クライアントの実装、キャッシュなど）で処理することができます。また、特定のアプリケーションの特別な知識を必要とせずに、人々が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を使用するアプリケーションは、メソッド、ステータスコード、既存のヘッダーフィールドなどの汎用プロトコル要素のセマンティクスを再定義、改良、またはオーバーレイしてはなりません。代わりに、そのアプリケーションに固有のプロトコル要素、つまりHTTPリソースに仕様に焦点を合わせる必要があります。
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:
仕様を書くときは、HTTPがどのように実装、サポート、使用されるかを正確に指定したいと思うことがよくあります。ただし、これはHTTP動作の意図しないプロファイルに簡単につながる可能性があります。たとえば、このような言語の仕様を見るのは一般的です。
| A POST request MUST result in a 201 (Created) response.
|POSTリクエストは、201（作成）の応答をもたらす必要があります。
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.
これは、実際に実際の展開でステータスコードが異なる可能性がある理由がいくつかある場合、応答は常に201（作成）になるというクライアントの期待を形成します。たとえば、認証、サーバー側のエラー、またはリダイレクトを必要とするプロキシがある場合があります。クライアントがこれを予測しない場合、アプリケーションの展開は脆弱です。
See Section 4.2 for more details.
詳細については、セクション4.2を参照してください。
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.
別の一般的なプラクティスは、HTTPサーバーの名前空間（またはその一部）が単一のアプリケーションの使用専用であると仮定することです。これにより、そのスペースに特別なアプリケーション固有のセマンティクスが効果的にオーバーレイされ、他のアプリケーションが使用されないようになります。
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.
[BCP190]で説明されているように、標準的なURL空間の一部での「しゃがむ」ことは、標準的なリソースをサーバーの権限を奪い、展開の問題を引き起こす可能性があるため、標準の悪い実践です。
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.
パスのようなURIコンポーネントを静的に定義する代わりに、HTTPを使用したアプリケーションがリンク[Webリンク]を定義および使用して、展開を柔軟に可能にすることをお勧めします。
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).
この方法でランタイムリンクを使用すると、特にアプリケーションが複数の実装や展開を行う場合（標準化されたものの場合が多い場合）、他の多くの利点があります。
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.
たとえば、リンクを使用してナビゲートすることで、リクエストをリダイレクトのオーバーヘッドなしで別のサーバーにルーティングできるため、マシン全体の展開を適切にサポートできます。
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.
リンクを使用することにより、同じサーバー上のさまざまなアプリケーションを「混合および一致させる」こともできます。リンクの使用は、リンクを含むドキュメントにはターゲットに関する情報も含めることができるため、拡張性、バージョン、機能管理のための自然なメカニズムも提供します。
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.
リンクを使用すると、Webで見られるキャッシュの無効化も提供します。リソースの状態が変更されると、アプリケーションは影響を受けるリンクを変更して、新鮮なコピーが常に取得されるようになります。
See Section 4.4 for more details.
詳細については、セクション4.4を参照してください。
HTTP offers a number of features to applications, such as:
HTTPは、次のようなアプリケーションに多くの機能を提供します。
* Message framing
* メッセージフレーミング
* Multiplexing (in HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3])
* 多重化（http/2 [http/2]およびhttp/3 [http/3]）
* Integration with TLS
* TLSとの統合
* Support for intermediaries (proxies, gateways, content delivery networks (CDNs))
* 仲介者のサポート（プロキシ、ゲートウェイ、コンテンツ配信ネットワーク（CDNS））
* Client authentication
* クライアント認証
* Content negotiation for format, language, and other features
* フォーマット、言語、その他の機能のコンテンツネゴシエーション
* Caching for server scalability, latency and bandwidth reduction, and reliability
* サーバーのスケーラビリティ、レイテンシと帯域幅の削減、信頼性のキャッシュ
* Granularity of access control (through use of a rich space of URLs)
* アクセス制御の粒度（URLの豊富なスペースの使用による）
* Partial content to selectively request part of a response
* 応答の一部を選択的に要求する部分コンテンツ
* The ability to interact with the application easily using a Web browser
* Webブラウザを使用して簡単にアプリケーションと対話する機能
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.
HTTPを使用するアプリケーションは、プロトコルが提供するさまざまな機能を利用して、ユーザーがそれらの機能から最大の利益を受け取り、アプリケーションをさまざまな状況で展開できるようにすることをお勧めします。適切な設計トレードオフは特定の状況に非常に固有であるため、このドキュメントでは特定の機能を使用する必要はありません。ただし、セクション4のプラクティスに従うことは良い出発点です。
This section contains best practices for specifying the use of HTTP by applications, including practices for specific HTTP protocol elements.
このセクションには、特定のHTTPプロトコル要素のプラクティスを含むアプリケーションによるHTTPの使用を指定するためのベストプラクティスが含まれています。
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]をHTTPの主要な参照として使用する必要があります。具体的な理由がない限り、HTTPスイートのすべての仕様を参照する必要はありません（たとえば、特定の機能が呼び出されます）。
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.
HTTPはホップバイホッププロトコルであるため、アプリケーションによって制御されていない実装によって接続を処理できます。たとえば、プロキシ、CDN、ファイアウォールなど。特定のバージョンのHTTPを必要とすることで、これらの状況で使用することが難しくなり、相互運用性に害を及ぼします。したがって、HTTPを使用するアプリケーションが使用するHTTPの最小バージョンを指定することをお勧めしません。
However, if an application's deployment benefits from the use of a particular version of HTTP (for example, HTTP/2's multiplexing), this ought be noted.
ただし、アプリケーションの展開が特定のバージョンのHTTP（たとえば、HTTP/2のマルチプレックス）の使用から利益を得る場合、これに注意する必要があります。
Applications using HTTP MUST NOT specify a maximum version, to preserve the protocol's ability to evolve.
HTTPを使用したアプリケーションは、プロトコルの進化能力を維持するために、最大バージョンを指定してはなりません。
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:
プロトコルの相互作用の例を指定する場合、アプリケーションは要求メッセージと応答メッセージの両方を完全なヘッダーセクション、できればHTTP/1.1形式[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
[content here]
[ここのコンテンツ]
The server-side behaviours of an application are most effectively specified by defining the following protocol elements:
アプリケーションのサーバー側の動作は、次のプロトコル要素を定義することにより、最も効果的に指定されています。
* Media types [RFC6838], often based upon a format convention such as JSON [JSON];
* 多くの場合、JSON [JSON]などの形式コンベンションに基づいて、メディアタイプ[RFC6838]。
* HTTP header fields, per Section 4.7; and
* HTTPヘッダーフィールド、セクション4.7ごと。と
* The behaviour of resources, as identified by link relations [WEB-LINKING].
* リンク関係[Webリンク]によって識別されるリソースの動作。
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:
アプリケーションは、これらのプロトコル要素を作成して、リンク関係によって識別され、次のような指定された動作を実装するリソースのセットを定義することにより、操作を定義できます。
* retrieval of resource state using GET in one or more formats identified by media type;
* メディアタイプによって識別された1つ以上の形式で取得するリソース状態の取得。
* resource creation or update using POST or PUT, with an appropriately identified request content format;
* 適切に識別された要求コンテンツ形式を使用して、POSTまたはPUTを使用したリソースの作成または更新。
* data processing using POST and identified request and response content format(s); and
* 投稿および識別された要求および応答コンテンツ形式を使用したデータ処理。と
* Resource deletion using DELETE.
* deleteを使用したリソース削除。
For example, an application might specify:
たとえば、アプリケーションが指定する場合があります。
| 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.
|
| The Example-Count response header field on Widget representations
| indicates how many Widgets are held by the sender.
|
| 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.
Applications can also specify the use of URI Templates [URI-TEMPLATE] to allow clients to generate URLs based upon runtime data.
アプリケーションは、URIテンプレート[URI-Template]の使用を指定して、クライアントがランタイムデータに基づいてURLを生成できるようにすることもできます。
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.
クライアントの動作に対するアプリケーションの期待は、Webブラウザーのものと密接に一致するはずです。
One way to do this is to define it in terms of [FETCH] since that is the abstraction that browsers use for HTTP.
これを行う1つの方法は、ブラウザが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:
一部のクライアントの動作（自動リダイレクト処理など）および拡張機能（例：Cookie）はHTTPでは必要ありませんが、それでも非常に一般的になりました。HTTPを使用したアプリケーションによってそれらの使用が明示的に指定されていない場合、混乱と相互運用性の問題がある可能性があります。特に：
Redirect handling: Applications need to specify how redirects are expected to be handled; see Section 4.6.1.
リダイレクト処理：アプリケーションは、リダイレクトの処理方法を指定する必要があります。セクション4.6.1を参照してください。
Cookies: Applications using HTTP should explicitly reference the Cookie specification [COOKIES] if they are required.
Cookie：HTTPを使用するアプリケーションは、必要な場合はCookie仕様[Cookie]を明示的に参照する必要があります。
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を使用したアプリケーションでは、HTTPSを使用する場合、[HTTP]のセクション4.3.4に従ってTLS証明書を確認する必要があります。
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.
HTTPを使用したアプリケーションは、クライアントが通常交渉されるHTTP機能を静的にサポートする必要はありません。たとえば、クライアントが特定のコンテンツコーディング（[http]、セクション8.4.1）で応答をサポートする必要があるため、それを交渉する代わりに（[http]、セクション12.5.3）は、それ以外の場合は適合したクライアントがアプリケーションと相互操作できないことを意味します。ただし、アプリケーションはそのような機能の実装を促進できます。
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 [URL]で識別されます。[BCP190]が説明するように、URLの一部は、そのサーバーの所有者（「権限」とも呼ばれる）の制御下にあるように設計されており、展開の柔軟性を与えます。
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.
これは、ほとんどの場合、HTTPを使用するアプリケーションの仕様に固定アプリケーションURLまたはパスが含まれないことを意味します。単一展開APIの指定がパスプレフィックス「/app/v1」（たとえば）を指定するための一般的な慣行ですが、IETF仕様でそうすることは不適切です。
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).
したがって、仕様ライターは、クライアントがアプリケーションのURLを発見できるようにするためのいくつかのメカニズムを必要としています。さらに、アプリケーションを使用する必要があるURLスキームを指定し、専用ポートを使用するか、HTTPのポートを再利用するかを指定する必要があります。
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.
一般に、クライアントは、他の関連リソースへのリンクを含む可能性のある特定の展開に関する情報を含む初期ドキュメントを要求することにより、特定のアプリケーションサーバーとの対話を開始します。そうすることで、展開が可能な限り柔軟であることが保証され（複数のサーバーに及ぶ可能性があります）、進化を可能にし、アプリケーションにクライアントに「ディスカバリードキュメント」を調整する機会を与えます。
There are a few common patterns for discovering that initial URL.
その初期URLを発見するためのいくつかの一般的なパターンがあります。
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.
URL発見の最も簡単なメカニズムは、完全な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.
ただし、クライアントがサーバーのホスト名とアプリケーションのIDのみを知っている場合、その情報から初期URLを導き出す何らかの方法が必要です。
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:
アプリケーションは、URLパスの固定プレフィックスを定義できません。[BCP190]を参照してください。代わりに、そのようなアプリケーションの仕様では、次の戦略のいずれかを使用できます。
* 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.
* そのアプリケーションのエントリポイントとして、よく知られているURI [有名なURI]を登録します。これにより、他のアプリケーションと衝突しないすべての潜在的なサーバーに固定されたパスが提供されます。
* 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.
* サーバー当局が、エントリポイントのURLを生成するためのURIテンプレート[URI-Template]または同様のメカニズムを伝えることができます。たとえば、これは構成ドキュメントまたはその他のアーティファクトで行われる場合があります。
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.
ディスカバリードキュメントが配置されると、フェッチし、後で再利用するためにキャッシュされ（メタデータで許可されている場合）、完全なURIまたはURLテンプレートを使用してアプリケーションに関連する他のリソースを見つけるために使用できます。
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.
場合によっては、アプリケーションはそのような発見文書を使用することを望まない場合があります。たとえば、通信が非常に短い場合、またはそのようにすることの潜在的な懸念が発見文書の使用を排除する場合です。これらの状況は、すべてのアプリケーションのリソースを有名な場所に配置することで対処できます。
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].
HTTPを使用するアプリケーションは、通常、「HTTP」および/または「HTTPS」URIスキームを採用します。「HTTPS」は、認証、完全性、および機密性を提供するだけでなく、広範な監視攻撃を軽減するために推奨されます[RFC7258]。
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:
ただし、アプリケーション固有のスキームも定義できます。HTTPを使用してアプリケーションのURIスキームを定義する場合、留意すべき多くのトレードオフと警告があります。
* 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.
* 変更されていないWebブラウザーは、新しいスキームをサポートしません。Webブラウザー（[HTML]のRegisterProtocolhandler（）、およびいくつかの独自のアプローチ）で新しいURIスキームを登録することは可能ですが、これらのメカニズムのサポートはすべてのブラウザーによって共有されず、その機能は異なります。
* 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.
* 既存の非ブラウザークライアント、仲介者、サーバー、および関連するソフトウェアは、新しいスキームを認識しません。たとえば、クライアントライブラリはリクエストの発送に失敗し、キャッシュが応答の保存を拒否し、プロキシがリクエストの転送に失敗する可能性があります。
* 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.
* URLは一般にHTTPアーティファクトで発生し、しばしば自動的に生成されるため（例えば、位置応答ヘッダーフィールド）、新しいスキームが一貫して使用されることを保証することは困難です。
* 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.
* 新しいスキームによって特定されたリソースは、「HTTP」および/または「HTTPS」URLを使用して引き続き利用できます。これらのURLは、「漏れ」に使用できます。これにより、セキュリティと操作性の問題が発生します。たとえば、新しいスキームを使用して、リクエストが「通常の」Webサイトに送信されないようにすることが失敗する可能性があります。
* 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.
* Webの同じオリジンポリシーなど、URLの起源[RFC6454]に依存する機能は、スキームの変更によって影響を受けます。
* 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".
* Cookie [Cookie]、Authentication [HTTP]、Caching [HTTPキャッシュ]、HTTP Strict Transport Security（HSTS）[RFC6797]、およびクロスオリジンリソース共有（CORS）[FETCH]などのHTTP固有の機能はそれらの定義と実装方法に応じて、正しく動作します。一般に、それらは、URLが常に「HTTP」または「HTTPS」になるという仮定で設計および実装されます。
* Web features that require a secure context [SECCTXT] will likely treat a new scheme as insecure.
* 安全なコンテキスト[SECCTXT]を必要とするWeb機能は、新しいスキームを不安定であると扱う可能性があります。
See [RFC7595] for more information about minting new URI schemes.
新しいURIスキームのミントの詳細については、[RFC7595]を参照してください。
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).
アプリケーションは、該当するデフォルトポート（HTTPの80、HTTPSの443）を使用するか、他のポートに展開できます。この決定は、展開時に行うことができます。または、アプリケーションの仕様（たとえば、そのアプリケーションのポートを登録すること）によって奨励される場合があります。
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).
非デフォルトポートが使用されている場合、そのリソースのすべてのURLの権限に反映する必要があります。デフォルトのポートを変更する唯一のメカニズムは、URIスキームの変更です（セクション4.4.2を参照）。
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.
デフォルト以外のポートを使用すると、プライバシーへの影響があります（つまり、プロトコルは他のトラフィックと区別できるようになりました）、および操作性の懸念（一部のネットワークがブロックまたは干渉する可能性があるため）。プライバシーへの影響（この識別可能性に起因するものを含む）は、セキュリティに関する考慮事項で文書化する必要があります。
See [RFC7605] for further guidance.
さらなるガイダンスについては、[RFC7605]を参照してください。
Applications that use HTTP MUST confine themselves to using registered HTTP methods such as GET, POST, PUT, DELETE, and PATCH.
HTTPを使用するアプリケーションは、get、post、put、削除、パッチなどの登録されたHTTPメソッドを使用することに限定する必要があります。
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.
新しいHTTPメソッドはまれです。IETFレビュー（[http]を参照）を使用して「HTTPメソッドレジストリ」に登録する必要があり、ジェネリックも必要です。つまり、1つのアプリケーションのリソースだけでなく、すべてのリソースに適用できる可能性があることを意味します。
While historically some applications (e.g., [RFC4791]) have defined application-specific methods, [HTTP] now forbids this.
歴史的には、一部のアプリケーション（[RFC4791]など）はアプリケーション固有の方法を定義していますが、[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.
著者が新しい方法が必要であると信じている場合、HTTPコミュニティと早期に関与することをお勧めします（例：<mailto：ietf-http-wg@w3.org>メーリングリスト）。アプリケーションの仕様の一部としてではなく。
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.
GETは、最も一般的で便利なHTTPメソッドです。その検索セマンティクスにより、キャッシュと副作用のないリンクが可能になり、HTTPを使用することの多くの利点があります。
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.
多くの場合、URLのクエリコンポーネントを使用して、GETでクエリを実行できます。これはWebブラウジングのおなじみのパターンであり、結果をキャッシュすることができ、しばしば高価なプロセスの効率を向上させることができます。ただし、場合によっては、URIの構文が限られているため、クエリを表現するには扱いにくい場合があります。特に、バイナリデータがクエリ項の一部を形成する場合、URI構文に準拠するためにエンコードする必要があります。
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実装は、サポートするURLのサイズを制限しますが、最新のHTTPソフトウェアには以前よりもはるかに寛大な制限があります（通常、[HTTP]で要求されるように、8000オクテットをかなり多く）。
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.
これらの場合、HTTPを使用するアプリケーションは、Postの使用にリクエストのコンテンツのクエリを表現することを検討する場合があります。そうすることで、実装のオーバーヘッドとURLの長さの制限のエンコードが回避されます。ただし、そうすることで、キャッシュやクエリの結果へのリンクなどのGETの利点が失われることに注意する必要があります。したがって、ポストクエリのサポートを必要とするHTTPを使用するアプリケーションは、両方の方法を許可することを検討する必要があります。
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.
GETリクエストの処理は、アプリケーションの状態を変更したり、クライアントにとって重要な他の副作用を持つことはできません。さらに、TLSの初期データによって保護されている一部のGETリクエストは、リプレイ攻撃に対して脆弱である可能性があります（[RFC8470]を参照）。これには、ロギングや同様の機能が含まれていないことに注意してください。[HTTP]、セクション9.2.1を参照してください。
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).
最後に、汎用HTTP構文はGETリクエストメッセージがコンテンツを含めることを許可しているが、目的はメッセージパーサーを汎用にすることであることに注意してください。[HTTP]、セクション9.3.1、GETのコンテンツは推奨されず、意味がなく、一般的なHTTPソフトウェア（仲介者、キャッシュ、サーバー、クライアントライブラリなど）によって無視または拒否されます。
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.
オプション方法はメタデータ検索用に定義され、Web分散オーサリングとバージョン（WebDAV）[RFC4918]とCORS [Fetch]の両方で使用されます。HTTPベースのAPIは、多くの場合、リソースに関するメタデータを取得する必要があるため、多くの場合、使用が検討されます。
However, OPTIONS does have significant limitations:
ただし、オプションには大きな制限があります。
* It isn't possible to link to the metadata with a simple URL because OPTIONS is not the default method.
* オプションはデフォルトの方法ではないため、メタデータに単純なURLにリンクすることはできません。
* 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.
* HTTPキャッシュはリソースの表現（つまり、GETとヘッド）の表現で動作するため、オプションの応答はキャッシュできません。オプションの応答が個別にキャッシュされている場合、HTTPキャッシュの有効期限、セカンダリキー、およびその他のメカニズムとの相互作用を考慮する必要があります。
* OPTIONS is "chatty" -- requesting metadata separately increases the number of requests needed to interact with the application.
* オプションは「チャット」です。メタデータをリクエストすると、アプリケーションとの対話に必要なリクエストの数が個別に増加します。
* Implementation support for OPTIONS is not universal; some servers do not expose the ability to respond to OPTIONS requests without significant effort.
* オプションの実装サポートは普遍的ではありません。一部のサーバーでは、大規模な努力なしにオプションリクエストに応答する能力を公開しません。
Instead of OPTIONS, one of these alternative approaches might be more appropriate:
オプションの代わりに、これらの代替アプローチの1つがより適切かもしれません。
* 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]).
* サーバー全体のメタデータの場合、よく知られているURI [よく知られたURI]を作成するか、必要に応じて既存のURIを使用します（例：HOST-META [RFC6415]）。
* 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.
* 特定のリソースに関するメタデータの場合、リンク応答ヘッダーフィールドまたは応答のコンテンツにシリアル化されたリンクフィールドを使用して、個別のリソースとリンクを作成します。[Web-Linking]を参照してください。リンクヘッダーフィールドはヘッド応答で利用できることに注意してください。これは、クライアントがリソースと対話する前にリソースの機能を発見したい場合に役立ちます。
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.
HTTPステータスコードは、キャッシュ、仲介者、クライアントなどの汎用HTTPコンポーネントの利益のためにセマンティクスを伝えます。ただし、アプリケーションは使用に多くの落とし穴に遭遇する可能性があります。
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.
まず、ステータスコードは、多くの場合、アプリケーション自体以外のコンポーネントによって生成されます。これは、たとえば、ネットワークエラーが発生したときに発生する可能性があります。キャプティブポータル、プロキシ、またはコンテンツ配信ネットワークが存在する場合。または、サーバーが過負荷になっている場合、または攻撃を受けていると思われる場合。特定のエラー条件に遭遇した場合、一般的なクライアントソフトウェアによって生成することもできます。その結果、アプリケーションがこれらのステータスコードのいずれかに特定のセマンティクスを割り当てる場合、ステータスコードはアプリケーション自体ではなく汎用コンポーネントによって生成されたため、クライアントをその状態について誤解させることができます。
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ステータスコードにアプリケーションエラーをマッピングすると、1対1のコードが、適用されるHTTPステータスコードの有限空間が使い果たされる状況につながることがよくあります。これは、セマンティクスとアプリケーションのリンクがせいぜい希薄であるにもかかわらず、新しいアプリケーション固有のステータスコードを造ったり、既存のステータスコードを使用したりするなど、多くの悪いプラクティスにつながります。
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.
代わりに、HTTPを使用するアプリケーションは、エラーを定義して最も適用可能なステータスコードを使用し、疑わしい場合は一般的なステータスコード（200、400、および500）を寛大に使用する必要があります。重要なことに、ステータスコードとアプリケーションエラーの間に1対1の関係を指定してはならず、上記の疲労問題を回避する必要があります。
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.
同じステータスコードにマッピングされた複数のエラー条件を区別し、上記の誤った分布の問題を回避するために、HTTPを使用したアプリケーションは、応答のメッセージコンテンツおよび/またはヘッダーフィールドにより細かいエラー情報を伝える必要があります。[問題控除]は、そのための1つの方法を提供します。
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ステータスコードのセットが拡張できるため、HTTPを使用したアプリケーションは、クライアントが適用されるすべてのステータスコードを優雅に処理できるはずであることを明示的に指摘する必要があります（つまり、特定のステータスコードの汎用N00セマンティクスに戻ります。認識していないクライアントが400（悪い要求）として安全に処理できます。このようなリストは近い将来には完了しないため、これは潜在的なステータスコードの「ランドリーリスト」を作成する方が望ましいです。
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.
HTTPを使用したアプリケーションは、定義をコピーするだけであっても、HTTPステータスコードのセマンティクスを再指定してはなりません。特定の理由フレーズを使用する必要があることは推奨されません。理由フレーズにはHTTPに機能がないため、実装によって保存されることが保証されておらず、HTTP/2 [HTTP/2]メッセージ形式ではまったく携帯されていません。
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.
アプリケーションは、登録されたHTTPステータスコードのみを使用する必要があります。方法と同様に、新しいHTTPステータスコードはまれであり、（[http]によって）IETFレビューに登録する必要があります。同様に、HTTPステータスコードは汎用です。それらは、1つのアプリケーションのリソースだけでなく、すべてのリソースに適用できる可能性がある（[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.
著者が新しいステータスコードが必要であると信じている場合、HTTPコミュニティと早期に関与することをお勧めします（例：<mailto：ietf-http-wg@w3.org>メーリングリスト）。アプリケーションの仕様の一部としてではなく、拡張機能。
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.
[http]のセクション15.4で指定された3xxシリーズのステータスコードは、リクエストを満たすためにユーザーエージェントを別のリソースに指示します。これらの中で最も一般的なのは301、302、307、および308であり、それらはすべて、クライアントがリクエストを再送信する場所を示すために位置応答ヘッダーフィールドを使用します。
There are two ways that the members of this group of status codes differ:
このステータスコードグループのメンバーが異なる方法は2つあります。
* 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.
* 彼らが永続的であろうと一時的であるかどうか。永続的なリダイレクトを使用して、クライアントに保存されているリンク（ブックマークなど）を更新できますが、一時的なものはできません。これはHTTPキャッシングに影響を与えないことに注意してください。それは完全に個別です。
* 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.
* リダイレクトリクエストがリクエストメソッドを投稿から取得することを許可するかどうか。通常、Webブラウザーは301と302の場合に投稿を変更します。したがって、メソッドを変更せずにリダイレクトを可能にするために、308と307が作成されました。
This table summarises their relationships:
このテーブルは彼らの関係を要約しています：
+==============================+===========+===========+
| | Permanent | Temporary |
+==============================+===========+===========+
| Allows change of the request | 301 | 302 |
| method from POST to GET | | |
+------------------------------+-----------+-----------+
| Does not allow change of the | 308 | 307 |
| request method | | |
+------------------------------+-----------+-----------+
Table 1
表1
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.
303（その他を参照）ステータスコードを使用して、操作の結果がGETを使用して別の場所で利用できることをクライアントに通知できます。
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.
[http]で述べたように、ユーザーエージェントは、特定のステータスコードのセマンティクスを理解していなくても、位置応答ヘッダーフィールドを持つ3xxリダイレクトに自動的に従うことができます。しかし、彼らはそうする必要はありません。したがって、HTTPを使用するアプリケーションが自動的に従うようにリダイレクトする場合、これが必要なときに状況を明示的に指定する必要があります。
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.
リダイレクトはキャッシュすることができます（適切なキャッシュディレクティブが存在する場合）が、それを超えて「粘着性」ではありません。つまり、URIのリダイレクトは、類似のURI（例えば、クエリパラメーターが異なる）がそうなると仮定してクライアントになりません。また、リダイレクトされます。
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. 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.
HTTPを使用したアプリケーションは、301および302の応答が、ブラウザと互換性を持つように後続のリクエスト方法を投稿（ただし他の方法）から変更することを指定することをお勧めします。一般に、リダイレクトされた要求が行われると、ヘッダーフィールドは元のリクエストからコピーされます。ただし、さまざまなメカニズムによって変更できます。たとえば、要求の起源（および時にはパス）が変更されると、承認（[HTTP]、セクション11）およびCookie（[Cookie]）ヘッダーフィールドが変更されます。HTTPを使用するアプリケーションは、定義する要求ヘッダーフィールドを指定して、リダイレクト時に変更または削除する必要があるかどうかを指定する必要があります。ただし、ジェネリッククライアント（ブラウザのような）はそのような要件に気付かないため、この動作は依存することはできません。
Applications often define new HTTP header fields. Typically, using HTTP header fields is appropriate in a few different situations:
多くの場合、アプリケーションは新しいHTTPヘッダーフィールドを定義します。通常、HTTPヘッダーフィールドを使用することは、いくつかの異なる状況で適切です。
* The field is useful to intermediaries (who often wish to avoid parsing message content), and/or
* このフィールドは、メッセージコンテンツの解析を避けたいことが多い）および/または
* The field is useful to generic HTTP software (e.g., clients, servers), and/or
* このフィールドは、一般的なHTTPソフトウェア（クライアント、サーバーなど）、および/または
* It is not possible to include their values in the message content (usually because a format does not allow it).
* メッセージコンテンツに値を含めることはできません（通常、形式では許可されていないため）。
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.
上記の条件が満たされていない場合、通常、他の場所でアプリケーション固有の情報を伝える方が良いです。たとえば、メッセージコンテンツやURLクエリ文字列などです。
New header fields MUST be registered, per Section 16.3 of [HTTP].
[HTTP]のセクション16.3に従って、新しいヘッダーフィールドを登録する必要があります。
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.
[HTTP]のセクション16.3.2を参照して、新しいヘッダーフィールドをミントする際に考慮するガイドラインについては。[構造化場]は、新しいヘッダーフィールドに共通の構造を提供し、解析と取り扱いにおける多くの問題を回避します。新しいヘッダーフィールドを使用することをお勧めします。
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.
ヘッダーフィールド名は短くなることをお勧めします（フィールド圧縮が使用されている場合でも、オーバーヘッドがあります）が、適切に具体的です。特に、ヘッダーフィールドがアプリケーションに固有の場合、そのアプリケーションの識別子は、ハイフンで区切られたヘッダーフィールド名のプレフィックスを形成できます。
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.
たとえば、「例」アプリケーションが3つのヘッダーフィールドを作成する必要がある場合、それらは「例フー」、「例バー」、および「例バズ」と呼ばれる場合があります。ここでの主な動機は、アプリケーションの名前空間の一部を予約するのではなく、より一般的なフィールド名の消費を避けることであることに注意してください。関連する考慮事項については、[RFC6648]を参照してください。
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.
既存のHTTPヘッダーフィールドのセマンティクスは、登録を更新したり、拡張機能を定義したりすることなく再定義してはなりません（許可されている場合）。たとえば、HTTPを使用するアプリケーションでは、位置ヘッダーフィールドが特定のコンテキストで特別な意味を持つことを指定できません。
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.
ヘッダーフィールドとHTTPキャッシングの間の相互作用については、セクション4.9を参照してください。特に、選択に使用されるヘッダーフィールドを要求します（[httpキャッシュ]のセクション4.1ごとに）応答はそこに影響を及ぼし、慎重に検討する必要があります。
See Section 4.10 for considerations regarding header fields that carry application state (e.g., Cookie).
アプリケーション状態（例：Cookie）を運ぶヘッダーフィールドに関する考慮事項については、セクション4.10を参照してください。
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.
メッセージコンテンツの一般的な構文規則には、JSON [JSON]、XML [XML]、および簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]が含まれます。それらの使用のためのベストプラクティスは、このドキュメントの範囲外です。
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.
アプリケーションは、定義する各形式の個別のメディアタイプを登録する必要があります。これにより、それらを明確に識別し、それらの使用について交渉することが可能になります。詳細については、[RFC6838]を参照してください。
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キャッシュ[HTTPキャッシュ]は、アプリケーションにHTTPを使用することの主な利点の1つです。スケーラビリティを提供し、レイテンシを減らし、信頼性を向上させます。さらに、HTTPキャッシュは、ブラウザやその他のクライアント、フォワードおよびリバースプロキシとしてのネットワーク、コンテンツ配信ネットワーク、およびサーバーソフトウェアの一部で容易に利用できます。
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を使用しているアプリケーションがキャッシュを利用するように設計されていない場合でも、キャッシュが介在するときに正しい動作を維持するためにその応答を処理する方法を検討する必要があります（ネットワーク、サーバー、クライアント、または介入インフラストラクチャで）。
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.
短い新鮮な寿命（[httpキャッシング]、セクション4.2）を割り当てること - たとえば、5秒 - は、複数のクライアントおよび/または同じ要求を繰り返し作成する単一のクライアントを満足させるために応答を再利用できるようにします。一般に、何かを再利用することが安全である場合は、新鮮な寿命を割り当てることを検討してください。
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.
新鮮さを指定する最も一般的な方法は、最大年齢の応答指令（[HTTPキャッシュ]、セクション5.2.2.1）です。ヘッダーフィールドの有効期限（[httpキャッシュ]、セクション5.3）も使用できますが、必要ありません。すべての最新のキャッシュ実装は、キャッシュコントロールヘッダーフィールドをサポートしており、デルタとして新鮮さを指定することは通常、より便利でエラーが発生しやすくなります。
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.
ほとんどの応答をキャッシュするには、パブリックレスポンスディレクティブ（[HTTPキャッシュ]、セクション5.2.2.9）を追加する必要はありません。認証された応答を保存することが望ましい場合、またはステータスコードがキャッシュによって理解されておらず、利用可能な明示的な新鮮さの情報がない場合にのみ必要です。
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.
状況によっては、明示的なキャッシュのない応答は、新鮮な新鮮さの寿命を使用して保存され、提供されます。[HTTPキャッシュ]、セクション4.2.2を参照してください。ヒューリスティックはアプリケーションの制御下にあるわけではないため、一般に、明示的な新鮮さの寿命を設定するか、応答を明示的に無効にすることが望ましいです。
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).
応答のキャッシュが望まれない場合、適切なキャッシュ応答指令は店舗ではありません。他の指令は必要ありません。また、ストアなしでは、応答がキャッシュされる可能性のある状況では送信する必要があります。[httpキャッシュ]、セクション3を参照してください。ノーキャッシュ指令により、検証なしでキャッシュによって再利用されないだけで、応答を保存できることに注意してください。それは（その名前にもかかわらず）キャッシュを妨げません。
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
[content]
[コンテンツ]
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.
著者は、Origin Serverから切断された場合、古い応答（キャッシュ制御：Max-Age = 0を使用）をキャッシュによって再利用できることを理解する必要があります。これは、ネットワークの問題を処理するのに役立ちます。
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キャッシュ]のセクション4.2.4および[RFC5861]を参照してください。
Stale responses can be refreshed by assigning a validator, saving both transfer bandwidth and latency for large responses; see Section 13 of [HTTP].
古い応答は、バリデーターを割り当てることで更新でき、大きな応答のために転送帯域幅とレイテンシの両方を保存できます。[http]のセクション13を参照してください。
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.
アプリケーションが新鮮な寿命とは別の生涯を表現する必要がある場合、これは応答のコンテンツまたは別のヘッダーフィールドのいずれかで個別に伝達する必要があります。これが起こると、HTTPキャッシングとその寿命との関係は、応答が新鮮と見なされる限り使用されるため、慎重に検討する必要があります。
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).
特に、アプリケーションの著者は、Origin Serverから新たに取得されていない応答を処理する方法を検討する必要があります。有効期間のような概念がある場合、応答の年齢を考慮してこれを計算する必要があります（[httpキャッシュ]、セクション4.2.3を参照）。
One way to address this is to explicitly specify that responses need to be fresh upon use.
これに対処する1つの方法は、使用時に応答が新鮮である必要があることを明示的に指定することです。
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 make their responses uncacheable (e.g., with the no-store cache directive defined in [HTTP-CACHING], Section 5.2.2.5) or send the Vary response header field ([HTTP], Section 12.5.5) on all responses from that resource (including the "default" response).
アプリケーションがリクエストヘッダーフィールドを使用して応答のヘッダーフィールドまたはコンテンツを変更する場合、著者はこれがキャッシュに影響を与えることを指摘する必要があります。一般に、そのようなリソースは、応答を無効にする必要があります（たとえば、[httpキャッシュ]、セクション5.2.2.5で定義されているストアなしのキャッシュ指令）または変化する応答ヘッダーフィールド（[http]、セクション12.5を送信する必要があります。5）そのリソースからのすべての応答（「デフォルト」応答を含む）。
For example, this response:
たとえば、この応答：
HTTP/1.1 200 OK
Content-Type: application/example+xml
Cache-Control: max-age=60
ETag: "sa0f8wf20fs0f"
Vary: Accept-Encoding
[content]
[コンテンツ]
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.
プライベートキャッシュと共有キャッシュの両方で60秒間保存でき、IF-NONE-MATCHで再確認でき、受け入れエンコードリクエストヘッダーフィールドで変化します。
Applications can use stateful cookies [COOKIES] to identify a client and/or store client-specific data to contextualise requests.
アプリケーションは、Stateful Cookie [Cookie]を使用して、クライアントまたは/またはクライアント固有のデータを識別してリクエストをコンテキスト化することができます。
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.
使用する場合、Cookieのスコーピングと使用を慎重に指定することが重要です。アプリケーションが機密データまたは機能を公開している場合（たとえば、周囲の権限として機能することにより）、エクスプロイトが可能です。緩和には、クライアントの意図を確保するためにリクエスト固有のトークンを使用することが含まれます。
Clients often need to send multiple requests to perform a task.
多くの場合、クライアントはタスクを実行するために複数のリクエストを送信する必要があります。
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.
HTTP/1 [HTTP/1.1]では、複数の接続を開くことで並列リクエストがほとんどサポートされます。接続の混雑制御が調整されないため、あまりにも多くの同時接続が使用されている場合、アプリケーションのパフォーマンスが影響を受ける可能性があります。さらに、アプリケーションがいつ発行するか、特定の要求に使用する接続を決定することは難しい場合があり、パフォーマンスにさらに影響を与えます。
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/2 [HTTP/2]およびHTTP/3 [HTTP/3]は、アプリケーションに多重化を提供し、複数の接続を使用する必要性を削除します。ただし、アプリケーションのパフォーマンスは、サーバーが応答の優先順位付けを選択する方法によって依然として大きな影響を受ける可能性があります。アプリケーションに応じて、サーバーが応答の優先順位を決定したり、クライアントがサーバーの優先順位を示唆することが最適かもしれません（たとえば、[http-priority]を参照）。
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.
HTTPのすべてのバージョンで、リクエストは独立して行われます。処理命令を保証するために2つのリクエストの相対順序に依存することはできません。これは、仲介者による多重化プロトコルを介して送信されるか、異なるオリジンサーバーに送信されるか、サーバーが別の順序で処理を実行する可能性があるためです。2つのリクエストが厳密な順序付けが必要な場合、結果が最初の応答が始まったときに2番目の要求を発行することを確認するための唯一の信頼できる方法です。
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.
アプリケーションは、単一の輸送接続に関する個別の要求間の関係について仮定してはなりません。そうすることで、HTTPがステートレスプロトコルとしての多くの仮定を破り、相互運用性、セキュリティ、操作性、および進化に問題を引き起こします。
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.
アプリケーションは、HTTP認証（[http]のセクション11）を使用してクライアントを識別できます。[RFC7617]に従って、基本認証スキームは、チャネルが安全でない限り（「HTTPS」URIスキームを使用するなど）、機密情報または貴重な情報を保護するのに適していません。同様に、[RFC7616]は、安全なチャネルで使用されるダイジェスト認証スキームを必要とします。
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.
HTTPSを使用すると、クライアントは証明書[RFC8446]を使用して認証される場合がありますが、そのような認証は本質的に基礎となる輸送接続に範囲されていることに注意してください。その結果、クライアントは、応答の準備に認証されたステータスが使用されたかどうかを知る方法がありません（ *および/またはプライベートキャッシュ指令は部分的な兆候を提供できます）。新しい接続を開くことです。
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.
使用する場合、認証のスコーピングと使用を慎重に指定することが重要です。アプリケーションが機密データまたは機能を公開している場合（たとえば、周囲の権限として機能することにより、[RFC6454]のセクション8.3を参照）、エクスプロイトが可能です。緩和には、クライアントの意図を確保するためにリクエスト固有のトークンを使用することが含まれます。
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.
Webブラウザーでアプリケーションを使用する意図がない場合でも、そのリソースはブラウザや他のHTTPクライアントが利用できるままになります。これは、HTTPを使用するそのようなすべてのアプリケーションが、特にセキュリティに関して、ブラウザがそれらと対話する方法を検討する必要があることを意味します。
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.
たとえば、POSTリクエストを使用してアプリケーションの状態を変更できる場合、Webブラウザーは、任意のWebサイトからクロスサイトリクエストForgery（CSRF）に簡単に協力できます。
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.
または、攻撃者がアプリケーションのリソースから返されたコンテンツの制御を獲得した場合（たとえば、リクエストの一部が応答に反映されている場合、または応答に攻撃者が変更できる外部情報が含まれています）。データと機能は、それらが起源であるかのように - クロスサイトスクリプト（XSS）攻撃として知られる手法です。
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.
これは、HTTPを使用するアプリケーションが考慮する必要がある種類の問題のほんの一部です。一般的に、最良のアプローチは、アプリケーションを実際にWebアプリケーションとして考慮し、安全な開発のためのベストプラクティスに従うことです。
A complete enumeration of such practices is out of scope for this document, but some considerations include:
このようなプラクティスの完全な列挙は、このドキュメントの範囲外ではありませんが、いくつかの考慮事項は次のとおりです。
* Using an application-specific media type in the Content-Type header field, and requiring clients to fail if it is not used.
* コンテンツタイプのヘッダーフィールドでアプリケーション固有のメディアタイプを使用し、使用していない場合はクライアントに失敗する必要があります。
* 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.
* X-Content-Type-Options：nosniff [fetch]を使用して、攻撃者のコントロールの下のコンテンツをWebブラウザーによってアクティブなコンテンツとして解釈されるフォームに同アクセスできないことを確認します。
* 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.
* Content-Security-Policy [CSP]を使用して、アクティブコンテンツの機能（つまり、HTML [HTML]やPDFなどのスクリプトを実行できる）を制約し、XSS攻撃を軽減します。
* Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data in URLs from being leaked in the Referer request header field.
* Referrer-Policy [Referrer-Policy]を使用して、URLの機密データが参照要求ヘッダーフィールドに漏れなくなるのを防ぎます。
* Using the 'HttpOnly' flag on Cookies to ensure that cookies are not exposed to browser scripting languages [COOKIES].
* Cookieで「httponly」フラグを使用して、Cookieがブラウザスクリプト言語[Cookie]にさらされないようにします。
* 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.
* Webブラウザーが提供するスクリプト環境により、攻撃者が圧縮空間を繰り返しプローブできるようにするため、機密情報（認証トークン、パスワードなど）での圧縮の使用を回避します。攻撃者が通信のネットワークパスにアクセスできる場合、この情報を回復するためにこの機能を使用できます。
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を使用したアプリケーションの仕様は、これらのメカニズムを特定の方法で使用する必要があるか、単にセキュリティ上の考慮事項で指摘する場合があります。
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応答の例は、次のように見えるかもしれません。
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
[content]
[コンテンツ]
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.
アプリケーションに目標としてブラウザの互換性がある場合、クライアントの相互作用は[フェッチ]の観点から定義する必要があります。これは、ブラウザがHTTPに使用する抽象化であるためです。これらのベストプラクティスの多くが実施されます。
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.
多くのHTTP機能はOrigin [RFC6454]にスコープされているため、アプリケーションは同じOrigin Serverを使用する他のアプリケーション（Webブラウジングを含む）と展開する方法を検討する必要もあります。
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.
たとえば、Cookie [Cookie]を使用してアプリケーション状態を運ぶ場合、すべてのリクエストでデフォルトですべてのリクエストを送信します（パスでスコープしない限り）。これにより、セキュリティの問題やクッキー名の衝突につながる可能性があります。
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).
これらの問題の解決策の1つは、アプリケーションに専用のホスト名を要求して、独自の起源を持つことです。ただし、複数のアプリケーションを単一のホスト名に展開できるようにすることが望ましいことがよくあります。そうすることで、最も展開の柔軟性が最も多く、それらを一緒に「混合」することができます（詳細については[BCP190]を参照）。
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.
したがって、HTTPを使用するアプリケーションは、原点に関する複数のアプリケーションを許可するよう努力する必要があります。具体的には、Cookieの使用を指定する場合、HTTP認証レルム[HTTP]、またはその他の起源全体のHTTPメカニズムを使用する場合、HTTPを使用したアプリケーションは特定の名前の使用を義務付けるのではなく、代わりに展開を設定させます。指定されたメカニズムを使用して、それらを原点の一部にスコーピングすることを考慮する必要があります。
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].
最新のWebブラウザは、あるOriginのコンテンツの機能を制約して、個人情報の漏れを避けるために別のリソースからリソースにアクセスします。その結果、クロスオリジンデータをブラウザに公開したいアプリケーションでは、CORSプロトコルを実装する必要があります。[フェッチ]を参照してください。
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:
HTTP/2は、[HTTP/2]、セクション8.4のクライアントにリクエスト/応答ペアを「プッシュ」/応答ペアを「プッシュ」する機能を追加しました。サーバーのプッシュは、多くの一般的なアプリケーションセマンティクス（「ファンアウト」や公開/サブスクライブなど）には自然に適合しているように見えますが、いくつかの警告に注意する必要があります。
* 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 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.
* サーバープッシュは、特にクライアントが実際に要求されたリソースとの争いがある場合、誤って使用した場合、HTTPにマイナスのパフォーマンスに影響を与える可能性があります。
* Server push is implemented differently in different clients, especially regarding interaction with HTTP caching, and capabilities might vary.
* サーバーのプッシュは、特にHTTPキャッシュとの対話に関して、異なるクライアントで異なる方法で実装されており、機能は異なる場合があります。
* 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.
* サーバープッシュのAPIは現在、一部の実装では利用できず、他のものでは大きく異なります。特に、現在のブラウザAPIはありません。
* Server push is not supported in HTTP/1.1 or HTTP/1.0.
* サーバープッシュは、HTTP/1.1またはHTTP/1.0ではサポートされていません。
* Server push does not form part of the "core" semantics of HTTP and therefore might not be supported by future versions of the protocol.
* サーバープッシュは、HTTPの「コア」セマンティクスの一部を形成しないため、プロトコルの将来のバージョンではサポートされない可能性があります。
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].
完全な応答が利用可能になる前にクライアントがリクエストに関連する作業を実行できるケースを最適化したいアプリケーション（たとえば、内部に含まれる可能性のあるもののリンクを取得する）は、103（初期ヒント）ステータスコードを使用することで利益を得ることができます。[RFC8297]を参照してください。
Applications using server push directly need to enforce the requirements regarding authority in [HTTP/2], Section 8.4 to avoid cross-origin push attacks.
サーバープッシュを使用したアプリケーションは、クロスオリジンプッシュ攻撃を避けるために、[http/2]、セクション8.4の権限に関する要件を直接実施する必要があります。
It's often necessary to introduce new features into application protocols and change existing ones.
多くの場合、アプリケーションプロトコルに新しい機能を導入し、既存のプロトコルを変更する必要があります。
In HTTP, backwards-incompatible changes can be made using mechanisms such as:
HTTPでは、以下のようなメカニズムを使用して、逆方向に不可能な変更を行うことができます。
* Using a distinct link relation type [WEB-LINKING] to identify a URL for a resource that implements the new functionality.
* 異なるリンク関係タイプ[Web-Linking]を使用して、新しい機能を実装するリソースのURLを識別します。
* Using a distinct media type [RFC6838] to identify formats that enable the new functionality.
* 異なるメディアタイプ[RFC6838]を使用して、新しい機能を有効にするフォーマットを識別します。
* Using a distinct HTTP header field to implement new functionality outside the message content.
* 異なるHTTPヘッダーフィールドを使用して、メッセージコンテンツの外側に新しい機能を実装します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
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.
HTTPを使用したアプリケーションは、HTTP自体のセキュリティ上の考慮事項と使用される拡張機能の対象となります。[HTTP]、[HTTPキャッシュ]、および[Webリンク]は、とりわけ関連することがよくあります。
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.
セクション4.4.2では、「HTTPS」URLのサポートを推奨し、「HTTP」URLの使用を阻止して、認証、完全性、および機密性を提供し、広範な監視攻撃を緩和します。HTTPを使用した多くのアプリケーションは、ベアラートークン（セッションCookieなど）で認証と承認を実行します。トランスポートが暗号化されていない場合、HTTP通信を盗聴または変更できる攻撃者は、多くの場合、リソースの運用を実行するための特権をエスカレートすることができます。
Section 4.9.3 highlights the potential for mismatch between HTTP caching and application-specific storage of responses or information therein.
セクション4.9.3は、HTTPキャッシュとその中の応答または情報のアプリケーション固有のストレージとの間の不一致の可能性を強調しています。
Section 4.10 discusses the impact of using stateful mechanisms in the protocol as ambient authority and suggests a mitigation.
セクション4.10では、プロトコルにおけるステートフルメカニズムを周囲の権威として使用することの影響について説明し、緩和を提案しています。
Section 4.13 highlights the implications of Web browsers' capabilities on applications that use HTTP.
セクション4.13は、HTTPを使用するアプリケーションに対するWebブラウザの機能の意味を強調しています。
Section 4.14 discusses the issues that arise when applications are deployed on the same origin as websites (and other applications).
セクション4.14では、アプリケーションがWebサイト（およびその他のアプリケーション）と同じ起源に展開されたときに発生する問題について説明します。
Section 4.15 highlights risks of using HTTP/2 server push in a manner other than that specified.
セクション4.15は、指定されたもの以外の方法でHTTP/2サーバープッシュを使用するリスクを強調しています。
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.
実装の変更を含む方法でHTTPを使用するアプリケーション（たとえば、新しいURIスキームや非標準的な方法のサポートが必要な場合）は、親HTTP実装から「フォーク」の実装を持つリスクがあり、結果として結果が得られるリスクがあります。それらは、上流に組み込まれたパッチやその他のセキュリティの改善の恩恵を受けていません。
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.
HTTPクライアントは、さまざまな情報をサーバーに公開できます。アプリケーションの操作の一部として明示的に送信される情報（たとえば、名前やその他のユーザーが入力したデータ）および「On the Wire」（これは、「HTTPS」がセクション4.4.2で推奨される理由の1つです）、その他の情報多くの場合、ユーザーのアクティビティを時間の経過とともに接続することにより、それほど明白ではない手段で収集できます。
This includes session information, tracking the client through fingerprinting, and code execution.
これには、セッション情報、フィンガープリントによるクライアントの追跡、およびコード実行が含まれます。
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.
セッション情報には、クライアントのIPアドレス、TLSセッションチケット、Cookie、クライアントのキャッシュに保存されているETAG、その他のステートフルメカニズムなどが含まれます。アプリケーションは、セッションメカニズムが避けられないか、動作に必要でない限り、セッションメカニズムを使用しないようにすることをお勧めします。その場合、これらのリスクを文書化する必要があります。それらが使用される場合、そのような状態のクリアを許可するために実装を奨励する必要があります。
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.
フィンガープリントは、クライアントのメッセージと動作のユニークな側面を使用して、異なる要求と接続を接続します。たとえば、ユーザーエージェントリクエストヘッダーフィールドは、実装に関する特定の情報を伝えます。Accept-Language Request Headerフィールドは、ユーザーの優先言語を伝えます。組み合わせて、これらのマーカーの多くを使用して、クライアントを一意に識別し、データに対する制御に影響を与えます。その結果、アプリケーションは、クライアントがリクエストで機能するために必要な情報のみを放出する必要があることを指定することをお勧めします。
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.
最後に、アプリケーションがコードを実行する能力を公開する場合、環境を観察する能力をクライアントに指紋に塗りつけ、プライベートデータを取得して操作する機会として使用できるため、細心の注意が必要です（セッション情報を含む）。たとえば、高解像度タイマーへのアクセス（間接的に）を使用して、基礎となるハードウェアのプロファイルを使用して、システムの一意の識別子を作成できます。可能な場合は、モバイルコードの使用を許可しないようにアプリケーションをお勧めします。避けられない場合、結果のシステムのセキュリティプロパティは慎重に精査する必要があります。
[BCP190] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 8820, DOI 10.17487/RFC8820, June 2020, <https://www.rfc-editor.org/rfc/rfc8820>.
[BCP190]ノッティンガム、M。、「URIデザインと所有権」、BCP 190、RFC 8820、DOI 10.17487/RFC8820、2020年6月、<https://www.rfc-editor.org/rfc/rfc820>。
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[HTTP] Fielding、R.、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/info/rfc9110>。
[HTTP-CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[HTTPキャッシュ] Fielding、R.、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "Http Caching"、Std 98、RFC 9111、DOI 10.17487/RFC9111、2022年6月、<https：//www.rfc-editor.org/info/rfc9111>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.
[RFC6454] Barth、A。、「Web Origin Concept」、RFC 6454、DOI 10.17487/RFC6454、2011年12月、<https://www.rfc-editor.org/info/rfc6454>。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, <https://www.rfc-editor.org/info/rfc6648>.
[RFC6648] Saint-Andre、P.、Crocker、D。、およびM. Nottingham、「アプリケーションプロトコルにおける「X」プレフィックスと同様のコンストラクトを非難する」、BCP 178、RFC 6648、DOI 10.17487/RFC6648、2012年6月、<https://www.rfc-editor.org/info/rfc6648>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487/RFC6838、2013年1月、<https：//www.rfc-editor.org/info/rfc6838>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[STRUCTURED-FIELDS] Nottingham, M. and P-H. Kamp, "Structured Field Values for HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, <https://www.rfc-editor.org/info/rfc8941>.
[構造化場]ノッティンガム、M。およびP-H。Kamp、「HTTPの構造化されたフィールド値」、RFC 8941、DOI 10.17487/RFC8941、2021年2月、<https://www.rfc-editor.org/info/rfc8941>。
[URL] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[URL] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[WEB-LINKING] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[Web-Linking] Nottingham、M。、「Web Linking」、RFC 8288、DOI 10.17487/RFC8288、2017年10月、<https://www.rfc-editor.org/info/rfc8288>。
[WELL-KNOWN-URI] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.
[有名-URI]ノッティンガム、M。、「有名なユニフォームリソース識別子（URIS）」、RFC 8615、DOI 10.17487/RFC8615、2019年5月、<https://www.rfc-editor.org/info//RFC8615>。
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[Cookies] Barth、A。、「HTTP状態管理メカニズム」、RFC 6265、DOI 10.17487/RFC6265、2011年4月、<https://www.rfc-editor.org/info/rfc6265>。
[CSP] West, M., "Content Security Policy Level 3", W3C Working Draft, June 2021, <https://www.w3.org/TR/2021/WD-CSP3-20210629>.
[CSP] West、M。、「コンテンツセキュリティポリシーレベル3」、W3Cワーキングドラフト、2021年6月、<https://www.w3.org/tr/2021/wd-csp3-20210629>。
[FETCH] WHATWG, "Fetch - Living Standard", <https://fetch.spec.whatwg.org>.
[Fetch] Whatwg、 "Fetch -Living Standard"、<https://fetch.spec.whatwg.org>。
[HTML] WHATWG, "HTML - Living Standard", <https://html.spec.whatwg.org>.
[html] whatwg、 "html -living Standard"、<https://html.spec.whatwg.org>。
[HTTP-PRIORITY] 奥 一穂 (Oku, K.) and L. Pardue, "Extensible Prioritization Scheme for HTTP", RFC 9218, DOI 10.17487/RFC9218, June 2022, <https://www.rfc-editor.org/info/rfc9218>.
[HTTP優先度]奥奥奥（Oku、K。）およびL. Pardue、「HTTPの拡張可能な優先順位付けスキーム」、RFC 9218、DOI 10.17487/RFC9218、2022年6月、<https：//www.rfc-editor.org/情報/RFC9218>。
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/1.1] Fielding、R.、ed。、Nottingham、M.、ed。、およびJ. Reschke、ed。、 "Http/1.1"、Std 99、RFC 9112、DOI 10.17487/RFC9112、2022年6月、<<https://www.rfc-editor.org/info/rfc9112>。
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.
[HTTP/2] Thomson、M.、ed。and C. Benfield、ed。、「HTTP/2」、RFC 9113、DOI 10.17487/RFC9113、2022年6月、<https://www.rfc-editor.org/info/rfc9113>。
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[HTTP/3] Bishop、M.、ed。、 "HTTP/3"、RFC 9114、DOI 10.17487/RFC9114、2022年6月、<https://www.rfc-editor.org/info/rfc9114>。
[JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[JSON] Bray、T.、ed。、「JavaScriptオブジェクト表記（JSON）データインターチェンジ形式」、STD 90、RFC 8259、DOI 10.17487/RFC8259、2017年12月、<https://www.rfc-editor.org/info/rfc8259>。
[PROBLEM-DETAILS] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, <https://www.rfc-editor.org/info/rfc7807>.
[問題 - 控除]ノッティンガム、M。およびE.ワイルド、「HTTP APIの問題の詳細」、RFC 7807、DOI 10.17487/RFC7807、2016年3月、<https://www.rfc-editor.org/info/rfc7807>。
[REFERRER-POLICY] Eisinger, J. and E. Stark, "Referrer Policy", W3C Candidate Recommendation CR-referrer-policy-20170126, January 2017, <https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
[Referrer-Policy] Eisinger、J。およびE. Stark、「リファラーポリシー」、W3C候補の推奨CR-Referrer-Policy-20170126、2017年1月、<https://www.w3.org/tr/2017/cr-Referrer-Policy-20170126>。
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, DOI 10.17487/RFC3205, February 2002, <https://www.rfc-editor.org/info/rfc3205>.
[RFC3205]ムーア、K。、「基質としてのHTTPの使用について」、BCP 56、RFC 3205、DOI 10.17487/RFC3205、2002年2月、<https://www.rfc-editor.org/info/RFC3205>。
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March 2007, <https://www.rfc-editor.org/info/rfc4791>.
[RFC4791] Daboo、C.、Desruisseaux、B。、およびL. Dusseault、「WebDav（CalDav）への拡張カレンダー」、RFC 4791、DOI 10.17487/RFC4791、2007年3月、<https：//ww.rfc-editor。org/info/rfc4791>。
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007, <https://www.rfc-editor.org/info/rfc4918>.
[RFC4918] Dusseault、L.、ed。、「Web分散オーサリングとバージョン（WebDav）のHTTP拡張機能」、RFC 4918、DOI 10.17487/RFC4918、2007年6月、<https：//www.rfc-editor.org/info/rfc4918>。
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, <https://www.rfc-editor.org/info/rfc5861>.
[RFC5861]ノッティンガム、M。、「古いコンテンツのHTTPキャッシュコントロール拡張」、RFC 5861、DOI 10.17487/RFC5861、2010年5月<https://www.rfc-editor.org/info/rfc5861>。
[RFC6415] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", RFC 6415, DOI 10.17487/RFC6415, October 2011, <https://www.rfc-editor.org/info/rfc6415>.
[RFC6415] Hammer-Lahav、E.、ed。およびB.クック、「Webホストメタデータ」、RFC 6415、DOI 10.17487/RFC6415、2011年10月、<https://www.rfc-editor.org/info/rfc6415>。
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012, <https://www.rfc-editor.org/info/rfc6797>.
[RFC6797] Hodges、J.、Jackson、C。、およびA. Barth、「HTTP Strict Transport Security（HSTS）」、RFC 6797、DOI 10.17487/RFC6797、2012年11月、<https：//www.rfc-editor。org/info/rfc6797>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「広範な監視は攻撃です」、BCP 188、RFC 7258、DOI 10.17487/RFC7258、<https：//www.rfc-editor.org/info/rfc72588>。
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「輸送層セキュリティ（TLS）アプリケーション層プロトコル交渉拡張」、RFC 7301、DOI 10.17487/RFC7301、2014年7月、<https://www.rfc-editor.org/info/rfc7301>。
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/info/rfc7595>.
[RFC7595] Thaler、D.、ed。、Hansen、T.、およびT. Hardie、「URIスキームのガイドラインと登録手順」、BCP 35、RFC 7595、DOI 10.17487/RFC7595、2015年6月、<HTTPS：//www.rfc-editor.org/info/rfc7595>。
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, August 2015, <https://www.rfc-editor.org/info/rfc7605>.
[RFC7605] Touch、J。、「割り当てられた輸送ポート番号の使用に関する推奨事項」、BCP 165、RFC 7605、DOI 10.17487/RFC7605、2015年8月、<https://www.rfc-editor.org/info/rfc7605>
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC7616] Shekh-Yusef、R.、Ed。、Ahrens、D.、およびS. Bremer、「HTTP Digest Access Authentication」、RFC 7616、DOI 10.17487/RFC7616、2015年9月、<https：//www.rfc-editor.org/info/rfc7616>。
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <https://www.rfc-editor.org/info/rfc7617>.
[RFC7617] Reschke、J。、「「基本」HTTP認証スキーム」、RFC 7617、DOI 10.17487/RFC7617、2015年9月、<https://www.rfc-editor.org/info/rfc7617>
[RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", RFC 8297, DOI 10.17487/RFC8297, December 2017, <https://www.rfc-editor.org/info/rfc8297>.
[RFC8297] OKU、K。、「ヒントを示すためのHTTPステータスコード」、RFC 8297、DOI 10.17487/RFC8297、2017年12月、<https://www.rfc-editor.org/info/rfc8297>
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/rfc8470>.
[RFC8470] Thomson、M.、Nottingham、M.、およびW. Tarreau、「HTTPで初期データを使用」、RFC 8470、DOI 10.17487/RFC8470、2018年9月、<https://www.rfc-edtion.org/g/情報/RFC8470>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C。and P. Hoffman、「Concise binary Object Lepressation（CBOR）」、STD 94、RFC 8949、DOI 10.17487/RFC8949、2020年12月、<https://www.rfc-editor.org/info/RFC8949>。
[SECCTXT] West, M., "Secure Contexts", W3C Candidate Recommendation, September 2021, <https://www.w3.org/TR/2021/CRD-secure-contexts-20210918>.
[Secctxt] West、M。、「Secure Contexts」、W3C候補の推奨、2021年9月、<https://www.w3.org/tr/2021/crd-secure-contexts-20210918>。
[URI-TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-editor.org/info/rfc6570>.
[Uri-Template] Gregorio、J.、Fielding、R.、Hadley、M.、Nottingham、M.、D。Orchard、 "URI Template"、RFC 6570、DOI 10.17487/RFC6570、2012年3月、<https：//www.rfc-editor.org/info/rfc6570>。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.
[XML] Bray、T.、Paoli、J.、Sperberg-Mcqueen、M.、Maler、E。、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第5版）」、W3C推奨REC-XML-20081126、2008年11月、<https://www.w3.org/tr/2008/rec-xml-20081126>。
[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.
[RFC3205]は、当時のプロトコルデザイナーが直面している懸念に基づいて、2000年代初頭に最高の現在の慣行を獲得しました。それ以来、HTTPの使用はかなり変化しています。その結果、このドキュメントは大幅に異なります。その結果、変更は個別にリストするには多すぎます。
Author's Address
著者の住所
Mark Nottingham
Prahran
Australia
Email: mnot@mnot.net
URI: https://www.mnot.net/