[要約] RFC 9205は、HTTPをアプリケーションプロトコルの基盤（基底プロトコル）として使用する際のベストプラクティスをまとめています。RFC 3205を廃止し、HTTP/2やHTTP/3などの進化を踏まえた最新の設計指針、セキュリティ、および拡張性のためのガイドラインを提供します。API設計者がHTTPのセマンティクスを適切に利用し、インターネット上での相互運用性を高めるための重要な参照ドキュメントです。
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.
このメモは、インターネットの最良の現行慣行（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.
このドキュメントは、Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group (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.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、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.
Copyright (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 ドキュメントに関連する IETF Trust の法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書は、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、法的規定のセクション 4.e に記載されている Revised BSD License のテキストを含める必要があり、Revised BSD License に記載されている通り、無保証で提供されます。
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"、"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 を一般的に識別する ALPN プロトコル ID [RFC7301]（例：「http/1.1」、「h2」、「h3」）を使用する、または
* 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 で概説されている利点の少なくとも一部が失われます。マインドシェアの利点も失われます。
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 (Created) になるという期待をクライアントに形成させます。クライアントがこれを予期していない場合、アプリケーションの展開は脆弱になります。
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 空間の一部を「占拠（squatting）」することは、サーバー自身の各リソースに対する権限を奪い、展開の問題を引き起こす可能性があるため、標準化においては悪い慣行です。
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-LINKING] を定義および使用して、展開の柔軟性を高めることが推奨されます。
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];
* メディアタイプ [RFC6838]（JSON [JSON] などの形式規則に基づくことが多い）。
* HTTP header fields, per Section 4.7; and
* HTTP ヘッダーフィールド（セクション 4.7 を参照）。および
* The behaviour of resources, as identified by link relations [WEB-LINKING].
* リンク関係 [WEB-LINKING] によって識別されるリソースの動作。
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つ以上の形式での GET を使用したリソース状態の取得。
* 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
* POST および識別されたリクエスト/レスポンスコンテンツ形式を使用したデータ処理。および
* 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.
アプリケーションは、クライアントが実行時のデータに基づいて URL を生成できるように、URI テンプレート [URI-TEMPLATE] の使用を指定することもできます。
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.
これを行う一つの方法は、ブラウザが HTTP に使用する抽象化である [FETCH] の用語で定義することです。
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:
一部のクライアントの動作（自動リダイレクト処理など）や拡張機能（クッキーなど）は、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.
クッキー：クッキーが必要な場合、HTTP を使用するアプリケーションはクッキー仕様 [COOKIES] を明示的に参照すべきです。
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] セクション 12.5.3) する代わりに、クライアントが特定のコンテンツコーディング ([HTTP] セクション 8.4.1) のレスポンスをサポートすることを要求すると、他の点では準拠しているクライアントがそのアプリケーションと相互運用できなくなります。ただし、アプリケーションがそのような機能の実装を推奨することは可能です。
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.
しかし、クライアントがサーバーのホスト名とアプリケーションの識別子しか知らない場合は、その情報から初期 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.
* そのアプリケーションのエントリポイントとして well-known URI [WELL-KNOWN-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.
通信が非常に短い場合や、ディスカバリドキュメントを使用することによる遅延の懸念から、アプリケーションがそのようなドキュメントを使用したくない場合があります。これらの状況は、アプリケーションのすべてのリソースを well-known な場所に配置することで対処できます。
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 スキームを使用します。認証、整合性、機密性を提供し、広範な監視攻撃 [RFC7258] を軽減するために、「https」を使用することが推奨されます。
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 ブラウザに新しい URI スキームを登録することは可能ですが（例：[HTML] の registerProtocolHandler() やいくつかの独自の手法）、これらのメカニズムのサポートはすべてのブラウザで共通ではなく、その機能も異なります。
* 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 アーティファクトで一般的に出現し、自動的に生成されることも多いため（例：Location レスポンスヘッダーフィールド）、新しいスキームが一貫して使用されることを保証するのは難しい場合があります。
* 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 の同一生成元ポリシー（same-origin policy）など、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".
* クッキー [COOKIES]、認証 [HTTP]、キャッシュ [HTTP-CACHING]、HTTP Strict Transport Security (HSTS) [RFC6797]、Cross-Origin Resource Sharing (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、DELETE、PATCH などの登録済み 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 Method Registry」に登録される必要があり、また汎用的である必要があります。つまり、一つのアプリケーションのリソースだけでなく、すべてのリソースに適用可能である可能性があります。
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> メーリングリストなど）に参加し、アプリケーションの仕様の一部としてではなく、独立した HTTP 拡張として提案を文書化することが推奨されます。
GET is the most common and useful HTTP method; its retrieval semantics allow caching and side-effect free linking and underlie many of the benefits of using HTTP.
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 の構文の制限により、GET がクエリの表現に適さないことがあります。特にバイナリデータがクエリ条件の一部を構成する場合、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 の利点が失われることに注意すべきです。したがって、POST によるクエリのサポートを必要とする 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.
実装は失敗した HTTP GET リクエストを再試行する可能性があり、実際に再試行するため、GET リクエストの処理によってアプリケーションの状態を変更したり、クライアントにとって重要な他の副作用を発生させたりすべきではありません。さらに、TLS Early Data によって保護された一部の 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.
OPTIONS メソッドはメタデータ取得のために定義され、Web Distributed Authoring and Versioning (WebDAV) [RFC4918] と CORS [FETCH] の両方で使用されます。HTTP ベースの API ではリソースに関するメタデータを取得する必要が多いため、OPTIONS の使用が検討されることがよくあります。
However, OPTIONS does have significant limitations:
しかし、OPTIONS には大きな制限があります。
* It isn't possible to link to the metadata with a simple URL because OPTIONS is not the default method.
* OPTIONS はデフォルトのメソッドではないため、単純な 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.
* OPTIONS レスポンスは、HTTP キャッシュがリソースの表現（GET および HEAD）に対して動作するため、キャッシュ不可能です。OPTIONS レスポンスを個別にキャッシュする場合、HTTP キャッシュの有効期限、セカンダリキー、その他のメカニズムとの相互作用を考慮する必要があります。
* OPTIONS is "chatty" -- requesting metadata separately increases the number of requests needed to interact with the application.
* OPTIONS は「通信回数が多い（chatty）」です。メタデータを個別にリクエストすると、アプリケーションとの対話に必要なリクエスト数が増加します。
* Implementation support for OPTIONS is not universal; some servers do not expose the ability to respond to OPTIONS requests without significant effort.
* OPTIONS の実装サポートは普遍的ではありません。サーバーによっては、多大な労力なしに OPTIONS リクエストに応答する機能を公開していないものもあります。
Instead of OPTIONS, one of these alternative approaches might be more appropriate:
OPTIONS の代わりに、次のような代替アプローチの方が適切な場合があります。
* 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]).
* サーバー全体のメタデータについては、well-known URI [WELL-KNOWN-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.
* 特定のリソースに関するメタデータについては、別のリソースを作成し、Link レスポンスヘッダーフィールドまたはレスポンスの内容にシリアライズされたリンクを使用してそのリソースにリンクします。[WEB-LINKING] を参照してください。Link ヘッダーフィールドは HEAD レスポンスでも利用可能であり、クライアントが対話する前にリソースの機能を発見したい場合に有用です。
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 を使用するアプリケーションは、レスポンスのメッセージ内容やヘッダーフィールドで、より詳細なエラー情報を伝えるべきです。[PROBLEM-DETAILS] はそのための一つの方法を提供します。
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 セマンティクスにフォールバックして）処理できるべきであることを明示的に指摘すべきです（例：499 を認識しないクライアントは 400 (Bad Request) として安全に処理できます）。これは、潜在的なステータスコードの「羅列（laundry list）」を作成するよりも好ましいです。そのようなリストは近い将来に完成することはないからです。
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 ステータスコードのセマンティクスを再定義してはなりません。特定のリーズンフレーズ（reason phrase）の使用を要求することは推奨されません。リーズンフレーズは 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 ステータスコードは汎用的であり、（[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> メーリングリストなど）に参加し、アプリケーションの仕様の一部としてではなく、独立した HTTP 拡張として提案を文書化することが推奨されます。
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 であり、これらはすべて Location レスポンスヘッダーフィールドを使用して、クライアントがリクエストを再送信すべき場所を示します。
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.
* 恒久的（permanent）か一時的（temporary）か。恒久的なリダイレクトは、クライアントに保存されているリンク（ブックマークなど）の更新に使用できますが、一時的なリダイレクトは使用できません。これは 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.
* リダイレクトされたリクエストがメソッドを POST から GET に変更することを許可するかどうか。Web ブラウザは一般に 301 と 302 で POST から GET に変更します。そのため、メソッドを変更せずにリダイレクトできるように 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 (See Other) ステータスコードは、操作の結果が 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] で述べられているように、ユーザーエージェントは、特定のステータスコードのセマンティクスを理解していなくても、Location レスポンスヘッダーフィールドを持つ 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.
リダイレクトは（適切なキャッシュディレクティブが存在する場合）キャッシュできますが、それを超えて "粘着性（sticky）" ではありません。つまり、ある 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 レスポンスが後続のリクエストメソッドを POST（他のメソッドは不可）から GET に変更することを指定することが推奨されます。一般に、リダイレクトされたリクエストが行われる際、そのヘッダーフィールドは元のリクエストからコピーされます。ただし、さまざまなメカニズムによって変更される可能性があります。たとえば、リクエストのオリジン（および場合によってはパス）が変更されると、送信される Authorization ([HTTP] セクション 11) や Cookie ([COOKIES]) ヘッダーフィールドは変化します。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 を参照してください。[STRUCTURED-FIELDS] は新しいヘッダーフィールドに共通の構造を提供し、解析や処理における多くの問題を回避します。新しいヘッダーフィールドではこれを使用することが推奨されます。
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.
たとえば、「example」アプリケーションが3つのヘッダーフィールドを作成する必要がある場合、それらは「example-foo」、「example-bar」、「example-baz」と呼ばれるかもしれません。ここでの主な動機は、より汎用的なフィールド名を消費することを避けることであり、アプリケーションのために名前空間の一部を予約することではないことに注意してください。関連する考慮事項については [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 を使用するアプリケーションは、Location ヘッダーフィールドが特定のコンテキストで特別な意味を持つことを指定することはできません。
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-CACHING] セクション 4.1) に使用されるリクエストヘッダーフィールドはそこに影響を与えるため、慎重に検討する必要があります。
See Section 4.10 for considerations regarding header fields that carry application state (e.g., 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-CACHING] は、アプリケーションに HTTP を使用することの主要な利点の一つです。スケーラビリティを提供し、遅延を削減し、信頼性を向上させます。さらに、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.
たとえ5秒のような短いフレッシュネス寿命（[HTTP-CACHING] セクション 4.2）を割り当てるだけでも、レスポンスを再利用して複数のクライアントや、同じリクエストを繰り返す単一のクライアントを満たすことができます。一般に、再利用しても安全なものであれば、フレッシュネス寿命を割り当てることを検討してください。
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.
フレッシュネスを指定する最も一般的な方法は、max-age レスポンスディレクティブ ([HTTP-CACHING] セクション 5.2.2.1) です。Expires ヘッダーフィールド ([HTTP-CACHING] セクション 5.3) も使用できますが、必須ではありません。すべての現代的なキャッシュ実装は Cache-Control ヘッダーフィールドをサポートしており、フレッシュネスを時間差（デルタ）として指定する方が通常は便利でミスが少なくなります。
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.
ほとんどのレスポンスをキャッシュするために public レスポンスディレクティブ ([HTTP-CACHING] セクション 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-CACHING] セクション 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).
レスポンスのキャッシュを望まない場合、適切なキャッシュレスポンスディレクティブは no-store です。他のディレクティブは不要であり、no-store はレスポンスがキャッシュされる可能性がある状況でのみ送信する必要があります。[HTTP-CACHING] セクション 3 を参照してください。no-cache ディレクティブは、レスポンスの保存は許可しますが、検証なしでの再利用を禁止するだけであることに注意してください。その名前に反して、キャッシュを妨げるものではありません。
For example, this response cannot be stored or reused by a cache:
たとえば、次のレスポンスはキャッシュによって保存または再利用できません。
HTTP/1.1 200 OK
Content-Type: application/example+xml
Cache-Control: no-store
[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.
著者は、オリジンサーバーから切断された際、期限切れ（stale）のレスポンス（例：Cache-Control: 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.
特定のレスポンスに対してそのような再利用が適さない場合、オリジンは must-revalidate キャッシュディレクティブを送信すべきです。期限切れ（stale）のコンテンツに関する追加の制御については、[HTTP-CACHING] セクション 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).
特に、アプリケーションの作成者は、オリジンサーバーから新たに取得されたものではないレスポンスをどのように扱うべきかを考慮する必要があります。有効期間のような概念がある場合、レスポンスの経過時間（age）を考慮して計算する必要があります（[HTTP-CACHING] セクション 4.2.3 を参照）。
One way to address this is to explicitly specify that responses need to be fresh upon use.
これに対処する一つの方法は、使用時にレスポンスがフレッシュである必要があることを明示的に指定することです。
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-CACHING] セクション 5.2.2.5 で定義されている no-store キャッシュディレクティブを使用）、そのリソースからのすべてのレスポンス（「デフォルト」のレスポンスを含む）に Vary レスポンスヘッダーフィールド ([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 で再検証でき、Accept-Encoding リクエストヘッダーフィールドによって変化します。
Applications can use stateful cookies [COOKIES] to identify a client and/or store client-specific data to contextualise requests.
アプリケーションは、状態を持つクッキー [COOKIES] を使用してクライアントを識別したり、リクエストを文脈化するためのクライアント固有のデータを保存したりできます。
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.
クッキーを使用する場合、そのスコープと使用方法を慎重に指定することが重要です。アプリケーションが機密データや機能を公開している場合（例：アンビエントオーソリティとして機能する場合）、攻撃が可能になります。緩和策としては、クライアントの意図を確認するためにリクエスト固有のトークンを使用することなどが挙げられます。
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] によれば、Basic 認証スキームは、チャネルがセキュアでない限り（「https」URI スキームを使用するなど）、機密情報や重要な情報を保護するのには適していません。同様に、[RFC7616] は Digest 認証スキームをセキュアなチャネルで使用することを要求しています。
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] を使用してクライアントを認証することもできますが、そのような認証は本質的に基礎となるトランスポート接続にスコープが限定されることに注意してください。その結果、クライアントは、レスポンスの作成に認証されたステータスが使用されたかどうかを知る方法がありません（Vary: * や private キャッシュディレクティブが部分的な兆候を示すことはありますが）。確実に未認証のレスポンスを取得する唯一の方法は、新しい接続を開くことです。
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 サイトからクロスサイトリクエストフォージェリ (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.
* Content-Type ヘッダーフィールドでアプリケーション固有のメディアタイプを使用し、それが使用されていない場合はクライアントをエラーにすること。
* 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 内の機密データが Referer リクエストヘッダーフィールドに漏洩するのを防ぐこと。
* Using the 'HttpOnly' flag on Cookies to ensure that cookies are not exposed to browser scripting languages [COOKIES].
* クッキーに 'HttpOnly' フラグを使用して、クッキーがブラウザのスクリプト言語にさらされないようにすること [COOKIES]。
* 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 に使用する抽象化である [FETCH] の用語でクライアントの対話を定義すべきです。これにより、これらのベストプラクティスの多くが強制されます。
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 機能はオリジン [RFC6454] にスコープが限定されているため、アプリケーションは、同じオリジンサーバーを使用する他のアプリケーション（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.
たとえば、クッキー [COOKIES] を使用してアプリケーションの状態を運ぶ場合、デフォルトでは（パスで制限されていない限り）オリジンへのすべてのリクエストで送信され、アプリケーションはオリジンサーバー上の他のアプリケーションからのクッキーを受け取る可能性があります。これはクッキー名の衝突だけでなく、セキュリティ上の問題を引き起こす可能性があります。
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).
これらの問題への解決策の一つは、アプリケーションに専用のホスト名を要求して、独自のオリジンを持たせることです。しかし、単一のホスト名に複数のアプリケーションを展開できるようにすることが望ましい場合もよくあります。そうすることで展開の柔軟性が最大化され、それらを「混合」させることが可能になります（詳細は [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 を使用するアプリケーションは、1つのオリジン上で複数のアプリケーションを許容するように努めるべきです。具体的には、クッキーの使用、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 ブラウザは、プライベート情報の漏洩を避けるため、あるオリジンのコンテンツが別のオリジンのリソースにアクセスする機能を制限しています。その結果、クロスオリジンデータをブラウザに公開したいアプリケーションは、CORS プロトコルを実装する必要があります。[FETCH] を参照してください。
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 (Early Hints) ステータスコードを使用することで利益を得られる可能性があります。[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-CACHING]、[WEB-LINKING] などが関連することが多いです。
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 を使用する多くのアプリケーションは、ベアラートークン（セッションクッキー内など）を使用して認証と認可を行います。トランスポートが暗号化されていない場合、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）」の情報（これがセクション 4.4.2 で「https」が推奨される理由の一つです）以外にも、あまり明白ではない手段で、多くの場合、時間の経過とともにユーザーの活動を結びつけることで、他の情報が収集される可能性があります。
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 セッションチケット、クッキー、クライアントのキャッシュに保存された 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.
フィンガープリントは、クライアントのメッセージや動作の特異な側面を使用して、無関係なリクエストや接続を結びつけます。たとえば、User-Agent リクエストヘッダーフィールドは実装に関する特定の情報を伝え、Accept-Language リクエストヘッダーフィールドはユーザーの優先言語を伝えます。これらのマーカーを組み合わせることで、クライアントを一意に特定し、データに対する制御に影響を与えることができます。その結果、アプリケーションは、クライアントがリクエストの機能に必要な情報のみを送信するように指定することが推奨されます。
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] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 8820, DOI 10.17487/RFC8820, June 2020, <https://www.rfc-editor.org/rfc/rfc8820>.
[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., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <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-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>.
[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., "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>.
[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., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <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., 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>.
[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., 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>.
[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., "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>.
[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>.
[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>.
[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., 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>.
[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, October 2017, <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>.
[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>.
[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 State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <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., "Content Security Policy Level 3", W3C Working Draft, June 2021, <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-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/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., 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/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, June 2022, <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, June 2022, <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., "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>.
[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>.
[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>.
[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. and E. Stark, "Referrer Policy", W3C Candidate Recommendation CR-referrer-policy-20170126, January 2017, <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] 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>.
[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., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, DOI 10.17487/RFC4791, March 2007, <https://www.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., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007, <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] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, <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. and B. Cook, "Web Host Metadata", RFC 6415, DOI 10.17487/RFC6415, October 2011, <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., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012, <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. 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>.
[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., 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>.
[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., 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>.
[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., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, August 2015, <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., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <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., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <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., "An HTTP Status Code for Indicating Hints", RFC 8297, DOI 10.17487/RFC8297, December 2017, <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., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>
[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., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/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 Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <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 Candidate Recommendation, September 2021, <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., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <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., 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>.
[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年代初頭の最良の現行慣行 (BCP) を取りまとめたものでした。それ以来、HTTP の使用方法は大きく変化しました。その結果、このドキュメントは大幅に異なるものとなっています。そのため、変更点は非常に多く、個別にリストアップすることはできません。
Author's Address
著者の住所
Mark Nottingham
Prahran
Australia
Email: mnot@mnot.net
URI: https://www.mnot.net/