[要約] RFC 9110は、HTTP/1.1およびHTTP/2のセマンティクスとコンテンツに関する標準を定義しています。この文書は、HTTPプロトコルがどのように機能し、Webサーバーとクライアント間で情報がどのように交換されるかについての基本的なルールと概念を提供します。主な目的は、リソースの識別、操作、および表現を通じてインターネット上での情報の伝達と操作を可能にすることです。このRFCは、Web開発、API設計、インターネット通信の基盤として広く利用されています。関連するRFCには、RFC 7230（HTTP/1.1メッセージ構文とルーティング）、RFC 7540（HTTP/2）、RFC 7231（HTTP/1.1メソッドとステータスコード）などがあります。
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 9110 Adobe
STD: 97 M. Nottingham, Ed.
Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, Fastly
7538, 7615, 7694 J. Reschke, Ed.
Updates: 3864 greenbytes
Category: Standards Track June 2022
ISSN: 2070-1721
HTTP Semantics
HTTPセマンティクス
Abstract
概要
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.
HyperText Transfer Protocol（HTTP）は、分散、共同、ハイパーテキスト情報システムのためのステートレスアプリケーションレベルのプロトコルです。このドキュメントでは、HTTPの全体的なアーキテクチャについて説明し、共通の用語を確立し、すべてのバージョンで共有されるプロトコルの側面を定義します。この定義には、コアプロトコル要素、拡張性メカニズム、および「HTTP」および「HTTPS」均一リソース識別子（URI）スキームがあります。
This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.
このドキュメントは、RFC 3864およびObsoletes RFCS 2818、7231、7232、7233、7235、7538、7615、7694、および7230の一部を更新します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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 Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc9110.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9110で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction
1.1. Purpose
1.2. History and Evolution
1.3. Core Semantics
1.4. Specifications Obsoleted by This Document
2. Conformance
2.1. Syntax Notation
2.2. Requirements Notation
2.3. Length Requirements
2.4. Error Handling
2.5. Protocol Version
3. Terminology and Core Concepts
3.1. Resources
3.2. Representations
3.3. Connections, Clients, and Servers
3.4. Messages
3.5. User Agents
3.6. Origin Server
3.7. Intermediaries
3.8. Caches
3.9. Example Message Exchange
4. Identifiers in HTTP
4.1. URI References
4.2. HTTP-Related URI Schemes
4.2.1. http URI Scheme
4.2.2. https URI Scheme
4.2.3. http(s) Normalization and Comparison
4.2.4. Deprecation of userinfo in http(s) URIs
4.2.5. http(s) References with Fragment Identifiers
4.3. Authoritative Access
4.3.1. URI Origin
4.3.2. http Origins
4.3.3. https Origins
4.3.4. https Certificate Verification
4.3.5. IP-ID Reference Identity
5. Fields
5.1. Field Names
5.2. Field Lines and Combined Field Value
5.3. Field Order
5.4. Field Limits
5.5. Field Values
5.6. Common Rules for Defining Field Values
5.6.1. Lists (#rule ABNF Extension)
5.6.1.1. Sender Requirements
5.6.1.2. Recipient Requirements
5.6.2. Tokens
5.6.3. Whitespace
5.6.4. Quoted Strings
5.6.5. Comments
5.6.6. Parameters
5.6.7. Date/Time Formats
6. Message Abstraction
6.1. Framing and Completeness
6.2. Control Data
6.3. Header Fields
6.4. Content
6.4.1. Content Semantics
6.4.2. Identifying Content
6.5. Trailer Fields
6.5.1. Limitations on Use of Trailers
6.5.2. Processing Trailer Fields
6.6. Message Metadata
6.6.1. Date
6.6.2. Trailer
7. Routing HTTP Messages
7.1. Determining the Target Resource
7.2. Host and :authority
7.3. Routing Inbound Requests
7.3.1. To a Cache
7.3.2. To a Proxy
7.3.3. To the Origin
7.4. Rejecting Misdirected Requests
7.5. Response Correlation
7.6. Message Forwarding
7.6.1. Connection
7.6.2. Max-Forwards
7.6.3. Via
7.7. Message Transformations
7.8. Upgrade
8. Representation Data and Metadata
8.1. Representation Data
8.2. Representation Metadata
8.3. Content-Type
8.3.1. Media Type
8.3.2. Charset
8.3.3. Multipart Types
8.4. Content-Encoding
8.4.1. Content Codings
8.4.1.1. Compress Coding
8.4.1.2. Deflate Coding
8.4.1.3. Gzip Coding
8.5. Content-Language
8.5.1. Language Tags
8.6. Content-Length
8.7. Content-Location
8.8. Validator Fields
8.8.1. Weak versus Strong
8.8.2. Last-Modified
8.8.2.1. Generation
8.8.2.2. Comparison
8.8.3. ETag
8.8.3.1. Generation
8.8.3.2. Comparison
8.8.3.3. Example: Entity Tags Varying on Content-Negotiated
Resources
9. Methods
9.1. Overview
9.2. Common Method Properties
9.2.1. Safe Methods
9.2.2. Idempotent Methods
9.2.3. Methods and Caching
9.3. Method Definitions
9.3.1. GET
9.3.2. HEAD
9.3.3. POST
9.3.4. PUT
9.3.5. DELETE
9.3.6. CONNECT
9.3.7. OPTIONS
9.3.8. TRACE
10. Message Context
10.1. Request Context Fields
10.1.1. Expect
10.1.2. From
10.1.3. Referer
10.1.4. TE
10.1.5. User-Agent
10.2. Response Context Fields
10.2.1. Allow
10.2.2. Location
10.2.3. Retry-After
10.2.4. Server
11. HTTP Authentication
11.1. Authentication Scheme
11.2. Authentication Parameters
11.3. Challenge and Response
11.4. Credentials
11.5. Establishing a Protection Space (Realm)
11.6. Authenticating Users to Origin Servers
11.6.1. WWW-Authenticate
11.6.2. Authorization
11.6.3. Authentication-Info
11.7. Authenticating Clients to Proxies
11.7.1. Proxy-Authenticate
11.7.2. Proxy-Authorization
11.7.3. Proxy-Authentication-Info
12. Content Negotiation
12.1. Proactive Negotiation
12.2. Reactive Negotiation
12.3. Request Content Negotiation
12.4. Content Negotiation Field Features
12.4.1. Absence
12.4.2. Quality Values
12.4.3. Wildcard Values
12.5. Content Negotiation Fields
12.5.1. Accept
12.5.2. Accept-Charset
12.5.3. Accept-Encoding
12.5.4. Accept-Language
12.5.5. Vary
13. Conditional Requests
13.1. Preconditions
13.1.1. If-Match
13.1.2. If-None-Match
13.1.3. If-Modified-Since
13.1.4. If-Unmodified-Since
13.1.5. If-Range
13.2. Evaluation of Preconditions
13.2.1. When to Evaluate
13.2.2. Precedence of Preconditions
14. Range Requests
14.1. Range Units
14.1.1. Range Specifiers
14.1.2. Byte Ranges
14.2. Range
14.3. Accept-Ranges
14.4. Content-Range
14.5. Partial PUT
14.6. Media Type multipart/byteranges
15. Status Codes
15.1. Overview of Status Codes
15.2. Informational 1xx
15.2.1. 100 Continue
15.2.2. 101 Switching Protocols
15.3. Successful 2xx
15.3.1. 200 OK
15.3.2. 201 Created
15.3.3. 202 Accepted
15.3.4. 203 Non-Authoritative Information
15.3.5. 204 No Content
15.3.6. 205 Reset Content
15.3.7. 206 Partial Content
15.3.7.1. Single Part
15.3.7.2. Multiple Parts
15.3.7.3. Combining Parts
15.4. Redirection 3xx
15.4.1. 300 Multiple Choices
15.4.2. 301 Moved Permanently
15.4.3. 302 Found
15.4.4. 303 See Other
15.4.5. 304 Not Modified
15.4.6. 305 Use Proxy
15.4.7. 306 (Unused)
15.4.8. 307 Temporary Redirect
15.4.9. 308 Permanent Redirect
15.5. Client Error 4xx
15.5.1. 400 Bad Request
15.5.2. 401 Unauthorized
15.5.3. 402 Payment Required
15.5.4. 403 Forbidden
15.5.5. 404 Not Found
15.5.6. 405 Method Not Allowed
15.5.7. 406 Not Acceptable
15.5.8. 407 Proxy Authentication Required
15.5.9. 408 Request Timeout
15.5.10. 409 Conflict
15.5.11. 410 Gone
15.5.12. 411 Length Required
15.5.13. 412 Precondition Failed
15.5.14. 413 Content Too Large
15.5.15. 414 URI Too Long
15.5.16. 415 Unsupported Media Type
15.5.17. 416 Range Not Satisfiable
15.5.18. 417 Expectation Failed
15.5.19. 418 (Unused)
15.5.20. 421 Misdirected Request
15.5.21. 422 Unprocessable Content
15.5.22. 426 Upgrade Required
15.6. Server Error 5xx
15.6.1. 500 Internal Server Error
15.6.2. 501 Not Implemented
15.6.3. 502 Bad Gateway
15.6.4. 503 Service Unavailable
15.6.5. 504 Gateway Timeout
15.6.6. 505 HTTP Version Not Supported
16. Extending HTTP
16.1. Method Extensibility
16.1.1. Method Registry
16.1.2. Considerations for New Methods
16.2. Status Code Extensibility
16.2.1. Status Code Registry
16.2.2. Considerations for New Status Codes
16.3. Field Extensibility
16.3.1. Field Name Registry
16.3.2. Considerations for New Fields
16.3.2.1. Considerations for New Field Names
16.3.2.2. Considerations for New Field Values
16.4. Authentication Scheme Extensibility
16.4.1. Authentication Scheme Registry
16.4.2. Considerations for New Authentication Schemes
16.5. Range Unit Extensibility
16.5.1. Range Unit Registry
16.5.2. Considerations for New Range Units
16.6. Content Coding Extensibility
16.6.1. Content Coding Registry
16.6.2. Considerations for New Content Codings
16.7. Upgrade Token Registry
17. Security Considerations
17.1. Establishing Authority
17.2. Risks of Intermediaries
17.3. Attacks Based on File and Path Names
17.4. Attacks Based on Command, Code, or Query Injection
17.5. Attacks via Protocol Element Length
17.6. Attacks Using Shared-Dictionary Compression
17.7. Disclosure of Personal Information
17.8. Privacy of Server Log Information
17.9. Disclosure of Sensitive Information in URIs
17.10. Application Handling of Field Names
17.11. Disclosure of Fragment after Redirects
17.12. Disclosure of Product Information
17.13. Browser Fingerprinting
17.14. Validator Retention
17.15. Denial-of-Service Attacks Using Range
17.16. Authentication Considerations
17.16.1. Confidentiality of Credentials
17.16.2. Credentials and Idle Clients
17.16.3. Protection Spaces
17.16.4. Additional Response Fields
18. IANA Considerations
18.1. URI Scheme Registration
18.2. Method Registration
18.3. Status Code Registration
18.4. Field Name Registration
18.5. Authentication Scheme Registration
18.6. Content Coding Registration
18.7. Range Unit Registration
18.8. Media Type Registration
18.9. Port Registration
18.10. Upgrade Token Registration
19. References
19.1. Normative References
19.2. Informative References
Appendix A. Collected ABNF
Appendix B. Changes from Previous RFCs
B.1. Changes from RFC 2818
B.2. Changes from RFC 7230
B.3. Changes from RFC 7231
B.4. Changes from RFC 7232
B.5. Changes from RFC 7233
B.6. Changes from RFC 7235
B.7. Changes from RFC 7538
B.8. Changes from RFC 7615
B.9. Changes from RFC 7694
Acknowledgements
Index
Authors' Addresses
The Hypertext Transfer Protocol (HTTP) is a family of stateless, application-level, request/response protocols that share a generic interface, extensible semantics, and self-descriptive messages to enable flexible interaction with network-based hypertext information systems.
ハイパーテキスト転送プロトコル（HTTP）は、ネットワークベースのハイパーテキスト情報システムとの柔軟な対話を可能にするために、一般的なインターフェイス、拡張可能なセマンティクス、および自己記述的なメッセージを共有する、ステートレス、アプリケーションレベルのリクエスト/応答プロトコルのファミリーです。
HTTP hides the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do not need to be aware of each client's purpose: a request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. This allows general-purpose implementations to be used effectively in many different contexts, reduces interaction complexity, and enables independent evolution over time.
HTTPは、提供されるリソースの種類に依存しないクライアントに均一なインターフェイスを提示することにより、サービスの実装方法の詳細を隠します。同様に、サーバーは各クライアントの目的を認識する必要はありません。特定のタイプのクライアントまたは事前に決められたアプリケーションステップに関連付けられるのではなく、リクエストを単独で考慮することができます。これにより、汎用の実装を多くの異なるコンテキストで効果的に使用し、相互作用の複雑さを軽減し、時間の経過とともに独立した進化を可能にします。
HTTP is also designed for use as an intermediation protocol, wherein proxies and gateways can translate non-HTTP information systems into a more generic interface.
HTTPは、中間化プロトコルとして使用するように設計されており、プロキシとゲートウェイは非HTTP情報システムをより一般的なインターフェイスに変換できます。
One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
この柔軟性の結果の1つは、インターフェイスの背後にあるものに関してプロトコルを定義できないことです。代わりに、通信の構文、受信したコミュニケーションの意図、および受信者の予想される動作を定義することに限定されます。通信が単独で考慮される場合、成功したアクションは、サーバーが提供する観察可能なインターフェイスへの対応する変更に反映される必要があります。ただし、複数のクライアントが並行して行動し、おそらくクロスプルーズで行動する可能性があるため、そのような変更を単一の応答の範囲を超えて観察できることを要求することはできません。
HTTP has been the primary information transfer protocol for the World Wide Web since its introduction in 1990. It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname. As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries. These protocols were eventually defined as HTTP/0.9 and HTTP/1.0 (see [HTTP/1.0]).
HTTPは、1990年の導入以来、World Wide Webの主要な情報転送プロトコルとなっています。低遅延リクエストの些細なメカニズムとして始まりました。PathName。Webが成長するにつれて、HTTPはメッセージ内でリクエストと応答を囲み、MIMEのようなメディアタイプを使用して任意のデータ形式を転送し、仲介者を介したルートリクエストを拡張しました。これらのプロトコルは、最終的にHTTP/0.9およびHTTP/1.0として定義されました（[http/1.0]を参照）。
HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging syntax, improving its interoperability, scalability, and robustness across the Internet. This included length-based data delimiters for both fixed and dynamic (chunked) content, a consistent framework for content negotiation, opaque validators for conditional requests, cache controls for better cache consistency, range requests for partial updates, and default persistent connections. HTTP/1.1 was introduced in 1995 and published on the Standards Track in 1997 [RFC2068], revised in 1999 [RFC2616], and revised again in 2014 ([RFC7230] through [RFC7235]).
HTTP/1.1は、既存のテキストベースのメッセージング構文との互換性を保持しながら、プロトコルの機能を改良し、インターネット全体で相互運用性、スケーラビリティ、堅牢性を向上させるように設計されています。これには、固定および動的（チャンク）コンテンツの両方の長さベースのデータデリミタ、コンテンツネゴシエーションのための一貫したフレームワーク、条件付き要求の不透明なバリデーター、より良いキャッシュの一貫性のためのキャッシュコントロール、部分的な更新の範囲要求、デフォルトの永続的な接続が含まれます。HTTP/1.1は1995年に導入され、1997年にStandards Trackに掲載され[RFC2068]、1999年に改訂され[RFC2616]、2014年に再び改訂（[RFC7235]）。
HTTP/2 ([HTTP/2]) introduced a multiplexed session layer on top of the existing TLS and TCP protocols for exchanging concurrent HTTP messages with efficient field compression and server push. HTTP/3 ([HTTP/3]) provides greater independence for concurrent messages by using QUIC as a secure multiplexed transport over UDP instead of TCP.
HTTP/2（[HTTP/2]）は、効率的なフィールド圧縮とサーバープッシュと同時のHTTPメッセージを交換するために、既存のTLSの上に多重化セッションレイヤーとTCPプロトコルを導入しました。HTTP/3（[HTTP/3]）は、TCPの代わりにUDPを介した安全な多重化された輸送としてQUICを使用することにより、同時メッセージのより大きな独立性を提供します。
All three major versions of HTTP rely on the semantics defined by this document. They have not obsoleted each other because each one has specific benefits and limitations depending on the context of use. Implementations are expected to choose the most appropriate transport and messaging syntax for their particular context.
HTTPの3つの主要バージョンはすべて、このドキュメントで定義されたセマンティクスに依存しています。それぞれが使用のコンテキストに応じて特定の利点と制限があるため、彼らはお互いを廃止していません。実装は、特定のコンテキストに最も適切なトランスポートとメッセージングの構文を選択することが期待されています。
This revision of HTTP separates the definition of semantics (this document) and caching ([CACHING]) from the current HTTP/1.1 messaging syntax ([HTTP/1.1]) to allow each major protocol version to progress independently while referring to the same core semantics.
HTTPのこの改訂は、セマンティクス（このドキュメント）とキャッシュ（[キャッシュ]）の定義を現在のHTTP/1.1メッセージング構文（[http/1.1]）から分離して、同じコアを参照しながら各主要なプロトコルバージョンが独立して進行できるようにします。セマンティクス。
HTTP provides a uniform interface for interacting with a resource (Section 3.1) -- regardless of its type, nature, or implementation -- by sending messages that manipulate or transfer representations (Section 3.2).
HTTPは、表現を操作または転送するメッセージを送信することにより、リソース（セクション3.1）と対話するための均一なインターフェイスを提供します（セクション3.1）。
Each message is either a request or a response. A client constructs request messages that communicate its intentions and routes those messages toward an identified origin server. A server listens for requests, parses each message received, interprets the message semantics in relation to the identified target resource, and responds to that request with one or more response messages. The client examines received responses to see if its intentions were carried out, determining what to do next based on the status codes and content received.
各メッセージは、リクエストまたは応答のいずれかです。クライアントは、意図を通信する要求メッセージを構築し、それらのメッセージを識別されたOrigin Serverにルーティングします。サーバーはリクエストを聴き、受信した各メッセージを解析し、特定されたターゲットリソースに関連するメッセージセマンティクスを解釈し、1つ以上の応答メッセージでその要求に応答します。クライアントは、受信した回答を調べて、その意図が実行されたかどうかを確認し、受信したステータスコードとコンテンツに基づいて次に何をすべきかを決定します。
HTTP semantics include the intentions defined by each request method (Section 9), extensions to those semantics that might be described in request header fields, status codes that describe the response (Section 15), and other control data and resource metadata that might be given in response fields.
HTTPセマンティクスには、各リクエストメソッド（セクション9）で定義された意図、リクエストヘッダーフィールドで説明されているセマンティクスの拡張、応答（セクション15）、および与えられる可能性のある他の制御データとリソースメタデータの拡張が含まれます。応答フィールド。
Semantics also include representation metadata that describe how content is intended to be interpreted by a recipient, request header fields that might influence content selection, and the various selection algorithms that are collectively referred to as "content negotiation" (Section 12).
セマンティクスには、コンテンツが受信者によって解釈される方法を説明する表現メタデータ、コンテンツ選択に影響を与える可能性のあるヘッダーフィールド、および「コンテンツネゴシエーション」と呼ばれるさまざまな選択アルゴリズムも含まれます（セクション12）。
+============================================+===========+=====+
| Title | Reference | See |
+============================================+===========+=====+
| HTTP Over TLS | [RFC2818] | B.1 |
+--------------------------------------------+-----------+-----+
| HTTP/1.1 Message Syntax and Routing [*] | [RFC7230] | B.2 |
+--------------------------------------------+-----------+-----+
| HTTP/1.1 Semantics and Content | [RFC7231] | B.3 |
+--------------------------------------------+-----------+-----+
| HTTP/1.1 Conditional Requests | [RFC7232] | B.4 |
+--------------------------------------------+-----------+-----+
| HTTP/1.1 Range Requests | [RFC7233] | B.5 |
+--------------------------------------------+-----------+-----+
| HTTP/1.1 Authentication | [RFC7235] | B.6 |
+--------------------------------------------+-----------+-----+
| HTTP Status Code 308 (Permanent Redirect) | [RFC7538] | B.7 |
+--------------------------------------------+-----------+-----+
| HTTP Authentication-Info and Proxy- | [RFC7615] | B.8 |
| Authentication-Info Response Header Fields | | |
+--------------------------------------------+-----------+-----+
| HTTP Client-Initiated Content-Encoding | [RFC7694] | B.9 |
+--------------------------------------------+-----------+-----+
Table 1
表1
[*] This document only obsoletes the portions of RFC 7230 that are independent of the HTTP/1.1 messaging syntax and connection management; the remaining bits of RFC 7230 are obsoleted by "HTTP/1.1" [HTTP/1.1].
[*]このドキュメントは、HTTP/1.1メッセージングの構文と接続管理に依存しないRFC 7230の部分のみを廃止します。RFC 7230の残りのビットは、「HTTP/1.1」[HTTP/1.1]によって廃止されています。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], extended with the notation for case-sensitivity in strings defined in [RFC7405].
この仕様では、[RFC7405]で定義された文字列の症例感度の表記法とともに拡張された[RFC5234]の拡張されたBackus-NAURフォーム（ABNF）表記を使用します。
It also uses a list extension, defined in Section 5.6.1, that allows for compact definition of comma-separated lists using a "#" operator (similar to how the "*" operator indicates repetition). Appendix A shows the collected grammar with all list operators expanded to standard ABNF notation.
また、セクション5.6.1で定義されているリスト拡張子を使用します。これにより、「＃」演算子を使用してコンマ分離リストのコンパクトな定義が可能になります（「*」演算子が繰り返しを示す方法と同様）。付録Aは、収集された文法が標準のABNF表記に拡張されたすべてのリストオペレーターを含む文法を示しています。
As a convention, ABNF rule names prefixed with "obs-" denote obsolete grammar rules that appear for historical reasons.
慣習として、ABNFルール名は「obs-」が付いている名前を付けて、歴史的な理由で表示される時代遅れの文法ルールを示しています。
The following core rules are included by reference, as defined in Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).
[RFC5234]の付録B.1で定義されているように、次のコアルールは参照によって含まれています：アルファ（文字）、CR（キャリッジリターン）、CRLF（CR LF）、CTL（コントロール）、数字（10-9）、dquote（二重引用）、hexdig（hexadecimal 0-9/a-f/a-f）、htab（水平タブ）、lf（ラインフィード）、オクテット（データの8ビットシーケンス）、sp（スペース）、およびvchar（目に見えるus-ascii文字）。
Section 5.6 defines some generic syntactic components for field values.
セクション5.6では、フィールド値の一般的な構文コンポーネントを定義します。
This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in [RFC6365].
この仕様では、[RFC6365]で定義されている「文字」、「文字エンコードスキーム」、「charset」、「プロトコル要素」という用語を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, or caches, depending on what behavior is being constrained by the requirement. Additional requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication.
この仕様は、HTTP通信の参加者の役割に応じた適合基準をターゲットにします。したがって、要件に応じて、送信者、受信者、クライアント、サーバー、ユーザーエージェント、仲介者、オリジンサーバー、プロキシ、ゲートウェイ、またはキャッシュに要件が配置されます。単一の通信の範囲を超えて適用される場合、実装、リソース所有者、およびプロトコル要素登録に追加の要件が掲載されます。
The verb "generate" is used instead of "send" where a requirement applies only to implementations that create the protocol element, rather than an implementation that forwards a received element downstream.
動詞「生成」は、「送信」ではなく使用され、要件は、受信した要素を下流に転送する実装ではなく、プロトコル要素を作成する実装にのみ適用されます。
An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes in HTTP.
HTTPに参加する役割に関連するすべての要件に準拠している場合、実装は適合と見なされます。
A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules. Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message).
送信者は、対応するABNFルールで定義された文法と一致しないプロトコル要素を生成してはなりません。特定のメッセージ内で、送信者は、他の役割の参加者によってのみ生成されることが許可されているプロトコル要素または構文の代替品を生成してはなりません（つまり、送信者がそのメッセージに対して持たない役割）。
Conformance to HTTP includes both conformance to the particular messaging syntax of the protocol version in use and conformance to the semantics of protocol elements sent. For example, a client that claims conformance to HTTP/1.1 but fails to recognize the features required of HTTP/1.1 recipients will fail to interoperate with servers that adjust their responses in accordance with those claims. Features that reflect user choices, such as content negotiation and user-selected extensions, can impact application behavior beyond the protocol stream; sending protocol elements that inaccurately reflect a user's choices will confuse the user and inhibit choice.
HTTPへの適合には、使用中のプロトコルバージョンの特定のメッセージング構文への適合と、送信されたプロトコル要素のセマンティクスへの適合の両方が含まれます。たとえば、HTTP/1.1への適合を請求するが、HTTP/1.1レシピエントに必要な機能を認識できないクライアントは、それらの請求に従って応答を調整するサーバーと相互運用できません。コンテンツネゴシエーションやユーザーが選択した拡張機能など、ユーザーの選択を反映する機能は、プロトコルストリームを超えてアプリケーションの動作に影響を与える可能性があります。ユーザーの選択を不正確に反映するプロトコル要素を送信すると、ユーザーが混乱し、選択を阻害します。
When an implementation fails semantic conformance, recipients of that implementation's messages will eventually develop workarounds to adjust their behavior accordingly. A recipient MAY employ such workarounds while remaining conformant to this protocol if the workarounds are limited to the implementations at fault. For example, servers often scan portions of the User-Agent field value, and user agents often scan the Server field value, to adjust their own behavior with respect to known bugs or poorly chosen defaults.
実装がセマンティックの適合性に失敗すると、その実装のメッセージの受信者は最終的に回避策を開発し、それに応じて動作を調整します。受信者は、回避策が障害のある実装に制限されている場合、このプロトコルに適合したままでいる間、そのような回避策を使用する場合があります。たとえば、サーバーは多くの場合、ユーザーエージェントのフィールド値の部分をスキャンし、ユーザーエージェントはサーバーのフィールド値をスキャンして、既知のバグまたは選択不足のデフォルトに関して独自の動作を調整することがよくあります。
A recipient SHOULD parse a received protocol element defensively, with only marginal expectations that the element will conform to its ABNF grammar and fit within a reasonable buffer size.
受信者は、受け取ったプロトコル要素を防御的に解析する必要があります。これは、要素がABNF文法に適合し、合理的なバッファーサイズに適合するというわずかな期待のみで、防御的に解析する必要があります。
HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore, what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past three decades of HTTP use and is expected to continue changing in the future.
HTTPには、適切な長さが展開のコンテキストと実装の目的に応じて大きく異なるため、そのプロトコル要素の多くに特定の長さの制限がありません。したがって、送信者と受信者間の相互運用性は、各プロトコル要素の妥当な長さに関する共通の期待に依存します。さらに、一部のプロトコル要素の合理的な長さであると一般に理解されているものは、過去30年間のHTTP使用の過程で変化し、将来変化し続けると予想されています。
At a minimum, a recipient MUST be able to parse and process protocol element lengths that are at least as long as the values that it generates for those same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own resources needs to be able to parse and process those same references when received as a target URI.
少なくとも、受信者は、他のメッセージで同じプロトコル要素に対して生成する値が少なくとも生成される限り、プロトコル要素の長さを解析および処理できる必要があります。たとえば、独自のリソースへの非常に長いURI参照を公開するOrigin Serverは、ターゲットURIとして受信したときに同じ参照を解析および処理できる必要があります。
Many received protocol elements are only parsed to the extent necessary to identify and forward that element downstream. For example, an intermediary might parse a received field into its field name and field value components, but then forward the field without further parsing inside the field value.
多くの受信プロトコル要素は、その要素を下流に識別して転送するために必要な範囲でのみ解析されます。たとえば、仲介者は、受信したフィールドをフィールド名とフィールド値コンポーネントに解析する可能性がありますが、フィールド値の内側にさらに解析することなくフィールドを転送する場合があります。
A recipient MUST interpret a received protocol element according to the semantics defined for it by this specification, including extensions to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly implements what is implied by those semantics. For example, an origin server might disregard the contents of a received Accept-Encoding header field if inspection of the User-Agent header field indicates a specific implementation version that is known to fail on receipt of certain content codings.
受信者は、受信者が（経験または構成を通じて）送信者がそれらのセマンティクスによって暗示されているものを誤って実装することを（経験または構成を通じて）決定しない限り、この仕様の拡張を含む、この仕様によって定義されたセマンティクスに従って受信したプロトコル要素を解釈する必要があります。たとえば、ユーザーエージェントヘッダーフィールドの検査が特定のコンテンツコーディングの受領に失敗することが知られている特定の実装バージョンを示している場合、Origin Serverは受信した受信エンコードヘッダーフィールドの内容を無視する場合があります。
Unless noted otherwise, a recipient MAY attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous.
特に明記しない限り、受信者は無効なコンストラクトから使用可能なプロトコル要素を回復しようとする場合があります。HTTPは、プロトコルの異なるアプリケーションには異なるエラー処理戦略が必要であるため、セキュリティに直接影響を与える場合を除き、特定のエラー処理メカニズムを定義しません。たとえば、Webブラウザは、ABNFに従って位置ヘッダーフィールドが解析されない応答から透過的に回復したい場合がありますが、システム制御クライアントは、あらゆる形態のエラー回復が危険であると考える場合があります。
Some requests can be automatically retried by a client in the event of an underlying connection failure, as described in Section 9.2.2.
セクション9.2.2で説明されているように、いくつかの要求は、基礎となる接続障害が発生した場合にクライアントが自動的に再試行することができます。
HTTP's version number consists of two decimal digits separated by a "." (period or decimal point). The first digit (major version) indicates the messaging syntax, whereas the second digit (minor version) indicates the highest minor version within that major version to which the sender is conformant (able to understand for future communication).
HTTPのバージョン番号は、「。」で区切られた2つの10進数で構成されています。（期間または小数点）。最初の数字（メジャーバージョン）はメッセージングの構文を示しますが、2番目の数字（マイナーバージョン）は、送信者が適合しているメジャーバージョン内の最高マイナーバージョン（将来のコミュニケーションを理解できる）を示します。
While HTTP's core semantics don't change between protocol versions, their expression "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire format. Additionally, HTTP allows incremental, backwards-compatible changes to be made to the protocol without changing its version through the use of defined extension points (Section 16).
HTTPのコアセマンティクスはプロトコルバージョン間で変更されませんが、「ワイヤー上」の式が変更される可能性があるため、互換性のない変更がワイヤ形式に行われるとHTTPバージョン数が変更されます。さらに、HTTPは、定義された拡張ポイントを使用してバージョンを変更せずに、プロトコルに対して増分、後方互換の変更を行うことができます（セクション16）。
The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's corresponding specification(s). For example, the version "HTTP/1.1" is defined by the combined specifications of this document, "HTTP Caching" [CACHING], and "HTTP/1.1" [HTTP/1.1].
プロトコルバージョン全体として、そのバージョンに対応する仕様に定められた一連の要件に対する送信者の適合性が示されています。たとえば、バージョン「HTTP/1.1」は、このドキュメントの組み合わせた仕様、「HTTPキャッシュ」[キャッシュ]、および「HTTP/1.1」[HTTP/1.1]によって定義されます。
HTTP's major version number is incremented when an incompatible message syntax is introduced. The minor number is incremented when changes made to the protocol have the effect of adding to the message semantics or implying additional capabilities of the sender.
HTTPのメジャーバージョン番号は、互換性のないメッセージ構文が導入されると増加します。マイナー数は、プロトコルに加えられた変更がメッセージセマンティクスに追加するか、送信者の追加機能を暗示する効果がある場合に増加します。
The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients).
マイナーバージョンは、送信者がプロトコルの後方互換サブセットのみを使用している場合でも、送信者の通信機能を宣伝し、それにより、より高度な機能を（サーバーによって）または将来のリクエスト（クライアントによる）で使用できることを受信者に知らせます。。
When a major version of HTTP does not define any minor versions, the minor version "0" is implied. The "0" is used when referring to that protocol within elements that require a minor version identifier.
HTTPのメジャーバージョンがマイナーバージョンを定義しない場合、マイナーバージョン「0」が暗示されています。「0」は、マイナーバージョン識別子を必要とする要素内のそのプロトコルを参照するときに使用されます。
HTTP was created for the World Wide Web (WWW) architecture and has evolved over time to support the scalability needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology used to define HTTP.
HTTPは、World Wide Web（www）アーキテクチャ用に作成され、世界中のハイパーテキストシステムのスケーラビリティニーズをサポートするために時間とともに進化しました。そのアーキテクチャの多くは、HTTPを定義するために使用される用語に反映されています。
The target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Most resources are identified by a Uniform Resource Identifier (URI), as described in Section 4.
HTTP要求のターゲットは「リソース」と呼ばれます。HTTPは、リソースの性質を制限しません。リソースとの対話に使用される可能性のあるインターフェイスを定義するだけです。ほとんどのリソースは、セクション4で説明されているように、均一なリソース識別子（URI）によって識別されます。
One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (Section 9) and a few request-modifying header fields. A resource cannot treat a request in a manner inconsistent with the semantics of the method of the request. For example, though the URI of a resource might imply semantics that are not safe, a client can expect the resource to avoid actions that are unsafe when processing a request with a safe method (see Section 9.2.1).
HTTPの設計目標の1つは、リクエストセマンティクスとリクエストセマンティクスを要求セマンティクス（セクション9）といくつかのリクエスト修正ヘッダーフィールドに付与することで可能にされるリクエストセマンティクスから分離することです。リソースは、要求の方法のセマンティクスと矛盾する方法でリクエストを扱うことはできません。たとえば、リソースのURIは安全ではないセマンティクスを意味する場合がありますが、クライアントは、安全な方法でリクエストを処理するときに安全でないアクションを回避することをクライアントに期待できます（セクション9.2.1を参照）。
HTTP relies upon the Uniform Resource Identifier (URI) standard [URI] to indicate the target resource (Section 7.1) and relationships between resources.
HTTPは、標的リソース（セクション7.1）とリソース間の関係を示すために、均一なリソース識別子（URI）標準[URI]に依存しています。
A "representation" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol. A representation consists of a set of representation metadata and a potentially unbounded stream of representation data (Section 8).
「表現」とは、プロトコルを介して容易に伝達できる形式で、特定のリソースの過去、現在、または目的の状態を反映することを目的とした情報です。表現は、表現メタデータのセットと、潜在的に無制限の表現データの流れで構成されています（セクション8）。
HTTP allows "information hiding" behind its uniform interface by defining communication with respect to a transferable representation of the resource state, rather than transferring the resource itself. This allows the resource identified by a URI to be anything, including temporal functions like "the current weather in Laguna Beach", while potentially providing information that represents that resource at the time a message is generated [REST].
HTTPは、リソース自体を転送するのではなく、リソース状態の転送可能な表現に関して通信を定義することにより、均一なインターフェイスの背後に「隠れている」ことができます。これにより、URIによって識別されたリソースは、「ラグナビーチの現在の天気」などの時間的機能を含め、メッセージが生成された時点でそのリソースを表す情報を提供する可能性があることを含め、何でもすることができます[REST]。
The uniform interface is similar to a window through which one can observe and act upon a thing only through the communication of messages to an independent actor on the other side. A shared abstraction is needed to represent ("take the place of") the current or desired state of that thing in our communications. When a representation is hypertext, it can provide both a representation of the resource state and processing instructions that help guide the recipient's future interactions.
均一なインターフェイスは、反対側の独立した俳優とのメッセージの通信を通してのみ、物事を観察し、行動できる窓に似ています。私たちのコミュニケーションでそのことの現在または望ましい状態を表す（「取る」）を表すために共有された抽象化が必要です。表現がハイパーテキストの場合、リソース状態の表現と、受信者の将来の相互作用を導くのに役立つ処理手順の両方を提供できます。
A target resource might be provided with, or be capable of generating, multiple representations that are each intended to reflect the resource's current state. An algorithm, usually based on content negotiation (Section 12), would be used to select one of those representations as being most applicable to a given request. This "selected representation" provides the data and metadata for evaluating conditional requests (Section 13) and constructing the content for 200 (OK), 206 (Partial Content), and 304 (Not Modified) responses to GET (Section 9.3.1).
ターゲットリソースには、リソースの現在の状態を反映することを目的とした複数の表現が提供されるか、生成できる場合があります。通常、コンテンツネゴシエーション（セクション12）に基づいたアルゴリズムは、特定のリクエストに最も適用できるものとしてこれらの表現のいずれかを選択するために使用されます。この「選択された表現」は、条件付きリクエスト（セクション13）を評価し、200（OK）、206（部分コンテンツ）、および304（変更されていない）応答（セクション9.3.1）のコンテンツを構築するためのデータとメタデータを提供します。
HTTP is a client/server protocol that operates over a reliable transport- or session-layer "connection".
HTTPは、信頼性の高いトランスポートまたはセッション層の「接続」で動作するクライアント/サーバープロトコルです。
An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
HTTP「クライアント」は、1つ以上のHTTP要求を送信する目的でサーバーへの接続を確立するプログラムです。HTTP「サーバー」は、HTTP応答を送信してHTTPリクエストにサービスを提供するために接続を受け入れるプログラムです。
The terms client and server refer only to the roles that these programs perform for a particular connection. The same program might act as a client on some connections and a server on others.
クライアントとサーバーという用語は、これらのプログラムが特定の接続に対して実行する役割のみを参照します。同じプログラムは、一部の接続でクライアントとして機能し、他の接続のサーバーとして機能する場合があります。
HTTP is defined as a stateless protocol, meaning that each request message's semantics can be understood in isolation, and that the relationship between connections and messages on them has no impact on the interpretation of those messages. For example, a CONNECT request (Section 9.3.6) or a request with the Upgrade header field (Section 7.8) can occur at any time, not just in the first message on a connection. Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers.
HTTPは、ステートレスプロトコルとして定義されます。つまり、各要求メッセージのセマンティクスは単独で理解でき、接続とメッセージの関係はそれらのメッセージの解釈に影響を与えないことを意味します。たとえば、接続のリクエスト（セクション9.3.6）またはアップグレードヘッダーフィールド（セクション7.8）のリクエストは、接続の最初のメッセージだけでなく、いつでも発生する可能性があります。多くの実装は、HTTPのステートレス設計に依存して、プロキシ接続を再利用したり、複数のサーバーでバランスの要求を動的にロードしたりします。
As a result, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent. Some non-standard HTTP extensions (e.g., [RFC4559]) have been known to violate this requirement, resulting in security and interoperability problems.
その結果、接続が保護され、そのエージェントに固有でない限り、同じ接続上の2つの要求が同じユーザーエージェントからのものであるとサーバーが想定してはなりません。一部の非標準のHTTP拡張機能（例：[RFC4559]）は、この要件に違反することが知られており、セキュリティと相互運用性の問題をもたらしています。
HTTP is a stateless request/response protocol for exchanging "messages" across a connection. The terms "sender" and "recipient" refer to any implementation that sends or receives a given message, respectively.
HTTPは、接続全体で「メッセージ」を交換するためのステートレスリクエスト/応答プロトコルです。「送信者」と「受信者」という用語は、それぞれ特定のメッセージを送信または受信する実装を指します。
A client sends requests to a server in the form of a "request" message with a method (Section 9) and request target (Section 7.1). The request might also contain header fields (Section 6.3) for request modifiers, client information, and representation metadata, content (Section 6.4) intended for processing in accordance with the method, and trailer fields (Section 6.5) to communicate information collected while sending the content.
クライアントは、メソッド（セクション9）とリクエストターゲット（セクション7.1）を使用した「要求」メッセージの形式でサーバーにリクエストを送信します。リクエストには、リクエスト修飾子、クライアント情報、および表現メタデータのヘッダーフィールド（セクション6.3）、メソッドに従って処理することを目的としたコンテンツ（セクション6.4）、およびトレーラーフィールド（セクション6.5）が収集された情報を通信し、コンテンツ。
A server responds to a client's request by sending one or more "response" messages, each including a status code (Section 15). The response might also contain header fields for server information, resource metadata, and representation metadata, content to be interpreted in accordance with the status code, and trailer fields to communicate information collected while sending the content.
サーバーは、それぞれがステータスコード（セクション15）を含む1つ以上の「応答」メッセージを送信することにより、クライアントの要求に応答します。応答には、サーバー情報、リソースメタデータ、および表現メタデータのヘッダーフィールド、ステータスコードに従って解釈されるコンテンツ、およびコンテンツの送信中に収集された情報を通信するトレーラーフィールドも含まれている場合があります。
The term "user agent" refers to any of the various client programs that initiate a request.
「ユーザーエージェント」という用語は、リクエストを開始するさまざまなクライアントプログラムのいずれかを指します。
The most familiar form of user agent is the general-purpose Web browser, but that's only a small percentage of implementations. Other common user agents include spiders (web-traversing robots), command-line tools, billboard screens, household appliances, scales, light bulbs, firmware update scripts, mobile apps, and communication devices in a multitude of shapes and sizes.
ユーザーエージェントの最もよく知られている形式は、汎用Webブラウザーですが、実装のほんの一部にすぎません。その他の一般的なユーザーエージェントには、クモ（Webトレーバーロボット）、コマンドラインツール、ビルボードスクリーン、家電製品、スケール、電球、ファームウェアアップデートスクリプト、モバイルアプリ、多数の形状とサイズの通信デバイスが含まれます。
Being a user agent does not imply that there is a human user directly interacting with the software agent at the time of a request. In many cases, a user agent is installed or configured to run in the background and save its results for later inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph.
ユーザーエージェントであることは、リクエスト時にソフトウェアエージェントと直接対話する人間のユーザーがいることを意味するものではありません。多くの場合、ユーザーエージェントがインストールまたはバックグラウンドで実行され、その結果を後で検査するために保存するように構成されています（または、興味深いまたは誤っている可能性のある結果のサブセットのみを保存します）。たとえば、クモには通常、スタートURIが与えられ、ハイパーテキストグラフとしてWebをクロールしながら特定の動作に従うように構成されています。
Many user agents cannot, or choose not to, make interactive suggestions to their user or provide adequate warning for security or privacy concerns. In the few cases where this specification requires reporting of errors to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise, requirements that an automated action be confirmed by the user before proceeding might be met via advance configuration choices, run-time options, or simple avoidance of the unsafe action; confirmation does not imply any specific user interface or interruption of normal processing if the user has already made that choice.
多くのユーザーエージェントは、ユーザーにインタラクティブな提案を行うことも、セキュリティやプライバシーの懸念について適切な警告を提供することもできません。この仕様でユーザーへのエラーのレポートが必要ないくつかのケースでは、そのようなレポートはエラーコンソールまたはログファイルでのみ観察可能であることが許容されます。同様に、進行前にユーザーによって自動化されたアクションが確認されるという要件は、事前構成の選択、ランタイムオプション、または安全でないアクションの単純な回避を介して満たされる可能性があります。確認は、ユーザーがすでにその選択を行っている場合、特定のユーザーインターフェイスまたは通常の処理の中断を意味するものではありません。
The term "origin server" refers to a program that can originate authoritative responses for a given target resource.
「Origin Server」という用語は、特定のターゲットリソースの権威ある応答を発信できるプログラムを指します。
The most familiar form of origin server are large public websites. However, like user agents being equated with browsers, it is easy to be misled into thinking that all origin servers are alike. Common origin servers also include home automation units, configurable networking components, office machines, autonomous robots, news feeds, traffic cameras, real-time ad selectors, and video-on-demand platforms.
Origin Serverの最も馴染みのある形式は、大規模な公開Webサイトです。ただし、ユーザーエージェントがブラウザと同一視されているのと同様に、すべてのオリジンサーバーが同じであると考えるのは簡単です。Common Origin Serverには、ホームオートメーションユニット、構成可能なネットワーキングコンポーネント、オフィスマシン、自律ロボット、ニュースフィード、トラフィックカメラ、リアルタイム広告セレクター、ビデオオンデマンドプラットフォームも含まれます。
Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and the origin server (O).
ほとんどのHTTP通信は、URIによって識別されたいくつかのリソースを表現するための検索要求（取得）で構成されています。最も簡単な場合、これは、ユーザーエージェント（UA）とOrigin Server（O）の間の単一の双方向接続（===）を介して達成される可能性があります。
request >
UA ======================================= O
< response
Figure 1
図1
HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of HTTP "intermediary": proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.
HTTPにより、仲介者を使用して、一連の接続を介してリクエストを満たすことができます。HTTP「仲介」には、プロキシ、ゲートウェイ、トンネルの3つの一般的な形式があります。場合によっては、単一の仲介者がオリジンサーバー、プロキシ、ゲートウェイ、またはトンネルとして機能する場合があり、各リクエストの性質に基づいて動作を切り替えます。
> > > >
UA =========== A =========== B =========== C =========== O
< < < <
Figure 2
図2
The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response message that travels the whole chain will pass through four separate connections. Some HTTP communication options might apply only to the connection with the nearest, non-tunnel neighbor, only to the endpoints of the chain, or to all connections along the chain. Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For example, B might be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, at the same time that it is handling A's request. Likewise, later requests might be sent through a different path of connections, often based on dynamic configuration for load balancing.
上の図は、ユーザーエージェントとOrigin Serverの間の3つの仲介者（A、B、およびC）を示しています。チェーン全体を移動するリクエストまたは応答メッセージは、4つの個別の接続を通過します。一部のHTTP通信オプションは、チェーンのエンドポイント、またはチェーンに沿ったすべての接続にのみ、最も近い非タンネルネイバーとの接続にのみ適用される場合があります。図は線形ですが、各参加者は複数の同時通信に従事している可能性があります。たとえば、BはA以外の多くのクライアントからリクエストを受け取っている可能性があり、Aのリクエストを処理すると同時に、C以外のサーバーにリクエストを転送します。同様に、後のリクエストは、多くの場合、ロードバランスの動的な構成に基づいて、接続の異なるパスを介して送信される場合があります。
The terms "upstream" and "downstream" are used to describe directional requirements in relation to the message flow: all messages flow from upstream to downstream. The terms "inbound" and "outbound" are used to describe directional requirements in relation to the request route: inbound means "toward the origin server", whereas outbound means "toward the user agent".
「上流」および「下流」という用語は、メッセージフローに関連する方向要件を記述するために使用されます。すべてのメッセージは上流から下流に流れます。「インバウンド」および「アウトバウンド」という用語は、リクエストルートに関連する方向要件を記述するために使用されます。インバウンドは「オリジンサーバーに向かって」を意味しますが、アウトバウンドは「ユーザーエージェントに向かって」を意味します。
A "proxy" is a message-forwarding agent that is chosen by the client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary for the sake of security services, annotation services, or shared caching. Some proxies are designed to apply transformations to selected messages or content while they are being forwarded, as described in Section 7.7.
「プロキシ」は、通常、ローカル構成ルールを介してクライアントによって選択され、絶対URIの何らかのタイプのリクエストを受信し、HTTPインターフェイスを介して翻訳を介してそれらのリクエストを満たそうとするメッセージに選択されるメッセージです。「HTTP」URIのプロキシリクエストなど、一部の翻訳は最小限ですが、他のリクエストでは、まったく異なるアプリケーションレベルのプロトコルとの翻訳が必要になる場合があります。プロキシは、セキュリティサービス、注釈サービス、または共有キャッシュのために、一般的な仲介者を通じて組織のHTTP要求をグループ化するためによく使用されます。一部のプロキシは、セクション7.7で説明されているように、転送中に選択されたメッセージまたはコンテンツに変換を適用するように設計されています。
A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance through "accelerator" caching, and to enable partitioning or load balancing of HTTP services across multiple machines.
「ゲートウェイ」（別名「リバースプロキシ」）は、アウトバウンド接続のオリジンサーバーとして機能するが、受信したリクエストを変換し、別のサーバーまたはサーバーにインバウンドする仲介者です。ゲートウェイは、レガシーまたは信頼できない情報サービスをカプセル化し、「アクセラレータ」キャッシングを介したサーバーのパフォーマンスを改善し、複数のマシンにわたるHTTPサービスのパーティションまたはロードバランスを有効にするために、多くの場合使用されます。
All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers needs to conform to user agent requirements on the gateway's inbound connection.
Origin Serverに適用されるすべてのHTTP要件は、ゲートウェイのアウトバウンド通信にも適用されます。ゲートウェイは、この仕様の範囲外のHTTPへのプライベートエクステンションを含む、任意のプロトコルを使用してインバウンドサーバーと通信します。ただし、サードパーティのHTTPサーバーと相互運用したいHTTP-to-HTTPゲートウェイは、ゲートウェイのインバウンド接続でユーザーエージェントの要件に準拠する必要があります。
A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as when Transport Layer Security (TLS, [TLS13]) is used to establish confidential communication through a shared firewall proxy.
「トンネル」は、メッセージを変更せずに2つの接続間のブラインドリレーとして機能します。一度アクティブになると、トンネルはHTTP通信の当事者とは見なされませんが、トンネルはHTTPリクエストによって開始された可能性があります。リレー接続の両端が閉じられたときにトンネルが存在しなくなります。トンネルは、輸送層のセキュリティ（TLS、[TLS13]）が共有ファイアウォールプロキシを介して機密通信を確立するために使用される場合など、仲介者を介して仮想接続を拡張するために使用されます。
The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the knowledge or permission of message senders. Network intermediaries are indistinguishable (at a protocol level) from an on-path attacker, often introducing security flaws or interoperability problems due to mistakenly violating HTTP semantics.
仲介者の上記のカテゴリは、HTTP通信の参加者として行動するもののみを考慮しています。また、メッセージ送信者の知識や許可なしにHTTPトラフィックをフィルタリングまたはリダイレクトするネットワークプロトコルスタックの下層層に作用できる仲介者もあります。ネットワーク仲介業者は、パス上の攻撃者と見分けがつかない（プロトコルレベルで）、HTTPセマンティクスに誤って違反しているためにセキュリティの欠陥や相互運用性の問題を導入することがよくあります。
For example, an "interception proxy" [RFC3040] (also commonly known as a "transparent proxy" [RFC1919]) differs from an HTTP proxy because it is not chosen by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies.
たとえば、「インターセプトプロキシ」[RFC3040]（一般に「透明プロキシ」[RFC1919]としても知られています）は、クライアントによって選択されていないため、HTTPプロキシとは異なります。代わりに、インターセプトプロキシが発信されるTCPポート80パケット（および他の一般的なポートトラフィック）をフィルタリングまたはリダイレクトします。インターセプトプロキシは、非ローカルなインターネットサービスを使用する前にアカウントサブスクリプションを強制する手段として、およびネットワーク使用ポリシーを実施するための企業ファイアウォール内で一般的にパブリックネットワークアクセスポイントで見られます。
A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server MAY employ a cache, though a cache cannot be used while acting as a tunnel.
「キャッシュ」は、以前の応答メッセージと、メッセージストレージ、取得、削除を制御するサブシステムのローカルストアです。キャッシュは、将来のリクエストで応答時間とネットワーク帯域幅の消費を減らすために、キャッシュ可能な応答を保存します。クライアントまたはサーバーはキャッシュを使用する場合がありますが、トンネルとして機能するときはキャッシュを使用できません。
The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from O (via C) for a request that has not been cached by UA or A.
キャッシュの効果は、チェーンに沿った参加者の1人がその要求に適用可能なキャッシュ応答を持っている場合、要求/応答チェーンが短縮されることです。BがUAまたはAにキャッシュされていない要求に対して、BがO（Cを介して）からの以前の応答のキャッシュコピーを持っている場合、結果のチェーンを示しています。
> >
UA =========== A =========== B - - - - - - C - - - - - - O
< <
Figure 3
図3
A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in [CACHING].
キャッシュが後続のリクエストに答える際に使用するために応答メッセージのコピーを保存することが許可されている場合、応答は「キャッシュ可能」です。応答がキャッシュ可能な場合でも、クライアントまたはOrigin Serverによって、特定のリクエストにそのキャッシュされた応答を使用できる時期に追加の制約がある可能性があります。キャッシュの動作とキャッシュ可能な応答のHTTP要件は、[キャッシュ]で定義されています。
There is a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large organizations. These include national hierarchies of proxy caches to save bandwidth and reduce latency, content delivery networks that use gateway caching to optimize regional and global distribution of popular sites, collaborative systems that broadcast or multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments, and so on.
World Wide Webおよび内部で展開されているキャッシュのさまざまなアーキテクチャと構成があります。これらには、帯域幅を節約してレイテンシを削減するためのプロキシキャッシュの全国階層、ゲートウェイキャッシュを使用するコンテンツ配信ネットワーク、人気サイトの地域およびグローバルな分布、放送またはマルチキャストキャッシュエントリ、使用のための事前にフェッチしたキャッシュエントリのアーカイブのコラボレーティブシステム、オフラインまたは高速環境など。
The following example illustrates a typical HTTP/1.1 message exchange for a GET request (Section 9.3.1) on the URI "http://www.example.com/ hello.txt":
次の例は、URI "http://www.example.com/ hello.txt"のget request（セクション9.3.1）の典型的なHTTP/1.1メッセージ交換を示しています。
Client request:
クライアントのリクエスト：
GET /hello.txt HTTP/1.1
User-Agent: curl/7.64.1
Host: www.example.com
Accept-Language: en, mi
Server response:
サーバーの応答：
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! My content includes a trailing CRLF.
「こんにちは世界」私のコンテンツには、後続のCRLFが含まれています。
Uniform Resource Identifiers (URIs) [URI] are used throughout HTTP as the means for identifying resources (Section 3.1).
均一なリソース識別子（URIS）[URI]は、リソースを識別する手段としてHTTP全体で使用されます（セクション3.1）。
URI references are used to target requests, indicate redirects, and define relationships.
URI参照は、リクエストをターゲットにし、リダイレクトを示し、関係を定義するために使用されます。
The definitions of "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host", "path-abempty", "segment", and "query" are adopted from the URI generic syntax. An "absolute-path" rule is defined for protocol elements that can contain a non-empty path component. (This rule differs slightly from the path-abempty rule of RFC 3986, which allows for an empty path, and path-absolute rule, which does not allow paths that begin with "//".) A "partial-URI" rule is defined for protocol elements that can contain a relative URI but not a fragment component.
「uri-reference」、「absolute-uri」、「relative-part」、 "authority"、 "port"、 "host"、 "path-abemptty"、 "segment"、 "query"の定義は、から採用されています。URIジェネリック構文。「絶対パス」ルールは、空でないパスコンポーネントを含むプロトコル要素に対して定義されます。（このルールは、RFC 3986のパスアビーム型ルールとはわずかに異なります。これにより、空のパスと「//」から始まるパスを許可しないパス曖昧なルールが可能になります。）「部分uri」ルールは相対URIを含むがフラグメントコンポーネントを含むことができるプロトコル要素用に定義されています。
URI-reference = <URI-reference, see [URI], Section 4.1>
absolute-URI = <absolute-URI, see [URI], Section 4.3>
relative-part = <relative-part, see [URI], Section 4.2>
authority = <authority, see [URI], Section 3.2>
uri-host = <host, see [URI], Section 3.2.2>
port = <port, see [URI], Section 3.2.3>
path-abempty = <path-abempty, see [URI], Section 3.3>
segment = <segment, see [URI], Section 3.3>
query = <query, see [URI], Section 3.4>
absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ]
Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components (partial-URI), or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the target URI (Section 7.1).
URI参照を許可するHTTPの各プロトコル要素は、ABNFの生成で、要素があらゆる形式の参照（URI-Reference）を許可するかどうかを示します。部分uri）、または上記のいくつかの組み合わせ。特に示されない限り、URI参照はターゲットURI（セクション7.1）に対して解析されます。
It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements. Note that this implies some structures and on-wire representations (for example, the request line in HTTP/1.1) will necessarily be larger in some cases.
すべての送信者と受信者が、プロトコル要素に8000オクテットの長さのURIを少なくともサポートすることをお勧めします。これは、いくつかの構造とワイヤの表現（たとえば、HTTP/1.1の要求行が必然的に大きくなることを意味することに注意してください。
IANA maintains the registry of URI Schemes [BCP35] at <https://www.iana.org/assignments/uri-schemes/>. Although requests might target any URI scheme, the following schemes are inherent to HTTP servers:
IANAは、<https://www.iana.org/assignments/uri-schemes/>でURIスキーム[BCP35]のレジストリ[BCP35]を維持しています。リクエストは任意のURIスキームをターゲットにする可能性がありますが、次のスキームはHTTPサーバーに固有のものです。
+============+====================================+=========+
| URI Scheme | Description | Section |
+============+====================================+=========+
| http | Hypertext Transfer Protocol | 4.2.1 |
+------------+------------------------------------+---------+
| https | Hypertext Transfer Protocol Secure | 4.2.2 |
+------------+------------------------------------+---------+
Table 2
表2
Note that the presence of an "http" or "https" URI does not imply that there is always an HTTP server at the identified origin listening for connections. Anyone can mint a URI, whether or not a server exists and whether or not that server currently maps that identifier to a resource. The delegated nature of registered names and IP addresses creates a federated namespace whether or not an HTTP server is present.
「http」または「https」uriの存在は、識別されたオリジンに接続をリスニングしているhttpサーバーが常にあることを意味するものではないことに注意してください。誰でも、サーバーが存在するかどうか、そしてそのサーバーが現在識別子をリソースにマッピングするかどうかにかかわらず、誰でもURIを鋳造できます。登録名とIPアドレスの委任された性質は、HTTPサーバーが存在するかどうかにかかわらず、フェデレーションネームスペースを作成します。
The "http" URI scheme is hereby defined for minting identifiers within the hierarchical namespace governed by a potential HTTP origin server listening for TCP ([TCP]) connections on a given port.
「HTTP」URIスキームは、特定のポートのTCP（[TCP]）接続をリスニングする潜在的なHTTPオリジナルサーバーによって支配される階層名空間内のミント識別子に対して定義されます。
http-URI = "http" "://" authority path-abempty [ "?" query ]
The origin server for an "http" URI is identified by the authority component, which includes a host identifier ([URI], Section 3.2.2) and optional port number ([URI], Section 3.2.3). If the port subcomponent is empty or not given, TCP port 80 (the reserved port for WWW services) is the default. The origin determines who has the right to respond authoritatively to requests that target the identified resource, as defined in Section 4.3.2.
「HTTP」URIのOrigin Serverは、ホスト識別子（[URI]、セクション3.2.2）とオプションのポート番号（[URI]、セクション3.2.3）を含む権限コンポーネントによって識別されます。ポートサブコンポーネントが空であるか、与えられていない場合、TCPポート80（WWWサービス用の予約ポート）がデフォルトです。起源は、セクション4.3.2で定義されているように、特定されたリソースをターゲットにする要求に対して、権威的に応答する権利を持っている人を決定します。
A sender MUST NOT generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid.
送信者は、空のホスト識別子を備えた「HTTP」URIを生成してはなりません。このようなURI参照を処理する受信者は、無効として拒否する必要があります。
The hierarchical path component and optional query component identify the target resource within that origin server's namespace.
階層パスコンポーネントとオプションのクエリコンポーネントは、そのOrigin Serverの名前空間内のターゲットリソースを識別します。
The "https" URI scheme is hereby defined for minting identifiers within the hierarchical namespace governed by a potential origin server listening for TCP connections on a given port and capable of establishing a TLS ([TLS13]) connection that has been secured for HTTP communication. In this context, "secured" specifically means that the server has been authenticated as acting on behalf of the identified authority and all HTTP communication with that server has confidentiality and integrity protection that is acceptable to both client and server.
「HTTPS」URIスキームは、特定のポートでTCP接続をリスニングする潜在的なオリジンサーバーによって支配され、HTTP通信のために確保されたTLS（[TLS13]）接続を確立できる階層型名空間内のミント識別子に対して定義されます。この文脈では、「Secured」は、識別された権限に代わって行動するものとしてサーバーが認証されており、そのサーバーとのすべてのHTTP通信が、クライアントとサーバーの両方に受け入れられる機密性と整合性保護を持っていることを特に意味します。
https-URI = "https" "://" authority path-abempty [ "?" query ]
The origin server for an "https" URI is identified by the authority component, which includes a host identifier ([URI], Section 3.2.2) and optional port number ([URI], Section 3.2.3). If the port subcomponent is empty or not given, TCP port 443 (the reserved port for HTTP over TLS) is the default. The origin determines who has the right to respond authoritatively to requests that target the identified resource, as defined in Section 4.3.3.
「HTTPS」URIのOrigin Serverは、ホスト識別子（[URI]、セクション3.2.2）とオプションのポート番号（[URI]、セクション3.2.3）を含む権限コンポーネントによって識別されます。ポートサブコンポーネントが空であるか、与えられていない場合、TCPポート443（TLSを超えるHTTP用の予約ポート）がデフォルトです。起源は、セクション4.3.3で定義されているように、特定されたリソースをターゲットにする要求に対して、権威ある対応をする権利を持っている人を決定します。
A sender MUST NOT generate an "https" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid.
送信者は、空のホスト識別子を備えた「HTTPS」URIを生成してはなりません。このようなURI参照を処理する受信者は、無効として拒否する必要があります。
The hierarchical path component and optional query component identify the target resource within that origin server's namespace.
階層パスコンポーネントとオプションのクエリコンポーネントは、そのOrigin Serverの名前空間内のターゲットリソースを識別します。
A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts secured responses to those requests. Note that the definition of what cryptographic mechanisms are acceptable to client and server are usually negotiated and can change over time.
クライアントは、「HTTPS」リソースのHTTP要求が、通信する前に保護され、それらのリクエストに対する安全な応答のみを受け入れることを確認する必要があります。クライアントに受け入れられている暗号化メカニズムの定義は、通常交渉され、時間とともに変化する可能性があることに注意してください。
Resources made available via the "https" scheme have no shared identity with the "http" scheme. They are distinct origins with separate namespaces. However, extensions to HTTP that are defined as applying to all origins with the same host, such as the Cookie protocol [COOKIE], allow information set by one service to impact communication with other services within a matching group of host domains. Such extensions ought to be designed with great care to prevent information obtained from a secured connection being inadvertently exchanged within an unsecured context.
「HTTPS」スキームを介して利用可能になったリソースには、「HTTP」スキームと共有されたアイデンティティはありません。それらは別々の名前空間を持つ明確な起源です。ただし、Cookieプロトコル[Cookie]など、同じホストを持つすべての起源に適用されると定義されるHTTPへの拡張により、1つのサービスが設定した情報がホストドメインの一致するグループ内の他のサービスとの通信に影響を与えることができます。このような拡張機能は、安全な接続から得られた情報が無担保のコンテキスト内で不注意に交換されるのを防ぐために、細心の注意を払って設計する必要があります。
URIs with an "http" or "https" scheme are normalized and compared according to the methods defined in Section 6 of [URI], using the defaults described above for each scheme.
「HTTP」または「HTTPS」スキームを持つURISは正規化され、[URI]のセクション6で定義されている方法に従って比較され、各スキームについて上記のデフォルトを使用します。
HTTP does not require the use of a specific method for determining equivalence. For example, a cache key might be compared as a simple string, after syntax-based normalization, or after scheme-based normalization.
HTTPでは、等価性を決定するための特定の方法を使用する必要はありません。たとえば、キャッシュキーは、構文ベースの正規化後、またはスキームベースの正規化の後、単純な文字列として比較される場合があります。
Scheme-based normalization (Section 6.2.3 of [URI]) of "http" and "https" URIs involves the following additional rules:
「http」および「https」urisのスキームベースの正規化（[uri]のセクション6.2.3）には、次の追加ルールが含まれます。
* If the port is equal to the default port for a scheme, the normal form is to omit the port subcomponent.
* ポートがスキームのデフォルトポートに等しい場合、通常のフォームはポートサブコンポーネントを省略することです。
* When not being used as the target of an OPTIONS request, an empty path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead.
* オプション要求のターゲットとして使用されていない場合、空のパスコンポーネントは「/」の絶対パスに相当するため、通常のフォームは代わりに「/」のパスを提供することです。
* The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.
* スキームとホストは症例感受信性であり、通常は小文字で提供されます。他のすべてのコンポーネントは、ケースに敏感な方法で比較されます。
* Characters other than those in the "reserved" set are equivalent to their percent-encoded octets: the normal form is to not encode them (see Sections 2.1 and 2.2 of [URI]).
* 「予約済み」セットの文字以外の文字は、その割合でエンコードされたオクテットに相当します。通常の形式は、それらをエンコードしないことです（[URI]のセクション2.1および2.2を参照）。
For example, the following three URIs are equivalent:
たとえば、次の3つのURIは同等です。
http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html
Two HTTP URIs that are equivalent after normalization (using any method) can be assumed to identify the same resource, and any HTTP component MAY perform normalization. As a result, distinct resources SHOULD NOT be identified by HTTP URIs that are equivalent after normalization (using any method defined in Section 6.2 of [URI]).
正規化後に同等の2つのHTTP URI（任意の方法を使用）を想定して、同じリソースを識別し、HTTPコンポーネントは正規化を実行できます。その結果、正規化後に同等のHTTP URIによって異なるリソースを特定するべきではありません（[URI]のセクション6.2で定義されている方法を使用）。
The URI generic syntax for authority also includes a userinfo subcomponent ([URI], Section 3.2.1) for including user authentication information in the URI. In that subcomponent, the use of the format "user:password" is deprecated.
権限のURI Generic構文には、URIにユーザー認証情報を含めるためのUserInfoサブコンポーネント（[URI]、セクション3.2.1）も含まれています。そのサブコンポーネントでは、フォーマット「ユーザー：パスワード」の使用が非推奨です。
Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password.
一部の実装では、ユーザー識別子またはパスワードを公開する可能性がある場合でも、コマンドの呼び出しオプション、構成ファイル、ブックマークリストなど、認証情報の内部構成にuserInfoコンポーネントを使用しています。
A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" or "https" URI reference is generated within a message as a target URI or field value.
送信者は、「HTTP」または「HTTPS」URI参照がターゲットURIまたはフィールド値としてメッセージ内で生成されたときに、userInfoサブコンポーネント（およびその「@"delimiter）を生成してはなりません。
Before making use of an "http" or "https" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing attacks.
信頼できないソースから受信した「HTTP」または「HTTPS」URI参照を使用する前に、受信者はuserInfoを解析し、その存在をエラーとして扱う必要があります。フィッシング攻撃のために権限を曖昧にするために使用されている可能性があります。
Fragment identifiers allow for indirect identification of a secondary resource, independent of the URI scheme, as defined in Section 3.5 of [URI]. Some protocol elements that refer to a URI allow inclusion of a fragment, while others do not. They are distinguished by use of the ABNF rule for elements where fragment is allowed; otherwise, a specific rule that excludes fragments is used.
フラグメント識別子は、[URI]のセクション3.5で定義されているように、URIスキームとは無関係に、二次リソースの間接的な識別を可能にします。URIを参照するプロトコル要素の中には、フラグメントを含めることができますが、他のプロトコル要素も含まれません。それらは、フラグメントが許可されている要素のABNFルールを使用することにより区別されます。それ以外の場合、フラグメントを除外する特定のルールが使用されます。
| *Note:* The fragment identifier component is not part of the
| scheme definition for a URI scheme (see Section 4.3 of [URI]),
| thus does not appear in the ABNF definitions for the "http" and
| "https" URI schemes above.
Authoritative access refers to dereferencing a given identifier, for the sake of access to the identified resource, in a way that the client believes is authoritative (controlled by the resource owner). The process for determining whether access is granted is defined by the URI scheme and often uses data within the URI components, such as the authority component when the generic syntax is used. However, authoritative access is not limited to the identified mechanism.
権威あるアクセスとは、識別されたリソースへのアクセスのために、クライアントが権威ある（リソース所有者によって制御される）と信じている方法で、特定の識別子の委任を指します。アクセスが許可されているかどうかを判断するプロセスは、URIスキームによって定義され、一般的な構文が使用される場合の権限コンポーネントなど、URIコンポーネント内のデータを使用することがよくあります。ただし、権威あるアクセスは特定されたメカニズムに限定されません。
Section 4.3.1 defines the concept of an origin as an aid to such uses, and the subsequent subsections explain how to establish that a peer has the authority to represent an origin.
セクション4.3.1では、起源の概念をそのような用途への支援として定義し、その後のサブセクションは、ピアが起源を表す権限を持っていることを確立する方法を説明します。
See Section 17.1 for security considerations related to establishing authority.
当局の確立に関連するセキュリティに関する考慮事項については、セクション17.1を参照してください。
The "origin" for a given URI is the triple of scheme, host, and port after normalizing the scheme and host to lowercase and normalizing the port to remove any leading zeros. If port is elided from the URI, the default port for that scheme is used. For example, the URI
特定のURIの「起源」は、スキームとホストを正規化し、主要なゼロを削除するためにポートを正規化した後、スキーム、ホスト、およびポートのトリプルです。ポートがURIから除外されている場合、そのスキームのデフォルトポートが使用されます。たとえば、URI
https://Example.Com/happy.js
would have the origin
起源があります
{ "https", "example.com", "443" }
{"https"、 "emple.com"、 "443"}
which can also be described as the normalized URI prefix with port always present:
これは、常に存在するポートを備えた正規化されたURIプレフィックスとして記述することもできます。
https://example.com:443
Each origin defines its own namespace and controls how identifiers within that namespace are mapped to resources. In turn, how the origin responds to valid requests, consistently over time, determines the semantics that users will associate with a URI, and the usefulness of those semantics is what ultimately transforms these mechanisms into a resource for users to reference and access in the future.
各オリジンは独自の名前空間を定義し、その名前空間内の識別子がリソースにマッピングされる方法を制御します。次に、Originが有効な要求にどのように応答するかは、時間の経過とともに一貫してユーザーがURIに関連付けるセマンティクスを決定します。これらのセマンティクスの有用性は、これらのメカニズムを最終的にユーザーが将来のユーザーを参照してアクセスできるリソースに変換するものです。。
Two origins are distinct if they differ in scheme, host, or port. Even when it can be verified that the same entity controls two distinct origins, the two namespaces under those origins are distinct unless explicitly aliased by a server authoritative for that origin.
スキーム、ホスト、またはポートが異なる場合、2つの起源は異なります。同じエンティティが2つの異なる起源を制御することを確認できる場合でも、それらの起源の下の2つの名前空間は、その起源に対して権威あるサーバーによって明示的にエイリアスされない限り明確です。
Origin is also used within HTML and related Web protocols, beyond the scope of this document, as described in [RFC6454].
起源は、[RFC6454]で説明されているように、このドキュメントの範囲を超えて、HTMLおよび関連するWebプロトコル内でも使用されます。
Although HTTP is independent of the transport protocol, the "http" scheme (Section 4.2.1) is specific to associating authority with whomever controls the origin server listening for TCP connections on the indicated port of whatever host is identified within the authority component. This is a very weak sense of authority because it depends on both client-specific name resolution mechanisms and communication that might not be secured from an on-path attacker. Nevertheless, it is a sufficient minimum for binding "http" identifiers to an origin server for consistent resolution within a trusted environment.
HTTPはトランスポートプロトコルとは無関係ですが、「HTTP」スキーム（セクション4.2.1）は、権限を制御するために権限を関連付けることに固有のものであり、当局コンポーネント内で識別されるホストの指定されたポートでTCP接続をリスニングするオリジンサーバーを制御します。これは非常に弱い権威の感覚です。なぜなら、それは、パス上の攻撃者から保護されていない可能性のあるクライアント固有の名前解決メカニズムとコミュニケーションの両方に依存するためです。それにもかかわらず、信頼できる環境内で一貫した解像度のために、Origin Serverに「HTTP」識別子をバインドするのに十分な最小値です。
If the host identifier is provided as an IP address, the origin server is the listener (if any) on the indicated TCP port at that IP address. If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS, to find an address for an appropriate origin server.
ホスト識別子がIPアドレスとして提供されている場合、Origin Serverは、そのIPアドレスの指定されたTCPポートのリスナー（もしあれば）です。ホストが登録名の場合、登録名は、適切なオリジンサーバーのアドレスを見つけるために、DNSなどの名前解像度サービスで使用する間接識別子です。
When an "http" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by resolving the host identifier to an IP address, establishing a TCP connection to that address on the indicated port, and sending over that connection an HTTP request message containing a request target that matches the client's target URI (Section 7.1).
「HTTP」URIが指定されたリソースへのアクセスを要求するコンテキスト内で使用される場合、クライアントは、ホスト識別子をIPアドレスに解決し、指定されたポートでそのアドレスへのTCP接続を確立し、送信することでアクセスを試みることができます。その接続は、クライアントのターゲットURI（セクション7.1）に一致するリクエストターゲットを含むHTTP要求メッセージです。
If the server responds to such a request with a non-interim HTTP response message, as described in Section 15, then that response is considered an authoritative answer to the client's request.
セクション15で説明されているように、サーバーがそのような要求に応答する場合、そのようなリクエストがセクション15で説明されているように、その応答はクライアントの要求に対する権威ある回答と見なされます。
Note, however, that the above is not the only means for obtaining an authoritative response, nor does it imply that an authoritative response is always necessary (see [CACHING]). For example, the Alt-Svc header field [ALTSVC] allows an origin server to identify other services that are also authoritative for that origin. Access to "http" identified resources might also be provided by protocols outside the scope of this document.
ただし、上記は権威ある応答を得るための唯一の手段ではなく、権威ある応答が常に必要であることを意味することもありません（[キャッシュ]を参照）。たとえば、ALT-SVCヘッダーフィールド[AltSVC]により、Origin Serverは、その起源に対して権威ある他のサービスを特定できます。「HTTP」識別されたリソースへのアクセスは、このドキュメントの範囲外のプロトコルによっても提供される場合があります。
The "https" scheme (Section 4.2.2) associates authority based on the ability of a server to use the private key corresponding to a certificate that the client considers to be trustworthy for the identified origin server. The client usually relies upon a chain of trust, conveyed from some prearranged or configured trust anchor, to deem a certificate trustworthy (Section 4.3.4).
「HTTPS」スキーム（セクション4.2.2）は、クライアントが特定されたOrigin Serverに対して信頼できると考える証明書に対応する秘密キーを使用するサーバーの能力に基づいて、権限を関連付けます。クライアントは通常、信頼できる証明書（セクション4.3.4）を考慮するために、いくつかの事前表現または構成された信頼アンカーから伝えられる信頼の連鎖に依存しています。
In HTTP/1.1 and earlier, a client will only attribute authority to a server when they are communicating over a successfully established and secured connection specifically to that URI origin's host. The connection establishment and certificate verification are used as proof of authority.
HTTP/1.1以前に、クライアントは、そのURI Originのホストと特に確立され確信された接続を介して通信している場合のみ、サーバーに権限を属性します。接続の確立と証明書の検証は、権限の証明として使用されます。
In HTTP/2 and HTTP/3, a client will attribute authority to a server when they are communicating over a successfully established and secured connection if the URI origin's host matches any of the hosts present in the server's certificate and the client believes that it could open a connection to that host for that URI. In practice, a client will make a DNS query to check that the origin's host contains the same server IP address as the established connection. This restriction can be removed by the origin server sending an equivalent ORIGIN frame [RFC8336].
HTTP/2およびHTTP/3では、URI Originのホストがサーバーの証明書に存在するホストのいずれかと一致し、クライアントがそれが可能であると考えている場合、クライアントは、正常に確立され、保護された接続を通信しているときに、サーバーに権限を属性します。そのuriのホストへの接続を開きます。実際には、クライアントがDNSクエリを作成して、Originのホストが確立された接続と同じサーバーIPアドレスが含まれていることを確認します。この制限は、同等のオリジンフレーム[RFC8336]を送信するOrigin Serverによって削除できます。
The request target's host and port value are passed within each HTTP request, identifying the origin and distinguishing it from other namespaces that might be controlled by the same server (Section 7.2). It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces or at least prepared to reject requests that appear to have been misdirected (Section 7.4).
リクエストターゲットのホストとポート値は各HTTP要求内で渡され、起源を特定し、同じサーバーによって制御される可能性のある他の名前空間から区別します（セクション7.2）。証明書の秘密鍵を制御するサービスが提供されるサービスが、対応する「HTTPS」名前空間を管理するか、少なくとも誤った方向に向けられていると思われるリクエストを拒否する準備をしていることを確実にすることは、起源の責任です（セクション7.4）。
An origin server might be unwilling to process requests for certain target URIs even when they have the authority to do so. For example, when a host operates distinct services on different ports (e.g., 443 and 8000), checking the target URI at the origin server is necessary (even after the connection has been secured) because a network attacker might cause connections for one port to be received at some other port. Failing to check the target URI might allow such an attacker to replace a response to one target URI (e.g., "https://example.com/foo") with a seemingly authoritative response from the other port (e.g., "https://example.com:8000/foo").
Origin Serverは、特定のターゲットURIのリクエストを処理したくない場合があります。たとえば、ホストが異なるポート（443および8000など）で異なるサービスを操作する場合、ネットワーク攻撃者が1つのポートの接続を引き起こす可能性があるため、Origin ServerでターゲットURIを確認する必要があります（接続が固定された後でも）他の港で受け取られます。ターゲットURIをチェックしないと、そのような攻撃者が1つのターゲットURI（例： "https://example.com/foo"）への応答を他のポートからの一見権威ある応答（例： "https：//example.com:8000/foo "）。
Note that the "https" scheme does not rely on TCP and the connected port number for associating authority, since both are outside the secured communication and thus cannot be trusted as definitive. Hence, the HTTP communication might take place over any channel that has been secured, as defined in Section 4.2.2, including protocols that don't use TCP.
「HTTPS」スキームは、担保付き通信の外側であり、したがって決定的であると信頼できないため、TCPと関連する権限の接続ポート番号に依存していないことに注意してください。したがって、TCPを使用しないプロトコルを含むセクション4.2.2で定義されているように、HTTP通信は保護されているチャネルで行われる場合があります。
When an "https" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by resolving the host identifier to an IP address, establishing a TCP connection to that address on the indicated port, securing the connection end-to-end by successfully initiating TLS over TCP with confidentiality and integrity protection, and sending over that connection an HTTP request message containing a request target that matches the client's target URI (Section 7.1).
「HTTPS」URIが指定されたリソースへのアクセスを要求するコンテキスト内で使用される場合、クライアントは、ホスト識別子をIPアドレスに解決し、指定されたポート上のそのアドレスへのTCP接続を確立し、接続を固定することでアクセスを試みることができます。エンドツーエンドは、機密性と整合性保護を備えたTCPを介したTLSを正常に開始し、その接続でクライアントのターゲットURIに一致するリクエストターゲットを含むHTTP要求メッセージを送信します（セクション7.1）。
If the server responds to such a request with a non-interim HTTP response message, as described in Section 15, then that response is considered an authoritative answer to the client's request.
セクション15で説明されているように、サーバーがそのような要求に応答する場合、そのようなリクエストがセクション15で説明されているように、その応答はクライアントの要求に対する権威ある回答と見なされます。
Note, however, that the above is not the only means for obtaining an authoritative response, nor does it imply that an authoritative response is always necessary (see [CACHING]).
ただし、上記は権威ある応答を得るための唯一の手段ではなく、権威ある応答が常に必要であることを意味することもありません（[キャッシュ]を参照）。
To establish a secured connection to dereference a URI, a client MUST verify that the service's identity is an acceptable match for the URI's origin server. Certificate verification is used to prevent server impersonation by an on-path attacker or by an attacker that controls name resolution. This process requires that a client be configured with a set of trust anchors.
控えめなURIへの保護された接続を確立するには、クライアントは、サービスのIDがURIのOrigin Serverの許容可能な一致であることを確認する必要があります。証明書の検証は、パス上の攻撃者または名前の解決を制御する攻撃者によるサーバーのなりすましを防ぐために使用されます。このプロセスでは、クライアントを信頼できるアンカーのセットで構成する必要があります。
In general, a client MUST verify the service identity using the verification process defined in Section 6 of [RFC6125]. The client MUST construct a reference identity from the service's host: if the host is a literal IP address (Section 4.3.5), the reference identity is an IP-ID, otherwise the host is a name and the reference identity is a DNS-ID.
一般に、クライアントは[RFC6125]のセクション6で定義されている検証プロセスを使用して、サービスIDを検証する必要があります。クライアントは、サービスのホストから参照IDを構築する必要があります。ホストがリテラルIPアドレス（セクション4.3.5）の場合、参照IDはIP-IDです。ID。
A reference identity of type CN-ID MUST NOT be used by clients. As noted in Section 6.2.1 of [RFC6125], a reference identity of type CN-ID might be used by older clients.
タイプCN-IDの参照IDは、クライアントが使用してはなりません。[RFC6125]のセクション6.2.1で述べたように、CN-IDタイプの参照IDは、古いクライアントが使用する場合があります。
A client might be specially configured to accept an alternative form of server identity verification. For example, a client might be connecting to a server whose address and hostname are dynamic, with an expectation that the service will present a specific certificate (or a certificate matching some externally defined reference identity) rather than one matching the target URI's origin.
クライアントは、サーバーIDの検証の代替形式を受け入れるように特別に構成されている場合があります。たとえば、クライアントはアドレスとホスト名が動的であるサーバーに接続している可能性があり、サービスがターゲットURIの起源と一致するのではなく、特定の証明書（または外部から定義された参照IDと一致する証明書）を提示することを期待しています。
In special cases, it might be appropriate for a client to simply ignore the server's identity, but it must be understood that this leaves a connection open to active attack.
特別な場合、クライアントがサーバーのIDを単純に無視することは適切かもしれませんが、これによりアクティブな攻撃に接続が開かれていることを理解する必要があります。
If the certificate is not valid for the target URI's origin, a user agent MUST either obtain confirmation from the user before proceeding (see Section 3.5) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it.
証明書がターゲットURIの起源に対して有効でない場合、ユーザーエージェントは、進行する前にユーザーから確認を取得するか（セクション3.5を参照）、または悪い証明書エラーで接続を終了する必要があります。自動化されたクライアントは、エラーを適切な監査ログ（利用可能な場合）にログに記録する必要があり、接続を終了する必要があります（悪い証明書エラーを使用）。自動化されたクライアントは、このチェックを無効にする構成設定を提供する場合がありますが、それを有効にする設定を提供する必要があります。
A server that is identified using an IP address literal in the "host" field of an "https" URI has a reference identity of type IP-ID. An IP version 4 address uses the "IPv4address" ABNF rule, and an IP version 6 address uses the "IP-literal" production with the "IPv6address" option; see Section 3.2.2 of [URI]. A reference identity of IP-ID contains the decoded bytes of the IP address.
「HTTPS」の「ホスト」フィールドでリテラルのIPアドレスを使用して識別されるサーバーは、タイプIP-IDの参照アイデンティティを持っています。IPバージョン4アドレスは、「IPv4Address」ABNFルールを使用し、IPバージョン6アドレスは「IP-Literal」制作を「IPv6Address」オプションで使用します。[URI]のセクション3.2.2を参照してください。IP-IDの参照IDには、IPアドレスのデコードされたバイトが含まれています。
An IP version 4 address is 4 octets, and an IP version 6 address is 16 octets. Use of IP-ID is not defined for any other IP version. The iPAddress choice in the certificate subjectAltName extension does not explicitly include the IP version and so relies on the length of the address to distinguish versions; see Section 4.2.1.6 of [RFC5280].
IPバージョン4アドレスは4オクテットで、IPバージョン6アドレスは16オクテットです。IP-IDの使用は、他のIPバージョンでは定義されていません。証明書SubjectAltName拡張子のiPaddress選択には、IPバージョンを明示的に含まれていないため、バージョンを区別するためのアドレスの長さに依存しています。[RFC5280]のセクション4.2.1.6を参照してください。
A reference identity of type IP-ID matches if the address is identical to an iPAddress value of the subjectAltName extension of the certificate.
アドレスが証明書のsubjectaltname拡張子のiPaddress値と同一である場合、タイプIP-IDの参照IDは一致します。
HTTP uses "fields" to provide data in the form of extensible name/ value pairs with a registered key namespace. Fields are sent and received within the header and trailer sections of messages (Section 6).
HTTPは「フィールド」を使用して、登録されたキーネームスペースを持つ拡張可能な名前/値ペアの形式のデータを提供します。フィールドは、メッセージのヘッダーおよびトレーラーセクション内で送信および受信されます（セクション6）。
A field name labels the corresponding field value as having the semantics defined by that name. For example, the Date header field is defined in Section 6.6.1 as containing the origination timestamp for the message in which it appears.
フィールド名は、その名前で定義されたセマンティクスを持つ対応するフィールド値にラベル付けされます。たとえば、日付ヘッダーフィールドは、セクション6.6.1で、表示されるメッセージのオリジネーションタイムスタンプを含むと定義されています。
field-name = token
Field names are case-insensitive and ought to be registered within the "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see Section 16.3.1.
フィールド名はケース非感受性であり、「HyperText Transfer Protocol（HTTP）フィールド名レジストリ」に登録する必要があります。セクション16.3.1を参照してください。
The interpretation of a field does not change between minor versions of the same major HTTP version, though the default behavior of a recipient in the absence of such a field can change. Unless specified otherwise, fields are defined for all versions of HTTP. In particular, the Host and Connection fields ought to be recognized by all HTTP implementations whether or not they advertise conformance with HTTP/1.1.
フィールドの解釈は、同じ主要なHTTPバージョンのマイナーバージョン間で変更されませんが、そのようなフィールドがない場合の受信者のデフォルトの動作は変更される可能性があります。特に指定されていない限り、フィールドはhttpのすべてのバージョンに対して定義されています。特に、HTTP/1.1との適合性を宣伝するかどうかにかかわらず、すべてのHTTP実装によってホストと接続フィールドが認識されるべきです。
New fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them; see Section 16.3.
定義されたセマンティクスが、それらを認識していない受信者が安全に無視できる場合、プロトコルバージョンを変更せずに新しいフィールドを導入できます。セクション16.3を参照してください。
A proxy MUST forward unrecognized header fields unless the field name is listed in the Connection header field (Section 7.6.1) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients SHOULD ignore unrecognized header and trailer fields. Adhering to these requirements allows HTTP's functionality to be extended without updating or removing deployed intermediaries.
フィールド名が接続ヘッダーフィールドにリストされている場合（セクション7.6.1）、またはプロキシがそのようなフィールドをブロックまたはその他の方法で変換するように特別に構成されていない限り、プロキシは認識されていないヘッダーフィールドを転送する必要があります。他の受信者は、認識されていないヘッダーとトレーラーフィールドを無視する必要があります。これらの要件を順守することで、展開された仲介者を更新または削除することなく、HTTPの機能を拡張できます。
Field sections are composed of any number of "field lines", each with a "field name" (see Section 5.1) identifying the field, and a "field line value" that conveys data for that instance of the field.
フィールドセクションは、フィールドを識別する「フィールド名」（セクション5.1を参照）と、フィールドのそのインスタンスのデータを伝える「フィールドライン値」を持つ任意の「フィールドライン」で構成されています。
When a field name is only present once in a section, the combined "field value" for that field consists of the corresponding field line value. When a field name is repeated within a section, its combined field value consists of the list of corresponding field line values within that section, concatenated in order, with each field line value separated by a comma.
フィールド名がセクションに1回のみ存在する場合、そのフィールドの合計「フィールド値」は、対応するフィールドライン値で構成されます。セクション内でフィールド名が繰り返されると、その組み合わせたフィールド値は、そのセクション内の対応するフィールドライン値のリストで構成され、順番に連結され、各フィールドライン値はコンマで分離されます。
For example, this section:
たとえば、このセクション：
Example-Field: Foo, Bar Example-Field: Baz
例：フィールド：foo、bar example-field：baz
contains two field lines, both with the field name "Example-Field". The first field line has a field line value of "Foo, Bar", while the second field line value is "Baz". The field value for "Example-Field" is the list "Foo, Bar, Baz".
両方ともフィールド名「例フィールド」がある2つのフィールドラインが含まれています。最初のフィールドラインには「Foo、bar」のフィールドライン値があり、2番目のフィールドライン値は「baz」です。「フィールドの例」のフィールド値は、「foo、bar、baz」のリストです。
A recipient MAY combine multiple field lines within a field section that have the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma (",") and optional whitespace (OWS, defined in Section 5.6.3). For consistency, use comma SP.
受信者は、メッセージのセマンティクスを変更せずに、同じフィールド名を1つのフィールドラインに変更するフィールドセクション内の複数のフィールドラインを組み合わせることができます。（ "、"）およびオプションの白人（OWS、セクション5.6.3で定義）。一貫性を得るには、Comma spを使用してください。
The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a proxy MUST NOT change the order of these field line values when forwarding a message.
したがって、同じ名前のフィールドラインが受信される順序は、フィールド値の解釈にとって重要です。プロキシは、メッセージを転送するときにこれらのフィールドライン値の順序を変更してはなりません。
This means that, aside from the well-known exception noted below, a sender MUST NOT generate multiple field lines with the same name in a message (whether in the headers or trailers) or append a field line when a field line of the same name already exists in the message, unless that field's definition allows multiple field line values to be recombined as a comma-separated list (i.e., at least one alternative of the field's definition allows a comma-separated list, such as an ABNF rule of #(values) defined in Section 5.6.1).
これは、以下に記載されているよく知られている例外を除いて、送信者は、同じ名前のフィールドラインが同じ名前で同じ名前を持つ複数のフィールドライン（ヘッダーまたはトレーラー内で）を生成してはならないことを意味します。そのフィールドの定義により、複数のフィールドライン値がコンマ分離リストとして複数のフィールドライン値を再結合できない限り、すでに存在しています（つまり、フィールドの定義の少なくとも1つの選択肢は、＃のABNFルールなどのコンマ区切りリストを許可します（値）セクション5.6.1で定義されています）。
| *Note:* In practice, the "Set-Cookie" header field ([COOKIE])
| often appears in a response message across multiple field lines
| and does not use the list syntax, violating the above
| requirements on multiple field lines with the same field name.
| Since it cannot be combined into a single field value,
| recipients ought to handle "Set-Cookie" as a special case while
| processing fields. (See Appendix A.2.3 of [Kri2001] for
| details.)
The order in which field lines with differing field names are received in a section is not significant. However, it is good practice to send header fields that contain additional control data first, such as Host on requests and Date on responses, so that implementations can decide when not to handle a message as early as possible.
セクションでフィールド名が異なるフィールドラインが受信される順序は重要ではありません。ただし、リクエストに応じてホストや日付など、追加のコントロールデータを最初に含めるヘッダーフィールドを送信することをお勧めします。そのため、実装はできるだけ早くメッセージを処理しない場合を決定できます。
A server MUST NOT apply a request to the target resource until it receives the entire request header section, since later header field lines might include conditionals, authentication credentials, or deliberately misleading duplicate header fields that could impact request processing.
サーバーは、リクエストヘッダーセクション全体を受信するまでターゲットリソースにリクエストを適用してはなりません。後のヘッダーフィールドラインには、条件、認証資格情報、またはリクエスト処理に影響を与える可能性のある重複ヘッダーフィールドが誤解を招く可能性があるためです。
HTTP does not place a predefined limit on the length of each field line, field value, or on the length of a header or trailer section as a whole, as described in Section 2. Various ad hoc limitations on individual lengths are found in practice, often depending on the specific field's semantics.
HTTPは、セクション2で説明されているように、各フィールドラインの長さ、フィールド値、またはヘッダーまたはトレーラーセクションの長さに事前定義された制限を配置しません。多くの場合、特定のフィールドのセマンティクスに依存します。
A server that receives a request header field line, field value, or set of fields larger than it wishes to process MUST respond with an appropriate 4xx (Client Error) status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks (Section 11.2 of [HTTP/1.1]).
リクエストヘッダーフィールドライン、フィールド値、または処理を望むよりも大きいフィールドのセットを受信するサーバーは、適切な4XX（クライアントエラー）ステータスコードで応答する必要があります。このようなヘッダーフィールドを無視すると、密輸攻撃を要求するサーバーの脆弱性が高まります（[http/1.1]のセクション11.2）。
A client MAY discard or truncate received field lines that are larger than the client wishes to process if the field semantics are such that the dropped value(s) can be safely ignored without changing the message framing or response semantics.
クライアントは、フィールドセマンティクスがメッセージフレーミングまたは応答セマンティクスを変更せずに安全に無視できるようにフィールドセマンティクスが安全に無視できるように、クライアントが処理したいよりも大きい受信したフィールドラインを廃棄または切り捨てることができます。
HTTP field values consist of a sequence of characters in a format defined by the field's grammar. Each field's grammar is usually defined using ABNF ([RFC5234]).
HTTPフィールド値は、フィールドの文法で定義された形式の文字のシーケンスで構成されています。各フィールドの文法は通常、ABNF（[RFC5234]）を使用して定義されます。
field-value = *field-content
field-content = field-vchar
[ 1*( SP / HTAB / field-vchar ) field-vchar ]
field-vchar = VCHAR / obs-text
obs-text = %x80-FF
A field value does not include leading or trailing whitespace. When a specific version of HTTP allows such whitespace to appear in a message, a field parsing implementation MUST exclude such whitespace prior to evaluating the field value.
フィールド値には、先頭または末尾の空白は含まれません。HTTPの特定のバージョンがそのような白文学がメッセージに表示される場合、フィールド解析の実装は、フィールド値を評価する前にそのような空白を除外する必要があります。
Field values are usually constrained to the range of US-ASCII characters [USASCII]. Fields needing a greater range of characters can use an encoding, such as the one defined in [RFC8187]. Historically, HTTP allowed field content with text in the ISO-8859-1 charset [ISO-8859-1], supporting other charsets only through use of [RFC2047] encoding. Specifications for newly defined fields SHOULD limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB. A recipient SHOULD treat other allowed octets in field content (i.e., obs-text) as opaque data.
フィールド値は通常、US-ASCII文字[USASCII]の範囲に制約されます。幅広い範囲の文字を必要とするフィールドは、[RFC8187]で定義されているものなど、エンコードを使用できます。歴史的に、HTTPは、ISO-8859-1チャーセット[ISO-8859-1]にテキストを含むフィールドコンテンツを許可し、[RFC2047]エンコードを使用してのみ他の充電器をサポートしました。新たに定義されたフィールドの仕様は、その値を目に見えるUS-ASCIIオクテット（VCHAR）、SP、およびHTABに制限する必要があります。受信者は、フィールドコンテンツ（つまり、obs-text）の他の許可されたオクテットを不透明なデータとして扱う必要があります。
Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message. Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake of robustness when they appear within a safe context (e.g., an application-specific quoted string that will not be processed by any downstream HTTP parser).
CR、LF、またはNUL文字を含むフィールド値は、実装がそれらの文字を解析して解釈する可能性があるさまざまな方法により、無効で危険です。フィールド値内のCR、LF、またはNULの受信者は、メッセージをさらに処理または転送する前に、メッセージを拒否するか、それらの各文字をSPに置き換える必要があります。他のCTL文字を含むフィールド値も無効です。ただし、受信者は、安全なコンテキスト内に表示されるときに堅牢性のためにそのような文字を保持する場合があります（たとえば、下流のHTTPパーサーによって処理されないアプリケーション固有の引用文字列）。
Fields that only anticipate a single member as the field value are referred to as "singleton fields".
フィールド値として単一のメンバーのみを予測するフィールドは、「シングルトンフィールド」と呼ばれます。
Fields that allow multiple members as the field value are referred to as "list-based fields". The list operator extension of Section 5.6.1 is used as a common notation for defining field values that can contain multiple members.
フィールド値として複数のメンバーを許可するフィールドは、「リストベースのフィールド」と呼ばれます。セクション5.6.1のリスト演算子拡張は、複数のメンバーを含む可能性のあるフィールド値を定義するための一般的な表記として使用されます。
Because commas (",") are used as the delimiter between members, they need to be treated with care if they are allowed as data within a member. This is true for both list-based and singleton fields, since a singleton field might be erroneously sent with multiple members and detecting such errors improves interoperability. Fields that expect to contain a comma within a member, such as within an HTTP-date or URI-reference element, ought to be defined with delimiters around that element to distinguish any comma within that data from potential list separators.
コンマ（ "、"）はメンバー間の区切り文字として使用されるため、メンバー内のデータとして許可されている場合は、注意して扱う必要があります。これは、リストベースとシングルトンフィールドの両方に当てはまります。シングルトンフィールドは複数のメンバーと誤って送信され、そのようなエラーを検出すると相互運用性が向上する可能性があるためです。HTTP-DateまたはURI-Reference要素内など、メンバー内にコンマを含めることを期待するフィールドは、その要素の周りのデリミターで定義して、そのデータ内のコンマを潜在的なリストセパレーターから区別する必要があります。
For example, a textual date and a URI (either of which might contain a comma) could be safely carried in list-based field values like these:
たとえば、テキストの日付とURI（どちらもコンマを含む可能性がある）は、次のようなリストベースのフィールド値に安全に運ばれる可能性があります。
Example-URIs: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/"
Example-Dates: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters are almost always used with the quoted-string production (Section 5.6.4); using a different syntax inside double-quotes will likely cause unnecessary confusion.
二重引用層の区切り文字は、ほとんど常に引用された弦の生産で使用されていることに注意してください（セクション5.6.4）。ダブルクォート内で異なる構文を使用すると、不必要な混乱を引き起こす可能性があります。
Many fields (such as Content-Type, defined in Section 8.3) use a common syntax for parameters that allows both unquoted (token) and quoted (quoted-string) syntax for a parameter value (Section 5.6.6). Use of common syntax allows recipients to reuse existing parser components. When allowing both forms, the meaning of a parameter value ought to be the same whether it was received as a token or a quoted string.
多くのフィールド（セクション8.3で定義されているコンテンツタイプなど）は、パラメーター値に対して、引用されていない（トークン）と引用（引用されたストリング）構文の両方を可能にするパラメーターに共通の構文を使用します（セクション5.6.6）。一般的な構文を使用すると、受信者は既存のパーサーコンポーネントを再利用できます。両方のフォームを許可する場合、パラメーター値の意味は、トークンとして受信されたものであろうと引用されている文字列として受信されていても、同じである必要があります。
| *Note:* For defining field value syntax, this specification
| uses an ABNF rule named after the field name to define the
| allowed grammar for that field's value (after said value has
| been extracted from the underlying messaging syntax and
| multiple instances combined into a list).
A #rule extension to the ABNF rules of [RFC5234] is used to improve readability in the definitions of some list-based field values.
[RFC5234]のABNFルールの#rule拡張は、リストベースのフィールド値の定義の読みやすさを改善するために使用されます。
A construct "#" is defined, similar to "*", for defining comma-delimited lists of elements. The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS, defined in Section 5.6.3).
コンマが決定する要素のリストを定義するために、「*」と同様のコンストラクト「＃」が定義されています。完全なフォームは、「<n>＃<m>要素」であり、少なくとも<n>およびせいぜい<m>要素を示すもので、それぞれが単一のコンマ（ "、"）とオプションの白文字（OWS、セクション5.6で定義されています）で区切られています。3）。
In any production that uses the list construct, a sender MUST NOT generate empty list elements. In other words, a sender has to generate lists that satisfy the following syntax:
リストコンストラクトを使用する任意の生産では、送信者は空のリスト要素を生成してはなりません。言い換えれば、送信者は次の構文を満たすリストを生成する必要があります。
1#element => element *( OWS "," OWS element )
and:
と：
#element => [ 1#element ]
and for n >= 1 and m > 1:
n> = 1およびm> 1の場合：
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
Appendix A shows the collected ABNF for senders after the list constructs have been expanded.
付録Aは、リストコンストラクトが拡張された後、送信者の収集されたABNFを示しています。
Empty elements do not contribute to the count of elements present. A recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of-service mechanism. In other words, a recipient MUST accept lists that satisfy the following syntax:
空の要素は、存在する要素のカウントに寄与しません。受信者は、妥当な数の空のリスト要素を解析して無視する必要があります。値をマージする送信者による一般的な間違いを処理するのに十分ですが、サービス拒否メカニズムとして使用できるほどではありません。言い換えれば、受信者は次の構文を満たすリストを受け入れる必要があります。
#element => [ element ] *( OWS "," OWS [ element ] )
Note that because of the potential presence of empty list elements, the RFC 5234 ABNF cannot enforce the cardinality of list elements, and consequently all cases are mapped as if there was no cardinality specified.
空のリスト要素が存在する可能性があるため、RFC 5234 ABNFはリスト要素のカーディナリティを強制できないため、すべてのケースが指定されていないかのようにマッピングされていることに注意してください。
For example, given these ABNF productions:
たとえば、これらのABNFプロダクションを考えると、
example-list = 1#example-list-elmt
example-list-elmt = token ; see Section 5.6.2
Then the following are valid values for example-list (not including the double quotes, which are present for delimitation only):
次に、次の値は、たとえばリストの有効な値です（境界設定のみに存在する二重引用符は含まれません）：
"foo,bar" "foo ,bar," "foo , ,bar,charlie"
「foo、bar "" foo、bar "" foo、、bar、charlie "
In contrast, the following values would be invalid, since at least one non-empty element is required by the example-list production:
対照的に、少なくとも1つの非空白の要素がサンプルリストの生成で必要とされるため、次の値は無効になります。
"" "," ", ,"
"" "、"、 "
Tokens are short textual identifiers that do not include whitespace or delimiters.
トークンは、空白または区切り文字を含まない短いテキスト識別子です。
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
; any VCHAR, except delimiters
Many HTTP field values are defined using common syntax components, separated by whitespace or specific delimiting characters. Delimiters are chosen from the set of US-ASCII visual characters not allowed in a token (DQUOTE and "(),/:;<=>?@[\]{}").
多くのHTTPフィールド値は、Whitespaceまたは特定の区切り文字で区切られた一般的な構文コンポーネントを使用して定義されています。デリミターは、トークン（dquote and "（）、/:; <=>？@[\] {}"）で許可されていないus-asciiの視覚文字のセットから選択されます。
This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), and BWS ("bad" whitespace).
この仕様では、3つのルールを使用して、線形の白面の使用を示します：OWS（オプションの白面）、RWS（必要な白人）、およびBWS（ "Bad" Whitespace）。
The OWS rule is used where zero or more linear whitespace octets might appear. For protocol elements where optional whitespace is preferred to improve readability, a sender SHOULD generate the optional whitespace as a single SP; otherwise, a sender SHOULD NOT generate optional whitespace except as needed to overwrite invalid or unwanted protocol elements during in-place message filtering.
OWSルールは、ゼロ以上の線形の白色のオクテットが表示される場合に使用されます。オプションの両方が読みやすさを向上させるために優先されるプロトコル要素の場合、送信者はオプションのWhitespaceを単一のSPとして生成する必要があります。それ以外の場合、送信者は、インプレースメッセージフィルタリング中に無効なまたは不要なプロトコル要素を上書きするために必要な場合を除き、オプションの空白を生成してはなりません。
The RWS rule is used when at least one linear whitespace octet is required to separate field tokens. A sender SHOULD generate RWS as a single SP.
RWSルールは、フィールドトークンを分離するために少なくとも1つの線形の白面のオクテットが必要な場合に使用されます。送信者は、単一のspとしてRWを生成する必要があります。
OWS and RWS have the same semantics as a single SP. Any content known to be defined as OWS or RWS MAY be replaced with a single SP before interpreting it or forwarding the message downstream.
OWSおよびRWには、単一のspと同じセマンティクスがあります。OWSまたはRWSとして定義されることが知られているコンテンツは、それを解釈するか、下流のメッセージを転送する前に、単一のSPに置き換えることができます。
The BWS rule is used where the grammar allows optional whitespace only for historical reasons. A sender MUST NOT generate BWS in messages. A recipient MUST parse for such bad whitespace and remove it before interpreting the protocol element.
BWSルールは、文法が歴史的な理由でのみオプションの空白を許可する場合に使用されます。送信者は、メッセージでBWSを生成してはなりません。受信者は、プロトコル要素を解釈する前に、そのような悪い白面を解析し、それを削除する必要があります。
BWS has no semantics. Any content known to be defined as BWS MAY be removed before interpreting it or forwarding the message downstream.
BWSにはセマンティクスがありません。BWSとして定義されていることが知られているコンテンツは、それを解釈するか、メッセージを下流に転送する前に削除される場合があります。
OWS = *( SP / HTAB )
; optional whitespace
RWS = 1*( SP / HTAB )
; required whitespace
BWS = OWS
; "bad" whitespace
A string of text is parsed as a single value if it is quoted using double-quote marks.
一連のテキストは、二重引用マークを使用して引用されている場合、単一の値として解析されます。
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string and comment constructs. Recipients that process the value of a quoted-string MUST handle a quoted-pair as if it were replaced by the octet following the backslash.
Backslash Octet（ "\"）は、引用されたストリングおよびコメントコンストラクト内のシングルオクテット引用メカニズムとして使用できます。引用されたストリングの値を処理する受信者は、バックスラッシュに続いてオクテットに置き換えられたかのように、引用されたペアを処理する必要があります。
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
A sender SHOULD NOT generate a quoted-pair in a quoted-string except where necessary to quote DQUOTE and backslash octets occurring within that string. A sender SHOULD NOT generate a quoted-pair in a comment except where necessary to quote parentheses ["(" and ")"] and backslash octets occurring within that comment.
送信者は、その文字列内で発生するdquoteとバックスラッシュのオクテットを引用するために必要な場合を除き、引用されたストリングで引用されたペアを生成しないでください。送信者は、そのコメント内で発生している括弧[（ "and"） "]とバックスラッシュオクテットを引用するために必要な場合を除き、コメントで引用されたペアを生成しないでください。
Comments can be included in some HTTP fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition.
コメントは、括弧付きのコメントテキストを囲むことにより、一部のHTTPフィールドに含めることができます。コメントは、フィールド値定義の一部として「コメント」を含むフィールドでのみ許可されています。
comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
Parameters are instances of name/value pairs; they are often used in field values as a common syntax for appending auxiliary information to an item. Each parameter is usually delimited by an immediately preceding semicolon.
パラメーターは、名前/値ペアのインスタンスです。これらは、アイテムに補助情報を追加するための一般的な構文としてフィールド値でよく使用されます。通常、各パラメーターは、直前のセミコロンによって区切られています。
parameters = *( OWS ";" OWS [ parameter ] )
parameter = parameter-name "=" parameter-value
parameter-name = token
parameter-value = ( token / quoted-string )
Parameter names are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. Examples of parameters and some equivalent forms can be seen in media types (Section 8.3.1) and the Accept header field (Section 12.5.1).
パラメーター名はケース非感受性です。パラメーター値のセマンティクスに応じて、パラメーター値は症例に敏感でない場合があります。パラメーターといくつかの同等の形式の例は、メディアタイプ（セクション8.3.1）および受け入れヘッダーフィールド（セクション12.5.1）で見ることができます。
A parameter value that matches the token production can be transmitted either as a token or within a quoted-string. The quoted and unquoted values are equivalent.
トークンの生産に一致するパラメーター値は、トークンとして、または引用されたストリング内で送信できます。引用された値と引用されていない値は同等です。
| *Note:* Parameters do not allow whitespace (not even "bad" | whitespace) around the "=" character.
|*注：*パラメーターは、「=」文字の周りの空白（「悪い」| whitespaceさえありません）を許可しません。
Prior to 1995, there were three different formats commonly used by servers to communicate timestamps. For compatibility with old implementations, all three are defined here. The preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format [RFC5322].
1995年以前は、タイムスタンプを通信するためにサーバーが一般的に使用する3つの異なる形式がありました。古い実装との互換性については、3つすべてがここで定義されています。優先形式は、インターネットメッセージ形式[RFC5322]で使用される日付と時刻の仕様の固定長および単一ゾーンサブセットです。
HTTP-date = IMF-fixdate / obs-date
An example of the preferred format is
優先形式の例は次のとおりです
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
Examples of the two obsolete formats are
2つの時代遅れの形式の例はあります
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
A recipient that parses a timestamp value in an HTTP field MUST accept all three HTTP-date formats. When a sender generates a field that contains one or more timestamps defined as HTTP-date, the sender MUST generate those timestamps in the IMF-fixdate format.
HTTPフィールドのタイムスタンプ値を解析する受信者は、3つのHTTP-Date形式すべてを受け入れる必要があります。送信者がHTTP-Dateとして定義された1つ以上のタイムスタンプを含むフィールドを生成する場合、送信者はIMF-FixDate形式でそれらのタイムスタンプを生成する必要があります。
An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC). The first two formats indicate UTC by the three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor of the UTC name; values in the asctime format are assumed to be in UTC.
HTTP-Date値は、調整されたユニバーサル時間（UTC）のインスタンスとしての時間を表します。最初の2つの形式は、UTC名の前任者であるグリニッジ平均時間「GMT」の3文字の略語によるUTCを示しています。ASCTIME形式の値は、UTCにあると想定されています。
A "clock" is an implementation capable of providing a reasonable approximation of the current instant in UTC. A clock implementation ought to use NTP ([RFC5905]), or some similar protocol, to synchronize with UTC.
「クロック」とは、UTCの現在の瞬間の合理的な近似を提供できる実装です。クロック実装では、UTCと同期するには、NTP（[RFC5905]）または同様のプロトコルを使用する必要があります。
Preferred format:
優先形式：
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone/capitalization subset of the format
; see Section 3.3 of [RFC5322]
day-name = %s"Mon" / %s"Tue" / %s"Wed"
/ %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun"
date1 = day SP month SP year ; e.g., 02 Jun 1982
日付1 =デイスパ月の年。例：1982年6月2日
day = 2DIGIT
month = %s"Jan" / %s"Feb" / %s"Mar" / %s"Apr"
/ %s"May" / %s"Jun" / %s"Jul" / %s"Aug"
/ %s"Sep" / %s"Oct" / %s"Nov" / %s"Dec"
year = 4DIGIT
GMT = %s"GMT"
time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (leap second)
hour = 2DIGIT minute = 2DIGIT second = 2DIGIT
hour = 2 digit minute = 2桁second = 2桁
Obsolete formats:
時代遅れの形式：
obs-date = rfc850-date / asctime-date
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT date2 = day "-" month "-" 2DIGIT ; e.g., 02-Jun-82
rfc850-date = day-name-l "、" sp date2 sp sp gmt date2 = day " - " month " - " 2digit;たとえば、02-Jun-82
day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday"
/ %s"Thursday" / %s"Friday" / %s"Saturday"
/ %s"Sunday"
asctime-date = day-name SP date3 SP time-of-day SP year date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) ; e.g., Jun 2
asctime-date = day-name sp date3 sp日時間sp year date3 = month sp（2digit /（sp 1digit））;例：6月2日
HTTP-date is case sensitive. Note that Section 4.2 of [CACHING] relaxes this for cache recipients.
http-dateはケースに敏感です。[キャッシュ]のセクション4.2は、キャッシュ受信者のためにこれを緩和することに注意してください。
A sender MUST NOT generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar. The semantics of day-name, day, month, year, and time-of-day are the same as those defined for the Internet Message Format constructs with the corresponding name ([RFC5322], Section 3.3).
送信者は、文法のSPとして特別に含まれるものを超えて、HTTP-Dateで追加の空白を生成してはなりません。日名、日、月、年、および時刻のセマンティクスは、対応する名前（[RFC5322]、セクション3.3）を持つインターネットメッセージ形式のコンストラクトで定義されたものと同じです。
Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, MUST interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits.
2桁の年を使用するRFC850-Date形式のタイムスタンプ値の受信者は、将来50年以上になっているように見えるタイムスタンプを、過去の最近の年を表していると解釈する必要があります。。
Recipients of timestamp values are encouraged to be robust in parsing timestamps unless otherwise restricted by the field definition. For example, messages are occasionally forwarded over HTTP from a non-HTTP source that might generate any of the date and time specifications defined by the Internet Message Format.
タイムスタンプの値の受信者は、フィールドの定義に特に制限されていない限り、タイムスタンプを解析する際に堅牢であることが奨励されます。たとえば、メッセージは、インターネットメッセージ形式で定義された日付と時刻の仕様のいずれかを生成する可能性のある非HTTPソースからHTTPを介して転送されることがあります。
| *Note:* HTTP requirements for timestamp formats apply only to
| their usage within the protocol stream. Implementations are
| not required to use these formats for user presentation,
| request logging, etc.
Each major version of HTTP defines its own syntax for communicating messages. This section defines an abstract data type for HTTP messages based on a generalization of those message characteristics, common structure, and capacity for conveying semantics. This abstraction is used to define requirements on senders and recipients that are independent of the HTTP version, such that a message in one version can be relayed through other versions without changing its meaning.
HTTPの各メジャーバージョンは、メッセージを通信するための独自の構文を定義します。このセクションでは、これらのメッセージ特性の一般化、共通構造、およびセマンティクスを伝える能力に基づいて、HTTPメッセージの抽象データ型を定義します。この抽象化は、HTTPバージョンに依存しない送信者と受信者の要件を定義するために使用され、1つのバージョンのメッセージを他のバージョンでその意味を変えることなく中継することができます。
A "message" consists of the following:
「メッセージ」は次のもので構成されています。
* control data to describe and route the message,
* メッセージを記述およびルーティングするためのデータを制御し、
* a headers lookup table of name/value pairs for extending that control data and conveying additional information about the sender, message, content, or context,
* その制御データを拡張し、送信者、メッセージ、コンテンツ、またはコンテキストに関する追加情報を伝えるための名前/値のペアのヘッダールックアップテーブル
* a potentially unbounded stream of content, and
* コンテンツの潜在的に無制限のストリーム、および
* a trailers lookup table of name/value pairs for communicating information obtained while sending the content.
* コンテンツの送信中に取得した情報を通信するための名前/値のトレーラールックアップテーブル。
Framing and control data is sent first, followed by a header section containing fields for the headers table. When a message includes content, the content is sent after the header section, potentially followed by a trailer section that might contain fields for the trailers table.
フレーミングと制御データが最初に送信され、その後、ヘッダーテーブルのフィールドを含むヘッダーセクションが続きます。メッセージにコンテンツが含まれている場合、コンテンツはヘッダーセクションの後に送信され、その後にトレーラーテーブルのフィールドが含まれる可能性のあるトレーラーセクションが続く可能性があります。
Messages are expected to be processed as a stream, wherein the purpose of that stream and its continued processing is revealed while being read. Hence, control data describes what the recipient needs to know immediately, header fields describe what needs to be known before receiving content, the content (when present) presumably contains what the recipient wants or needs to fulfill the message semantics, and trailer fields provide optional metadata that was unknown prior to sending the content.
メッセージはストリームとして処理されると予想されます。これにより、そのストリームの目的とその継続的な処理が読み取り中に明らかになります。したがって、コントロールデータは受信者がすぐに知る必要があることを説明し、ヘッダーフィールドはコンテンツを受信する前に知る必要があるものを説明します。コンテンツを送信する前に不明だったメタデータ。
Messages are intended to be "self-descriptive": everything a recipient needs to know about the message can be determined by looking at the message itself, after decoding or reconstituting parts that have been compressed or elided in transit, without requiring an understanding of the sender's current application state (established via prior messages). However, a client MUST retain knowledge of the request when parsing, interpreting, or caching a corresponding response. For example, responses to the HEAD method look just like the beginning of a response to GET but cannot be parsed in the same manner.
メッセージは「自己記述的」であることを目的としています。受信者は、メッセージ自体を見ることで、メッセージ自体を見ることで、輸送中に圧縮または排除された部分を解読または再構成した後、メッセージ自体を見ることで、メッセージ自体を見ることで決定できるすべてのものを意図しています。送信者の現在のアプリケーション状態（以前のメッセージを介して確立）。ただし、クライアントは、対応する応答を解析、解釈、またはキャッシュするときに、リクエストの知識を保持する必要があります。たとえば、ヘッドメソッドへの応答は、取得への応答の始まりのように見えますが、同じ方法で解析することはできません。
Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some versions. For example, trailers were introduced within the HTTP/1.1 chunked transfer coding as a trailer section after the content. An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream.
このメッセージの抽象化は、一部のバージョンにはない機能を含む、HTTPの多くのバージョンにわたる一般化であることに注意してください。たとえば、トレーラーは、コンテンツ後にトレーラーセクションとしてHTTP/1.1チャンク転送コーディング内に導入されました。同等の機能は、各ストリームを終了するヘッダーブロック内のHTTP/2およびHTTP/3に存在します。
Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection. Each major version of HTTP defines its own framing mechanism.
メッセージフレーミングは、各メッセージがどのように始まるかを示し、各メッセージを同じ接続の他のメッセージまたはノイズと区別できるようにします。HTTPの各メジャーバージョンは、独自のフレーミングメカニズムを定義します。
HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end a response. For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early. For that reason, almost all modern implementations use explicit framing in the form of length-delimited sequences of message data.
HTTP/0.9およびHTTP/1.0の早期展開は、応答を終了するために基礎となる接続の閉鎖を使用しました。後方互換性のために、この暗黙のフレーミングはHTTP/1.1でも許可されています。ただし、暗黙のフレーミングは、接続が早期に閉じると不完全な応答を区別できない場合があります。そのため、ほとんどすべての最新の実装では、メッセージデータの長さの識別されたシーケンスの形で明示的なフレーミングを使用します。
A message is considered "complete" when all of the octets indicated by its framing are available. Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete.
メッセージは、そのフレーミングで示されるすべてのオクテットが利用可能である場合、「完全」と見なされます。明示的なフレーミングが使用されない場合、輸送レベルのエラーが完全でないことを示していない限り、不完全な応答と区別できない場合でも、基礎となる接続のクローズによって終了する応答メッセージは完全であると見なされます。
Messages start with control data that describe its primary purpose. Request message control data includes a request method (Section 9), request target (Section 7.1), and protocol version (Section 2.5). Response message control data includes a status code (Section 15), optional reason phrase, and protocol version.
メッセージは、その主な目的を説明する制御データから始まります。要求メッセージ制御データには、要求方法（セクション9）、要求ターゲット（セクション7.1）、およびプロトコルバージョン（セクション2.5）が含まれます。応答メッセージ制御データには、ステータスコード（セクション15）、オプションの理由フレーズ、およびプロトコルバージョンが含まれます。
In HTTP/1.1 ([HTTP/1.1]) and earlier, control data is sent as the first line of a message. In HTTP/2 ([HTTP/2]) and HTTP/3 ([HTTP/3]), control data is sent as pseudo-header fields with a reserved name prefix (e.g., ":authority").
HTTP/1.1（[http/1.1]）および以前に、コントロールデータがメッセージの最初の行として送信されます。http/2（[http/2]）およびhttp/3（[http/3]）で、コントロールデータは、予約済みの名前のプレフィックス（ "：authority"）を持つ擬似ヘッダーフィールドとして送信されます。
Every HTTP message has a protocol version. Depending on the version in use, it might be identified within the message explicitly or inferred by the connection over which the message is received. Recipients use that version information to determine limitations or potential for later communication with that sender.
すべてのHTTPメッセージにはプロトコルバージョンがあります。使用中のバージョンに応じて、メッセージが明示的に識別されるか、メッセージが受信される接続によって推測される場合があります。受信者は、そのバージョン情報を使用して、その送信者との後のコミュニケーションの制限または可能性を決定します。
When a message is forwarded by an intermediary, the protocol version is updated to reflect the version used by that intermediary. The Via header field (Section 7.6.3) is used to communicate upstream protocol information within a forwarded message.
メッセージが仲介者によって転送されると、プロトコルバージョンが更新され、その仲介者が使用するバージョンが反映されます。Via Headerフィールド（セクション7.6.3）は、転送されたメッセージ内で上流のプロトコル情報を通信するために使用されます。
A client SHOULD send a request version equal to the highest version to which the client is conformant and whose major version is no higher than the highest version supported by the server, if this is known. A client MUST NOT send a version to which it is not conformant.
クライアントは、クライアントがコンフォーマルであり、そのメジャーバージョンがサーバーでサポートされている最高バージョンよりも高くない最高バージョンに等しいリクエストバージョンを送信する必要があります。クライアントは、コンフォーマルでないバージョンを送信してはなりません。
A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions.
サーバーがHTTP仕様を誤って実装していることがわかっている場合、クライアントは、クライアントが少なくとも1つの通常の要求を試みた後にのみ、より低い要求バージョンを送信できます。サーバーは、より高い要求バージョンを不適切に処理します。
A server SHOULD send a response version equal to the highest version to which the server is conformant that has a major version less than or equal to the one received in the request. A server MUST NOT send a version to which it is not conformant. A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version.
サーバーは、リクエストで受信したものよりも少ないメジャーバージョンを持つサーバーがコンフォーマントである最高バージョンに等しい応答バージョンを送信する必要があります。サーバーは、コンフォーマルでないバージョンを送信してはなりません。サーバーは、何らかの理由でクライアントの主要なプロトコルバージョンのサービスを拒否することを望む場合、505（サポートされていない）応答を送信できます。
A recipient that receives a message with a major version number that it implements and a minor version number higher than what it implements SHOULD process the message as if it were in the highest minor version within that major version to which the recipient is conformant. A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version.
実装するメジャーバージョン番号と、実装するものよりも高いマイナーバージョン番号でメッセージを受信する受信者は、受信者が適合しているメジャーバージョン内の最高マイナーバージョンのようにメッセージを処理する必要があります。受信者は、より高いバージョンのサポートをまだ示していない受信者に送信された場合、より高いマイナーバージョンのメッセージが、同じメジャーバージョンの実装によって安全に処理されるのに十分な後方互換性があると想定できます。
Fields (Section 5) that are sent or received before the content are referred to as "header fields" (or just "headers", colloquially).
コンテンツの前に送信または受信されるフィールド（セクション5）は、「ヘッダーフィールド」（または単に「ヘッダー」）と呼ばれます。
The "header section" of a message consists of a sequence of header field lines. Each header field might modify or extend message semantics, describe the sender, define the content, or provide additional context.
メッセージの「ヘッダーセクション」は、ヘッダーフィールドラインのシーケンスで構成されています。各ヘッダーフィールドは、メッセージセマンティクスを変更または拡張したり、送信者を説明したり、コンテンツを定義したり、追加のコンテキストを提供したりする場合があります。
| *Note:* We refer to named fields specifically as a "header
| field" when they are only allowed to be sent in the header
| section.
HTTP messages often transfer a complete or partial representation as the message "content": a stream of octets sent after the header section, as delineated by the message framing.
HTTPメッセージは、メッセージ「コンテンツ」：ヘッダーセクションの後に送信されたオクテットのストリームとして、完全または部分表現をメッセージフレーミングで描写するように、多くの場合、完全または部分表現を転送します。
This abstract definition of content reflects the data after it has been extracted from the message framing. For example, an HTTP/1.1 message body (Section 6 of [HTTP/1.1]) might consist of a stream of data encoded with the chunked transfer coding -- a sequence of data chunks, one zero-length chunk, and a trailer section -- whereas the content of that same message includes only the data stream after the transfer coding has been decoded; it does not include the chunk lengths, chunked framing syntax, nor the trailer fields (Section 6.5).
コンテンツのこの抽象的な定義は、メッセージフレーミングから抽出された後のデータを反映しています。たとえば、HTTP/1.1メッセージ本文（[http/1.1]のセクション6）は、チャンク転送コーディングでエンコードされたデータのストリーム（データチャンクのシーケンス、1つのゼロ長チャンク、トレーラーセクション）で構成される場合があります。 - 一方、同じメッセージの内容には、転送コーディングがデコードされた後のデータストリームのみが含まれます。チャンクの長さ、チャンクフレーミング構文、トレーラーフィールドは含まれません（セクション6.5）。
| *Note:* Some field names have a "Content-" prefix. This is an
| informal convention; while some of these fields refer to the
| content of the message, as defined above, others are scoped to
| the selected representation (Section 3.2). See the individual
| field's definition to disambiguate.
The purpose of content in a request is defined by the method semantics (Section 9).
リクエスト内のコンテンツの目的は、メソッドセマンティクス（セクション9）で定義されます。
For example, a representation in the content of a PUT request (Section 9.3.4) represents the desired state of the target resource after the request is successfully applied, whereas a representation in the content of a POST request (Section 9.3.3) represents information to be processed by the target resource.
たとえば、プット要求の内容（セクション9.3.4）の表現は、リクエストが正常に適用された後、ターゲットリソースの目的の状態を表しますが、POSTリクエストの内容（セクション9.3.3）の表現は表現します。ターゲットリソースによって処理される情報。
In a response, the content's purpose is defined by the request method, response status code (Section 15), and response fields describing that content. For example, the content of a 200 (OK) response to GET (Section 9.3.1) represents the current state of the target resource, as observed at the time of the message origination date (Section 6.6.1), whereas the content of the same status code in a response to POST might represent either the processing result or the new state of the target resource after applying the processing.
応答では、コンテンツの目的は、要求方法、応答ステータスコード（セクション15）、およびそのコンテンツを記述する応答フィールドによって定義されます。たとえば、get（セクション9.3.1）への200（OK）応答の内容は、メッセージの出発日（セクション6.6.1）の時点で観察されるように、ターゲットリソースの現在の状態を表します。POSTへの応答の同じステータスコードは、処理結果または処理を適用した後のターゲットリソースの新しい状態のいずれかを表す場合があります。
The content of a 206 (Partial Content) response to GET contains either a single part of the selected representation or a multipart message body containing multiple parts of that representation, as described in Section 15.3.7.
取得するための206（部分コンテンツ）応答の内容には、セクション15.3.7で説明されているように、選択した表現の単一部分またはその表現の複数の部分を含むマルチパートメッセージ本文が含まれています。
Response messages with an error status code usually contain content that represents the error condition, such that the content describes the error state and what steps are suggested for resolving it.
エラーステータスコードを持つ応答メッセージには、通常、エラー条件を表すコンテンツが含まれているため、コンテンツがエラー状態とそれを解決するために提案されている手順を記述します。
Responses to the HEAD request method (Section 9.3.2) never include content; the associated response header fields indicate only what their values would have been if the request method had been GET (Section 9.3.1).
ヘッドリクエスト方法（セクション9.3.2）への応答には、コンテンツが含まれません。関連する応答ヘッダーフィールドは、要求方法が取得された場合の値のみを示しています（セクション9.3.1）。
2xx (Successful) responses to a CONNECT request method (Section 9.3.6) switch the connection to tunnel mode instead of having content.
接続要求方法に対する2xx（成功）応答（セクション9.3.6）は、コンテンツを持つ代わりにトンネルモードに接続を切り替えます。
All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses do not include content.
すべての1XX（情報）、204（コンテンツなし）、および304（変更されていない）応答には、コンテンツは含まれていません。
All other responses do include content, although that content might be of zero length.
他のすべての応答にはコンテンツが含まれていますが、そのコンテンツの長さはゼロかもしれません。
When a complete or partial representation is transferred as message content, it is often desirable for the sender to supply, or the recipient to determine, an identifier for a resource corresponding to that specific representation. For example, a client making a GET request on a resource for "the current weather report" might want an identifier specific to the content returned (e.g., "weather report for Laguna Beach at 20210720T1711"). This can be useful for sharing or bookmarking content from resources that are expected to have changing representations over time.
完全または部分表現がメッセージコンテンツとして転送される場合、その特定の表現に対応するリソースの識別子である送信者が供給するか、受信者が決定することが望ましいことがよくあります。たとえば、「現在の気象報告書」のリソースをGETリクエストするクライアントは、返されるコンテンツに固有の識別子を必要とする場合があります（たとえば、「20210720T1711のLaguna Beachの気象レポート」）。これは、時間の経過とともに変化する表現があると予想されるリソースからコンテンツを共有またはブックマークするのに役立ちます。
For a request message:
リクエストメッセージの場合：
* If the request has a Content-Location header field, then the sender asserts that the content is a representation of the resource identified by the Content-Location field value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by this specification). The information might still be useful for revision history links.
* リクエストにコンテンツロケーションヘッダーフィールドがある場合、送信者はコンテンツがコンテンツロケーションフィールド値によって識別されるリソースの表現であると主張します。ただし、そのようなアサーションは、他の手段で検証できない限り、信頼できません（この仕様では定義されていません）。情報は、改訂履歴リンクに依然として役立つ可能性があります。
* Otherwise, the content is unidentified by HTTP, but a more specific identifier might be supplied within the content itself.
* それ以外の場合、コンテンツはHTTPによって固定されていませんが、コンテンツ自体内でより具体的な識別子が提供される場合があります。
For a response message, the following rules are applied in order until a match is found:
応答メッセージの場合、一致が見つかるまで次のルールが順番に適用されます。
1. If the request method is HEAD or the response status code is 204 (No Content) or 304 (Not Modified), there is no content in the response.
1. 要求方法がヘッドであるか、応答ステータスコードが204（コンテンツなし）または304（変更されていない）の場合、応答にコンテンツはありません。
2. If the request method is GET and the response status code is 200 (OK), the content is a representation of the target resource (Section 7.1).
2. 要求方法が取得され、応答ステータスコードが200（OK）の場合、コンテンツはターゲットリソースの表現です（セクション7.1）。
3. If the request method is GET and the response status code is 203 (Non-Authoritative Information), the content is a potentially modified or enhanced representation of the target resource as provided by an intermediary.
3. リクエストメソッドが取得され、応答ステータスコードが203の場合（非承認情報）、コンテンツは、中間によって提供されるターゲットリソースの潜在的に変更または強化された表現です。
4. If the request method is GET and the response status code is 206 (Partial Content), the content is one or more parts of a representation of the target resource.
4. リクエストメソッドが取得され、応答ステータスコードが206（部分コンテンツ）の場合、コンテンツはターゲットリソースの表現の1つ以上の部分です。
5. If the response has a Content-Location header field and its field value is a reference to the same URI as the target URI, the content is a representation of the target resource.
5. 応答にコンテンツロケーションヘッダーフィールドがあり、そのフィールド値がターゲットURIと同じURIへの参照である場合、コンテンツはターゲットリソースの表現です。
6. If the response has a Content-Location header field and its field value is a reference to a URI different from the target URI, then the sender asserts that the content is a representation of the resource identified by the Content-Location field value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by this specification).
6. 応答にコンテンツロケーションヘッダーフィールドがあり、そのフィールド値がターゲットURIとは異なるURIへの参照である場合、送信者はコンテンツがコンテンツロケーションフィールド値によって識別されるリソースの表現であると主張します。ただし、そのようなアサーションは、他の手段で検証できない限り、信頼できません（この仕様では定義されていません）。
7. Otherwise, the content is unidentified by HTTP, but a more specific identifier might be supplied within the content itself.
7. それ以外の場合、コンテンツはHTTPによって固定されていませんが、コンテンツ自体内でより具体的な識別子が提供される場合があります。
Fields (Section 5) that are located within a "trailer section" are referred to as "trailer fields" (or just "trailers", colloquially). Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post-processing status information.
「トレーラーセクション」内にあるフィールド（セクション5）は、「トレーラーフィールド」（または単に「トレーラー」）と呼ばれます。トレーラーフィールドは、メッセージの整合性チェック、デジタル署名、配信メトリック、または後処理ステータス情報の提供に役立ちます。
Trailer fields ought to be processed and stored separately from the fields in the header section to avoid contradicting message semantics known at the time the header section was complete. The presence or absence of certain header fields might impact choices made for the routing or processing of the message as a whole before the trailers are received; those choices cannot be unmade by the later discovery of trailer fields.
トレーラーフィールドは、ヘッダーセクションのヘッダーセクションのフィールドとは別に処理および保存される必要があります。特定のヘッダーフィールドの有無は、トレーラーを受信する前に、メッセージ全体のルーティングまたは処理のために行われた選択に影響を与える可能性があります。これらの選択は、後のトレーラーフィールドの発見によって手に入らないことはできません。
A trailer section is only possible when supported by the version of HTTP in use and enabled by an explicit framing mechanism. For example, the chunked transfer coding in HTTP/1.1 allows a trailer section to be sent after the content (Section 7.1.2 of [HTTP/1.1]).
トレーラーセクションは、使用中のHTTPのバージョンによってサポートされ、明示的なフレーミングメカニズムによって有効になった場合にのみ可能です。たとえば、HTTP/1.1のチャンク転送コーディングにより、コンテンツの後にトレーラーセクションを送信できます（[HTTP/1.1]のセクション7.1.2）。
Many fields cannot be processed outside the header section because their evaluation is necessary prior to receiving the content, such as those that describe message framing, routing, authentication, request modifiers, response controls, or content format. A sender MUST NOT generate a trailer field unless the sender knows the corresponding header field name's definition permits the field to be sent in trailers.
メッセージのフレーミング、ルーティング、認証、要求修飾子、応答コントロール、コンテンツ形式など、コンテンツを受信する前に評価が必要であるため、ヘッダーセクションの外側で多くのフィールドを処理できません。送信者は、対応するヘッダーフィールド名の定義がトレーラーで送信されることを許可していることを送信者が知っていない限り、トレーラーフィールドを生成してはなりません。
Trailer fields can be difficult to process by intermediaries that forward messages from one protocol version to another. If the entire message can be buffered in transit, some intermediaries could merge trailer fields into the header section (as appropriate) before it is forwarded. However, in most cases, the trailers are simply discarded. A recipient MUST NOT merge a trailer field into a header section unless the recipient understands the corresponding header field definition and that definition explicitly permits and defines how trailer field values can be safely merged.
トレーラーフィールドは、あるプロトコルバージョンから別のプロトコルバージョンにメッセージを転送する仲介者が処理するのが難しい場合があります。メッセージ全体を輸送中にバッファリングできる場合、一部の仲介者は、転送される前にトレーラーフィールドをヘッダーセクション（必要に応じて）にマージできます。ただし、ほとんどの場合、トレーラーは単に破棄されます。受信者が対応するヘッダーフィールドの定義を理解し、その定義がトレーラーフィールド値を安全に統合する方法を明示的に許可および定義しない限り、トレーラーフィールドをヘッダーセクションにマージしてはなりません。
The presence of the keyword "trailers" in the TE header field (Section 10.1.4) of a request indicates that the client is willing to accept trailer fields, on behalf of itself and any downstream clients. For requests from an intermediary, this implies that all downstream clients are willing to accept trailer fields in the forwarded response. Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the trailer section(s) will not be dropped by any of the clients.
リクエストのTEヘッダーフィールド（セクション10.1.4）にキーワード「トレーラー」が存在することは、クライアントがそれ自体とダウンストリームクライアントに代わってトレーラーフィールドを受け入れることをいとわないことを示しています。仲介者からのリクエストの場合、これは、すべての下流のクライアントが転送された応答でトレーラーフィールドを受け入れることをいとわないことを意味します。「トレーラー」の存在は、クライアントが応答で特定のトレーラーフィールドを処理することを意味しないことに注意してください。トレーラーセクションは、クライアントのいずれによってもドロップされないことだけです。
Because of the potential for trailer fields to be discarded in transit, a server SHOULD NOT generate trailer fields that it believes are necessary for the user agent to receive.
トレーラーフィールドが輸送中に破棄される可能性があるため、サーバーはユーザーエージェントが受信する必要があると考えているトレーラーフィールドを生成してはなりません。
The "Trailer" header field (Section 6.6.2) can be sent to indicate fields likely to be sent in the trailer section, which allows recipients to prepare for their receipt before processing the content. For example, this could be useful if a field name indicates that a dynamic checksum should be calculated as the content is received and then immediately checked upon receipt of the trailer field value.
「トレーラー」ヘッダーフィールド（セクション6.6.2）は、トレーラーセクションに送信される可能性が高いフィールドを示すために送信できます。これにより、受信者はコンテンツを処理する前に領収書の準備ができます。たとえば、これは、コンテンツが受信されたときに動的チェックサムを計算し、トレーラーフィールド値を受信するとすぐにチェックされることをフィールド名が示す場合に役立ちます。
Like header fields, trailer fields with the same name are processed in the order received; multiple trailer field lines with the same name have the equivalent semantics as appending the multiple values as a list of members. Trailer fields that might be generated more than once during a message MUST be defined as a list-based field even if each member value is only processed once per field line received.
ヘッダーフィールドと同様に、同じ名前のトレーラーフィールドは受信した順序で処理されます。同じ名前の複数のトレーラーフィールドラインには、複数の値をメンバーのリストとして追加すると同等のセマンティクスがあります。メッセージ中に複数回生成される可能性のあるトレーラーフィールドは、各メンバーの値が受信したフィールドラインごとに1回のみ処理された場合でも、リストベースのフィールドとして定義する必要があります。
At the end of a message, a recipient MAY treat the set of received trailer fields as a data structure of name/value pairs, similar to (but separate from) the header fields. Additional processing expectations, if any, can be defined within the field specification for a field intended for use in trailers.
メッセージの最後に、受信者は、受信したトレーラーフィールドのセットを、ヘッダーフィールドと同様の（ただし、別の）名前/値ペアのデータ構造として扱うことができます。トレーラーで使用することを目的としたフィールドのフィールド仕様内で、追加の処理期待を定義できます。
Fields that describe the message itself, such as when and how the message has been generated, can appear in both requests and responses.
メッセージ自体を説明するフィールドは、メッセージ自体がいつ、どのように生成されたかなど、リクエストと応答の両方に表示されます。
The "Date" header field represents the date and time at which the message was originated, having the same semantics as the Origination Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as defined in Section 5.6.7.
「日付」ヘッダーフィールドは、[RFC5322]のセクション3.6.1で定義されているオリジネーション日付フィールド（Orig-date）と同じセマンティクスを持つ、メッセージが発信された日付と時刻を表します。セクション5.6.7で定義されているように、フィールド値はHTTP-DATEです。
Date = HTTP-date
An example is
例は次のとおりです
Date: Tue, 15 Nov 1994 08:12:31 GMT
A sender that generates a Date header field SHOULD generate its field value as the best available approximation of the date and time of message generation. In theory, the date ought to represent the moment just before generating the message content. In practice, a sender can generate the date value at any time during message origination.
日付ヘッダーフィールドを生成する送信者は、メッセージ生成の日付と時刻の最良の近似値としてフィールド値を生成する必要があります。理論的には、日付はメッセージコンテンツを生成する直前の瞬間を表す必要があります。実際には、送信者はメッセージの起源中にいつでも日付値を生成できます。
An origin server with a clock (as defined in Section 5.6.7) MUST generate a Date header field in all 2xx (Successful), 3xx (Redirection), and 4xx (Client Error) responses, and MAY generate a Date header field in 1xx (Informational) and 5xx (Server Error) responses.
クロックを備えたオリジンサーバー（セクション5.6.7で定義）は、すべての2XX（成功）、3XX（リダイレクト）、および4XX（クライアントエラー）応答で日付ヘッダーフィールドを生成する必要があり、1XXで日付ヘッダーフィールドを生成する場合があります。（情報）および5xx（サーバーエラー）応答。
An origin server without a clock MUST NOT generate a Date header field.
クロックのないオリジンサーバーは、日付ヘッダーフィールドを生成してはなりません。
A recipient with a clock that receives a response message without a Date header field MUST record the time it was received and append a corresponding Date header field to the message's header section if it is cached or forwarded downstream.
日付ヘッダーフィールドなしで応答メッセージを受信するクロックを持つ受信者は、受信した時間を記録し、下流にキャッシュまたは転送された場合、メッセージのヘッダーセクションに対応する日付ヘッダーフィールドを追加する必要があります。
A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received.
無効な日付ヘッダーフィールド値で応答を受信するクロックを持つ受信者は、その値を応答の受信時間に置き換える場合があります。
A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server. For example, custom applications of HTTP might convey a Date if the server is expected to adjust its interpretation of the user's request based on differences between the user agent and server clocks.
ユーザーエージェントは、リクエストで日付ヘッダーフィールドを送信する場合がありますが、通常、有用な情報をサーバーに伝えるとは思わない限り、デートヘッダーフィールドを送信できません。たとえば、HTTPのカスタムアプリケーションは、ユーザーエージェントとサーバークロックの違いに基づいてユーザーの要求の解釈を調整するとサーバーが予想される場合、日付を伝える場合があります。
The "Trailer" header field provides a list of field names that the sender anticipates sending as trailer fields within that message. This allows a recipient to prepare for receipt of the indicated metadata before it starts processing the content.
「トレーラー」ヘッダーフィールドは、送信者がそのメッセージ内のトレーラーフィールドとして送信すると予想するフィールド名のリストを提供します。これにより、受信者は、コンテンツの処理を開始する前に、指定されたメタデータを受信する準備ができます。
Trailer = #field-name
For example, a sender might indicate that a signature will be computed as the content is being streamed and provide the final signature as a trailer field. This allows a recipient to perform the same check on the fly as it receives the content.
たとえば、送信者は、コンテンツがストリーミングされているときに署名が計算され、トレーラーフィールドとして最終的な署名を提供することを示す場合があります。これにより、受信者はコンテンツを受け取るときと同じチェックをその場で実行できます。
A sender that intends to generate one or more trailer fields in a message SHOULD generate a Trailer header field in the header section of that message to indicate which fields might be present in the trailers.
メッセージ内で1つ以上のトレーラーフィールドを生成する予定の送信者は、そのメッセージのヘッダーセクションにトレーラーヘッダーフィールドを生成して、トレーラーにどのフィールドが存在するかを示す必要があります。
If an intermediary discards the trailer section in transit, the Trailer field could provide a hint of what metadata was lost, though there is no guarantee that a sender of Trailer will always follow through by sending the named fields.
仲介者がトレーラーセクションを輸送中に廃棄する場合、トレーラーフィールドはメタデータが失われたもののヒントを提供できますが、予告編の送信者が常に指名されたフィールドを送信することで常に続くという保証はありません。
HTTP request message routing is determined by each client based on the target resource, the client's proxy configuration, and establishment or reuse of an inbound connection. The corresponding response routing follows the same connection chain back to the client.
HTTP要求メッセージルーティングは、ターゲットリソース、クライアントのプロキシ構成、およびインバウンド接続の確立または再利用に基づいて、各クライアントによって決定されます。対応する応答ルーティングは、同じ接続チェーンをクライアントに戻します。
Although HTTP is used in a wide variety of applications, most clients rely on the same resource identification mechanism and configuration techniques as general-purpose Web browsers. Even when communication options are hard-coded in a client's configuration, we can think of their combined effect as a URI reference (Section 4.1).
HTTPはさまざまなアプリケーションで使用されていますが、ほとんどのクライアントは、汎用Webブラウザーと同じリソース識別メカニズムと構成手法に依存しています。クライアントの構成で通信オプションがハードコーディングされている場合でも、それらの組み合わせ効果をURI参照と考えることができます（セクション4.1）。
A URI reference is resolved to its absolute form in order to obtain the "target URI". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side processing ([URI], Section 3.5).
URI参照は、「ターゲットURI」を取得するために、その絶対形式に解決されます。ターゲットURIは、クライアント側の処理（[URI]、セクション3.5）のためにフラグメント識別子が予約されているため、参照のフラグメントコンポーネントを除外します。
To perform an action on a "target resource", the client sends a request message containing enough components of its parsed target URI to enable recipients to identify that same resource. For historical reasons, the parsed target URI components, collectively referred to as the "request target", are sent within the message control data and the Host header field (Section 7.2).
「ターゲットリソース」でアクションを実行するために、クライアントは、受信者が同じリソースを識別できるように、解析されたターゲットURIの十分なコンポーネントを含む要求メッセージを送信します。歴史的な理由から、「要求ターゲット」と総称される解析されたターゲットURIコンポーネントは、メッセージ制御データとホストヘッダーフィールド内で送信されます（セクション7.2）。
There are two unusual cases for which the request target components are in a method-specific form:
リクエストターゲットコンポーネントがメソッド固有の形式である2つの異常なケースがあります。
* For CONNECT (Section 9.3.6), the request target is the host name and port number of the tunnel destination, separated by a colon.
* Connect（セクション9.3.6）の場合、リクエストターゲットは、コロンで区切られたトンネル宛先のホスト名とポート番号です。
* For OPTIONS (Section 9.3.7), the request target can be a single asterisk ("*").
* オプション（セクション9.3.7）の場合、リクエストターゲットは単一のアスタリスク（ "*"）にすることができます。
See the respective method definitions for details. These forms MUST NOT be used with other methods.
詳細については、それぞれのメソッド定義を参照してください。これらのフォームは、他の方法で使用してはなりません。
Upon receipt of a client's request, a server reconstructs the target URI from the received components in accordance with their local configuration and incoming connection context. This reconstruction is specific to each major protocol version. For example, Section 3.3 of [HTTP/1.1] defines how a server determines the target URI of an HTTP/1.1 request.
クライアントの要求を受け取ると、サーバーは、ローカル構成と着信接続コンテキストに従って、受信コンポーネントからターゲットURIを再構築します。この再構成は、各主要なプロトコルバージョンに固有です。たとえば、[HTTP/1.1]のセクション3.3は、サーバーがHTTP/1.1要求のターゲットURIを決定する方法を定義しています。
| *Note:* Previous specifications defined the recomposed target | URI as a distinct concept, the "effective request URI".
|*注：*再構成されたターゲットを定義した以前の仕様|明確な概念としてのURI、「効果的な要求URI」。
The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple host names.
リクエストの「ホスト」ヘッダーフィールドは、ターゲットURIからホストとポート情報を提供し、Origin Serverが複数のホスト名のリクエストをサービスしながらリソースを区別できるようにします。
In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in some cases, supplanted by the ":authority" pseudo-header field of a request's control data.
HTTP/2 [HTTP/2]およびHTTP/3 [HTTP/3]では、ホストヘッダーフィールドは、場合によっては、リクエストの制御データの「権限」疑似ヘッダーフィールドに取って代わられます。
Host = uri-host [ ":" port ] ; Section 4
The target URI's authority information is critical for handling a request. A user agent MUST generate a Host header field in a request unless it sends that information as an ":authority" pseudo-header field. A user agent that sends Host SHOULD send it as the first field in the header section of a request.
ターゲットURIの権限情報は、リクエストを処理するために重要です。ユーザーエージェントは、その情報を「：権限」疑似ヘッダーフィールドとして送信しない限り、リクエストでホストヘッダーフィールドを生成する必要があります。ホストを送信するユーザーエージェントは、リクエストのヘッダーセクションの最初のフィールドとして送信する必要があります。
For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:
たとえば、<http://www.example.org/pub/www/> <http://www.example.orgのOrigin Serverへの取得リクエストは以下で始まります。
GET /pub/WWW/ HTTP/1.1
Host: www.example.org
Since the host and port information acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the host and port information for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.
ホストおよびポート情報はアプリケーションレベルのルーティングメカニズムとして機能するため、共有キャッシュを毒するか、意図しないサーバーにリクエストをリダイレクトしようとするマルウェアの頻繁なターゲットです。インターセプトプロキシは、内部サーバーへのリクエストをリダイレクトするためにホストとポート情報に依存している場合、または共有キャッシュのキャッシュキーとして使用するために特に脆弱です。。
Once the target URI and its origin are determined, a client decides whether a network request is necessary to accomplish the desired semantics and, if so, where that request is to be directed.
ターゲットURIとその起源が決定されると、クライアントは、希望するセマンティクスを達成するためにネットワーク要求が必要かどうかを決定します。
If the client has a cache [CACHING] and the request can be satisfied by it, then the request is usually directed there first.
クライアントにキャッシュ[キャッシュ]があり、リクエストがそれによって満たされる可能性がある場合、通常、リクエストは最初にそこに向けられます。
If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy is to be used to satisfy the request. Proxy configuration is implementation-dependent, but is often based on URI prefix matching, selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI.
要求がキャッシュによって満たされていない場合、一般的なクライアントはその構成をチェックして、プロキシを使用してリクエストを満たすかどうかを判断します。プロキシ構成は実装依存ですが、多くの場合、URIプレフィックスマッチング、選択的権限マッチング、またはその両方に基づいており、プロキシ自体は通常「HTTP」または「HTTPS」URIによって識別されます。
If an "http" or "https" proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy and then sending it an HTTP request message containing a request target that matches the client's target URI.
「HTTP」または「HTTPS」プロキシが適用される場合、クライアントはそのプロキシへの接続を確立（または再利用する）ことにより、クライアントのターゲットURIに一致するリクエストターゲットを含むHTTP要求メッセージを送信することにより、インバウンドを接続します。
If no proxy is applicable, a typical client will invoke a handler routine (specific to the target URI's scheme) to obtain access to the identified resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification.
プロキシが適用されない場合、典型的なクライアントは、識別されたリソースへのアクセスを取得するために、ハンドラールーチン（ターゲットURIのスキームに固有）を呼び出します。それがどのように達成されるかは、ターゲットURIスキームに依存し、関連する仕様によって定義されます。
Section 4.3.2 defines how to obtain access to an "http" resource by establishing (or reusing) an inbound connection to the identified origin server and then sending it an HTTP request message containing a request target that matches the client's target URI.
セクション4.3.2は、識別されたOriginサーバーへのインバウンド接続を確立（または再利用する）し、クライアントのターゲットURIに一致するリクエストターゲットを含むHTTP要求メッセージを送信することにより、「HTTP」リソースへのアクセスを取得する方法を定義します。
Section 4.3.3 defines how to obtain access to an "https" resource by establishing (or reusing) an inbound secured connection to an origin server that is authoritative for the identified origin and then sending it an HTTP request message containing a request target that matches the client's target URI.
セクション4.3.3は、識別されたオリジンに対して権威あるオリジンサーバーへのインバウンドセキュリティ接続を確立（または再利用する）ことにより、「HTTPS」リソースへのアクセスを取得する方法を定義し、一致するリクエストターゲットを含むHTTPリクエストメッセージを送信するクライアントのターゲットURI。
Once a request is received by a server and parsed sufficiently to determine its target URI, the server decides whether to process the request itself, forward the request to another server, redirect the client to a different resource, respond with an error, or drop the connection. This decision can be influenced by anything about the request or connection context, but is specifically directed at whether the server has been configured to process requests for that target URI and whether the connection context is appropriate for that request.
リクエストがサーバーによって受信され、ターゲットURIを決定するのに十分に解析されたら、サーバーは要求自体を処理するか、リクエストを別のサーバーに転送するか、クライアントを別のリソースにリダイレクトするか、エラーで応答するか、ドロップするかどうかを決定します。繋がり。この決定は、要求または接続のコンテキストに関するあらゆるものに影響を受ける可能性がありますが、サーバーがそのターゲットURIのリクエストを処理するように構成されているかどうか、および接続コンテキストがその要求に適しているかどうかに特に向けられています。
For example, a request might have been misdirected, deliberately or accidentally, such that the information within a received Host header field differs from the connection's host or port. If the connection is from a trusted gateway, such inconsistency might be expected; otherwise, it might indicate an attempt to bypass security filters, trick the server into delivering non-public content, or poison a cache. See Section 17 for security considerations regarding message routing.
たとえば、リクエストは、故意に誤ってまたは偶然に誤った方向に向けられていたため、受信したホストヘッダーフィールド内の情報は接続のホストまたはポートとは異なります。接続が信頼できるゲートウェイからのものである場合、そのような矛盾が予想される場合があります。それ以外の場合は、セキュリティフィルターをバイパスしたり、サーバーをだまして非公開コンテンツを配信したり、キャッシュを毒したりする試みを示している場合があります。メッセージルーティングに関するセキュリティに関する考慮事項については、セクション17を参照してください。
Unless the connection is from a trusted gateway, an origin server MUST reject a request if any scheme-specific requirements for the target URI are not met. In particular, a request for an "https" resource MUST be rejected unless it has been received over a connection that has been secured via a certificate valid for that target URI's origin, as defined by Section 4.2.2.
接続が信頼できるゲートウェイからのものでない限り、ターゲットURIのスキーム固有の要件が満たされていない場合、Origin Serverはリクエストを拒否する必要があります。特に、セクション4.2.2で定義されているように、そのターゲットURIの起源に対して有効な証明書を介して保護されている接続を介して受信されない限り、「HTTPS」リソースの要求を拒否する必要があります。
The 421 (Misdirected Request) status code in a response indicates that the origin server has rejected the request because it appears to have been misdirected (Section 15.5.20).
応答の421（誤った要求）ステータスコードは、Origin Serverが誤った方向に向けられているように見えるため、リクエストを拒否したことを示しています（セクション15.5.20）。
A connection might be used for multiple request/response exchanges. The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier.
複数のリクエスト/応答交換に接続が使用される場合があります。リクエストメッセージと応答メッセージを相関させるために使用されるメカニズムは、バージョンに依存します。HTTPの一部のバージョンは、メッセージの暗黙的な順序付けを使用しますが、他のバージョンは明示的な識別子を使用します。
All responses, regardless of the status code (including interim responses) can be sent at any time after a request is received, even if the request is not yet complete. A response can complete before its corresponding request is complete (Section 6.1). Likewise, clients are not expected to wait any specific amount of time for a response. Clients (including intermediaries) might abandon a request if the response is not received within a reasonable period of time.
ステータスコード（暫定応答を含む）に関係なく、すべての応答は、リクエストがまだ完了していなくても、リクエストを受信した後でもいつでも送信できます。対応するリクエストが完了する前に、応答が完了することがあります（セクション6.1）。同様に、クライアントは応答のために特定の時間を待つことは期待されていません。クライアント（仲介者を含む）は、合理的な期間内に回答が受信されない場合、リクエストを放棄する場合があります。
A client that receives a response while it is still sending the associated request SHOULD continue sending that request unless it receives an explicit indication to the contrary (see, e.g., Section 9.5 of [HTTP/1.1] and Section 6.4 of [HTTP/2]).
関連するリクエストを送信している間に応答を受信するクライアントは、反対の明示的な表示を受け取らない限り、その要求を送信し続ける必要があります（例えば、[HTTP/1.1]のセクション9.5および[HTTP/2]のセクション6.4を参照してください。）。
As described in Section 3.7, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can enhance (or interfere) with either direction of the stream.
セクション3.7で説明されているように、仲介者はHTTP要求と応答の処理においてさまざまな役割を果たすことができます。一部の仲介業者は、パフォーマンスや可用性を改善するために使用されます。その他は、アクセス制御またはコンテンツのフィルタリングに使用されます。HTTPストリームには、パイプアンドフィルターアーキテクチャと同様の特性があるため、中間者がいずれかのストリームの方向で強化（または干渉）できる範囲に固有の制限はありません。
Intermediaries are expected to forward messages even when protocol elements are not recognized (e.g., new methods, status codes, or field names) since that preserves extensibility for downstream recipients.
仲介者は、プロトコル要素が認識されない場合でもメッセージを転送することが期待されます（たとえば、新しい方法、ステータスコード、またはフィールド名）。
An intermediary not acting as a tunnel MUST implement the Connection header field, as specified in Section 7.6.1, and exclude fields from being forwarded that are only intended for the incoming connection.
トンネルとして機能しない仲介者は、セクション7.6.1で指定されているように、接続ヘッダーフィールドを実装し、着信接続のみを目的とした転送からフィールドを除外する必要があります。
An intermediary MUST NOT forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly.
仲介者は、無限の要求ループから保護されていない限り、メッセージを自分自身に転送してはなりません。一般に、仲介者は、エイリアス、ローカルバリエーション、または文字通りのIPアドレスを含む独自のサーバー名を認識し、そのような要求に直接応答する必要があります。
An HTTP message can be parsed as a stream for incremental processing or forwarding downstream. However, senders and recipients cannot rely on incremental delivery of partial messages, since some implementations will buffer or delay message forwarding for the sake of network efficiency, security checks, or content transformations.
HTTPメッセージは、増分処理または下流の転送のストリームとして解析できます。ただし、一部の実装では、ネットワーク効率、セキュリティチェック、またはコンテンツの変換のためにメッセージ転送をバッファリングまたは遅延させるため、送信者と受信者は部分的なメッセージの増分配信に依存することはできません。
The "Connection" header field allows the sender to list desired control options for the current connection.
「接続」ヘッダーフィールドにより、送信者は現在の接続の目的の制御オプションをリストできます。
Connection = #connection-option
connection-option = token
Connection options are case-insensitive.
接続オプションはケースに依存しません。
When a field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field name within the Connection header field. Note that some versions of HTTP prohibit the use of fields for such information, and therefore do not allow the Connection field.
接続以外のフィールドを使用して、現在の接続に関する制御情報を提供する場合、送信者は接続ヘッダーフィールド内の対応するフィールド名をリストする必要があります。HTTPの一部のバージョンは、そのような情報に対するフィールドの使用を禁止しているため、接続フィールドを許可しないことに注意してください。
Intermediaries MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove any header or trailer field(s) from the message with the same name as the connection-option, and then remove the Connection header field itself (or replace it with the intermediary's own control options for the forwarded message).
仲介者は、メッセージが転送される前に受信した接続ヘッダーフィールドを解析する必要があり、このフィールドの接続オプションごとに、接続オプションと同じ名前のメッセージからヘッダーまたはトレーラーフィールドを削除し、次に削除する必要があります。接続ヘッダーフィールド自体（または、転送されたメッセージの仲介者自身の制御オプションに置き換えます）。
Hence, the Connection header field provides a declarative way of distinguishing fields that are only intended for the immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they will be blindly forwarded by older intermediaries.
したがって、接続ヘッダーフィールドは、チェーン上のすべての受信者を対象としたフィールド（「エンドツーエンド」を対象としたフィールドから、即時の受信者（「ホップバイホップ」）を対象としたフィールドを区別する宣言的な方法を提供します。）、メッセージを自己記述的であることを可能にし、将来の接続固有の拡張機能を、それらが古い仲介者によって盲目的に転送されることを恐れることなく展開できるようにします。
Furthermore, intermediaries SHOULD remove or replace fields that are known to require removal before forwarding, whether or not they appear as a connection-option, after applying those fields' semantics. This includes but is not limited to:
さらに、仲介業者は、それらのフィールドのセマンティクスを適用した後、接続オプションとして表示されるかどうかにかかわらず、転送前に除去を必要とすることが知られているフィールドを削除または交換する必要があります。これには、以下が含まれますが、これらに限定されません。
* Proxy-Connection (Appendix C.2.2 of [HTTP/1.1])
* プロキシ接続（[http/1.1]の付録C.2.2）
* Keep-Alive (Section 19.7.1 of [RFC2068])
* Keep-Alive（[RFC2068]のセクション19.7.1）
* TE (Section 10.1.4)
* TE（セクション10.1.4）
* Transfer-Encoding (Section 6.1 of [HTTP/1.1])
* 転送エンコード（[http/1.1]のセクション6.1）
* Upgrade (Section 7.8)
* アップグレード（セクション7.8）
A sender MUST NOT send a connection option corresponding to a field that is intended for all recipients of the content. For example, Cache-Control is never appropriate as a connection option (Section 5.2 of [CACHING]).
送信者は、コンテンツのすべての受信者を対象としたフィールドに対応する接続オプションを送信してはなりません。たとえば、キャッシュコントロールは、接続オプションとして適切ではありません（[キャッシュ]のセクション5.2）。
Connection options do not always correspond to a field present in the message, since a connection-specific field might not be needed if there are no parameters associated with a connection option. In contrast, a connection-specific field received without a corresponding connection option usually indicates that the field has been improperly forwarded by an intermediary and ought to be ignored by the recipient.
接続オプションは、接続オプションに関連付けられたパラメーターがない場合は接続固有のフィールドが必要ない場合があるため、メッセージに存在するフィールドに常に対応するとは限りません。対照的に、対応する接続オプションなしで受信した接続固有のフィールドは、通常、フィールドが仲介者によって不適切に転送され、受信者が無視する必要があることを示します。
When defining a new connection option that does not correspond to a field, specification authors ought to reserve the corresponding field name anyway in order to avoid later collisions. Such reserved field names are registered in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" (Section 16.3.1).
フィールドに対応しない新しい接続オプションを定義する場合、仕様著者は、後の衝突を回避するために、とにかく対応するフィールド名を予約する必要があります。このような予約されたフィールド名は、「HyperText Transfer Protocol（HTTP）フィールド名レジストリ」（セクション16.3.1）に登録されています。
The "Max-Forwards" header field provides a mechanism with the TRACE (Section 9.3.8) and OPTIONS (Section 9.3.7) request methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting to trace a request that appears to be failing or looping mid-chain.
「Max-Forwards」ヘッダーフィールドは、トレース（セクション9.3.8）とオプション（セクション9.3.7）のメカニズムを提供し、リクエストがプロキシによって転送される回数を制限する方法を要求します。これは、クライアントが失敗しているように見えるリクエストをトレースしようとしている場合、またはミッドチェーンのループをループしている場合に役立ちます。
Max-Forwards = 1*DIGIT
The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.
Max-Forwards値は、この要求メッセージを転送できる残りの回数を示す小数整数です。
Each intermediary that receives a TRACE or OPTIONS request containing a Max-Forwards header field MUST check and update its value prior to forwarding the request. If the received value is zero (0), the intermediary MUST NOT forward the request; instead, the intermediary MUST respond as the final recipient. If the received Max-Forwards value is greater than zero, the intermediary MUST generate an updated Max-Forwards field in the forwarded message with a field value that is the lesser of a) the received value decremented by one (1) or b) the recipient's maximum supported value for Max-Forwards.
Max-Forwardsヘッダーフィールドを含むトレースまたはオプションリクエストを受信する各仲介者は、リクエストを転送する前にその値を確認および更新する必要があります。受信価値がゼロ（0）の場合、仲介者は要求を転送してはなりません。代わりに、仲介者は最終受信者として応答する必要があります。受信したMax-Forwards値がゼロより大きい場合、仲介者は、a）1つまたはbによって減少した受信値の低いフィールド値で、転送メッセージに更新された最大型フィールドを生成する必要があります。Max-Forwardsの受信者の最大サポート値。
A recipient MAY ignore a Max-Forwards header field received with any other request methods.
受信者は、他のリクエスト方法で受信したMax-Forwardsヘッダーフィールドを無視する場合があります。
The "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server (on requests) or between the origin server and the client (on responses), similar to the "Received" header field in email (Section 3.6.7 of [RFC5322]). Via can be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders along the request/response chain.
「via」ヘッダーフィールドは、ユーザーエージェントとサーバー（リクエストに応じて）またはオリジンサーバーとクライアント間（応答）の間に中間プロトコルと受信者の存在を示します。[RFC5322]の3.6.7）。viaは、メッセージの前方を追跡し、リクエストループを回避し、リクエスト/応答チェーンに沿った送信者のプロトコル機能を特定するために使用できます。
Via = #( received-protocol RWS received-by [ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
; see Section 7.8
received-by = pseudonym [ ":" port ]
pseudonym = token
Each member of the Via field value represents a proxy or gateway that has forwarded the message. Each intermediary appends its own information about how the message was received, such that the end result is ordered according to the sequence of forwarding recipients.
VIAフィールド値の各メンバーは、メッセージを転送したプロキシまたはゲートウェイを表します。各仲介は、メッセージの受信方法に関する独自の情報を追加し、最終結果が転送受信者のシーケンスに従って順序付けられるようにします。
A proxy MUST send an appropriate Via header field, as described below, in each message that it forwards. An HTTP-to-HTTP gateway MUST send an appropriate Via header field in each inbound request message and MAY send a Via header field in forwarded response messages.
プロキシは、以下に説明するように、それが転送する各メッセージに適切なヘッダーフィールドを送信する必要があります。HTTP-to-HTTPゲートウェイは、各インバウンドリクエストメッセージに適切なヘッダーフィールドを送信し、転送された応答メッセージでヘッダーフィールドを送信する必要があります。
For each intermediary, the received-protocol indicates the protocol and protocol version used by the upstream sender of the message. Hence, the Via field value records the advertised protocol capabilities of the request/response chain such that they remain visible to downstream recipients; this can be useful for determining what backwards-incompatible features might be safe to use in response, or within a later request, as described in Section 2.5. For brevity, the protocol-name is omitted when the received protocol is HTTP.
各仲介について、受信したプロトコルは、メッセージの上流の送信者が使用するプロトコルとプロトコルバージョンを示します。したがって、VIAのフィールド値は、リクエスト/応答チェーンの広告されたプロトコル機能を記録し、それらが下流の受信者に見えるようにします。これは、セクション2.5で説明されているように、それに応じて安全に使用できるか、後の要求内で使用できるかどうかを判断するのに役立ちます。簡潔にするために、受信したプロトコルがHTTPである場合、プロトコル名は省略されます。
The received-by portion is normally the host and optional port number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym. If a port is not provided, a recipient MAY interpret that as meaning it was received on the default port, if any, for the received-protocol.
通常、受信した部分は、その後メッセージを転送した受信者サーバーまたはクライアントのホストとオプションのポート番号です。ただし、実際のホストが機密情報と見なされる場合、送信者はそれを仮名に置き換えることができます。ポートが提供されていない場合、受信者は、受信プロトコルに対して、デフォルトのポートでそれが受信されたという意味としてそれを解釈することができます。
A sender MAY generate comments to identify the software of each recipient, analogous to the User-Agent and Server header fields. However, comments in Via are optional, and a recipient MAY remove them prior to forwarding the message.
送信者は、ユーザーエージェントおよびサーバーヘッダーフィールドに類似した各受信者のソフトウェアを識別するためのコメントを生成できます。ただし、Viaのコメントはオプションであり、受信者はメッセージを転送する前にそれらを削除する場合があります。
For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin server at www.example.com. The request received by www.example.com would then have the following Via header field:
たとえば、リクエストメッセージをHTTP/1.0ユーザーエージェントから、HTTP/1.1を使用して「FRED」という名前の内部プロキシコードに送信できます。www.example.comのOrigin Serverに転送して要求します。www.example.comが受け取ったリクエストには、ヘッダーフィールドを介して以下があります。
Via: 1.0 fred, 1.1 p.example.net
Via：1.0 Fred、1.1 p.example.net
An intermediary used as a portal through a network firewall SHOULD NOT forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled, such an intermediary SHOULD replace each received-by host of any host behind the firewall by an appropriate pseudonym for that host.
ネットワークファイアウォールを介してポータルとして使用される仲介者は、明示的に可能にしない限り、ファイアウォール領域内のホストの名前とポートを転送しないでください。有効になっていない場合、そのような仲介者は、そのホストの適切な仮名で、ファイアウォールの背後にあるホストの受信者ごとに各ホストを置き換える必要があります。
An intermediary MAY combine an ordered subsequence of Via header field list members into a single member if the entries have identical received-protocol values. For example,
仲介者は、エントリに同一の受信プロトコル値を持っている場合、順序付けられたヘッダーフィールドリストメンバーの順序付けされたサブセンシュを単一のメンバーに組み合わせることができます。例えば、
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
Via：1.0 Ricky、1.1 Ethel、1.1 Fred、1.0 Lucy
could be collapsed to
に崩壊する可能性があります
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Via：1.0 Ricky、1.1 Mertz、1.0 Lucy
A sender SHOULD NOT combine multiple list members unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. A sender MUST NOT combine members that have different received-protocol values.
送信者は、すべて同じ組織管理下にある場合を除き、複数のリストメンバーを組み合わせてはなりません。ホストはすでに仮名に置き換えられています。送信者は、異なる受信プロトコル値を持つメンバーを組み合わせてはなりません。
Some intermediaries include features for transforming messages and their content. A proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational problems might occur when these transformations are applied to content intended for critical applications, such as medical imaging or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the content received is identical to the original.
一部の仲介業者には、メッセージとそのコンテンツを変換するための機能が含まれています。たとえば、プロキシは、キャッシュスペースを保存したり、遅いリンクでトラフィックの量を減らすために画像形式間を変換する場合があります。ただし、これらの変換が医療画像や科学データ分析などの重要なアプリケーションを対象としたコンテンツに適用される場合、特に整合性チェックまたはデジタル署名を使用して受信したコンテンツが元と同一であることを確認する場合、運用上の問題が発生する可能性があります。
An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed or configured to modify messages in a semantically meaningful way (i.e., modifications, beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder, or a privacy filter. Such transformations are presumed to be desired by whichever client (or client organization) chose the proxy.
HTTP-to-HTTPプロキシは、意味的に意味のある方法でメッセージを変更するように設計または構成されている場合（つまり、通常のHTTP処理で必要なものを超えて、メッセージを変更する方法で変更するように設計または構成されている場合、「変換プロキシ」と呼ばれます。元の送信者にとって重要であるか、下流の受信者にとって潜在的に重要である。たとえば、変換プロキシは、共有アノテーションサーバー（ローカルアノテーションデータベースへの参照を含めるための応答を変更する）、マルウェアフィルター、フォーマットトランスコダー、またはプライバシーフィルターとして機能している可能性があります。このような変換は、クライアント（またはクライアント組織）がプロキシを選択した場合でも望まれると推定されます。
If a proxy receives a target URI with a host name that is not a fully qualified domain name, it MAY add its own domain to the host name it received when forwarding the request. A proxy MUST NOT change the host name if the target URI contains a fully qualified domain name.
プロキシが、完全な資格のあるドメイン名ではないホスト名でターゲットURIを受信した場合、リクエストを転送するときに受け取ったホスト名に独自のドメインを追加する場合があります。ターゲットURIに完全な資格のあるドメイン名が含まれている場合、プロキシはホスト名を変更してはなりません。
A proxy MUST NOT modify the "absolute-path" and "query" parts of the received target URI when forwarding it to the next inbound server except as required by that forwarding protocol. For example, a proxy forwarding a request to an origin server via HTTP/1.1 will replace an empty path with "/" (Section 3.2.1 of [HTTP/1.1]) or "*" (Section 3.2.4 of [HTTP/1.1]), depending on the request method.
プロキシは、その転送プロトコルで要求されている場合を除き、次のインバウンドサーバーに転送する際に、受信したターゲットURIの「絶対パス」および「クエリ」部分を変更してはなりません。たとえば、HTTP/1.1を介してオリジンサーバーにリクエストを転送するプロキシは、空のパスを「/」（[http/1.1]のセクション3.2.1）または「*」（[http/"のセクション3.2.4）に置き換えます。1.1]）、リクエスト方法に応じて。
A proxy MUST NOT transform the content (Section 6.4) of a response message that contains a no-transform cache directive (Section 5.2.2.6 of [CACHING]). Note that this does not apply to message transformations that do not change the content, such as the addition or removal of transfer codings (Section 7 of [HTTP/1.1]).
プロキシは、変換されないキャッシュ指令（[キャッシュ]のセクション5.2.2.6）を含む応答メッセージのコンテンツ（セクション6.4）を変換してはなりません。これは、転送コーディングの追加や削除など、コンテンツを変更しないメッセージ変換には適用されないことに注意してください（[HTTP/1.1]のセクション7）。
A proxy MAY transform the content of a message that does not contain a no-transform cache directive. A proxy that transforms the content of a 200 (OK) response can inform downstream recipients that a transformation has been applied by changing the response status code to 203 (Non-Authoritative Information) (Section 15.3.4).
プロキシは、変換されないキャッシュ指令を含まないメッセージのコンテンツを変換する場合があります。200（OK）応答のコンテンツを変換するプロキシは、応答ステータスコードを203（非認証情報）に変更することで変換が適用されていることを下流の受信者に通知できます（セクション15.3.4）。
A proxy SHOULD NOT modify header fields that provide information about the endpoints of the communication chain, the resource state, or the selected representation (other than the content) unless the field's definition specifically allows such modification or the modification is deemed necessary for privacy or security.
プロキシは、フィールドの定義がそのような変更または変更がプライバシーまたはセキュリティに必要であると見なされない限り、通信チェーン、リソース状態、または選択された表現（コンテンツ以外）のエンドポイントに関する情報を提供するヘッダーフィールドを変更する必要はありません。。
The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol on the same connection.
「アップグレード」ヘッダーフィールドは、同じ接続上のHTTP/1.1から他のプロトコルへの移行のための簡単なメカニズムを提供することを目的としています。
A client MAY send a list of protocol names in the Upgrade header field of a request to invite the server to switch to one or more of the named protocols, in order of descending preference, before sending the final response. A server MAY ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection. Upgrade cannot be used to insist on a protocol change.
クライアントは、最終的な応答を送信する前に、優先順位の順にサーバーを1つ以上の名前のプロトコルに切り替えるようにサーバーを招待するようにリクエストのアップグレードヘッダーフィールドにプロトコル名のリストを送信できます。サーバーは、その接続で現在のプロトコルの使用を継続したい場合、受信したアップグレードヘッダーフィールドを無視する場合があります。アップグレードは、プロトコルの変更を主張するために使用できません。
Upgrade = #protocol
protocol = protocol-name ["/" protocol-version] protocol-name = token protocol-version = token
protocol = protocol-name ["/" protocol-version] protocol-name = token protocol-version = token
Although protocol names are registered with a preferred case, recipients SHOULD use case-insensitive comparison when matching each protocol-name to supported protocols.
プロトコル名は優先ケースに登録されていますが、受信者は各プロトコル名をサポートされているプロトコルと一致させるときに、ケースに依存しない比較を使用する必要があります。
A server that sends a 101 (Switching Protocols) response MUST send an Upgrade header field to indicate the new protocol(s) to which the connection is being switched; if multiple protocol layers are being switched, the sender MUST list the protocols in layer-ascending order. A server MUST NOT switch to a protocol that was not indicated by the client in the corresponding request's Upgrade header field. A server MAY choose to ignore the order of preference indicated by the client and select the new protocol(s) based on other factors, such as the nature of the request or the current load on the server.
101（スイッチングプロトコル）応答を送信するサーバーは、アップグレードヘッダーフィールドを送信して、接続が切り替えられている新しいプロトコルを示す必要があります。複数のプロトコルレイヤーが切り替えられている場合、送信者はレイヤーアセンディング順序でプロトコルをリストする必要があります。サーバーは、対応するリクエストのアップグレードヘッダーフィールドでクライアントによって示されなかったプロトコルに切り替えてはなりません。サーバーは、クライアントが示す優先順序を無視し、リクエストの性質やサーバー上の現在の負荷など、他の要因に基づいて新しいプロトコルを選択することを選択できます。
A server that sends a 426 (Upgrade Required) response MUST send an Upgrade header field to indicate the acceptable protocols, in order of descending preference.
426（アップグレードが必要）応答を送信するサーバーは、優先権の順に許容可能なプロトコルを示すためにアップグレードヘッダーフィールドを送信する必要があります。
A server MAY send an Upgrade header field in any other response to advertise that it implements support for upgrading to the listed protocols, in order of descending preference, when appropriate for a future request.
サーバーは、将来のリクエストに適した場合、降順の選好の順に、リストされたプロトコルへのアップグレードのサポートを実装することを広告するために、その他の応答でアップグレードヘッダーフィールドを送信する場合があります。
The following is a hypothetical example sent by a client:
以下は、クライアントから送信された仮想的な例です。
GET /hello HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: websocket, IRC/6.9, RTA/x11
The capabilities and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol(s) chosen. However, immediately after sending the 101 (Switching Protocols) response, the server is expected to continue responding to the original request as if it had received its equivalent within the new protocol (i.e., the server still has an outstanding request to satisfy after the protocol has been changed, and is expected to do so without requiring the request to be repeated).
プロトコルの変更後のアプリケーションレベルの通信の機能と性質は、選択された新しいプロトコルに完全に依存しています。ただし、101（切り替えプロトコル）応答を送信した直後に、サーバーは新しいプロトコル内で同等の受信者を受け取ったかのように元の要求に応答し続けることが期待されます（つまり、プロトコルの後に満足するための未解決のリクエストがあります変更が変更されており、リクエストを繰り返すことを要求することなくそうすることが期待されています）。
For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, it first responds with a 101 (Switching Protocols) message in HTTP/1.1 and then immediately follows that with the new protocol's equivalent of a response to a GET on the target resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of an additional round trip. A server MUST NOT switch protocols unless the received message semantics can be honored by the new protocol; an OPTIONS request can be honored by any protocol.
たとえば、アップグレードヘッダーフィールドがGETリクエストで受信され、サーバーがプロトコルを切り替えることを決定した場合、最初にHTTP/1.1の101（切り替えプロトコル）メッセージで応答し、その後、新しいプロトコルの応答に相当するものに直接従います。ターゲットリソースを取得します。これにより、追加の往復の遅延コストなしに、HTTPと同じセマンティクスを持つプロトコルに接続をアップグレードできます。受信したメッセージセマンティクスが新しいプロトコルで尊重されない限り、サーバーはプロトコルを切り替えてはなりません。オプションリクエストは、任意のプロトコルで尊重できます。
The following is an example response to the above hypothetical request:
以下は、上記の仮説リクエストに対する例の応答です。
HTTP/1.1 101 Switching Protocols Connection: upgrade Upgrade: websocket
http/1.1 101スイッチングプロトコル接続：アップグレードアップグレード：websocket
[... data stream switches to websocket with an appropriate response (as defined by new protocol) to the "GET /hello" request ...]
[...データストリームは、「get /hello」リクエストに対する適切な応答（新しいプロトコルで定義されている）でWebSocketに切り替えます...]
A sender of Upgrade MUST also send an "Upgrade" connection option in the Connection header field (Section 7.6.1) to inform intermediaries not to forward this field. A server that receives an Upgrade header field in an HTTP/1.0 request MUST ignore that Upgrade field.
アップグレードの送信者は、接続ヘッダーフィールド（セクション7.6.1）に「アップグレード」接続オプションを送信して、このフィールドを転送しないように仲介者に通知する必要があります。HTTP/1.0要求でアップグレードヘッダーフィールドを受信するサーバーは、そのアップグレードフィールドを無視する必要があります。
A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e., the client can't change the protocol it is sending in the middle of a message). If a server receives both an Upgrade and an Expect header field with the "100-continue" expectation (Section 10.1.1), the server MUST send a 100 (Continue) response before sending a 101 (Switching Protocols) response.
クライアントは、リクエストメッセージを完全に送信するまで、接続でアップグレードされたプロトコルの使用を開始できません（つまり、クライアントがメッセージの途中で送信しているプロトコルを変更できません）。サーバーが「100コントン」の期待を持つアップグレードと期待ヘッダーフィールドの両方を受信する場合（セクション10.1.1）、サーバーは101（切り替えプロトコル）応答を送信する前に100（続行）応答を送信する必要があります。
The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those purposes, it is more appropriate to use a 3xx (Redirection) response (Section 15.4).
アップグレードヘッダーフィールドは、既存の接続の上にプロトコルを切り替えることにのみ適用されます。基礎となる接続（輸送）プロトコルを切り替えたり、既存の通信を別の接続に切り替えるために使用することはできません。これらの目的では、3xx（リダイレクト）応答を使用する方が適切です（セクション15.4）。
This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined by the HTTP version rules of Section 2.5 and future updates to this specification. Additional protocol names ought to be registered using the registration procedure defined in Section 16.7.
この仕様では、セクション2.5のHTTPバージョンルールとこの仕様の将来の更新で定義されているように、ハイパーテキスト転送プロトコルのファミリーが使用するプロトコル名「HTTP」のみを定義します。セクション16.7で定義された登録手順を使用して、追加のプロトコル名を登録する必要があります。
The representation data associated with an HTTP message is either provided as the content of the message or referred to by the message semantics and the target URI. The representation data is in a format and encoding defined by the representation metadata header fields.
HTTPメッセージに関連付けられた表現データは、メッセージの内容として提供されるか、メッセージセマンティクスとターゲットURIによって言及されます。表現データは、表現メタデータヘッダーフィールドによって定義された形式とエンコードです。
The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define a two-layer, ordered encoding model:
表現データのデータ型は、ヘッダーフィールドのコンテンツタイプとコンテンツエンコードを介して決定されます。これらは、2層の順序付けられたエンコードモデルを定義します。
representation-data := Content-Encoding( Content-Type( data ) )
Representation header fields provide metadata about the representation. When a message includes content, the representation header fields describe how to interpret that data. In a response to a HEAD request, the representation header fields describe the representation data that would have been enclosed in the content if the same request had been a GET.
表現ヘッダーフィールドは、表現に関するメタデータを提供します。メッセージにコンテンツが含まれる場合、表現ヘッダーフィールドはそのデータを解釈する方法を説明します。ヘッドリクエストへの応答で、表現ヘッダーフィールドは、同じリクエストがGETであった場合、コンテンツに囲まれていた表現データを説明します。
The "Content-Type" header field indicates the media type of the associated representation: either the representation enclosed in the message content or the selected representation, as determined by the message semantics. The indicated media type defines both the data format and how that data is intended to be processed by a recipient, within the scope of the received message semantics, after any content codings indicated by Content-Encoding are decoded.
「コンテンツタイプ」ヘッダーフィールドは、関連する表現のメディアタイプを示します。メッセージセマンティクスによって決定されるメッセージコンテンツに囲まれた表現または選択した表現のいずれかです。指定されたメディアタイプは、コンテンツエンコードで示されたコンテンツコードがデコードされた後、受信したメッセージセマンティクスの範囲内で、データ形式とそのデータを受信者によって処理する方法の両方を定義します。
Content-Type = media-type
Media types are defined in Section 8.3.1. An example of the field is
メディアタイプは、セクション8.3.1で定義されています。フィールドの例は次のとおりです
Content-Type: text/html; charset=ISO-8859-4
A sender that generates a message containing content SHOULD generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown to the sender. If a Content-Type header field is not present, the recipient MAY either assume a media type of "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the data to determine its type.
コンテンツを含むメッセージを生成する送信者は、囲まれた表現の意図されたメディアタイプが送信者に知られていない場合を除き、そのメッセージにコンテンツタイプのヘッダーフィールドを生成する必要があります。コンテンツタイプのヘッダーフィールドが存在しない場合、受信者はメディアタイプの「アプリケーション/オクテットストリーム」（[RFC2046]、セクション4.5.1）を想定するか、そのタイプを決定するためにデータを調べることができます。
In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for a given representation. Some user agents examine the content and, in certain cases, override the received type (for example, see [Sniffing]). This "MIME sniffing" risks drawing incorrect conclusions about the data, which might expose the user to additional security risks (e.g., "privilege escalation"). Furthermore, distinct media types often share a common data format, differing only in how the data is intended to be processed, which is impossible to distinguish by inspecting the data alone. When sniffing is implemented, implementers are encouraged to provide a means for the user to disable it.
実際には、リソースの所有者は、特定の表現に正しいコンテンツタイプを提供するようにOrigin Serverを常に適切に構成するとは限りません。一部のユーザーエージェントはコンテンツを調べ、特定の場合、受信したタイプをオーバーライドします（たとえば、[スニッフィング]を参照）。この「マイムスニッフィング」は、データに関する誤った結論を引き出すリスクがあり、ユーザーが追加のセキュリティリスクにさらされる可能性があります（例：「特権エスカレーション」）。さらに、個別のメディアタイプは一般的なデータ形式を共有することが多く、データの処理方法のみが異なります。これは、データのみを検査することで区別することは不可能です。スニッフィングが実装されると、実装者はユーザーがそれを無効にする手段を提供することをお勧めします。
Although Content-Type is defined as a singleton field, it is sometimes incorrectly generated multiple times, resulting in a combined field value that appears to be a list. Recipients often attempt to handle this error by using the last syntactically valid member of the list, leading to potential interoperability and security issues if different implementations have different error handling behaviors.
コンテンツタイプはシングルトンフィールドとして定義されていますが、複数回誤って生成されることがあり、リストのように見える合計フィールド値が得られます。多くの場合、受信者はリストの最後の構文的に有効なメンバーを使用してこのエラーを処理しようとします。
HTTP uses media types [RFC2046] in the Content-Type (Section 8.3) and Accept (Section 12.5.1) header fields in order to provide open and extensible data typing and type negotiation. Media types define both a data format and various processing models: how to process that data in accordance with the message context.
HTTPは、オープンで拡張可能なデータタイピングとタイプネゴシエーションを提供するために、コンテンツタイプ（セクション8.3）および受け入れ（セクション12.5.1）ヘッダーフィールドでメディアタイプ[RFC2046]を使用します。メディアタイプは、データ形式とさまざまな処理モデルの両方を定義します。メッセージコンテキストに従ってそのデータを処理する方法。
media-type = type "/" subtype parameters type = token subtype = token
media-type = type "/"サブタイプパラメータータイプ=トークンサブタイプ=トークン
The type and subtype tokens are case-insensitive.
タイプとサブタイプのトークンはケース非感受性です。
The type/subtype MAY be followed by semicolon-delimited parameters (Section 5.6.6) in the form of name/value pairs. The presence or absence of a parameter might be significant to the processing of a media type, depending on its definition within the media type registry. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name.
タイプ/サブタイプに続いて、名前/値のペアの形式のセミコロン削除パラメーター（セクション5.6.6）が続く場合があります。メディアタイプのレジストリ内の定義に応じて、パラメーターの有無は、メディアタイプの処理にとって重要である可能性があります。パラメーター値のセマンティクスに応じて、パラメーター値は症例に敏感でない場合があります。
For example, the following media types are equivalent in describing HTML text data encoded in the UTF-8 character encoding scheme, but the first is preferred for consistency (the "charset" parameter value is defined as being case-insensitive in [RFC2046], Section 4.1.2):
たとえば、次のメディアタイプは、UTF-8文字エンコードスキームでエンコードされたHTMLテキストデータを記述する際に同等ですが、1つ目は一貫性に優先されます（「rfc2046]では「charset」パラメーター値はケース非感受性と定義されます。セクション4.1.2）：
text/html;charset=utf-8
Text/HTML;Charset="utf-8"
text/html; charset="utf-8"
text/html;charset=UTF-8
Media types ought to be registered with IANA according to the procedures defined in [BCP13].
メディアタイプは、[BCP13]で定義されている手順に従ってIANAに登録する必要があります。
HTTP uses "charset" names to indicate or negotiate the character encoding scheme ([RFC6365], Section 2) of a textual representation. In the fields defined by this document, charset names appear either in parameters (Content-Type), or, for Accept-Encoding, in the form of a plain token. In both cases, charset names are matched case-insensitively.
HTTPは、「Charset」名を使用して、テキスト表現の文字エンコードスキーム（[RFC6365]、セクション2）を示したり交渉したりします。このドキュメントで定義されたフィールドでは、charset名はパラメーター（コンテンツタイプ）に表示されるか、容認されるトークンの形で受け入れるために表示されます。どちらの場合も、charset名はケースインスセンシタルに一致します。
Charset names ought to be registered in the IANA "Character Sets" registry (<https://www.iana.org/assignments/character-sets>) according to the procedures defined in Section 2 of [RFC2978].
[RFC2978]のセクション2で定義されている手順に従って、チャーセット名はIANAの「文字セット」レジストリ（<https://www.iana.org/assignments/character-sets>）に登録する必要があります。
| *Note:* In theory, charset names are defined by the "mime-
| charset" ABNF rule defined in Section 2.3 of [RFC2978] (as
| corrected in [Err1912]). That rule allows two characters that
| are not included in "token" ("{" and "}"), but no charset name
| registered at the time of this writing includes braces (see
| [Err5433]).
MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body. All multipart types share a common syntax, as defined in Section 5.1.1 of [RFC2046], and include a boundary parameter as part of the media type value. The message body is itself a protocol element; a sender MUST generate only CRLF to represent line breaks between body parts.
MIMEは、多くの「マルチパート」タイプを提供します - 単一のメッセージ本文内の1つ以上の表現のカプセル。[RFC2046]のセクション5.1.1で定義されているように、すべてのマルチパートタイプは共通の構文を共有し、メディアタイプの値の一部として境界パラメーターを含みます。メッセージ本文自体はプロトコル要素です。送信者は、体の部分間のラインブレークを表すためにCRLFのみを生成する必要があります。
HTTP message framing does not use the multipart boundary as an indicator of message body length, though it might be used by implementations that generate or process the content. For example, the "multipart/form-data" type is often used for carrying form data in a request, as described in [RFC7578], and the "multipart/ byteranges" type is defined by this specification for use in some 206 (Partial Content) responses (see Section 15.3.7).
HTTPメッセージフレーミングは、コンテンツを生成または処理する実装によって使用される場合がありますが、メッセージボディの長さのインジケーターとしてマルチパート境界を使用しません。たとえば、[RFC7578]で説明されているように、「MultiPart/ Form-Data」タイプは、[RFC7578]に記載されているリクエスト内のフォームデータを運ぶためによく使用され、「MultiPart/ Byteranges」タイプは、206で使用するこの仕様によって定義されます（部分的コンテンツ）応答（セクション15.3.7を参照）。
The "Content-Encoding" header field indicates what content codings have been applied to the representation, beyond those inherent in the media type, and thus what decoding mechanisms have to be applied in order to obtain data in the media type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a representation's data to be compressed without losing the identity of its underlying media type.
「コンテンツエンコード」ヘッダーフィールドは、メディアタイプに固有のものを超えて、表現に適用されているコンテンツコーディング、したがって、コンテンツによって参照されるメディアタイプのデータを取得するためにどのようなデコードメカニズムを適用する必要があるかを示します。タイプヘッダーフィールド。コンテンツエンコードは、主に、基礎となるメディアタイプのアイデンティティを失うことなく、表現のデータを圧縮できるようにするために使用されます。
Content-Encoding = #content-coding
An example of its use is
その使用の例は次のとおりです
Content-Encoding: gzip
コンテンツエンコード：GZIP
If one or more encodings have been applied to a representation, the sender that applied the encodings MUST generate a Content-Encoding header field that lists the content codings in the order in which they were applied. Note that the coding named "identity" is reserved for its special role in Accept-Encoding and thus SHOULD NOT be included.
1つ以上のエンコーディングが表現に適用されている場合、エンコーディングを適用した送信者は、コンテンツコードを適用した順序でコンテンツコードをリストするコンテンツエンコードヘッダーフィールドを生成する必要があります。「アイデンティティ」という名前のコーディングは、受け入れエンコードにおける特別な役割のために予約されているため、含めるべきではないことに注意してください。
Additional information about the encoding parameters can be provided by other header fields not defined by this specification.
エンコードパラメーターに関する追加情報は、この仕様で定義されていない他のヘッダーフィールドによって提供できます。
Unlike Transfer-Encoding (Section 6.1 of [HTTP/1.1]), the codings listed in Content-Encoding are a characteristic of the representation; the representation is defined in terms of the coded form, and all other metadata about the representation is about the coded form unless otherwise noted in the metadata definition. Typically, the representation is only decoded just prior to rendering or analogous usage.
転送エンコード（[http/1.1]のセクション6.1）とは異なり、コンテンツエンコードにリストされているコードは表現の特性です。表現は、コード化された形式の観点から定義され、表現に関する他のすべてのメタデータは、メタデータの定義で特に記載されていない限り、コード化された形式に関するものです。通常、表現は、レンダリングまたは類似の使用の直前にのみ解読されます。
If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would not be restated in Content-Encoding even if it happens to be the same algorithm as one of the content codings. Such a content coding would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin server might choose to publish the same data as multiple representations that differ only in whether the coding is defined as part of Content-Type or Content-Encoding, since some user agents will behave differently in their handling of each response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content).
メディアタイプに、常に圧縮されているデータ形式などの固有のエンコードが含まれている場合、コンテンツコーディングの1つと同じアルゴリズムであっても、コンテンツエンコードでエンコードは修正されません。このようなコンテンツコーディングは、いくつかの奇妙な理由で、表現を形成するために2度目に適用された場合にのみリストされます。同様に、Origin Serverは、一部のユーザーエージェントが各応答の処理で異なる動作を異なるため、コーディングがコンテンツタイプまたはコンテンツエンコードの一部として定義されるかどうかのみが異なる複数の表現と同じデータを公開することを選択できます（例：、自動減圧とコンテンツのレンダリングの代わりに「保存...」ダイアログを開きます）。
An origin server MAY respond with a status code of 415 (Unsupported Media Type) if a representation in the request message has a content coding that is not acceptable.
リクエストメッセージの表現に受け入れられないコンテンツコーディングがある場合、Origin Serverは415（サポートされていないメディアタイプ）のステータスコードで応答できます。
Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted directly, and only decoded by the final recipient.
コンテンツコーディング値は、表現に適用された、または適用できるエンコード変換を示します。コンテンツコーディングは、主に、基礎となるメディアタイプのアイデンティティを失うことなく、情報を失うことなく、表現を圧縮またはその他の方法で有効に変換できるようにするために使用されます。多くの場合、表現はコード化された形式で保存され、直接送信され、最終受信者によってのみ解読されます。
content-coding = token
All content codings are case-insensitive and ought to be registered within the "HTTP Content Coding Registry", as described in Section 16.6
セクション16.6で説明されているように、すべてのコンテンツコーディングはケース非感受性であり、「HTTPコンテンツコーディングレジストリ」に登録する必要があります。
Content-coding values are used in the Accept-Encoding (Section 12.5.3) and Content-Encoding (Section 8.4) header fields.
コンテンツコーディング値は、受け入れエンコード（セクション12.5.3）およびコンテンツエンコード（セクション8.4）ヘッダーフィールドで使用されます。
The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding [Welch] that is commonly produced by the UNIX file compression program "compress". A recipient SHOULD consider "x-compress" to be equivalent to "compress".
「Compress」コーディングは、UNIXファイル圧縮プログラム「Compress」によって一般的に生成される適応型Lempel-Ziv-Welch（LZW）コーディング[Welch]です。受信者は、「X-Compress」が「圧縮」と同等であると考える必要があります。
The "deflate" coding is a "zlib" data format [RFC1950] containing a "deflate" compressed data stream [RFC1951] that uses a combination of the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
「DEFLATE」コーディングは、Lempel-ZIV（LZ77）圧縮アルゴリズムとHuffmanコーディングの組み合わせを使用する「デフレート」圧縮データストリーム[RFC1951]を含む「ZLIB」データ形式[RFC1950]です。
| *Note:* Some non-conformant implementations send the "deflate" | compressed data without the zlib wrapper.
|*注：*いくつかの不適合実装は「deflate」を送信します|Zlibラッパーなしの圧縮データ。
The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file compression program [RFC1952]. A recipient SHOULD consider "x-gzip" to be equivalent to "gzip".
「GZIP」コーディングは、GZIPファイル圧縮プログラム[RFC1952]によって一般的に生成される32ビット環状冗長チェック（CRC）を備えたLZ77コーディングです。受信者は、「x-gzip」が「gzip」に相当すると考える必要があります。
The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note that this might not be equivalent to all the languages used within the representation.
「コンテンツ言語」ヘッダーフィールドは、表現の対象となる聴衆の自然言語を説明しています。これは、表現内で使用されるすべての言語と同等ではない可能性があることに注意してください。
Content-Language = #language-tag
Language tags are defined in Section 8.5.1. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the users' own preferred language. Thus, if the content is intended only for a Danish-literate audience, the appropriate field is
言語タグは、セクション8.5.1で定義されています。コンテンツ言語の主な目的は、ユーザーがユーザー自身の優先言語に従って表現を特定して区別できるようにすることです。したがって、コンテンツがデンマーク語の聴衆のためだけに意図されている場合、適切なフィールドは
Content-Language: da
コンテンツ言語：DA
If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.
コンテンツ言語が指定されていない場合、デフォルトは、コンテンツがすべての言語オーディエンスを対象としていることです。これは、送信者がそれを自然言語に固有のものとは見なさないこと、または送信者がどの言語が意図されているかを知らないことを意味するかもしれません。
Multiple languages MAY be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented simultaneously in the original Maori and English versions, would call for
複数の言語は、複数の聴衆を対象としたコンテンツにリストされている場合があります。たとえば、元のマオリ版と英語版で同時に提示された「ワイタンギ条約」の演出は、
Content-Language: mi, en
Content-Language：mi、en
However, just because multiple languages are present within a representation does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
ただし、複数の言語が表現内に存在するからといって、複数の言語の聴衆を対象としているという意味ではありません。例は、「ラテン語の最初のレッスン」などの初心者の言語入門書です。これは、英語の聴衆が明らかに使用することを目的としています。この場合、コンテンツ言語には「EN」のみが適切に含まれます。
Content-Language MAY be applied to any media type -- it is not limited to textual documents.
コンテンツ言語は、あらゆるメディアタイプに適用される場合があります。これは、テキスト文書に限定されません。
A language tag, as defined in [RFC5646], identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded.
[RFC5646]で定義されている言語タグは、他の人間との情報のコミュニケーションのために人間によって話された、書かれた、またはその他の方法で伝えられた自然言語を識別します。コンピューター言語は明示的に除外されています。
HTTP uses language tags within the Accept-Language and Content-Language header fields. Accept-Language uses the broader language-range production defined in Section 12.5.4, whereas Content-Language uses the language-tag production defined below.
HTTPは、Accept-LanguageおよびContent-Languageヘッダーフィールド内で言語タグを使用します。Accept-Languageは、セクション12.5.4で定義されているより広範な言語範囲制作を使用しますが、コンテンツ言語は以下に定義されている言語タグの生産を使用します。
language-tag = <Language-Tag, see [RFC5646], Section 2.1>
A language tag is a sequence of one or more case-insensitive subtags, each separated by a hyphen character ("-", %x2D). In most cases, a language tag consists of a primary language subtag that identifies a broad family of related languages (e.g., "en" = English), which is optionally followed by a series of subtags that refine or narrow that language's range (e.g., "en-CA" = the variety of English as communicated in Canada). Whitespace is not allowed within a language tag. Example tags include:
言語タグは、それぞれがハイフン文字（ " - "、％x2d）で区切られた1つまたは複数のケースに影響を与えるサブタグのシーケンスです。ほとんどの場合、言語タグは、関連する言語の幅広いファミリ（「EN」=英語）を識別する一次言語サブタグで構成されています。「en-ca」=カナダで通信した英語の多様性）。ホワイトスペースは言語タグ内では許可されていません。タグの例は次のとおりです。
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
fr、en-us、es-419、az-arab、x-pig-latin、man-nkoo-gn
See [RFC5646] for further information.
詳細については、[RFC5646]を参照してください。
The "Content-Length" header field indicates the associated representation's data length as a decimal non-negative integer number of octets. When transferring a representation as content, Content-Length refers specifically to the amount of data enclosed so that it can be used to delimit framing (e.g., Section 6.2 of [HTTP/1.1]). In other cases, Content-Length indicates the selected representation's current length, which can be used by recipients to estimate transfer time or to compare with previously stored representations.
「コンテンツレングス」ヘッダーフィールドは、関連する表現のデータ長さを10進陰性の整数数のオクテット数として示します。表現をコンテンツとして転送する場合、コンテンツ長は、フレーミングを区切るために使用できるように、囲まれたデータの量を特異的に指します（例：[http/1.1]のセクション6.2）。それ以外の場合、コンテンツ長は選択された表現の現在の長さを示します。これは、受信者が転送時間を推定するために使用するか、以前に保存された表現と比較できることを示します。
Content-Length = 1*DIGIT
An example is
例は次のとおりです
Content-Length: 3495
コンテンツレングス：3495
A user agent SHOULD send Content-Length in a request when the method defines a meaning for enclosed content and it is not sending Transfer-Encoding. For example, a user agent normally sends Content-Length in a POST request even when the value is 0 (indicating empty content). A user agent SHOULD NOT send a Content-Length header field when the request message does not contain content and the method semantics do not anticipate such data.
ユーザーエージェントは、メソッドが囲まれたコンテンツの意味を定義する場合、転送エンコードを送信していない場合、リクエストにコンテンツレングスを送信する必要があります。たとえば、ユーザーエージェントは通常、値が0の場合でも、POSTリクエストでコンテンツレングスを送信します（空のコンテンツを示します）。リクエストメッセージにコンテンツが含まれておらず、メソッドセマンティクスがそのようなデータを予測しない場合、ユーザーエージェントはコンテンツ長ヘッダーフィールドを送信してはなりません。
A server MAY send a Content-Length header field in a response to a HEAD request (Section 9.3.2); a server MUST NOT send Content-Length in such a response unless its field value equals the decimal number of octets that would have been sent in the content of a response if the same request had used the GET method.
サーバーは、ヘッドリクエストへの応答でコンテンツレングスヘッダーフィールドを送信する場合があります（セクション9.3.2）。サーバーは、同じ要求がGETメソッドを使用した場合、そのフィールド値が応答のコンテンツに送信されていた10進数のオクテット数に等しい場合を除き、そのような応答でコンテンツ長を送信してはなりません。
A server MAY send a Content-Length header field in a 304 (Not Modified) response to a conditional GET request (Section 15.4.5); a server MUST NOT send Content-Length in such a response unless its field value equals the decimal number of octets that would have been sent in the content of a 200 (OK) response to the same request.
サーバーは、条件付きGETリクエストに対する304（変更されていない）応答（セクション15.4.5）にコンテンツレングスヘッダーフィールドを送信する場合があります。サーバーは、そのフィールド値が、同じ要求に対して200（OK）応答のコンテンツで送信されていた10進数のオクテット数に等しい場合を除き、そのような応答でコンテンツ長を送信してはなりません。
A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content). A server MUST NOT send a Content-Length header field in any 2xx (Successful) response to a CONNECT request (Section 9.3.6).
サーバーは、1xxまたは204（コンテンツなし）のステータスコードを使用して、任意の応答でコンテンツ長ヘッダーフィールドを送信してはなりません。サーバーは、接続要求に対する2xx（成功）応答（セクション9.3.6）でコンテンツレングスヘッダーフィールドを送信してはなりません。
Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server SHOULD send a Content-Length header field when the content size is known prior to sending the complete header section. This will allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse the connection for additional requests.
上記のケースとは別に、転送エンコードがない場合、オリジンサーバーは、完全なヘッダーセクションを送信する前にコンテンツサイズがわかっている場合にコンテンツ長ヘッダーフィールドを送信する必要があります。これにより、下流の受信者は転送進行状況を測定し、受信したメッセージがいつ完了したかを把握し、追加のリクエストの接続を再利用できるようになります。
Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of content, a recipient MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows or precision loss due to integer conversion (Section 17.5).
ゼロ以上のコンテンツレングスフィールド値は有効です。コンテンツの長さに定義された制限はないため、受信者は潜在的に大きな小数数を予測し、整数変換のオーバーフローまたは整数変換による精度の損失による解析エラーを防ぐ必要があります（セクション17.5）。
Because Content-Length is used for message delimitation in HTTP/1.1, its field value can impact how the message is parsed by downstream recipients even when the immediate connection is not using HTTP/1.1. If the message is forwarded by a downstream intermediary, a Content-Length field value that is inconsistent with the received message framing might cause a security failure due to request smuggling or response splitting.
コンテンツレングスはHTTP/1.1のメッセージ区切りに使用されるため、そのフィールド値は、即時接続がHTTP/1.1を使用していない場合でも、下流の受信者によってメッセージが解析される方法に影響を与える可能性があります。メッセージが下流の仲介者によって転送される場合、受信したメッセージフレーミングと矛盾するコンテンツレングスのフィールド値は、密輸または応答の分割を要求するためにセキュリティ障害を引き起こす可能性があります。
As a result, a sender MUST NOT forward a message with a Content-Length header field value that is known to be incorrect.
その結果、送信者は、間違っていることが知られているコンテンツ長ヘッダーフィールド値を持つメッセージを転送してはなりません。
Likewise, a sender MUST NOT forward a message with a Content-Length header field value that does not match the ABNF above, with one exception: a recipient of a Content-Length header field value consisting of the same decimal value repeated as a comma-separated list (e.g, "Content-Length: 42, 42") MAY either reject the message as invalid or replace that invalid field value with a single instance of the decimal value, since this likely indicates that a duplicate was generated or combined by an upstream message processor.
同様に、送信者は、上記のABNFと一致しないコンテンツ長ヘッダーフィールド値でメッセージを転送してはなりません。1つの例外を除きます。分離されたリスト（例： "Content-Length：42、42"）は、メッセージを無効として拒否するか、その無効なフィールド値を10進値の単一のインスタンスに置き換えることができます。上流のメッセージプロセッサ。
The "Content-Location" header field references a URI that can be used as an identifier for a specific resource corresponding to the representation in this message's content. In other words, if one were to perform a GET request on this URI at the time of this message's generation, then a 200 (OK) response would contain the same representation that is enclosed as content in this message.
「コンテンツロケーション」ヘッダーフィールドは、このメッセージのコンテンツの表現に対応する特定のリソースの識別子として使用できるURIを参照しています。言い換えれば、このメッセージの生成時にこのURIでGETリクエストを実行する場合、200（OK）応答には、このメッセージのコンテンツとして囲まれた同じ表現が含まれます。
Content-Location = absolute-URI / partial-URI
The field value is either an absolute-URI or a partial-URI. In the latter case (Section 4), the referenced URI is relative to the target URI ([URI], Section 5).
フィールド値は、絶対尿または部分uriのいずれかです。後者の場合（セクション4）、参照されたURIはターゲットURI（[URI]、セクション5）に関連しています。
The Content-Location value is not a replacement for the target URI (Section 7.1). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME body parts in Section 4 of [RFC2557]. However, its appearance in an HTTP message has some special implications for HTTP recipients.
コンテンツロケーション値は、ターゲットURIの代替ではありません（セクション7.1）。表現メタデータです。[RFC2557]のセクション4のMIMEボディパートに対して定義された同じ名前のヘッダーフィールドと同じ構文とセマンティクスがあります。ただし、HTTPメッセージに登場するには、HTTPレシピエントに特別な意味があります。
If Content-Location is included in a 2xx (Successful) response message and its value refers (after conversion to absolute form) to a URI that is the same as the target URI, then the recipient MAY consider the content to be a current representation of that resource at the time indicated by the message origination date. For a GET (Section 9.3.1) or HEAD (Section 9.3.2) request, this is the same as the default semantics when no Content-Location is provided by the server. For a state-changing request like PUT (Section 9.3.4) or POST (Section 9.3.3), it implies that the server's response contains the new representation of that resource, thereby distinguishing it from representations that might only report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the need for a subsequent GET request.
コンテンツロケーションが2xx（成功）応答メッセージに含まれており、その値がターゲットURIと同じURIに変換された後（絶対形式への変換後）を参照する場合、受信者はコンテンツを現在の表現と見なすことができます。その時点のそのリソースは、メッセージの出典日付で示されました。GET（セクション9.3.1）またはヘッド（セクション9.3.2）リクエストの場合、これはサーバーがコンテンツロケーションが提供されない場合のデフォルトのセマンティクスと同じです。Put（セクション9.3.4）や投稿（セクション9.3.3）などの状態を変える要求の場合、サーバーの応答にはそのリソースの新しい表現が含まれていることを意味し、それにより、アクションについてのみ報告する可能性のある表現と区別します（たとえば、「それはうまくいきました！」）。これにより、Authoringアプリケーションは、その後のGetリクエストを必要とせずにローカルコピーを更新できます。
If Content-Location is included in a 2xx (Successful) response message and its field value refers to a URI that differs from the target URI, then the origin server claims that the URI is an identifier for a different resource corresponding to the enclosed representation. Such a claim can only be trusted if both identifiers share the same resource owner, which cannot be programmatically determined via HTTP.
コンテンツロケーションが2xx（成功）応答メッセージに含まれており、そのフィールド値がターゲットURIとは異なるURIを指す場合、Origin Serverは、URIが囲まれた表現に対応する異なるリソースの識別子であると主張します。このようなクレームは、両方の識別子が同じリソース所有者を共有している場合にのみ信頼できます。
* For a response to a GET or HEAD request, this is an indication that the target URI refers to a resource that is subject to content negotiation and the Content-Location field value is a more specific identifier for the selected representation.
* GETまたはヘッドリクエストへの応答の場合、これはターゲットURIがコンテンツネゴシエーションの対象となるリソースを指し、コンテンツロケーションフィールド値が選択された表現のより具体的な識別子であることを示しています。
* For a 201 (Created) response to a state-changing method, a Content-Location field value that is identical to the Location field value indicates that this content is a current representation of the newly created resource.
* 状態変化方法に対する201（作成）応答の場合、位置フィールド値と同一のコンテンツロケーションフィールド値は、このコンテンツが新しく作成されたリソースの現在の表現であることを示します。
* Otherwise, such a Content-Location indicates that this content is a representation reporting on the requested action's status and that the same report is available (for future access with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as the content of the 200 (OK) response; the Content-Location field value provides an identifier for retrieving a copy of that same receipt in the future.
* それ以外の場合、そのようなコンテンツロケーションは、このコンテンツが要求されたアクションのステータスに関する表現レポートであり、特定のURIで同じレポートが（将来のアクセスのために）利用可能であることを示しています。たとえば、POSTリクエストを介して行われた購入トランザクションには、200（OK）応答のコンテンツとして領収書ドキュメントが含まれる場合があります。コンテンツロケーションフィールド値は、将来同じ領収書のコピーを取得するための識別子を提供します。
A user agent that sends Content-Location in a request message is stating that its value refers to where the user agent originally obtained the content of the enclosed representation (prior to any modifications made by that user agent). In other words, the user agent is providing a back link to the source of the original representation.
リクエストメッセージでコンテンツロケーションを送信するユーザーエージェントは、その値がユーザーエージェントが元々囲まれた表現のコンテンツを取得した場所を指していることを述べています（そのユーザーエージェントによって行われた変更の前）。つまり、ユーザーエージェントは、元の表現のソースへのバックリンクを提供しています。
An origin server that receives a Content-Location field in a request message MUST treat the information as transitory request context rather than as metadata to be saved verbatim as part of the representation. An origin server MAY use that context to guide in processing the request or to save it for other uses, such as within source links or versioning metadata. However, an origin server MUST NOT use such context information to alter the request semantics.
要求メッセージ内のコンテンツロケーションフィールドを受信するOrigin Serverは、表現の一部として逐語的に保存されるメタデータとしてではなく、情報を一時的な要求コンテキストとして扱う必要があります。Origin Serverは、そのコンテキストを使用して、リクエストの処理をガイドしたり、ソースリンク内やバージョン化メタデータなど、他の用途に合わせて保存する場合があります。ただし、Origin Serverは、そのようなコンテキスト情報を使用して要求セマンティクスを変更してはなりません。
For example, if a client makes a PUT request on a negotiated resource and the origin server accepts that PUT (without redirection), then the new state of that resource is expected to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse content selection identifier to update only one of the negotiated representations. If the user agent had wanted the latter semantics, it would have applied the PUT directly to the Content-Location URI.
たとえば、クライアントがネゴシエートされたリソースにリクエストを行い、Origin ServerがそのPut（リダイレクトなし）を受け入れる場合、そのリソースの新しい状態は、そのプットで提供される1つの表現と一致すると予想されます。コンテンツロケーションは、交渉された表現の1つのみを更新するための逆コンテンツ選択識別子の形式として使用することはできません。ユーザーエージェントが後者のセマンティクスを望んでいた場合、コンテンツロケーションURIに直接プットを適用していました。
Resource metadata is referred to as a "validator" if it can be used within a precondition (Section 13.1) to make a conditional request (Section 13). Validator fields convey a current validator for the selected representation (Section 3.2).
リソースメタデータは、条件付き要求（セクション13）を作成するために前提条件（セクション13.1）内で使用できる場合、「バリデーター」と呼ばれます。VALIDATORフィールドは、選択した表現の現在のバリデーターを伝えます（セクション3.2）。
In responses to safe requests, validator fields describe the selected representation chosen by the origin server while handling the response. Note that, depending on the method and status code semantics, the selected representation for a given response is not necessarily the same as the representation enclosed as response content.
安全なリクエストへの応答では、バリデーターフィールドは、応答を処理しながらOrigin Serverによって選択された選択された表現を説明しています。メソッドとステータスコードセマンティクスに応じて、特定の応答の選択された表現は、必ずしも応答コンテンツと囲まれた表現と同じではないことに注意してください。
In a successful response to a state-changing request, validator fields describe the new representation that has replaced the prior selected representation as a result of processing the request.
状態を変える要求に対する応答が成功したため、バリデーターフィールドは、リクエストの処理の結果として以前に選択された表現に置き換えられた新しい表現を説明しています。
For example, an ETag field in a 201 (Created) response communicates the entity tag of the newly created resource's representation, so that the entity tag can be used as a validator in later conditional requests to prevent the "lost update" problem.
たとえば、201（作成された）応答のETAGフィールドは、新しく作成されたリソースの表現のエンティティタグを伝え、エンティティタグを後の条件付きリクエストでバリデーターとして使用できるようにして、「紛失アップデート」の問題を防ぐことができます。
This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions: modification dates (Section 8.8.2) and opaque entity tags (Section 8.8.3). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning [WEBDAV], that are beyond the scope of this specification.
この仕様では、リソース状態を観察し、前提条件のテスト（セクション8.8.2）と不透明なエンティティタグ（セクション8.8.3）のテストに一般的に使用される2つの形式のメタデータを定義します。リソース状態を反映する追加のメタデータは、この仕様の範囲を超えたWeb分散オーサリングやバージョン[WebDav]など、HTTPのさまざまな拡張によって定義されています。
Validators come in two flavors: strong or weak. Weak validators are easy to generate but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult (and occasionally impossible) to generate efficiently. Rather than impose that all forms of resource adhere to the same strength of validator, HTTP exposes the type of validator in use and imposes restrictions on when weak validators can be used as preconditions.
バリデーターには、強いまたは弱いという2つのフレーバーがあります。弱いバリデーターは生成が簡単ですが、比較にはあまり役に立ちません。強力なバリデーターは比較に理想的ですが、効率的に生成することは非常に困難です（そして時には不可能）。あらゆる形態のリソースが同じバリデーターの強度に付着することを課すのではなく、HTTPは使用中のバリデーターのタイプを公開し、弱いバリッターを前処理として使用できる時期に制限を課します。
A "strong validator" is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the content of a 200 (OK) response to GET.
「強力なバリデーター」は、GETの200（OK）応答の内容で観察可能な表現データに変更が発生するたびに値を変更する表現メタデータです。
A strong validator might change for reasons other than a change to the representation data, such as when a semantically significant part of the representation metadata is changed (e.g., Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored responses held by remote caches and authoring tools.
強力なバリデーターは、表現メタデータの意味的に重要な部分が変更された場合など、表現データの変更以外の理由で変更される可能性がありますが（コンテンツタイプなど）、Origin Serverの最善の利益のみがあります。リモートキャッシュとオーサリングツールが保持している保存された応答を無効にする必要がある場合に値を変更します。
Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations associated with a particular resource over time. However, there is no implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same time and does not imply that those representations are equivalent).
キャッシュエントリは、有効期限に関係なく、任意に長期間持続する場合があります。したがって、キャッシュは、遠い過去に取得したバリデーターを使用してエントリを検証しようとする場合があります。強力なバリデーターは、時間の経過とともに特定のリソースに関連付けられたすべての表現のすべてのバージョンにわたって一意です。ただし、異なるリソースの表現全体にわたって一意性の意味はありません（つまり、同じ強力なバリデーターが同時に複数のリソースの表現に使用されている可能性があり、それらの表現が同等であることを意味しません）。
There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations.
実際に使用されているさまざまな強力なバリデーターがあります。最良のものは厳密な改訂制御に基づいており、表現への各変更により、表現が取得できるようになる前に、常に一意のノード名とリビジョン識別子が割り当てられます。応答ヘッダーフィールドが送信される前にデータが利用可能であり、検証リクエストを受信するたびにダイジェストを再計算する必要がない場合、表現データに適用される衝突耐性ハッシュ関数も十分です。ただし、リソースにメタデータのみが異なる明確な表現がある場合、同じデータ形式を共有するメディアタイプをめぐるコンテンツネゴシエーションで発生する可能性があるように、Origin Serverは、それらの表現を区別するために検証ターに追加情報を組み込む必要があります。。
In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data. This weakness might be due to limitations in how the value is calculated (e.g., clock resolution), an inability to ensure uniqueness for all possible representations of the resource, or a desire of the resource owner to group representations by some self-determined set of equivalency rather than unique sequences of data.
対照的に、「弱いバリデーター」は表現メタデータであり、表現データの変更ごとに変更されない可能性があります。この弱点は、値の計算方法（時計解像度など）の制限、リソースのすべての可能な表現の一意性を確保できないこと、または自己決定されたセットのセットによるグループ表現へのリソース所有者の欲求が原因である可能性があります。一意のデータシーケンスではなく、等価性。
An origin server SHOULD change a weak entity tag whenever it considers prior representations to be unacceptable as a substitute for the current representation. In other words, a weak entity tag ought to change whenever the origin server wants caches to invalidate old responses.
Origin Serverは、以前の表現が現在の表現の代替として受け入れられないと考えるたびに、弱いエンティティタグを変更する必要があります。言い換えれば、Origin Serverがキャッシュに古い応答を無効にしたいときはいつでも、弱いエンティティタグが変更されるべきです。
For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server load or weather quality). Likewise, a representation's modification time, if defined with only one-second resolution, might be a weak validator if it is possible for the representation to be modified twice during a single second and retrieved between those modifications.
たとえば、動的測定に基づいてコンテンツの変化が毎秒変化する天気レポートの表現は、キャッシュされた表現を有効にするために、同じ弱いバリデーターを使用して（Origin Serverの観点から）同等の表現のセットにグループ化される可能性があります。妥当な期間（おそらくサーバーの負荷または天気の質に基づいて動的に調整されます）。同様に、表現の変更時間は、1秒の解像度のみで定義されている場合、表現が1秒間に2回変更され、それらの変更の間で取得される可能性がある場合、弱いバリデーターになる可能性があります。
Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data. For example, if the origin server sends the same validator for a representation with a gzip content coding applied as it does for a representation with no content coding, then that validator is weak. However, two simultaneous representations might share the same strong validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data.
同様に、バリデーターは、特定のリソースの2つ以上の表現が同時に同時に同時に共有されている場合、それらの表現が同一の表現データを持っていない限り、弱くなります。たとえば、Origin Serverが、コンテンツコーディングのない表現に適用されるGZIPコンテンツのコーディングを使用した表現に対して同じバリデーターを送信する場合、そのバリデーターは弱いです。ただし、2つの異なるメディアタイプが同じ表現データで利用可能である場合など、表現メタデータが異なる場合、2つの同時表現が同じ強力なバリデーターを共有する場合があります。
Strong validators are usable for all conditional requests, including cache validation, partial content ranges, and "lost update" avoidance. Weak validators are only usable when the client does not require exact equality with previously obtained representation data, such as when validating a cache entry or limiting a web traversal to recent changes.
強力なバリデーターは、キャッシュ検証、部分コンテンツ範囲、「更新の紛失」の回避など、すべての条件付きリクエストに使用できます。弱いバリデーターは、クライアントがキャッシュエントリを検証したり、最近の変更にWebトラバーサルを制限したりする場合など、以前に取得した表現データと正確な平等を必要としない場合にのみ使用可能です。
The "Last-Modified" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request.
応答の「ラスト変更された」ヘッダーフィールドは、リクエストの処理の終了時に決定されたように、選択された表現が最後に変更されたと考えているオリジンサーバーが最後に変更されたと考えている日時を示すタイムスタンプを提供します。
Last-Modified = HTTP-date
An example of its use is
その使用の例は次のとおりです
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
An origin server SHOULD send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined, since its use in conditional requests and evaluating cache freshness ([CACHING]) can substantially reduce unnecessary transfers and significantly improve service availability and scalability.
Origin Serverは、条件付き要求とキャッシュの新鮮さ（[キャッシュ]）の評価（[キャッシュ]）を評価するため、最終変更日を合理的かつ一貫して決定できる選択された表現に対してラスト変更を送信する必要があります。およびスケーラビリティ。
A representation is typically the sum of many parts behind the resource interface. The last-modified time would usually be the most recent time that any of those parts were changed. How that value is determined for any given resource is an implementation detail beyond the scope of this specification.
表現は、通常、リソースインターフェイスの背後にある多くの部分の合計です。ラスト変更された時間は通常、これらの部品のいずれかが変更された最新の時間です。特定のリソースに対してその値がどのように決定されるかは、この仕様の範囲を超えた実装の詳細です。
An origin server SHOULD obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date field value for its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially if the representation changes near the time that the response is generated.
Origin Serverは、応答の日付フィールド値を生成する時間に、可能な限り近い表現の最後の修正値を取得する必要があります。これにより、受信者は、特に応答が生成される時間近くに表現が変化する場合、表現の変更時間を正確に評価することができます。
An origin server with a clock (as defined in Section 5.6.7) MUST NOT generate a Last-Modified date that is later than the server's time of message origination (Date, Section 6.6.1). If the last modification time is derived from implementation-specific metadata that evaluates to some time in the future, according to the origin server's clock, then the origin server MUST replace that value with the message origination date. This prevents a future modification date from having an adverse impact on cache validation.
クロックを備えたOrigin Server（セクション5.6.7で定義されている）は、サーバーのメッセージの起源の時刻（日付、セクション6.6.1）よりも遅いラスト修飾日を生成してはなりません。最後の変更時間が、Origin Serverのクロックに応じて、将来の時間に評価する実装固有のメタデータから導き出されている場合、Origin Serverはその値をメッセージの元気日付に置き換える必要があります。これにより、将来の変更日がキャッシュ検証に悪影響を与えることができなくなります。
An origin server without a clock MUST NOT generate a Last-Modified date for a response unless that date value was assigned to the resource by some other system (presumably one with a clock).
クロックのないOrigin Serverは、その日付値が他のシステム（おそらくクロック付きのシステム）によってリソースに割り当てられていない限り、応答のラスト修飾日を生成してはなりません。
A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules:
リクエストでバリデーターとして使用される場合、ラスト変更時間は、次のルールを使用して、それが強いと推測することができない限り、暗黙のうちに弱くなります。
* The validator is being compared by an origin server to the actual current validator for the representation and,
* バリデーターは、オリジンサーバーによって表現の実際の現在のバリデーターと比較されています。
* That origin server reliably knows that the associated representation did not change twice during the second covered by the presented validator;
* そのOrigin Serverは、提示されたVALIDATORのカバーされている2番目の表現中に関連する表現が2回変更されなかったことを確実に知っています。
or
また
* The validator is about to be used by a client in an If-Modified-Since, If-Unmodified-Since, or If-Range header field, because the client has a cache entry for the associated representation, and
* バリデーターは、クライアントが関連する表現のキャッシュエントリを持っているため、if-Modified-since、if-unmodified-since、またはif-rangeヘッダーフィールドでクライアントが使用しようとしています。
* That cache entry includes a Date value which is at least one second after the Last-Modified value and the client has reason to believe that they were generated by the same clock or that there is enough difference between the Last-Modified and Date values to make clock synchronization issues unlikely;
* そのキャッシュエントリには、ラスト修飾値の少なくとも1秒後の日付値が含まれており、クライアントはそれらが同じクロックで生成されたこと、またはラスト修飾値と日付値の間に十分な違いがあると信じる理由があります。時計の同期の問題はありません。
or
また
* The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation, and
* バリデーターは、中間キャッシュによって、表現のためにキャッシュエントリに保存されているバリデーターと比較されています。
* That cache entry includes a Date value which is at least one second after the Last-Modified value and the cache has reason to believe that they were generated by the same clock or that there is enough difference between the Last-Modified and Date values to make clock synchronization issues unlikely.
* そのキャッシュエントリには、ラスト修飾値の少なくとも1秒後の日付値が含まれており、キャッシュには同じクロックによって生成されたか、ラスト修飾値と日付値の間に十分な違いがあると信じる理由が含まれています。時計の同期の問題はありません。
This method relies on the fact that if two different responses were sent by the origin server during the same second, but both had the same Last-Modified time, then at least one of those responses would have a Date value equal to its Last-Modified time.
この方法は、同じ秒で2つの異なる応答がOrigin Serverによって送信されたが、両方とも同じ永続的な時間を持っていた場合、それらの応答の少なくとも1つはその日付値を持続する日付値を持つという事実に依存しています。時間。
The "ETag" field in a response provides the current entity tag for the selected representation, as determined at the conclusion of handling the request. An entity tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both. An entity tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
応答の「ETAG」フィールドは、リクエストの処理の終了時に決定されたように、選択した表現の現在のエンティティタグを提供します。エンティティタグは、それらの複数の表現が時間の経過に伴うリソース状態の変更に起因するかどうかに関係なく、同じリソースの複数の表現を区別するための不透明な検証装置、複数の表現が同時に有効であるかどうか、またはその両方をもたらすコンテンツネゴシエーションです。エンティティタグは、不透明な引用文字列で構成されており、おそらく弱点インジケーターが付いている可能性があります。
ETag = entity-tag
entity-tag = [ weak ] opaque-tag
weak = %s"W/"
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text
| *Note:* Previously, opaque-tag was defined to be a quoted-
| string ([RFC2616], Section 3.11); thus, some recipients might
| perform backslash unescaping. Servers therefore ought to avoid
| backslash characters in entity tags.
An entity tag can be more reliable for validation than a modification date in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP-date values is not sufficient, or where modification dates are not consistently maintained.
エンティティタグは、変更日、HTTP-DATE値の1秒の解像度では十分ではない場合、または変更日が一貫して維持されていない状況で不便な状況での変更日よりも、検証に対してより信頼性が高い場合があります。
Examples:
例：
ETag: "xyzzy" ETag: W/"xyzzy" ETag: ""
etag： "xyzzy" etag：w/"xyzzy" etag： ""
An entity tag can be either a weak or strong validator, with strong being the default. If an origin server provides an entity tag for a representation and the generation of that entity tag does not satisfy all of the characteristics of a strong validator (Section 8.8.1), then the origin server MUST mark the entity tag as weak by prefixing its opaque value with "W/" (case-sensitive).
エンティティタグは、弱いまたは強いバリデーターのいずれかであり、強いものがデフォルトです。Origin Serverが表現にエンティティタグを提供し、そのエンティティタグの生成が強力なバリデーターのすべての特性を満たしていない場合（セクション8.8.1）、Origin Serverはエンティティタグを弱いとマークする必要があります。「w/」（ケースセンシティブ）の不透明な値。
A sender MAY send the ETag field in a trailer section (see Section 6.5). However, since trailers are often ignored, it is preferable to send ETag as a header field unless the entity tag is generated while sending the content.
送信者は、トレーラーセクションにETAGフィールドを送信できます（セクション6.5を参照）。ただし、トレーラーはしばしば無視されるため、コンテンツの送信中にエンティティタグが生成されない限り、ヘッダーフィールドとしてETAGを送信することが望ましいです。
The principle behind entity tags is that only the service author knows the implementation of a resource well enough to select the most accurate and efficient validation mechanism for that resource, and that any such mechanism can be mapped to a simple sequence of octets for easy comparison. Since the value is opaque, there is no need for the client to be aware of how each entity tag is constructed.
エンティティタグの背後にある原則は、サービス著者のみが、そのリソースの最も正確で効率的な検証メカニズムを選択するのに十分なリソースの実装を知っていること、およびそのようなメカニズムを簡単に比較するためにオクテットのシンプルなシーケンスにマッピングできることです。値は不透明であるため、クライアントが各エンティティタグの構築方法を認識する必要はありません。
For example, a resource that has implementation-specific versioning applied to all changes might use an internal revision number, perhaps combined with a variance identifier for content negotiation, to accurately differentiate between representations. Other implementations might use a collision-resistant hash of representation content, a combination of various file attributes, or a modification timestamp that has sub-second resolution.
たとえば、すべての変更に適用される実装固有のバージョン化を備えたリソースは、おそらくコンテンツネゴシエーションの分散識別子と組み合わせて、表現を正確に区別するための内部改訂番号を使用する場合があります。他の実装では、表現コンテンツの衝突耐性ハッシュ、さまざまなファイル属性の組み合わせ、またはサブセカンドの解像度を持つ変更タイムスタンプを使用する場合があります。
An origin server SHOULD send an ETag for any selected representation for which detection of changes can be reasonably and consistently determined, since the entity tag's use in conditional requests and evaluating cache freshness ([CACHING]) can substantially reduce unnecessary transfers and significantly improve service availability, scalability, and reliability.
オリジンサーバーは、エンティティタグが条件付きリクエストで使用し、キャッシュの鮮度を評価する（[キャッシュ]）を評価し、不必要な転送を大幅に削減し、サービスの可用性を大幅に改善するため、変更の検出が合理的かつ一貫して決定できる選択された表現のETAGを送信する必要があります。、スケーラビリティ、および信頼性。
There are two entity tag comparison functions, depending on whether or not the comparison context allows the use of weak validators:
比較コンテキストが弱いバリエーターの使用を可能にするかどうかに応じて、2つのエンティティタグ比較関数があります。
"Strong comparison": two entity tags are equivalent if both are not weak and their opaque-tags match character-by-character.
「強い比較」：両方が弱くなく、彼らの不透明なタグが文字ごとに一致する場合、2つのエンティティタグが同等です。
"Weak comparison": two entity tags are equivalent if their opaque-tags match character-by-character, regardless of either or both being tagged as "weak".
「弱い比較」：2つのエンティティタグは、不透明なタグが「弱い」とタグ付けされているかどうかに関係なく、キャラクターごとにキャラクターごとに一致する場合と同等です。
The example below shows the results for a set of entity tag pairs and both the weak and strong comparison function results:
以下の例は、エンティティタグペアのセットの結果と、弱い比較関数と強い比較の両方の結果を示しています。
+========+========+===================+=================+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+========+========+===================+=================+
| W/"1" | W/"1" | no match | match |
+--------+--------+-------------------+-----------------+
| W/"1" | W/"2" | no match | no match |
+--------+--------+-------------------+-----------------+
| W/"1" | "1" | no match | match |
+--------+--------+-------------------+-----------------+
| "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+
Table 3
表3
Consider a resource that is subject to content negotiation (Section 12), and where the representations sent in response to a GET request vary based on the Accept-Encoding request header field (Section 12.5.3):
コンテンツネゴシエーションの対象となるリソース（セクション12）、およびGETリクエストに応じて送信される表現が、受け入れエンコードリクエストヘッダーフィールド（セクション12.5.3）に基づいて異なる場合を検討してください。
>> Request:
>>リクエスト：
GET /index HTTP/1.1 Host: www.example.com Accept-Encoding: gzip
Get /Index HTTP /1.1ホスト：www.example.com Accept-Encoding：gzip
In this case, the response might or might not use the gzip content coding. If it does not, the response might look like:
この場合、応答はGZIPコンテンツコーディングを使用する場合と使用できない場合があります。そうでない場合、応答は次のように見える場合があります。
>> Response:
>>応答：
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-a"
Content-Length: 70
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! Hello World! Hello World! Hello World! Hello World!
「こんにちは世界」「こんにちは世界」「こんにちは世界」「こんにちは世界」「こんにちは世界」
An alternative representation that does use gzip content coding would be:
GZIPコンテンツのコーディングを使用する代替表現は、次のとおりです。
>> Response:
>>応答：
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-b"
Content-Length: 43
Vary: Accept-Encoding
Content-Type: text/plain
Content-Encoding: gzip
...binary data...
...バイナリデータ...
| *Note:* Content codings are a property of the representation
| data, so a strong entity tag for a content-encoded
| representation has to be distinct from the entity tag of an
| unencoded representation to prevent potential conflicts during
| cache updates and range requests. In contrast, transfer
| codings (Section 7 of [HTTP/1.1]) apply only during message
| transfer and do not result in distinct entity tags.
The request method token is the primary source of request semantics; it indicates the purpose for which the client has made this request and what is expected by the client as a successful result.
リクエストメソッドトークンは、リクエストセマンティクスの主要なソースです。これは、クライアントがこの要求を行った目的と、クライアントが成功した結果として期待するものを示しています。
The request method's semantics might be further specialized by the semantics of some header fields when present in a request if those additional semantics do not conflict with the method. For example, a client can send conditional request header fields (Section 13.1) to make the requested action conditional on the current state of the target resource.
リクエストメソッドのセマンティクスは、これらの追加セマンティクスがメソッドと矛盾しない場合、リクエストに存在する場合、一部のヘッダーフィールドのセマンティクスによってさらに特化される可能性があります。たとえば、クライアントは条件付きリクエストヘッダーフィールド（セクション13.1）を送信して、ターゲットリソースの現在の状態を条件とする要求されたアクションを作成できます。
HTTP is designed to be usable as an interface to distributed object systems. The request method invokes an action to be applied to a target resource in much the same way that a remote method invocation can be sent to an identified object.
HTTPは、分散オブジェクトシステムのインターフェイスとして使用できるように設計されています。リクエストメソッドは、リモートメソッドの呼び出しを識別されたオブジェクトに送信できるのとほぼ同じ方法で、ターゲットリソースに適用されるアクションを呼び出します。
method = token
The method token is case-sensitive because it might be used as a gateway to object-based systems with case-sensitive method names. By convention, standardized methods are defined in all-uppercase US-ASCII letters.
メソッドトークンは、ケースに敏感なメソッド名を持つオブジェクトベースのシステムへのゲートウェイとして使用される可能性があるため、ケースに敏感です。慣習により、標準化された方法は、全隔離のUS-ASCII文字で定義されます。
Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide for better visibility and reuse in network-based systems [REST]. Once defined, a standardized method ought to have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are implemented or allowed.
分散オブジェクトとは異なり、HTTPの標準化された要求方法はリソース固有ではありません。均一なインターフェイスは、ネットワークベースのシステムでの可視性と再利用を改善するためです。定義されると、標準化されたメソッドは、任意のリソースに適用されると同じセマンティクスを持つ必要がありますが、各リソースは、それらのセマンティクスが実装または許可されているかどうか自体を決定します。
This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table.
この仕様は、次の表で概説されているように、HTTPで一般的に使用される多くの標準化されたメソッドを定義します。
+=========+============================================+=========+
| Method | Description | Section |
| Name | | |
+=========+============================================+=========+
| GET | Transfer a current representation of the | 9.3.1 |
| | target resource. | |
+---------+--------------------------------------------+---------+
| HEAD | Same as GET, but do not transfer the | 9.3.2 |
| | response content. | |
+---------+--------------------------------------------+---------+
| POST | Perform resource-specific processing on | 9.3.3 |
| | the request content. | |
+---------+--------------------------------------------+---------+
| PUT | Replace all current representations of the | 9.3.4 |
| | target resource with the request content. | |
+---------+--------------------------------------------+---------+
| DELETE | Remove all current representations of the | 9.3.5 |
| | target resource. | |
+---------+--------------------------------------------+---------+
| CONNECT | Establish a tunnel to the server | 9.3.6 |
| | identified by the target resource. | |
+---------+--------------------------------------------+---------+
| OPTIONS | Describe the communication options for the | 9.3.7 |
| | target resource. | |
+---------+--------------------------------------------+---------+
| TRACE | Perform a message loop-back test along the | 9.3.8 |
| | path to the target resource. | |
+---------+--------------------------------------------+---------+
Table 4
表4
All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL.
すべての汎用サーバーは、メソッドの取得とヘッドをサポートする必要があります。他のすべての方法はオプションです。
The set of methods allowed by a target resource can be listed in an Allow header field (Section 10.2.1). However, the set of allowed methods can change dynamically. An origin server that receives a request method that is unrecognized or not implemented SHOULD respond with the 501 (Not Implemented) status code. An origin server that receives a request method that is recognized and implemented, but not allowed for the target resource, SHOULD respond with the 405 (Method Not Allowed) status code.
ターゲットリソースで許可されるメソッドのセットは、許容ヘッダーフィールド（セクション10.2.1）にリストできます。ただし、許可されたメソッドのセットは動的に変更できます。認識されていないまたは実装されていないリクエストメソッドを受信するOrigin Serverは、501（実装されていない）ステータスコードで応答する必要があります。認識および実装されているがターゲットリソースに許可されていないリクエストメソッドを受信するOrigin Serverは、405（許可されていない）ステータスコードで応答する必要があります。
Additional methods, outside the scope of this specification, have been specified for use in HTTP. All such methods ought to be registered within the "Hypertext Transfer Protocol (HTTP) Method Registry", as described in Section 16.1.
この仕様の範囲外の追加方法は、HTTPで使用するために指定されています。このようなすべての方法は、セクション16.1で説明されているように、「HyperText Transfer Protocol（HTTP）メソッドレジストリ」に登録する必要があります。
Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
定義されたセマンティクスが本質的に読み取り専用である場合、リクエスト方法は「安全」と見なされます。つまり、クライアントは、ターゲットリソースに安全な方法を適用した結果として、Origin Serverの状態変更を要求せず、予想しません。同様に、安全な方法の合理的な使用は、害、財産の喪失、またはOrigin Serverの異常な負担を引き起こすとは期待されていません。
This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and cause the server to fail. Likewise, a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.
安全な方法のこの定義は、実装が潜在的に有害な動作、完全に読み取り専用ではない、または安全な方法を呼び出しながら副作用を引き起こす動作を含めることを妨げません。しかし、重要なのは、クライアントがその追加の動作を要求せず、それに対して説明責任を持たせることができないことです。たとえば、ほとんどのサーバーは、メソッドに関係なく、すべての応答の完了時にログファイルにアクセスするための要求情報を追加します。これは、ログストレージがいっぱいになり、サーバーが失敗する可能性がある場合でも安全であると見なされます。同様に、Web上で広告を選択することで開始される安全な要求は、多くの場合、広告アカウントを請求する副作用があります。
Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.
この仕様で定義された要求方法のうち、GET、ヘッド、オプション、およびトレースメソッドは安全であると定義されています。
The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.
安全な方法と安全でない方法を区別する目的は、自動検索プロセス（クモ）とキャッシュパフォーマンスの最適化（事前フェッチング）が害を引き起こすことを恐れずに動作させることを可能にすることです。さらに、ユーザーエージェントは、信頼できないコンテンツを処理する際に、安全でないメソッドの自動使用に適切な制約を適用できます。
A user agent SHOULD distinguish between safe and unsafe methods when presenting potential actions to a user, such that the user can be made aware of an unsafe action before it is requested.
ユーザーエージェントは、ユーザーに潜在的なアクションを提示する際に安全な方法と安全でないメソッドを区別する必要があります。そのため、ユーザーは要求される前に安全でないアクションを認識させることができます。
When a resource is constructed such that parameters within the target URI have the effect of selecting an action, it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example, it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete". If the purpose of such a resource is to perform an unsafe action, then the resource owner MUST disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate side effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching, building a search index, etc.
ターゲットURI内のパラメーターがアクションを選択する効果を持つようにリソースが構築される場合、アクションがリクエストメソッドセマンティクスと一致することを確認することはリソース所有者の責任です。たとえば、Webベースのコンテンツ編集ソフトウェアが「ページ？do = delete」などのクエリパラメーター内でアクションを使用することが一般的です。このようなリソースの目的が安全でないアクションを実行することである場合、リソースの所有者は、安全な要求方法を使用してアクセスしたときにそのアクションを無効または禁止する必要があります。自動化されたプロセスが、リンクメンテナンス、事前フェッチ、検索インデックスの構築など、すべてのURIリファレンスでGetを実行すると、不幸な副作用が発生します。
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.
要求方法は、そのメソッドを使用した複数の同一の要求のサーバーへの意図した効果が、そのような単一の要求の効果と同じである場合、「等程度」と見なされます。この仕様で定義された要求方法、put、削除、および安全な要求方法はidempotentです。
Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.
SAFEの定義と同様に、iDempotentプロパティは、ユーザーが要求されたものにのみ適用されます。サーバーは、各要求を個別にログに記録するか、リビジョン制御履歴を保持するか、各アイデンポテントリクエストに他の非公開副作用を実装できます。
Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.
クライアントがサーバーの応答を読み取ることができる前に通信障害が発生した場合、要求を自動的に繰り返すことができるため、iDempotentメソッドは区別されます。たとえば、クライアントがPUTリクエストを送信し、応答を受信する前に基礎となる接続が閉じられた場合、クライアントは新しい接続を確立し、iDempotentリクエストを再試行できます。リクエストを繰り返すと、元のリクエストが成功したとしても、同じ意図した効果があることがわかっていますが、応答は異なる場合があります。
A client SHOULD NOT automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied.
クライアントは、リクエストセマンティクスが実際に等身であることを知る手段がない場合、または元の要求が適用されないことを検出する手段を知る手段がない限り、非公開のメソッドでリクエストを自動的に再試行するべきではありません。
For example, a user agent can repeat a POST request automatically if it knows (through design or configuration) that the request is safe for that resource. Likewise, a user agent designed specifically to operate on a version control repository might be able to recover from partial failure conditions by checking the target resource revision(s) after a failed connection, reverting or fixing any changes that were partially applied, and then automatically retrying the requests that failed.
たとえば、ユーザーエージェントは、リクエストがそのリソースに対して安全であることを（設計または構成を通じて）知っている場合、自動的にPOSTリクエストを繰り返すことができます。同様に、バージョンコントロールリポジトリで動作するように特別に設計されたユーザーエージェントは、接続の失敗後にターゲットリソースの改訂をチェックし、部分的に適用された変更を戻すか修正してから自動的に修正することにより、部分障害条件から回復できる場合があります。失敗したリクエストを再試行します。
Some clients take a riskier approach and attempt to guess when an automatic retry is possible. For example, a client might automatically retry a POST request if the underlying transport connection closed before any part of a response is received, particularly if an idle persistent connection was used.
一部のクライアントは、よりリスクの高いアプローチを取り、自動再試行がいつ可能かを推測しようとします。たとえば、クライアントは、特にアイドルの永続的な接続が使用された場合、応答の一部が受信される前に基礎となるトランスポート接続が閉じた場合、自動的にPOSTリクエストを再試行する場合があります。
A proxy MUST NOT automatically retry non-idempotent requests. A client SHOULD NOT automatically retry a failed automatic retry.
プロキシは、非公開のリクエストを自動的に再試行してはなりません。クライアントは、自動再試行に自動的に再試行してはなりません。
For a cache to store and use a response, the associated method needs to explicitly allow caching and to detail under what conditions a response can be used to satisfy subsequent requests; a method definition that does not do so cannot be cached. For additional requirements see [CACHING].
応答を保存して使用するキャッシュの場合、関連する方法は、後続の要求を満たすために応答を使用できる条件下で、キャッシュを明示的に許可し、詳細にする必要があります。そうしないメソッド定義をキャッシュすることはできません。追加要件については、[キャッシュ]を参照してください。
This specification defines caching semantics for GET, HEAD, and POST, although the overwhelming majority of cache implementations only support GET and HEAD.
この仕様では、Get、Head、およびPostのキャッシュセマンティクスを定義しますが、圧倒的多数のキャッシュ実装はGETとヘッドのみをサポートしています。
The GET method requests transfer of a current selected representation for the target resource. A successful response reflects the quality of "sameness" identified by the target URI (Section 1.2.2 of [URI]). Hence, retrieving identifiable information via HTTP is usually performed by making a GET request on an identifier associated with the potential for providing that information in a 200 (OK) response.
GETメソッドは、ターゲットリソースの現在の選択された表現の転送を要求します。成功した応答は、ターゲットURI（[URI]のセクション1.2.2）によって特定された「同一性」の質を反映しています。したがって、HTTPを介して識別可能な情報を取得することは、通常、200（OK）応答でその情報を提供する可能性に関連する識別子にGETリクエストを行うことにより実行されます。
GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Applications that produce a URI for each important resource can benefit from those optimizations while enabling their reuse by other applications, creating a network effect that promotes further expansion of the Web.
GETは、情報検索の主要なメカニズムであり、ほぼすべてのパフォーマンスの最適化の焦点です。重要なリソースごとにURIを生成するアプリケーションは、他のアプリケーションによって再利用できるようになり、Webのさらなる拡張を促進するネットワーク効果を作成しながら、それらの最適化から利益を得ることができます。
It is tempting to think of resource identifiers as remote file system pathnames and of representations as being a copy of the contents of such files. In fact, that is how many resources are implemented (see Section 17.3 for related security considerations). However, there are no such limitations in practice.
リソース識別子をリモートファイルシステムパス名と考え、表現をそのようなファイルの内容のコピーとして考えるのは魅力的です。実際、それはいくつのリソースが実装されているかです（関連するセキュリティに関する考慮事項については、セクション17.3を参照）。ただし、実際にはそのような制限はありません。
The HTTP interface for a resource is just as likely to be implemented as a tree of content objects, a programmatic view on various database records, or a gateway to other information systems. Even when the URI mapping mechanism is tied to a file system, an origin server might be configured to execute the files with the request as input and send the output as the representation rather than transfer the files directly. Regardless, only the origin server needs to know how each resource identifier corresponds to an implementation and how that implementation manages to select and send a current representation of the target resource.
リソースのHTTPインターフェイスは、コンテンツオブジェクトのツリー、さまざまなデータベースレコードのプログラムビュー、または他の情報システムへのゲートウェイと同じように実装される可能性があります。URIマッピングメカニズムがファイルシステムに関連付けられている場合でも、リクエストとしてファイルを入力してファイルを実行し、ファイルを直接転送するのではなく表現として出力を送信するようにOrigin Serverが設定される場合があります。とにかく、各リソース識別子が実装にどのように対応するか、およびその実装がターゲットリソースの現在の表現を選択して送信する方法を知る必要があるOrigin Serverのみが必要です。
A client can alter the semantics of GET to be a "range request", requesting transfer of only some part(s) of the selected representation, by sending a Range header field in the request (Section 14.2).
クライアントは、Get of Getのセマンティクスを「範囲リクエスト」に変更し、選択した表現の一部のみを要求して、リクエストに範囲ヘッダーフィールドを送信することで要求できます（セクション14.2）。
Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.
リクエストメッセージフレーミングは使用された方法とは独立していますが、GETリクエストで受信したコンテンツには一般的に定義されたセマンティクスがなく、リクエストの意味やターゲットを変更することはできません。密輸攻撃の要求として（[http/1.1]のセクション11.2）。クライアントは、そのようなリクエストには目的があり、適切にサポートされることを以前に示していたOrigin Serverに直接作成されない限り、GETリクエストでコンテンツを生成するべきではありません。HTTP通信の参加者は、リクエストチェーンに沿った仲介者を知らないことが多いため、Origin Serverはコンテンツを受信するための民間契約に依存してはなりません。
The response to a GET request is cacheable; a cache MAY use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [CACHING]).
GETリクエストへの応答はキャッシュ可能です。キャッシュを使用して、キャッシュコントロールヘッダーフィールド（[キャッシュ]のセクション5.2）で特に示されない限り、後続のGETおよびヘッドリクエストを満たすことができます。
When information retrieval is performed with a mechanism that constructs a target URI from user-provided information, such as the query fields of a form using GET, potentially sensitive data might be provided that would not be appropriate for disclosure within a URI (see Section 17.9). In some cases, the data can be filtered or transformed such that it would not reveal such information. In others, particularly when there is no benefit from caching a response, using the POST method (Section 9.3.3) instead of GET can transmit such information in the request content rather than within the target URI.
GETを使用してフォームのクエリフィールドなど、ユーザーが提供する情報からターゲットURIを構築するメカニズムを使用して情報を取得すると、URI内の開示には適していない潜在的に機密データが提供される場合があります（セクション17.9を参照）。場合によっては、そのような情報が明らかにならないように、データをフィルタリングまたは変換できます。他の場合は、特に応答をキャッシュすることから利益がない場合、GETの代わりにPOSTメソッド（セクション9.3.3）を使用して、ターゲットURI内ではなくリクエストコンテンツにそのような情報を送信できます。
The HEAD method is identical to GET except that the server MUST NOT send content in the response. HEAD is used to obtain metadata about the selected representation without transferring its representation data, often for the sake of testing hypertext links or finding recent modifications.
ヘッドメソッドは、サーバーが応答にコンテンツを送信してはならないことを除いて、取得するのと同じです。ヘッドは、多くの場合、ハイパーテキストリンクをテストしたり、最近の変更を見つけたりするために、表現データを転送せずに選択した表現に関するメタデータを取得するために使用されます。
The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request method had been GET. However, a server MAY omit header fields for which a value is determined only while generating the content. For example, some servers buffer a dynamic response to GET until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to GET might contain Content-Length and Vary fields, for example, that are not generated within a HEAD response. These minor inconsistencies are considered preferable to generating and discarding the content for a HEAD request, since HEAD is usually requested for the sake of efficiency.
サーバーは、リクエストメソッドが取得された場合に送信されるヘッドリクエストに応じて、同じヘッダーフィールドを送信する必要があります。ただし、サーバーは、コンテンツの生成中にのみ値が決定されるヘッダーフィールドを省略する場合があります。たとえば、一部のサーバーは、最小限の量のデータが生成されるまで動的な応答をバッファーして、小さな応答をより効率的に区切るか、コンテンツの選択に関して遅い決定を下すことができるようにします。GETに対するこのような応答には、たとえば、ヘッド応答内で生成されないコンテンツレングスと変化するフィールドが含まれている場合があります。これらの軽度の矛盾は、ヘッドリクエストのコンテンツを生成および破棄するよりも好ましいと考えられています。これは、ヘッドが通常効率のために要求されるためです。
Although request message framing is independent of the method used, content received in a HEAD request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a HEAD request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.
リクエストメッセージフレーミングは使用される方法とは独立していますが、ヘッドリクエストで受信したコンテンツには一般的に定義されたセマンティクスがなく、リクエストの意味やターゲットを変更することはできず、リクエストを拒否して接続を閉じるためのいくつかの実装を導く可能性があります。密輸攻撃の要求として（[http/1.1]のセクション11.2）。クライアントは、そのようなリクエストには目的があり、適切にサポートされることを以前に示していたOrigin Serverに直接作成されない限り、ヘッドリクエストでコンテンツを生成するべきではありません。HTTP通信の参加者は、リクエストチェーンに沿った仲介者を知らないことが多いため、Origin Serverはコンテンツを受信するための民間契約に依存してはなりません。
The response to a HEAD request is cacheable; a cache MAY use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [CACHING]). A HEAD response might also affect previously cached responses to GET; see Section 4.3.5 of [CACHING].
ヘッドリクエストへの応答はキャッシュ可能です。キャッシュは、それを使用して、キャッシュコントロールヘッダーフィールド（[キャッシュ]のセクション5.2）で特に示されない限り、後続のヘッドリクエストを満たすことができます。頭の応答は、以前にキャッシュされた応答に影響を与える可能性があります。[キャッシュ]のセクション4.3.5を参照してください。
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):
POSTメソッドは、ターゲットリソースがリクエストに囲まれた表現をリソースの特定のセマンティクスに従って処理することを要求します。たとえば、POSTは次の機能（とりわけ）に使用されます。
* Providing a block of data, such as the fields entered into an HTML form, to a data-handling process;
* HTMLフォームに入力されたフィールドなどのデータブロックをデータ処理プロセスに提供します。
* Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
* 掲示板、ニュースグループ、メーリングリスト、ブログ、または同様の記事グループにメッセージを投稿します。
* Creating a new resource that has yet to be identified by the origin server; and
* Origin Serverによってまだ識別されていない新しいリソースを作成します。と
* Appending data to a resource's existing representation(s).
* リソースの既存の表現にデータを追加します。
An origin server indicates response semantics by choosing an appropriate status code depending on the result of processing the POST request; almost all of the status codes defined by this specification could be received in a response to POST (the exceptions being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not Satisfiable)).
Origin Serverは、POSTリクエストの処理の結果に応じて適切なステータスコードを選択することにより、応答セマンティクスを示します。この仕様で定義されたステータスコードのほぼすべては、POST（例外は206（部分コンテンツ）、304（変更されていない）、および416（範囲が満たされない））への応答で受信できます。
If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing a Location header field that provides an identifier for the primary resource created (Section 10.2.2) and a representation that describes the status of the request while referring to the new resource(s).
POSTリクエストの処理に正常に処理された結果としてOrigin Serverに1つ以上のリソースが作成された場合、Origin Serverは、作成されたプライマリリソースの識別子を提供するロケーションヘッダーフィールドを含む201（作成）応答を送信する必要があります（セクション10.2 10.2.2）および新しいリソースを参照しながらリクエストのステータスを説明する表現。
Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [CACHING]) and a Content-Location header field that has the same value as the POST's target URI (Section 8.7). A cached POST response can be reused to satisfy a later GET or HEAD request. In contrast, a POST request cannot be satisfied by a cached POST response because POST is potentially unsafe; see Section 4 of [CACHING].
投稿リクエストへの回答は、明示的な新鮮さ情報（[キャッシュ]のセクション4.2.1を参照）と、ポストのターゲットURIと同じ値を持つコンテンツロケーションヘッダーフィールド（セクション8.7）を含める場合にのみキャッシュ可能です。キャッシュされたポスト応答を再利用して、後の取得またはヘッドリクエストを満たすことができます。対照的に、ポストが安全でない可能性があるため、キャッシュされたポスト応答では、投稿リクエストを満たすことはできません。[キャッシュ]のセクション4を参照してください。
If the result of processing a POST would be equivalent to a representation of an existing resource, an origin server MAY redirect the user agent to that resource by sending a 303 (See Other) response with the existing resource's identifier in the Location field. This has the benefits of providing the user agent a resource identifier and transferring the representation via a method more amenable to shared caching, though at the cost of an extra request if the user agent does not already have the representation cached.
投稿の処理の結果が既存のリソースの表現に相当する場合、Origin Serverは、ロケーションフィールドの既存のリソースの識別子と303（他の）応答を送信することにより、ユーザーエージェントをそのリソースにリダイレクトする場合があります。これには、ユーザーエージェントが共有キャッシュをより適切にする方法を介してユーザーエージェントにリソース識別子を提供し、表現を転送する利点がありますが、ユーザーエージェントがまだキャッシュされていない場合は追加の要求を犠牲にします。
The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message content. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
PUTメソッドは、ターゲットリソースの状態を作成または置き換えることを要求します。リクエストメッセージコンテンツに囲まれた表現によって定義された状態に置き換えられます。特定の表現を成功させると、その後の同じターゲットリソースに乗ると、200（OK）応答で同等の表現が送信されることが示唆されます。ただし、ターゲットリソースが他のユーザーエージェントによって並行して行動される可能性があるか、後続のGETを受信する前にOrigin Serverによる動的処理の対象となる可能性があるため、このような状態の変更が観察可能であるという保証はありません。応答の成功は、Origin Serverによる処理時にユーザーエージェントの意図が達成されたことを意味します。
If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.
ターゲットリソースに現在の表現がなく、PUTが正常に作成する場合、Origin Serverは201（作成）応答を送信してユーザーエージェントに通知する必要があります。ターゲットリソースに現在の表現があり、その表現が囲まれた表現の状態に従って正常に変更されている場合、Origin Serverは200（OK）または204（コンテンツなし）応答のいずれかを送信する必要があります。リクエスト。
An origin server SHOULD verify that the PUT representation is consistent with its configured constraints for the target resource. For example, if an origin server determines a resource's representation metadata based on the URI, then the origin server needs to ensure that the content received in a successful PUT request is consistent with that metadata. When a PUT representation is inconsistent with the target resource, the origin server SHOULD either make them consistent, by transforming the representation or changing the resource configuration, or respond with an appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type values.
Origin Serverは、プット表現がターゲットリソースの構成された制約と一致していることを確認する必要があります。たとえば、Origin ServerがURIに基づいてリソースの表現メタデータを決定する場合、Origin Serverは、成功したPutリクエストで受信されたコンテンツがそのメタデータと一致することを確認する必要があります。プット表現がターゲットリソースと矛盾する場合、Origin Serverは、表現を変換するか、リソース構成を変更するか、表現が不適切である理由を説明するための十分な情報を含む適切なエラーメッセージで応答することにより、それらを一貫性にする必要があります。409（競合）または415（サポートされていないメディアタイプ）ステータスコードが推奨され、後者はコンテンツタイプの値の制約に固有のものです。
For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", the origin server ought to do one of:
たとえば、ターゲットリソースが常に「テキスト/HTML」のコンテンツタイプを持っているように構成されており、配置されている表現には「Image/JPEG」のコンテンツタイプがある場合、Origin Serverは次のいずれかを実行する必要があります。
a. reconfigure the target resource to reflect the new media type;
a. ターゲットリソースを再構成して、新しいメディアタイプを反映します。
b. transform the PUT representation to a format consistent with that of the resource before saving it as the new resource state; or,
b. プット表現を新しいリソース状態として保存する前に、リソースの表現と一致する形式に変換します。また、
c. reject the request with a 415 (Unsupported Media Type) response indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would be a suitable target for the new representation.
c. ターゲットリソースが「テキスト/HTML」に限定されていることを示す415（サポートされていないメディアタイプ）応答でリクエストを拒否します。
HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how such storage might change as a result of a change in resource state, nor how the origin server translates resource state into representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by the server.
HTTPは、PUTメソッドが、ユーザーエージェント要求の意図とOrigin Server Responseのセマンティクスによって表現できるものを超えて、Origin Serverの状態にどのように影響するかを正確に定義しません。その単語の意味で、HTTPを介して提供されるインターフェイスを超えて、リソースが何であるかを定義するものではありません。リソース状態の「保存」や、リソース状態の変更の結果としてそのようなストレージがどのように変化するか、またはOrigin Serverがリソース状態を表現にどのように変換するかを定義するものではありません。一般的に、リソースインターフェイスの背後にあるすべての実装の詳細は、サーバーによって意図的に隠されています。
This extends to how header and trailer fields are stored; while common header fields like Content-Type will typically be stored and returned upon subsequent GET requests, header and trailer field handling is specific to the resource that received the request. As a result, an origin server SHOULD ignore unrecognized header and trailer fields received in a PUT request (i.e., not save them as part of the resource state).
これは、ヘッダーフィールドとトレーラーフィールドの保存方法にまで及びます。コンテンツタイプのような一般的なヘッダーフィールドは通常、後続のGETリクエストで保存および返されますが、ヘッダーとトレーラーのフィールドの取り扱いは、リクエストを受け取ったリソースに固有です。その結果、Origin Serverは、Putリクエストで受信した認識されていないヘッダーおよびトレーラーフィールドを無視する必要があります（つまり、リソース状態の一部としてそれらを保存しません）。
An origin server MUST NOT send a validator field (Section 8.8), such as an ETag or Last-Modified field, in a successful response to PUT unless the request's representation data was saved without any transformation applied to the content (i.e., the resource's new representation data is identical to the content received in the PUT request) and the validator field value reflects the new representation. This requirement allows a user agent to know when the representation it sent (and retains in memory) is the result of the PUT, and thus it doesn't need to be retrieved again from the origin server. The new validator(s) received in the response can be used for future conditional requests in order to prevent accidental overwrites (Section 13.1).
Origin Serverは、リクエストの表現データがコンテンツに適用されずに保存されない限り、PUTに対する正常な応答で、ETAGまたはラスト修飾フィールドなどのバリデーターフィールド（セクション8.8）を送信してはなりません（つまり、リソースの新しいものに適用されない限り表現データは、PUTリクエストで受信したコンテンツと同一です）、VALIDATORフィールド値は新しい表現を反映しています。この要件により、ユーザーエージェントが送信した表現（およびメモリに保持する）がPUTの結果であることを知ることができるため、Origin Serverから再び取得する必要はありません。応答で受け取った新しいバリデーターは、偶発的な上書きを防ぐために、将来の条件付き要求に使用できます（セクション13.1）。
The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.
ポストメソッドとPUTメソッドの根本的な違いは、囲まれた表現の異なる意図によって強調されています。POSTリクエストのターゲットリソースは、リソース自身のセマンティクスに従って囲まれた表現を処理することを目的としていますが、PUTリクエストの囲まれた表現は、ターゲットリソースの状態を置き換えるものとして定義されます。したがって、正確な効果はOrigin Serverによってのみ知られているにもかかわらず、Putの意図は等隊であり、仲介者に見えるものです。
Proper interpretation of a PUT request presumes that the user agent knows which target resource is desired. A service that selects a proper URI on behalf of the client, after receiving a state-changing request, SHOULD be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved to a different URI, then the origin server MUST send an appropriate 3xx (Redirection) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.
PUTリクエストの適切な解釈は、ユーザーエージェントがどのターゲットリソースが望ましいかを知っていると推定します。状態を変更するリクエストを受け取った後、クライアントに代わって適切なURIを選択するサービスは、PUTではなくPOSTメソッドを使用して実装する必要があります。Origin Serverが要求されたPut State変更をターゲットリソースに変更せず、代わりにリソースが別のURIに移動されたときなど、別のリソースに適用することを希望する場合、Origin Serverは適切な3XXを送信する必要があります（リダイレクト）応答;その後、ユーザーエージェントは、リクエストをリダイレクトするかどうかについて独自の決定を下す場合があります。
A PUT request applied to the target resource can have side effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version (different resources that at one point shared the same state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource, and might also cause links to be added between the related resources.
ターゲットリソースに適用されるプットリクエストは、他のリソースに副作用をもたらす可能性があります。たとえば、記事には、各特定のバージョンを識別するURIとは別の「現在のバージョン」（リソース）を識別するためのURIがある場合があります（ある時点で現在のバージョンリソースと同じ状態を共有するリソースは異なります）。したがって、「現在のバージョン」の「The Currentバージョン」のリクエストが成功すると、ターゲットリソースの状態を変更することに加えて新しいバージョンリソースを作成する可能性があり、関連するリソース間にリンクが追加される可能性があります。
Some origin servers support use of the Content-Range header field (Section 14.4) as a request modifier to perform a partial PUT, as described in Section 14.5.
一部のオリジンサーバーは、セクション14.5で説明されているように、部分的なプットを実行するための要求修飾子として、コンテンツレンジヘッダーフィールド（セクション14.4）の使用をサポートしています。
Responses to the PUT method are not cacheable. If a successful PUT request passes through a cache that has one or more stored responses for the target URI, those stored responses will be invalidated (see Section 4.4 of [CACHING]).
PUTメソッドへの応答はキャッシュできません。成功したプット要求が、ターゲットURIの1つ以上の保存された応答を持つキャッシュを通過する場合、それらの保存された応答は無効になります（[キャッシュ]のセクション4.4を参照）。
The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the "rm" command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted.
削除メソッドは、Origin Serverがターゲットリソースとその現在の機能との関連性を削除することを要求します。実際、この方法は、UNIXの「RM」コマンドに似ています。以前に関連付けられた情報を削除するという期待ではなく、Origin ServerのURIマッピングで削除操作を表します。
If the target resource has one or more current representations, they might or might not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the nature of the resource and its implementation by the origin server (which are beyond the scope of this specification). Likewise, other implementation aspects of a resource might need to be deactivated or archived as a result of a DELETE, such as database or gateway connections. In general, it is assumed that the origin server will only allow DELETE on resources for which it has a prescribed mechanism for accomplishing the deletion.
ターゲットリソースに1つ以上の電流表現がある場合、リソースの性質とOrigin Serverによる実装に完全に応じて、それらはOrigin Serverによって破壊される可能性があり、関連するストレージが再生される可能性があります。この仕様の範囲を超えています）。同様に、リソースの他の実装側面は、データベースやゲートウェイ接続などの削除の結果として非アクティブ化またはアーカイブする必要がある場合があります。一般に、Origin Serverは、削除を達成するための規定のメカニズムがあるリソースの削除のみを許可すると想定されています。
Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect. For example, a resource that was previously created using a PUT request, or identified via the Location header field after a 201 (Created) response to a POST request, might allow a corresponding DELETE request to undo those actions. Similarly, custom user agent implementations that implement an authoring function, such as revision control clients using HTTP for remote operations, might use DELETE based on an assumption that the server's URI space has been crafted to correspond to a version repository.
削除方法を許可するリソースは比較的少ないです。その主な用途は、ユーザーがその効果に関して何らかの方向を持っているリモートオーサリング環境に適しています。たとえば、PUTリクエストを使用して以前に作成されたリソース、またはPOSTリクエストに対する201（作成された）応答の後にロケーションヘッダーフィールドを介して識別されたリソースは、対応する削除リクエストがそれらのアクションを元に戻すことができる場合があります。同様に、リモート操作にHTTPを使用してリビジョン制御クライアントなどのオーサリング関数を実装するカスタムユーザーエージェントの実装は、サーバーのURIスペースがバージョンリポジトリに対応するように作成されているという仮定に基づいて削除を使用する場合があります。
If a DELETE method is successfully applied, the origin server SHOULD send
削除メソッドが正常に適用された場合、Origin Serverは送信する必要があります
* a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted,
* アクションが成功する可能性が高いがまだ制定されていない場合、202（受け入れられた）ステータスコード、
* a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or
* アクションが制定されていて、それ以上の情報が提供されない場合、204（コンテンツなし）ステータスコード、または
* a 200 (OK) status code if the action has been enacted and the response message includes a representation describing the status.
* アクションが制定されており、応答メッセージにステータスを説明する表現が含まれている場合、200（OK）ステータスコード。
Although request message framing is independent of the method used, content received in a DELETE request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.
リクエストメッセージフレーミングは使用された方法とは独立していますが、削除要求で受信したコンテンツには一般的に定義されたセマンティクスがなく、リクエストの意味やターゲットを変更することはできません。密輸攻撃の要求として（[http/1.1]のセクション11.2）。クライアントは、そのようなリクエストには目的があり、適切にサポートされることを以前に示していたOrigin Serverに直接作成されない限り、削除要求でコンテンツを生成する必要はありません。HTTP通信の参加者は、リクエストチェーンに沿った仲介者を知らないことが多いため、Origin Serverはコンテンツを受信するための民間契約に依存してはなりません。
Responses to the DELETE method are not cacheable. If a successful DELETE request passes through a cache that has one or more stored responses for the target URI, those stored responses will be invalidated (see Section 4.4 of [CACHING]).
削除メソッドへの応答はキャッシュできません。成功した削除要求が、ターゲットURIの1つ以上の保存された応答を持つキャッシュを通過する場合、それらの保存された応答は無効になります（[キャッシュ]のセクション4.4を参照）。
The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request target and, if successful, thereafter restrict its behavior to blind forwarding of data, in both directions, until the tunnel is closed. Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security, [TLS13]).
Connectメソッドは、受信者がリクエストターゲットによって識別された宛先オリジンサーバーへのトンネルを確立することを要求し、その後、トンネルが閉じるまで、その動作を両方向にデータの盲目的転送に制限します。トンネルは、1つ以上のプロキシを介してエンドツーエンドの仮想接続を作成するために一般的に使用され、TLS（輸送層セキュリティ、[TLS13]）を使用して保護できます。
CONNECT uses a special form of request target, unique to this method, consisting of only the host and port number of the tunnel destination, separated by a colon. There is no default port; a client MUST send the port number even if the CONNECT request is based on a URI reference that contains an authority component with an elided port (Section 4.1). For example,
Connectは、この方法に固有の特別な形式のリクエストターゲットを使用します。これは、コロンで区切られたトンネルの宛先のホストとポート番号のみで構成されています。デフォルトのポートはありません。クライアントは、接続要求が、削除されたポートを持つ権限コンポーネントを含むURIリファレンスに基づいている場合でも、ポート番号を送信する必要があります（セクション4.1）。例えば、
CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com
connect server.example.com:80 http/1.1ホスト：server.example.com
A server MUST reject a CONNECT request that targets an empty or invalid port number, typically by responding with a 400 (Bad Request) status code.
サーバーは、通常、400（悪い要求）ステータスコードで応答することにより、空のポート番号または無効なポート番号をターゲットにする接続要求を拒否する必要があります。
Because CONNECT changes the request/response nature of an HTTP connection, specific HTTP versions might have different ways of mapping its semantics into the protocol's wire format.
ConnectはHTTP接続の要求/応答性を変更するため、特定のHTTPバージョンには、セマンティクスをプロトコルのワイヤー形式にマッピングするさまざまな方法がある場合があります。
CONNECT is intended for use in requests to a proxy. The recipient can establish a tunnel either by directly connecting to the server identified by the request target or, if configured to use another proxy, by forwarding the CONNECT request to the next inbound proxy. An origin server MAY accept a CONNECT request, but most origin servers do not implement CONNECT.
Connectは、プロキシへのリクエストで使用することを目的としています。受信者は、リクエストターゲットによって識別されたサーバーに直接接続するか、別のプロキシを使用するように構成されている場合、接続要求を次のインバウンドプロキシに転送することにより、トンネルを確立できます。Origin ServerはConnectリクエストを受け入れる場合がありますが、ほとんどのOrigin ServerはConnectを実装していません。
Any 2xx (Successful) response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the response header section; data received after that header section is from the server identified by the request target. Any response other than a successful response indicates that the tunnel has not yet been formed.
2xx（成功）応答は、送信者（およびすべてのインバウンドプロキシ）が応答ヘッダーセクションの直後にトンネルモードに切り替えることを示しています。そのヘッダーセクションの後に受信したデータは、要求ターゲットによって識別されたサーバーからのものです。成功した応答以外の応答は、トンネルがまだ形成されていないことを示しています。
A tunnel is closed when a tunnel intermediary detects that either side has closed its connection: the intermediary MUST attempt to send any outstanding data that came from the closed side to the other side, close both connections, and then discard any remaining data left undelivered.
トンネルの仲介者がどちらの側にも接続を閉じていることを検出するとトンネルが閉じられます。仲介者は、閉じた側から反対側に来た未解決のデータを送信し、両方の接続を閉じてから、残りのデータを削除しないようにしなければなりません。
Proxy authentication might be used to establish the authority to create a tunnel. For example,
プロキシ認証は、トンネルを作成する権限を確立するために使用される場合があります。例えば、
CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
Proxy-Authorization: basic aGVsbG86d29ybGQ=
There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to "example.com:25" would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying spam email. Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable list of safe request targets.
特に目的地がWebトラフィックを目的としていない有名または予約されたTCPポートである場合、任意のサーバーにトンネルを確立することには大きなリスクがあります。たとえば、「Example.com:25」への接続は、プロキシがSMTPトラフィックの予約ポートに接続することを示唆します。許可されれば、それはプロキシをだましてスパムメールを中継する可能性があります。Connectをサポートするプロキシは、その使用を限られた既知のポートセットまたは安全な要求ターゲットの構成可能なリストに制限する必要があります。
A server MUST NOT send any Transfer-Encoding or Content-Length header fields in a 2xx (Successful) response to CONNECT. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT.
サーバーは、Connectへの2XX（成功）応答で転送エンコードまたはコンテンツ長ヘッダーフィールドを送信してはなりません。クライアントは、CONNECTへの応答を成功させて受け取ったコンテンツレングスまたは転送エンコードヘッダーフィールドを無視する必要があります。
A CONNECT request message does not have content. The interpretation of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use.
接続要求メッセージにはコンテンツがありません。Connect Requestメッセージのヘッダーセクションの後に送信されたデータの解釈は、使用中のHTTPのバージョンに固有です。
Responses to the CONNECT method are not cacheable.
Connectメソッドへの応答はキャッシュできません。
The OPTIONS method requests information about the communication options available for the target resource, at either the origin server or an intervening intermediary. This method allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action.
Optionsメソッドは、Origin Serverまたは介在する仲介者のいずれかで、ターゲットリソースで利用可能な通信オプションに関する情報を要求します。この方法により、クライアントは、リソースアクションを暗示することなく、リソースに関連するオプションおよび/または要件、またはサーバーの機能を決定できます。
An OPTIONS request with an asterisk ("*") as the request target (Section 7.1) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or lack thereof).
リクエストターゲット（セクション7.1）としてアスタリスク（ "*"）を使用したオプション要求は、特定のリソースではなく、一般的にサーバーに適用されます。サーバーの通信オプションは通常、リソースに依存するため、「*」要求は「ping」または「op no-op」タイプのメソッドとしてのみ役立ちます。クライアントがサーバーの機能をテストできるようにする以外には何もしません。たとえば、これを使用して、HTTP/1.1の適合性（またはその欠如）のプロキシをテストできます。
If the request target is not an asterisk, the OPTIONS request applies to the options that are available when communicating with the target resource.
要求ターゲットがアスタリスクでない場合、オプションリクエストは、ターゲットリソースと通信するときに利用可能なオプションに適用されます。
A server generating a successful response to OPTIONS SHOULD send any header that might indicate optional features implemented by the server and applicable to the target resource (e.g., Allow), including potential extensions not defined by this specification. The response content, if any, might also describe the communication options in a machine or human-readable representation. A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP.
オプションへの応答を成功させるサーバーは、サーバーによって実装され、ターゲットリソースに適用されるオプションの機能を示す可能性のあるヘッダーを送信する必要があります。応答コンテンツは、もしあれば、マシンまたは人間の読み取り可能な表現の通信オプションについても説明する場合があります。このような表現の標準形式は、この仕様では定義されていませんが、HTTPへの将来の拡張によって定義される場合があります。
A client MAY send a Max-Forwards header field in an OPTIONS request to target a specific recipient in the request chain (see Section 7.6.2). A proxy MUST NOT generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field.
クライアントは、リクエストチェーンの特定の受信者をターゲットにするオプションリクエストで最大ヘッダーフィールドを送信できます（セクション7.6.2を参照）。プロキシは、マックスフォワードフィールドでリクエストが受信されない限り、リクエストを転送しながら最大ヘッダーフィールドを生成してはなりません。
A client that generates an OPTIONS request containing content MUST send a valid Content-Type header field describing the representation media type. Note that this specification does not define any use for such content.
コンテンツを含むオプションリクエストを生成するクライアントは、表現メディアタイプを説明する有効なコンテンツタイプのヘッダーフィールドを送信する必要があります。この仕様は、そのようなコンテンツの使用を定義していないことに注意してください。
Responses to the OPTIONS method are not cacheable.
オプションメソッドへの応答はキャッシュできません。
The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request SHOULD reflect the message received, excluding some fields described below, back to the client as the content of a 200 (OK) response. The "message/http" format (Section 10.1 of [HTTP/1.1]) is one way to do so. The final recipient is either the origin server or the first server to receive a Max-Forwards value of zero (0) in the request (Section 7.6.2).
トレースメソッドは、リクエストメッセージのリモート、アプリケーションレベルのループバックを要求します。リクエストの最終的な受信者は、以下に説明する一部のフィールドを除き、200（OK）応答のコンテンツとしてクライアントに戻って、受信したメッセージを反映する必要があります。「メッセージ/http」形式（[http/1.1]のセクション10.1）は、それを行う1つの方法です。最終的な受信者は、リクエストで最大値のゼロ（0）を受信したOrigin Serverまたは最初のサーバーのいずれかです（セクション7.6.2）。
A client MUST NOT generate fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would be foolish for a user agent to send stored user credentials (Section 11) or cookies [COOKIE] in a TRACE request. The final recipient of the request SHOULD exclude any request fields that are likely to contain sensitive data when that recipient generates the response content.
クライアントは、応答によって開示される可能性のある機密データを含むトレースリクエストでフィールドを生成してはなりません。たとえば、ユーザーエージェントが保存されたユーザー資格情報（セクション11）またはCookie [Cookie]をトレースリクエストで送信することは愚かです。リクエストの最終的な受信者は、その受信者が応答コンテンツを生成するときに機密データを含む可能性が高いリクエストフィールドを除外する必要があります。
TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (Section 7.6.3) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.
TRACEを使用すると、クライアントはリクエストチェーンの反対側で受信されているものを確認し、テストまたは診断情報にそのデータを使用できます。Viaヘッダーフィールド（セクション7.6.3）の値は、リクエストチェーンの痕跡として機能するため、特に興味深いものです。Max-Forwardsヘッダーフィールドを使用すると、クライアントはリクエストチェーンの長さを制限できます。これは、無限のループでメッセージを転送するプロキシのチェーンをテストするのに役立ちます。
A client MUST NOT send content in a TRACE request.
クライアントは、トレースリクエストでコンテンツを送信してはなりません。
Responses to the TRACE method are not cacheable.
TRACEメソッドへの応答はキャッシュできません。
The request header fields below provide additional information about the request context, including information about the user, user agent, and resource behind the request.
以下のリクエストヘッダーフィールドは、リクエストの背後にあるユーザー、ユーザーエージェント、リソースに関する情報を含む、リクエストコンテキストに関する追加情報を提供します。
The "Expect" header field in a request indicates a certain set of behaviors (expectations) that need to be supported by the server in order to properly handle this request.
リクエストの「期待」ヘッダーフィールドは、このリクエストを適切に処理するためにサーバーがサポートする必要がある一連の動作（期待）を示します。
Expect = #expectation
expectation = token [ "=" ( token / quoted-string ) parameters ]
The Expect field value is case-insensitive.
予想されるフィールド値は症例に依存しません。
The only expectation defined by this specification is "100-continue" (with no defined parameters).
この仕様で定義されている唯一の期待は、「100コント」（定義されたパラメーターなし）です。
A server that receives an Expect field value containing a member other than 100-continue MAY respond with a 417 (Expectation Failed) status code to indicate that the unexpected expectation cannot be met.
100を除くメンバーを含むフィールド値を受信するサーバーは、417（期待に失敗した）ステータスコードで応答して、予期しない期待を満たすことができないことを示します。
A "100-continue" expectation informs recipients that the client is about to send (presumably large) content in this request and wishes to receive a 100 (Continue) interim response if the method, target URI, and header fields are not sufficient to cause an immediate success, redirect, or error response. This allows the client to wait for an indication that it is worthwhile to send the content before actually doing so, which can improve efficiency when the data is huge or when the client anticipates that an error is likely (e.g., when sending a state-changing method, for the first time, without previously verified authentication credentials).
「100コントン」の期待は、この要求でクライアントが（おそらく大きな）コンテンツを（おそらく大きな）コンテンツを送信しようとしていることを受信者に通知し、メソッド、ターゲットURI、およびヘッダーフィールドが十分ではない場合、100（継続）暫定応答を受けたいと望んでいます。即時の成功、リダイレクト、またはエラー応答。これにより、クライアントは実際にそうする前にコンテンツを送信する価値があるという兆候を待つことができます。これにより、データが巨大なときやクライアントがエラーが可能性があると予想しているとき（たとえば、状態変化を送信するときの効率を改善できます。メソッドは、以前に検証された認証資格情報なしで初めて）。
For example, a request that begins with
たとえば、始まるリクエスト
PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue
allows the origin server to immediately respond with an error message, such as 401 (Unauthorized) or 405 (Method Not Allowed), before the client starts filling the pipes with an unnecessary data transfer.
クライアントが不要なデータ転送でパイプに記入を開始する前に、Origin Serverは401（許可されていない）や405（メソッドは許可されていない方法）などのエラーメッセージですぐに応答できます。
Requirements for clients:
クライアントの要件：
* A client MUST NOT generate a 100-continue expectation in a request that does not include content.
* クライアントは、コンテンツを含めないリクエストで100コントンの期待を生成してはなりません。
* A client that will wait for a 100 (Continue) response before sending the request content MUST send an Expect header field containing a 100-continue expectation.
* リクエストコンテンツを送信する前に100（継続）応答を待つクライアントは、100個の期待を含む期待ヘッダーフィールドを送信する必要があります。
* A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client MAY proceed to send the content even if it has not yet received a response. Furthermore, since 100 (Continue) responses cannot be sent through an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an indefinite period before sending the content.
* 特定の期間を待つ必要はありません。そのようなクライアントは、まだ応答を受け取っていない場合でも、コンテンツの送信を進めることができます。さらに、100（継続）応答はHTTP/1.0仲介者を介して送信できないため、そのようなクライアントはコンテンツを送信する前に無期限の期間待つべきではありません。
* A client that receives a 417 (Expectation Failed) status code in response to a request containing a 100-continue expectation SHOULD repeat that request without a 100-continue expectation, since the 417 response merely indicates that the response chain does not support expectations (e.g., it passes through an HTTP/1.0 server).
* 417の応答は単に応答チェーンが期待をサポートしていないことを示すため、417（予想が失敗した）ステータスコードを100を含むリクエストに応じてステータスコードを受信したクライアントは、100を獲得することなくその要求を繰り返す必要があります（例えば、HTTP/1.0サーバーを通過します）。
Requirements for servers:
サーバーの要件：
* A server that receives a 100-continue expectation in an HTTP/1.0 request MUST ignore that expectation.
* HTTP/1.0リクエストで100コントンの期待を受け取るサーバーは、その期待を無視する必要があります。
* A server MAY omit sending a 100 (Continue) response if it has already received some or all of the content for the corresponding request, or if the framing indicates that there is no content.
* サーバーは、対応するリクエストのコンテンツの一部またはすべてを既に受信している場合、またはフレーミングがコンテンツがないことを示している場合、100（継続）応答の送信を省略できます。
* A server that sends a 100 (Continue) response MUST ultimately send a final status code, once it receives and processes the request content, unless the connection is closed prematurely.
* 100（継続）応答を送信するサーバーは、接続が時期尚早に閉じられない限り、リクエストコンテンツを受信および処理したら、最終的に最終的なステータスコードを送信する必要があります。
* A server that responds with a final status code before reading the entire request content SHOULD indicate whether it intends to close the connection (e.g., see Section 9.6 of [HTTP/1.1]) or continue reading the request content.
* リクエストコンテンツ全体を読み取る前に最終的なステータスコードで応答するサーバーは、接続を閉じること（たとえば、[http/1.1]のセクション9.6を参照）を閉じるか、リクエストコンテンツの読み取りを続けるかを示す必要があります。
Upon receiving an HTTP/1.1 (or later) request that has a method, target URI, and complete header section that contains a 100-continue expectation and an indication that request content will follow, an origin server MUST send either:
メソッド、ターゲットURI、および100の継続的な期待とリクエストコンテンツが従うことを示す兆候を含むHTTP/1.1（またはそれ以降）リクエストを受信すると、Origin Serverは次のいずれかを送信する必要があります。
* an immediate response with a final status code, if that status can be determined by examining just the method, target URI, and header fields, or
* そのステータスをメソッド、ターゲットURI、ヘッダーフィールド、またはヘッダーフィールドのみを調べることで決定できる場合、最終的なステータスコードを使用した即時応答
* an immediate 100 (Continue) response to encourage the client to send the request content.
* クライアントがリクエストコンテンツを送信することを奨励するための即時100（継続）応答。
The origin server MUST NOT wait for the content before sending the 100 (Continue) response.
Origin Serverは、100（継続）応答を送信する前にコンテンツを待ってはなりません。
Upon receiving an HTTP/1.1 (or later) request that has a method, target URI, and complete header section that contains a 100-continue expectation and indicates a request content will follow, a proxy MUST either:
メソッド、ターゲットURI、および100コントンの予想を含み、リクエストコンテンツが続くことを示すHTTP/1.1（またはそれ以降）リクエストを受信すると、プロキシは次のとおりです。
* send an immediate response with a final status code, if that status can be determined by examining just the method, target URI, and header fields, or
* そのステータスをメソッド、ターゲットURI、ヘッダーフィールド、またはヘッダーフィールドのみを調べて決定できる場合、最終的なステータスコードで即時の応答を送信します。
* forward the request toward the origin server by sending a corresponding request-line and header section to the next inbound server.
* 対応するリクエストラインとヘッダーセクションを次のインバウンドサーバーに送信することにより、リクエストをOrigin Serverに転送します。
If the proxy believes (from configuration or past interaction) that the next inbound server only supports HTTP/1.0, the proxy MAY generate an immediate 100 (Continue) response to encourage the client to begin sending the content.
プロキシが（構成または過去の相互作用から）次のインバウンドサーバーがHTTP/1.0のみをサポートしていると考えている場合、プロキシはクライアントがコンテンツの送信を開始するように促すために、即時100（継続）応答を生成する場合があります。
The "From" header field contains an Internet email address for a human user who controls the requesting user agent. The address ought to be machine-usable, as defined by "mailbox" in Section 3.4 of [RFC5322]:
「From」ヘッダーフィールドには、要求するユーザーエージェントを制御する人間のユーザー向けのインターネットメールアドレスが含まれています。[RFC5322]のセクション3.4の「メールボックス」で定義されているように、アドレスは機械使用可能である必要があります。
From = mailbox
mailbox = <mailbox, see [RFC5322], Section 3.4>
An example is:
例は次のとおりです。
From: spider-admin@example.org
From：spider-admin@example.org
The From header field is rarely sent by non-robotic user agents. A user agent SHOULD NOT send a From header field without explicit configuration by the user, since that might conflict with the user's privacy interests or their site's security policy.
From Headerフィールドは、非ロボットユーザーエージェントによってめったに送信されません。ユーザーエージェントは、ユーザーによる明示的な構成なしにヘッダーフィールドを送信してはなりません。これは、ユーザーのプライバシー利益またはサイトのセキュリティポリシーと競合する可能性があるためです。
A robotic user agent SHOULD send a valid From header field so that the person responsible for running the robot can be contacted if problems occur on servers, such as if the robot is sending excessive, unwanted, or invalid requests.
ロボットユーザーエージェントは、ロボットの実行を担当する責任者がサーバーで問題が発生した場合、ロボットが過剰、不要な、または無効な要求を送信している場合など、ロボットを実行する責任者に連絡できるように、ヘッダーから有効なものを送信する必要があります。
A server SHOULD NOT use the From header field for access control or authentication, since its value is expected to be visible to anyone receiving or observing the request and is often recorded within logfiles and error reports without any expectation of privacy.
サーバーは、アクセス制御または認証にFrom Headerフィールドを使用してはなりません。その価値は、リクエストを受信または遵守している人に表示されると予想され、プライバシーを期待することなくログファイルおよびエラーレポート内で記録されることが多いためです。
The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the target URI was obtained (i.e., the "referrer", though the field name is misspelled). A user agent MUST NOT include the fragment and userinfo components of the URI reference [URI], if any, when generating the Referer field value.
「参照」[sic]ヘッダーフィールドにより、ユーザーエージェントは、ターゲットURIが取得されたリソースのURI参照を指定できます（つまり、フィールド名は間違っていますが、「リファラー」）。ユーザーエージェントは、参照フィールド値を生成するときに、URIリファレンス[URI]のフラグメントとuriInfoコンポーネントを含めてはなりません。
Referer = absolute-URI / partial-URI
The field value is either an absolute-URI or a partial-URI. In the latter case (Section 4), the referenced URI is relative to the target URI ([URI], Section 5).
フィールド値は、絶対尿または部分uriのいずれかです。後者の場合（セクション4）、参照されたURIはターゲットURI（[URI]、セクション5）に関連しています。
The Referer header field allows servers to generate back-links to other resources for simple analytics, logging, optimized caching, etc. It also allows obsolete or mistyped links to be found for maintenance. Some servers use the Referer header field as a means of denying links from other sites (so-called "deep linking") or restricting cross-site request forgery (CSRF), but not all requests contain it.
参照ヘッダーフィールドにより、サーバーは、シンプルな分析、ロギング、最適化されたキャッシングなどのために他のリソースにバックリンクを生成できます。また、メンテナンスのために廃止または誤ったリンクを見つけることができます。一部のサーバーは、他のサイトからのリンク（いわゆる「ディープリンク」）またはクロスサイトリクエスト偽造（CSRF）の制限を拒否する手段として、参照ヘッダーフィールドを使用しますが、すべてのリクエストが含まれているわけではありません。
Example:
例：
Referer: http://www.example.org/hypertext/Overview.html
If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard, or an entry within the user's bookmarks/favorites), the user agent MUST either exclude the Referer header field or send it with a value of "about:blank".
ターゲットURIが独自のURI（ユーザーキーボードからの入力、またはユーザーのブックマーク/お気に入り内のエントリ）を持たないソースから取得した場合、ユーザーエージェントは参照ヘッダーフィールドを除外するか、「About：blank」の値。
The Referer header field value need not convey the full URI of the referring resource; a user agent MAY truncate parts other than the referring origin.
参照ヘッダーフィールド値は、参照リソースの完全なURIを伝える必要はありません。ユーザーエージェントは、参照原点以外の部品を切り捨てることができます。
The Referer header field has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource that is supposed to be confidential (such as behind a firewall or internal to a secured service). Most general-purpose user agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent SHOULD NOT send a Referer header field if the referring resource was accessed with a secure protocol and the request target has an origin differing from that of the referring resource, unless the referring resource explicitly allows Referer to be sent. A user agent MUST NOT send a Referer header field in an unsecured HTTP request if the referring resource was accessed with a secure protocol. See Section 17.9 for additional security considerations.
参照ヘッダーフィールドには、リクエストコンテキストまたはユーザーの閲覧履歴に関する情報を明らかにする可能性があります。これは、参照リソースの識別子が個人情報（アカウント名など）または機密になるはずのリソースを明らかにしている場合にプライバシーの懸念事項です。（ファイアウォールの後ろや安全なサービスの内部など）。ほとんどの汎用ユーザーエージェントは、参照リソースがローカル「ファイル」または「データ」URIである場合、参照ヘッダーフィールドを送信しません。参照リソースが参照リソースが参照リソースの送信を許可しない限り、参照リソースが安全なプロトコルでアクセスされ、リクエストターゲットには参照リソースの起源とは異なる場合、ユーザーエージェントは参照ヘッダーフィールドを送信する必要はありません。ユーザーエージェントは、参照リソースに安全なプロトコルでアクセスされた場合、無担保HTTPリクエストで参照ヘッダーフィールドを送信してはなりません。追加のセキュリティに関する考慮事項については、セクション17.9を参照してください。
Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the unfortunate side effect of interfering with protection against CSRF attacks, which can be far more harmful to their users. Intermediaries and user agent extensions that wish to limit information disclosure in Referer ought to restrict their changes to specific edits, such as replacing internal domain names with pseudonyms or truncating the query and/or path components. An intermediary SHOULD NOT modify or delete the Referer header field when the field value shares the same scheme and host as the target URI.
一部の仲介者は、発信リクエストから参照ヘッダーフィールドを無差別に削除することが知られています。これには、CSRF攻撃に対する保護を妨害するという不幸な副作用があります。これは、ユーザーにとってはるかに有害です。参照者の情報開示を制限したい仲介者およびユーザーエージェント拡張機能は、内部ドメイン名を仮名に置き換えたり、クエリおよび/またはパスコンポーネントの切り捨てをしたりするなど、特定の編集に変更を制限する必要があります。フィールド値がターゲットURIと同じスキームとホストを共有している場合、仲介者は参照ヘッダーフィールドを変更または削除してはなりません。
The "TE" header field describes capabilities of the client with regard to transfer codings and trailer sections.
「TE」ヘッダーフィールドは、転送コーディングとトレーラーセクションに関するクライアントの機能を説明しています。
As described in Section 6.5, a TE field with a "trailers" member sent in a request indicates that the client will not discard trailer fields.
セクション6.5で説明されているように、リクエストで送信された「トレーラー」メンバーを持つTEフィールドは、クライアントがトレーラーフィールドを破棄しないことを示します。
TE is also used within HTTP/1.1 to advise servers about which transfer codings the client is able to accept in a response. As of publication, only HTTP/1.1 uses transfer codings (see Section 7 of [HTTP/1.1]).
TEは、HTTP/1.1内でも使用され、クライアントが応答で受け入れることができる転送コーディングについてサーバーにアドバイスします。出版時点では、HTTP/1.1のみが転送コーディングを使用します（[http/1.1]のセクション7を参照）。
The TE field value is a list of members, with each member (aside from "trailers") consisting of a transfer coding name token with an optional weight indicating the client's relative preference for that transfer coding (Section 12.4.2) and optional parameters for that transfer coding.
TEフィールド値はメンバーのリストであり、各メンバー（「トレーラー」を除く）が、転送コーディング（セクション12.4.2）に対するクライアントの相対的な好みを示すオプションの重みとオプションのパラメーターを示すオプションの重みで構成されています。その転送コーディング。
TE = #t-codings
t-codings = "trailers" / ( transfer-coding [ weight ] )
transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )
A sender of TE MUST also send a "TE" connection option within the Connection header field (Section 7.6.1) to inform intermediaries not to forward this field.
TEの送信者は、接続ヘッダーフィールド（セクション7.6.1）内に「TE」接続オプションを送信して、このフィールドを転送しないように仲介者に通知する必要があります。
The "User-Agent" header field contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use. A user agent SHOULD send a User-Agent header field in each request unless specifically configured not to do so.
「ユーザーエージェント」ヘッダーフィールドには、リクエストを発信するユーザーエージェントに関する情報が含まれています。これは、報告された相互運用性の問題の範囲を特定するためにサーバーがよく使用し、特定のユーザーエージェントの制限を回避するために回答または調整するために、および分析のために回答を調整します。ブラウザまたはオペレーティングシステムの使用に関して。ユーザーエージェントは、特にそうしないように設定されていない限り、各要求にユーザーエージェントヘッダーフィールドを送信する必要があります。
User-Agent = product *( RWS ( product / comment ) )
The User-Agent field value consists of one or more product identifiers, each followed by zero or more comments (Section 5.6.5), which together identify the user agent software and its significant subproducts. By convention, the product identifiers are listed in decreasing order of their significance for identifying the user agent software. Each product identifier consists of a name and optional version.
ユーザーエージェントのフィールド値は、1つ以上の製品識別子で構成され、それぞれがゼロ以上のコメント（セクション5.6.5）が続き、ユーザーエージェントソフトウェアとその重要なサブ製品を識別します。慣習により、製品識別子は、ユーザーエージェントソフトウェアを識別するための重要性の順序を減らすことにリストされています。各製品識別子は、名前とオプションのバージョンで構成されています。
product = token ["/" product-version] product-version = token
Product = token ["/" product-version] product-version = token
A sender SHOULD limit generated product identifiers to what is necessary to identify the product; a sender MUST NOT generate advertising or other nonessential information within the product identifier. A sender SHOULD NOT generate information in product-version that is not a version identifier (i.e., successive versions of the same product name ought to differ only in the product-version portion of the product identifier).
送信者は、生成された製品識別子を製品を識別するために必要なものに制限する必要があります。送信者は、製品識別子内の広告またはその他の非必須情報を生成してはなりません。送信者は、バージョン識別子ではない製品バージョンで情報を生成してはなりません（つまり、同じ製品名の連続したバージョンは、製品識別子の製品バージョン部分でのみ異なるはずです）。
Example:
例：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
A user agent SHOULD NOT generate a User-Agent header field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties. Overly long and detailed User-Agent field values increase request latency and the risk of a user being identified against their wishes ("fingerprinting").
ユーザーエージェントは、不必要に細かい詳細を含むユーザーエージェントヘッダーフィールドを生成しないでください。また、第三者によるサブ製品の追加を制限する必要があります。過度に長く詳細なユーザーエージェントのフィールド値は、要求の遅延と、ユーザーが希望に反して識別されるリスクを高めます（「フィンガープリント」）。
Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility with them, as this circumvents the purpose of the field. If a user agent masquerades as a different user agent, recipients can assume that the user intentionally desires to see responses tailored for that identified user agent, even if they might not work as well for the actual user agent being used.
同様に、実装は、フィールドの目的を回避するため、それらとの互換性を宣言するために、他の実装の製品トークンを使用しないことが推奨されます。ユーザーエージェントが別のユーザーエージェントを装っていた場合、受信者は、実際のユーザーエージェントが使用されているユーザーエージェントにも同様に機能しない場合でも、ユーザーがその識別されたユーザーエージェントに合わせて調整された応答を見ることを意図的に望んでいると想定できます。
The response header fields below provide additional information about the response, beyond what is implied by the status code, including information about the server, about the target resource, or about related resources.
以下の応答ヘッダーフィールドは、サーバー、ターゲットリソース、または関連リソースに関する情報を含むステータスコードによって暗示されるものを超えて、応答に関する追加情報を提供します。
The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field is strictly to inform the recipient of valid request methods associated with the resource.
「許可」ヘッダーフィールドには、ターゲットリソースでサポートされていると宣伝されているメソッドのセットがリストされています。このフィールドの目的は、リソースに関連付けられた有効な要求方法を受信者に通知することです。
Allow = #method
Example of use:
使用例：
Allow: GET, HEAD, PUT
許可：取得、頭、置きます
The actual set of allowed methods is defined by the origin server at the time of each request. An origin server MUST generate an Allow header field in a 405 (Method Not Allowed) response and MAY do so in any other response. An empty Allow field value indicates that the resource allows no methods, which might occur in a 405 response if the resource has been temporarily disabled by configuration.
許可されたメソッドの実際のセットは、各リクエストの時点でOrigin Serverによって定義されます。Origin Serverは、405（許可されていない方法）応答で許容ヘッダーフィールドを生成する必要があり、他の応答でそれを行うことができます。空の許可フィールド値は、リソースがメソッドを許可しないことを示します。これは、リソースが構成によって一時的に無効になっている場合、405応答で発生する可能性があります。
A proxy MUST NOT modify the Allow header field -- it does not need to understand all of the indicated methods in order to handle them according to the generic message handling rules.
プロキシは、許容ヘッダーフィールドを変更してはなりません。一般的なメッセージ処理ルールに従ってそれらを処理するために、指定されたすべてのメソッドを理解する必要はありません。
The "Location" header field is used in some responses to refer to a specific resource in relation to the response. The type of relationship is defined by the combination of request method and status code semantics.
「ロケーション」ヘッダーフィールドは、応答に関連する特定のリソースを参照するために、いくつかの応答で使用されます。関係のタイプは、リクエスト方法とステータスコードセマンティクスの組み合わせによって定義されます。
Location = URI-reference
The field value consists of a single URI-reference. When it has the form of a relative reference ([URI], Section 4.2), the final value is computed by resolving it against the target URI ([URI], Section 5).
フィールド値は、単一のURI参照で構成されています。相対参照（[URI]、セクション4.2）の形式がある場合、最終値はターゲットURI（[URI]、セクション5）に対して解決することにより計算されます。
For 201 (Created) responses, the Location value refers to the primary resource created by the request. For 3xx (Redirection) responses, the Location value refers to the preferred target resource for automatically redirecting the request.
201（作成）の回答の場合、場所値はリクエストによって作成された主要なリソースを指します。3xx（リダイレクト）応答の場合、位置値は、リクエストを自動的にリダイレクトするための優先ターゲットリソースを指します。
If the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the target URI (i.e., the redirection inherits the original reference's fragment, if any).
3XX（リダイレクト）応答で提供される位置値にフラグメントコンポーネントがない場合、ユーザーエージェントは、値がターゲットURIを生成するために使用されるURI参照のフラグメントコンポーネントを継承するかのようにリダイレクトを処理する必要があります（つまり、リダイレクトが継承します元の参照のフラグメント（ある場合）。
For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field:
たとえば、URIリファレンス「http://www.example.org/~tim」で生成されたget requestは、ヘッダーフィールドを含む303（その他を参照）応答をもたらす可能性があります。
Location: /People.html#tim
which suggests that the user agent redirect to
"http://www.example.org/People.html#tim"
Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field:
同様に、URIリファレンス「http://www.example.org/index.html#larry」で生成されたget requestは、ヘッダーフィールドを含む301（永続的に移動）応答をもたらす可能性があります。
Location: http://www.example.net/index.html
which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier.
これは、ユーザーエージェントが「http://www.example.net/index.html#larry」にリダイレクトし、元のフラグメント識別子を保存することを示唆しています。
There are circumstances in which a fragment identifier in a Location value would not be appropriate. For example, the Location header field in a 201 (Created) response is supposed to provide a URI that is specific to the created resource.
位置値のフラグメント識別子が適切ではない状況があります。たとえば、201（作成）応答の位置ヘッダーフィールドは、作成されたリソースに固有のURIを提供することになっています。
| *Note:* Some recipients attempt to recover from Location header
| fields that are not valid URI references. This specification
| does not mandate or define such processing, but does allow it
| for the sake of robustness. A Location field value cannot
| allow a list of members because the comma list separator is a
| valid data character within a URI-reference. If an invalid
| message is sent with multiple Location field lines, a recipient
| along the path might combine those field lines into one value.
| Recovery of a valid Location field value from that situation is
| difficult and not interoperable across implementations.
| *Note:* The Content-Location header field (Section 8.7) differs
| from Location in that the Content-Location refers to the most
| specific resource corresponding to the enclosed representation.
| It is therefore possible for a response to contain both the
| Location and Content-Location header fields.
Servers send the "Retry-After" header field to indicate how long the user agent ought to wait before making a follow-up request. When sent with a 503 (Service Unavailable) response, Retry-After indicates how long the service is expected to be unavailable to the client. When sent with any 3xx (Redirection) response, Retry-After indicates the minimum time that the user agent is asked to wait before issuing the redirected request.
サーバーは、「Retry-After」ヘッダーフィールドを送信して、ユーザーエージェントがフォローアップリクエストを行う前に待つべき時間を示します。503（サービスが利用できない）応答で送信されると、再試行後、サービスがクライアントが利用できないと予想される期間を示します。3xx（リダイレクト）応答で送信されると、再試行後のリダイレクトリクエストを発行する前に、ユーザーエージェントが待機するように求められる最小時間を示します。
The Retry-After field value can be either an HTTP-date or a number of seconds to delay after receiving the response.
再試行後のフィールド値は、応答を受け取った後、HTTP-Dateまたは数秒遅れである可能性があります。
Retry-After = HTTP-date / delay-seconds
A delay-seconds value is a non-negative decimal integer, representing time in seconds.
遅延秒値は、秒単位の時間を表す非陰性小数整数です。
delay-seconds = 1*DIGIT
Two examples of its use are
その使用の2つの例は次のとおりです
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
後者の例では、遅延は2分です。
The "Server" header field contains information about the software used by the origin server to handle the request, which is often used by clients to help identify the scope of reported interoperability problems, to work around or tailor requests to avoid particular server limitations, and for analytics regarding server or operating system use. An origin server MAY generate a Server header field in its responses.
「サーバー」ヘッダーフィールドには、オリジンサーバーがリクエストを処理するために使用するソフトウェアに関する情報が含まれています。これは、報告されている相互運用性の問題の範囲を特定するためにクライアントがよく使用し、特定のサーバーの制限を回避するためのリクエストを回避または調整するために、サーバーまたはオペレーティングシステムの使用に関する分析用。Origin Serverは、その応答でサーバーヘッダーフィールドを生成する場合があります。
Server = product *( RWS ( product / comment ) )
The Server header field value consists of one or more product identifiers, each followed by zero or more comments (Section 5.6.5), which together identify the origin server software and its significant subproducts. By convention, the product identifiers are listed in decreasing order of their significance for identifying the origin server software. Each product identifier consists of a name and optional version, as defined in Section 10.1.5.
サーバーヘッダーのフィールド値は、1つ以上の製品識別子で構成され、それぞれに続いてゼロ以上のコメント（セクション5.6.5）が続き、Origin Serverソフトウェアとその重要なサブ製品を識別します。慣習により、製品識別子は、Origin Serverソフトウェアを識別するための重要性の順序を減らすことにリストされています。各製品識別子は、セクション10.1.5で定義されているように、名前とオプションバージョンで構成されています。
Example:
例：
Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server header field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties. Overly long and detailed Server field values increase response latency and potentially reveal internal implementation details that might make it (slightly) easier for attackers to find and exploit known security holes.
Origin Serverは、不必要に微調整された詳細を含むサーバーヘッダーフィールドを生成してはなりません。また、第三者によるサブ製品の追加を制限する必要があります。過度に長く詳細なサーバーフィールド値は、応答の遅延を増加させ、攻撃者が既知のセキュリティホールを見つけて悪用することを（わずかに）簡単にする可能性のある内部実装の詳細を潜在的に明らかにします。
HTTP provides a general framework for access control and authentication, via an extensible set of challenge-response authentication schemes, which can be used by a server to challenge a client request and by a client to provide authentication information. It uses a case-insensitive token to identify the authentication scheme:
HTTPは、アクセス制御と認証の一般的なフレームワークを提供します。これは、クライアントリクエストに挑戦するためにサーバーと認証情報を提供するためにサーバーが使用できる拡張可能なチャレンジ応答認証スキームを介して、アクセス制御と認証の一般的なフレームワークを提供します。ケースに依存しないトークンを使用して、認証スキームを識別します。
auth-scheme = token
Aside from the general framework, this document does not specify any authentication schemes. New and existing authentication schemes are specified independently and ought to be registered within the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry". For example, the "basic" and "digest" authentication schemes are defined by [RFC7617] and [RFC7616], respectively.
一般的なフレームワークとは別に、このドキュメントでは認証スキームは指定されていません。新規および既存の認証スキームは独立して指定されており、「HyperText Transfer Protocol（HTTP）認証スキームレジストリ」に登録する必要があります。たとえば、「基本」および「ダイジェスト」認証スキームは、それぞれ[RFC7617]と[RFC7616]で定義されます。
The authentication scheme is followed by additional information necessary for achieving authentication via that scheme as either a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.
認証スキームの後に、パラメーターのコンマ分離されたリストまたはBase64エンコード情報を保持できる単一のシーケンスのいずれかとして、そのスキームを介して認証を達成するために必要な追加情報が続きます。
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
The token68 syntax allows the 66 unreserved URI characters ([URI]), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace ([RFC4648]).
token68構文により、66の未自由なURI文字（[uri]）に加えて、他のいくつかを許可するため、base64、base64url（url and filename safe alphabet）、base32、またはbase16（hex）エンコードを保持できます。、ただし、Whitespace（[RFC4648]）を除く。
Authentication parameters are name/value pairs, where the name token is matched case-insensitively and each parameter name MUST only occur once per challenge.
認証パラメーターは名前/値のペアであり、名前トークンはケースインテンシテーブで一致し、各パラメーター名はチャレンジごとに1回しか発生しません。
auth-param = token BWS "=" BWS ( token / quoted-string )
Parameter values can be expressed either as "token" or as "quoted-string" (Section 5.6). Authentication scheme definitions need to accept both notations, both for senders and recipients, to allow recipients to use generic parsing components regardless of the authentication scheme.
パラメーター値は、「トークン」または「引用された弦」として表すことができます（セクション5.6）。認証スキームの定義は、受信者が認証スキームに関係なく一般的な解析コンポーネントを使用できるようにするために、送信者と受信者の両方の表記を受け入れる必要があります。
For backwards compatibility, authentication scheme definitions can restrict the format for senders to one of the two variants. This can be important when it is known that deployed implementations will fail when encountering one of the two formats.
後方互換性の場合、認証スキームの定義は、送信者の形式を2つのバリエーションのいずれかに制限できます。これは、展開された実装が2つの形式のいずれかに遭遇したときに失敗することがわかっている場合に重要です。
A 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent, including a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.
401（不正な）応答メッセージは、リクエストされたリソースに適用される少なくとも1つの課題を含むwww-authenticateヘッダーフィールドを含む、ユーザーエージェントの承認に挑戦するためにOrigin Serverによって使用されます。
A 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client, including a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.
407（プロキシ認証が必要）応答メッセージは、要求されたリソースのプロキシに適用される少なくとも1つの課題を含むプロキシと認証ヘッダーフィールドを含む、クライアントの承認に挑戦するためにプロキシによって使用されます。
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
| *Note:* Many clients fail to parse a challenge that contains an
| unknown scheme. A workaround for this problem is to list well-
| supported schemes (such as "basic") first.
A user agent that wishes to authenticate itself with an origin server
-- usually, but not necessarily, after receiving a 401 (Unauthorized)
-- can do so by including an Authorization header field with the
request.
A client that wishes to authenticate itself with a proxy -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) -- can do so by including a Proxy-Authorization header field with the request.
プロキシで認証したいクライアント - 通常は、必ずしも407（プロキシ認証が必要）を受信した後、必ずしもそうではありませんが、リクエストにプロキシ承認ヘッダーフィールドを含めることでそうすることができます。
Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the user as appropriate. Transmission of credentials within header field values implies significant security considerations regarding the confidentiality of the underlying connection, as described in Section 17.16.1.
承認フィールド値とプロキシ認証フィールド値の両方に、応答で受け取った課題に基づいて、要求されているリソースの領域に対するクライアントの資格情報が含まれています（おそらく過去のある時点）。値を作成する際、ユーザーエージェントは、必要に応じてユーザーから資格情報を取得し、理解している最も安全な認証スchemeであると考えているものでチャレンジを選択することにより、そうする必要があります。ヘッダーフィールド値内の資格情報の送信は、セクション17.16.1で説明されているように、基礎となる接続の機密性に関する重要なセキュリティ上の考慮事項を意味します。
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial credentials (e.g., when the authentication scheme requires more than one round trip), an origin server SHOULD send a 401 (Unauthorized) response that contains a WWW-Authenticate header field with at least one (possibly new) challenge applicable to the requested resource.
資格情報を省略した保護されたリソースのリクエストを受信すると、無効な資格情報（たとえば、パスワードが悪い）または部分的な資格情報（例：認証スキームが複数の往復を必要とする場合）が含まれています。）要求されたリソースに適用される少なくとも1つの（おそらく新しい）課題を備えたwww-authenticateヘッダーフィールドを含む応答。
Likewise, upon receipt of a request that omits proxy credentials or contains invalid or partial proxy credentials, a proxy that requires authentication SHOULD generate a 407 (Proxy Authentication Required) response that contains a Proxy-Authenticate header field with at least one (possibly new) challenge applicable to the proxy.
同様に、プロキシ資格情報を省略したり、無効または部分的なプロキシ資格情報を含むリクエストを受け取ったとき、認証を必要とするプロキシは、少なくとも1つ（おそらく新しい）を持つプロキシ - 認証ヘッダーフィールドを含む407（プロキシ認証が必要）応答を生成する必要があります。プロキシに適用可能な課題。
A server that receives valid credentials that are not adequate to gain access ought to respond with the 403 (Forbidden) status code (Section 15.5.4).
アクセスを獲得するのに適切でない有効な資格情報を受信するサーバーは、403（禁止）ステータスコード（セクション15.5.4）で応答する必要があります。
HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.
HTTPは、アクセス認証のためのこの単純なチャレンジ応答フレームワークへのアプリケーションを制限しません。トランスポートレベルでの認証やメッセージカプセル化を介して、認証情報を指定する追加のヘッダーフィールドなど、追加のメカニズムを使用できます。ただし、このような追加のメカニズムは、この仕様では定義されていません。
Note that various custom mechanisms for user authentication use the Set-Cookie and Cookie header fields, defined in [COOKIE], for passing tokens related to authentication.
ユーザー認証用のさまざまなカスタムメカニズムは、認証に関連するトークンを通過するために、[Cookie]で定義されたセットクッキーおよびCookieヘッダーフィールドを使用していることに注意してください。
The "realm" authentication parameter is reserved for use by authentication schemes that wish to indicate a scope of protection.
「Realm」認証パラメーターは、保護の範囲を示す認証スキームで使用するために予約されています。
A "protection space" is defined by the origin (see Section 4.3.1) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but with different realms.
「保護スペース」は、アクセスするサーバーの原点（セクション4.3.1を参照）によって定義され、存在する場合はレルム値と組み合わせて定義されます。これらの領域により、サーバー上の保護されたリソースを、それぞれ独自の認証スキームおよび/または認証データベースを備えた一連の保護スペースに分割できます。レルム値は、一般にOrigin Serverによって割り当てられる文字列であり、認証スキームに固有の追加のセマンティクスを持つことができます。応答には、同じ認証スキームが異なる領域では複数の課題がある可能性があることに注意してください。
The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preferences (such as a configurable inactivity timeout).
保護スペースは、資格情報を自動的に適用できるドメインを決定します。事前の要求が承認されている場合、ユーザーエージェントは、認証スキーム、パラメーター、および/またはユーザー設定（設定可能な非アクティビティタイムアウトなど）によって決定される期間、その保護スペース内の他のすべての要求に対して同じ資格情報を再利用できます。。
The extent of a protection space, and therefore the requests to which credentials might be automatically applied, is not necessarily known to clients without additional information. An authentication scheme might define parameters that describe the extent of a protection space. Unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server.
保護スペースの範囲、したがって、資格情報が自動的に適用される可能性のある要求は、追加情報なしでクライアントに必ずしもわかっているわけではありません。認証スキームは、保護スペースの範囲を記述するパラメーターを定義する場合があります。認証スキームによって具体的に許可されていない限り、単一の保護スペースはサーバーの範囲外に拡張できません。
For historical reasons, a sender MUST only generate the quoted-string syntax. Recipients might have to support both token and quoted-string syntax for maximum interoperability with existing clients that have been accepting both notations for a long time.
歴史的な理由から、送信者は引用されたストリング構文のみを生成する必要があります。受信者は、両方の表記を長い間受け入れてきた既存のクライアントとの最大の相互運用性のために、トークンと引用のストリング構文の両方をサポートする必要がある場合があります。
The "WWW-Authenticate" response header field indicates the authentication scheme(s) and parameters applicable to the target resource.
「www-authenticate」応答ヘッダーフィールドは、ターゲットリソースに適用される認証スキームとパラメーターを示します。
WWW-Authenticate = #challenge
A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge. A server MAY generate a WWW-Authenticate header field in other response messages to indicate that supplying credentials (or different credentials) might affect the response.
401（不正な）応答を生成するサーバーは、少なくとも1つのチャレンジを含むwww-authenticateヘッダーフィールドを送信する必要があります。サーバーは、他の応答メッセージでwww-authenticateヘッダーフィールドを生成して、資格情報（または異なる資格情報）が応答に影響する可能性があることを示すことができます。
A proxy forwarding a response MUST NOT modify any WWW-Authenticate header fields in that response.
応答を転送するプロキシは、その応答でwww-authenticateヘッダーフィールドを変更してはなりません。
User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur multiple times.
ユーザーエージェントには、フィールド値を解析することに特に注意することをお勧めします。これには複数の課題が含まれている可能性があり、各チャレンジには認証パラメーターのコンマ分離リストが含まれている可能性があります。さらに、ヘッダーフィールド自体は複数回発生する可能性があります。
For instance:
例えば：
WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
type=1, title="Login to \"apps\""
This header field contains two challenges, one for the "Basic" scheme with a realm value of "simple" and another for the "Newauth" scheme with a realm value of "apps". It also contains two additional parameters, "type" and "title".
このヘッダーフィールドには、「シンプル」の領域値を持つ「基本」スキームの1つは、「アプリ」の領域値を持つ「NewAuth」スキームの1つは2つの課題が含まれています。また、「タイプ」と「タイトル」という2つの追加パラメーターも含まれています。
Some user agents do not recognize this form, however. As a result, sending a WWW-Authenticate field value with more than one member on the same field line might not be interoperable.
ただし、一部のユーザーエージェントはこのフォームを認識していません。その結果、同じフィールドライン上の複数のメンバーとwww-authenticateフィールド値を送信することは相互運用できない場合があります。
| *Note:* The challenge grammar production uses the list syntax
| as well. Therefore, a sequence of comma, whitespace, and comma
| can be considered either as applying to the preceding
| challenge, or to be an empty entry in the list of challenges.
| In practice, this ambiguity does not affect the semantics of
| the header field value and thus is harmless.
The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
「承認」ヘッダーフィールドにより、ユーザーエージェントは、401（不正な）応答を受信した後、通常は必ずしもではありませんが、オリジンサーバーで自分自身を認証できます。その値は、要求されているリソースの領域のユーザーエージェントの認証情報を含む資格情報で構成されています。
Authorization = credentials
If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).
リクエストが認証され、領域が指定されている場合、同じ資格情報がこの領域内の他のすべてのリクエストに対して有効であると推定されます（認証スキーム自体が、チャレンジ値に応じて異なる資格情報や同期の使用など、そうでないことを要求しないと仮定します。時計）。
A proxy forwarding a request MUST NOT modify any Authorization header fields in that request. See Section 3.5 of [CACHING] for details of and requirements pertaining to handling of the Authorization header field by HTTP caches.
リクエストを転送するプロキシは、そのリクエストの承認ヘッダーフィールドを変更してはなりません。HTTPキャッシュによる承認ヘッダーフィールドの処理に関する詳細と要件については、[キャッシュ]のセクション3.5を参照してください。
HTTP authentication schemes can use the "Authentication-Info" response field to communicate information after the client's authentication credentials have been accepted. This information can include a finalization message from the server (e.g., it can contain the server authentication).
HTTP認証スキームは、クライアントの認証資格情報が受け入れられた後、「認証INFO」応答フィールドを使用して情報を通知できます。この情報には、サーバーからのファイナライゼーションメッセージを含めることができます（たとえば、サーバー認証を含めることができます）。
The field value is a list of parameters (name/value pairs), using the "auth-param" syntax defined in Section 11.3. This specification only describes the generic format; authentication schemes using Authentication-Info will define the individual parameters. The "Digest" Authentication Scheme, for instance, defines multiple parameters in Section 3.5 of [RFC7616].
フィールド値は、セクション11.3で定義された「Auth-Param」構文を使用して、パラメーター（名前/値ペア）のリストです。この仕様は、汎用形式のみを記述します。Authentication-INFOを使用した認証スキームは、個々のパラメーターを定義します。たとえば、「ダイジェスト」認証スキームは、[RFC7616]のセクション3.5の複数のパラメーターを定義します。
Authentication-Info = #auth-param
The Authentication-Info field can be used in any HTTP response, independently of request method and status code. Its semantics are defined by the authentication scheme indicated by the Authorization header field (Section 11.6.2) of the corresponding request.
認証INFOフィールドは、要求方法とステータスコードとは無関係に、HTTP応答で使用できます。そのセマンティクスは、対応するリクエストの承認ヘッダーフィールド（セクション11.6.2）で示される認証スキームによって定義されます。
A proxy forwarding a response is not allowed to modify the field value in any way.
応答を転送するプロキシは、フィールド値をいかなる方法でも変更できません。
Authentication-Info can be sent as a trailer field (Section 6.5) when the authentication scheme explicitly allows this.
認証スキームがこれを明示的に許可する場合、Authentication-INFOはトレーラーフィールド（セクション6.5）として送信できます。
The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the proxy for this request. A proxy MUST send at least one Proxy-Authenticate header field in each 407 (Proxy Authentication Required) response that it generates.
「Proxy-Authenticate」ヘッダーフィールドは、このリクエストのプロキシに適用される認証スキームとパラメーターを示す少なくとも1つの課題で構成されています。プロキシは、生成する各407（プロキシ認証が必要）の各応答に少なくとも1つのプロキシ - 認証ヘッダーフィールドを送信する必要があります。
Proxy-Authenticate = #challenge
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the next outbound client on the response chain. This is because only the client that chose a given proxy is likely to have the credentials necessary for authentication. However, when multiple proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate network, it is common for credentials to be generated by the user agent and passed through the hierarchy until consumed. Hence, in such a configuration, it will appear as if Proxy-Authenticate is being forwarded because each proxy will send the same challenge set.
www-authenticateとは異なり、Proxy-authenticateヘッダーフィールドは、応答チェーンの次のアウトバウンドクライアントにのみ適用されます。これは、特定のプロキシを選択したクライアントのみが、認証に必要な資格情報を持っている可能性が高いためです。ただし、大企業ネットワーク内のオフィスや地域のキャッシュプロキシなど、同じ管理ドメイン内で複数のプロキシが使用される場合、資格情報がユーザーエージェントによって生成され、消費されるまで階層を通過することが一般的です。したがって、このような構成では、各プロキシが同じチャレンジセットを送信するため、プロキシ-Authenticateが転送されているかのように見えます。
Note that the parsing considerations for WWW-Authenticate apply to this header field as well; see Section 11.6.1 for details.
www-authenticateの解析に関する考慮事項は、このヘッダーフィールドにも適用されることに注意してください。詳細については、セクション11.6.1を参照してください。
The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy that requires authentication. Its value consists of credentials containing the authentication information of the client for the proxy and/or realm of the resource being requested.
「Proxy-Authorization」ヘッダーフィールドにより、クライアントは認証が必要なプロキシに自分自身（またはそのユーザー）を識別できます。その値は、要求されているリソースのプロキシおよび/または領域のクライアントの認証情報を含む資格情報で構成されています。
Proxy-Authorization = credentials
Unlike Authorization, the Proxy-Authorization header field applies only to the next inbound proxy that demanded authentication using the Proxy-Authenticate header field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first inbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.
承認とは異なり、Proxy-authorizationヘッダーフィールドは、プロキシと認証ヘッダーフィールドを使用して認証を要求する次のインバウンドプロキシにのみ適用されます。チェーンで複数のプロキシを使用すると、代理認証ヘッダーフィールドは、資格情報を受け取ると予想されていた最初のインバウンドプロキシによって消費されます。プロキシは、それが特定の要求を協力的に認証するメカニズムである場合、クライアント要求から次のプロキシにクライアント要求を中継する場合があります。
The "Proxy-Authentication-Info" response header field is equivalent to Authentication-Info, except that it applies to proxy authentication (Section 11.3) and its semantics are defined by the authentication scheme indicated by the Proxy-Authorization header field (Section 11.7.2) of the corresponding request:
「Proxy-authentication-info」応答ヘッダーフィールドは、認証INFOに相当しますが、プロキシ認証に適用され（セクション11.3）、そのセマンティクスは、プロキシ相当ヘッダーフィールド（セクション11.7で示される認証スキームによって定義されます。2）対応するリクエストの：
Proxy-Authentication-Info = #auth-param
However, unlike Authentication-Info, the Proxy-Authentication-Info header field applies only to the next outbound client on the response chain. This is because only the client that chose a given proxy is likely to have the credentials necessary for authentication. However, when multiple proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate network, it is common for credentials to be generated by the user agent and passed through the hierarchy until consumed. Hence, in such a configuration, it will appear as if Proxy-Authentication-Info is being forwarded because each proxy will send the same field value.
ただし、Authentication-INFOとは異なり、Proxy-authentication-infoヘッダーフィールドは、応答チェーンの次のアウトバウンドクライアントにのみ適用されます。これは、特定のプロキシを選択したクライアントのみが、認証に必要な資格情報を持っている可能性が高いためです。ただし、大企業ネットワーク内のオフィスや地域のキャッシュプロキシなど、同じ管理ドメイン内で複数のプロキシが使用される場合、資格情報がユーザーエージェントによって生成され、消費されるまで階層を通過することが一般的です。したがって、このような構成では、各プロキシが同じフィールド値を送信するため、プロキシ-Authentication-infoが転送されているかのように見えます。
Proxy-Authentication-Info can be sent as a trailer field (Section 6.5) when the authentication scheme explicitly allows this.
認証スキームがこれを明示的に許可する場合、Proxy-authentication-infoはトレーラーフィールド（セクション6.5）として送信できます。
When responses convey content, whether indicating a success or an error, the origin server often has different ways of representing that information; for example, in different formats, languages, or encodings. Likewise, different users or user agents might have differing capabilities, characteristics, or preferences that could influence which representation, among those available, would be best to deliver. For this reason, HTTP provides mechanisms for content negotiation.
応答がコンテンツを伝えるとき、成功かエラーであろうと、Origin Serverにはその情報を表現するさまざまな方法があります。たとえば、さまざまな形式、言語、またはエンコーディングで。同様に、異なるユーザーやユーザーエージェントには、利用可能な表現の中でどの表現に影響を与える可能性のある能力、特性、または好みが異なる場合があります。このため、HTTPはコンテンツネゴシエーションのメカニズムを提供します。
This specification defines three patterns of content negotiation that can be made visible within the protocol: "proactive" negotiation, where the server selects the representation based upon the user agent's stated preferences; "reactive" negotiation, where the server provides a list of representations for the user agent to choose from; and "request content" negotiation, where the user agent selects the representation for a future request based upon the server's stated preferences in past responses.
この仕様では、プロトコル内で見えるようにすることができるコンテンツネゴシエーションの3つのパターンを定義します。「プロアクティブ」ネゴシエーション。ユーザーエージェントの指定された設定に基づいてサーバーが表現を選択します。「リアクティブ」交渉。サーバーは、ユーザーエージェントが選択できる表現のリストを提供します。「コンテンツの要求」交渉。ユーザーエージェントは、過去の応答におけるサーバーの指定された設定に基づいて、将来の要求の表現を選択します。
Other patterns of content negotiation include "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters, "active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and "Transparent Content Negotiation" ([RFC2295]), where content selection is performed by an intermediary. These patterns are not mutually exclusive, and each has trade-offs in applicability and practicality.
コンテンツの交渉の他のパターンには、「条件付きコンテンツ」が含まれます。ここでは、表現はユーザーエージェントパラメーターに基づいて選択的にレンダリングされる複数の部分で構成されています。ユーザーエージェントの特性、および「透明なコンテンツネゴシエーション」（[RFC2295]）。ここで、コンテンツの選択は仲介者によって実行されます。これらのパターンは相互に排他的ではなく、それぞれに適用性と実用性にトレードオフがあります。
Note that, in all cases, HTTP is not aware of the resource semantics. The consistency with which an origin server responds to requests, over time and over the varying dimensions of content negotiation, and thus the "sameness" of a resource's observed representations over time, is determined entirely by whatever entity or algorithm selects or generates those responses.
すべての場合において、HTTPはリソースセマンティクスを認識していないことに注意してください。Origin Serverがリクエストに応答する一貫性は、時間の経過とともに、コンテンツネゴシエーションのさまざまな次元、したがって、リソースの観察された表現の「同一性」が時間の経過とともに「同一」であり、それらの応答を選択または生成するエンティティまたはアルゴリズムによって完全に決定されます。
When content negotiation preferences are sent by the user agent in a request to encourage an algorithm located at the server to select the preferred representation, it is called "proactive negotiation" (a.k.a., "server-driven negotiation"). Selection is based on the available representations for a response (the dimensions over which it might vary, such as language, content coding, etc.) compared to various information supplied in the request, including both the explicit negotiation header fields below and implicit characteristics, such as the client's network address or parts of the User-Agent field.
コンテンツネゴシエーションの選好が、サーバーにあるアルゴリズムを奨励するためにユーザーエージェントによって送信された場合、優先表現を選択するようにサーバーにあるアルゴリズムを奨励すると、「プロアクティブネゴシエーション」（別名、「サーバー主導のネゴシエーション」）と呼ばれます。選択は、以下の明示的なネゴシエーションヘッダーフィールドと暗黙の特性の両方を含む、リクエストで提供されたさまざまな情報と比較して、応答の利用可能な表現（言語、コンテンツコーディングなど、異なる可能性のある次元）に基づいています。クライアントのネットワークアドレスやユーザーエージェントフィールドの一部など。
Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult to describe to a user agent, or when the server desires to send its "best guess" to the user agent along with the first response (when that "best guess" is good enough for the user, this avoids the round-trip delay of a subsequent request). In order to improve the server's guess, a user agent MAY send request header fields that describe its preferences.
積極的な交渉は、利用可能な表現の中から選択するためのアルゴリズムをユーザーエージェントに説明するのが難しい場合、またはサーバーが最初の応答とともにユーザーエージェントに「最高の推測」を送信したい場合（その最良の推測である場合に有利です。「ユーザーにとっては十分です。これにより、後続のリクエストの往復遅延が回避されます）。サーバーの推測を改善するために、ユーザーエージェントは、その好みを説明するリクエストヘッダーフィールドを送信できます。
Proactive negotiation has serious disadvantages:
積極的な交渉には深刻な欠点があります。
* It is impossible for the server to accurately determine what might be "best" for any given user, since that would require complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want to view it on screen or print it on paper?);
* ユーザーエージェントの機能と応答の意図された使用の両方の完全な知識が必要になるため、サーバーが特定のユーザーにとって「最良」である可能性があるものを正確に判断することは不可能です（例えば、ユーザーは表示したいのですか？画面に表示されるか、紙に印刷しますか？）;
* Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage of responses have multiple representations) and a potential risk to the user's privacy;
* ユーザーエージェントにすべてのリクエストでその機能を説明することは、非常に非効率的である可能性があります（回答のごく一部のみが複数の表現を持っていることを考えると）、ユーザーのプライバシーに対する潜在的なリスクがあります。
* It complicates the implementation of an origin server and the algorithms for generating responses to a request; and,
* リクエストに対する応答を生成するためのOrigin Serverとアルゴリズムの実装を複雑にします。と、
* It limits the reusability of responses for shared caching.
* 共有キャッシュの応答の再利用性を制限します。
A user agent cannot rely on proactive negotiation preferences being consistently honored, since the origin server might not implement proactive negotiation for the requested resource or might decide that sending a response that doesn't conform to the user agent's preferences is better than sending a 406 (Not Acceptable) response.
Origin Serverは要求されたリソースのプロアクティブな交渉を実装しないか、ユーザーエージェントの設定に準拠していない応答を送信することは406を送信するよりも優れていると判断する可能性があるため、ユーザーエージェントは一貫して尊重されるプロアクティブな交渉の好みに依存することはできません（受け入れられない）応答。
A Vary header field (Section 12.5.5) is often sent in a response subject to proactive negotiation to indicate what parts of the request information were used in the selection algorithm.
さまざまなヘッダーフィールド（セクション12.5.5）は、選択アルゴリズムで使用された要求情報の部分を示すために、プロアクティブな交渉の対象となる応答でしばしば送信されます。
The request header fields Accept, Accept-Charset, Accept-Encoding, and Accept-Language are defined below for a user agent to engage in proactive negotiation of the response content. The preferences sent in these fields apply to any content in the response, including representations of the target resource, representations of error or processing status, and potentially even the miscellaneous text strings that might appear within the protocol.
リクエストヘッダーフィールドは、ユーザーエージェントが応答コンテンツの積極的な交渉に従事するために、以下に定義されています。これらのフィールドで送信される設定は、ターゲットリソースの表現、エラーまたは処理ステータスの表現、およびプロトコル内に表示される可能性のある雑多なテキスト文字列など、応答の任意のコンテンツに適用されます。
With "reactive negotiation" (a.k.a., "agent-driven negotiation"), selection of content (regardless of the status code) is performed by the user agent after receiving an initial response. The mechanism for reactive negotiation might be as simple as a list of references to alternative representations.
「リアクティブネゴシエーション」（別名、「エージェント主導型交渉」）により、最初の応答を受け取った後、ユーザーエージェントによってコンテンツの選択が実行されます。反応的交渉のメカニズムは、代替表現への参照のリストと同じくらい簡単かもしれません。
If the user agent is not satisfied by the initial response content, it can perform a GET request on one or more of the alternative resources to obtain a different representation. Selection of such alternatives might be performed automatically (by the user agent) or manually (e.g., by the user selecting from a hypertext menu).
ユーザーエージェントが最初の応答コンテンツによって満たされていない場合、別の表現を取得するために、1つ以上の代替リソースに対してGETリクエストを実行できます。このような代替品の選択は、自動的に（ユーザーエージェントによって）または手動で実行される場合があります（たとえば、ユーザーがハイパーテキストメニューから選択することによって）。
A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive negotiation by the user agent is preferred. For example, the alternatives listed in responses with the 300 (Multiple Choices) and 406 (Not Acceptable) status codes include information about available representations so that the user or user agent can react by making a selection.
サーバーは、代替案のリスト以外の初期表現を送信しないことを選択する場合があり、それにより、ユーザーエージェントによる反応的な交渉が望ましいことが示されます。たとえば、300（複数の選択肢）と406（許容されない）ステータスコードを含む応答にリストされている代替案には、ユーザーまたはユーザーエージェントが選択を行うことで反応できるように、利用可能な表現に関する情報が含まれています。
Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally when public caches are used to distribute server load and reduce network usage.
反応的な交渉は、応答が一般的に使用される寸法（タイプ、言語、エンコードなど）で異なる場合、オリジンサーバーがリクエストの調査からユーザーエージェントの機能を決定できない場合、および一般的にパブリックキャッシュが使用されている場合に有利です。サーバーのロードとネットワークの使用量を削減します。
Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation. Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being developed.
リアクティブな交渉は、ヘッダーセクションに送信された場合にユーザー認識のレイテンシを分解し、代替表現を取得するために2番目の要求が必要な場合、ユーザーエージェントの代替リストを送信することの欠点に苦しんでいます。さらに、この仕様は、自動選択をサポートするためのメカニズムを定義するものではありませんが、そのようなメカニズムが開発されないようにしません。
When content negotiation preferences are sent in a server's response, the listed preferences are called "request content negotiation" because they intend to influence selection of an appropriate content for subsequent requests to that resource. For example, the Accept (Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields can be sent in a response to indicate preferred media types and content codings for subsequent requests to that resource.
コンテンツネゴシエーションの設定がサーバーの応答で送信される場合、リストされた設定は「リクエストコンテンツネゴシエーション」と呼ばれます。なぜなら、そのリソースへの後続の要求に適したコンテンツの選択に影響を与えるつもりです。たとえば、受け入れ（セクション12.5.1）および受け入れエンコード（セクション12.5.3）ヘッダーフィールドは、そのリソースへの後続の要求のために優先されるメディアタイプとコンテンツコーディングを示すために応答で送信できます。
Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch" response header field, which allows discovery of which content types are accepted in PATCH requests.
同様に、[RFC5789]のセクション3.1では、パッチ要求でどのコンテンツタイプが受け入れられるかを発見できる「Accept-Patch」応答ヘッダーフィールドを定義します。
For each of the content negotiation fields, a request that does not contain the field implies that the sender has no preference on that dimension of negotiation.
各コンテンツネゴシエーションフィールドについて、フィールドを含まない要求は、送信者が交渉のその側面を好まないことを意味します。
If a content negotiation header field is present in a request and none of the available representations for the response can be considered acceptable according to it, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation for that request header field. This does not imply, however, that the client will be able to use the representation.
コンテンツネゴシエーションヘッダーフィールドがリクエストに存在し、応答の利用可能な表現のいずれもそれに従って許容できると見なすことができない場合、Origin Serverは406（許容されない）応答を送信することにより、ヘッダーフィールドを尊重するか、ヘッダーを無視できます。その要求ヘッダーフィールドのコンテンツネゴシエーションの対象ではないかのように応答を扱うことによりフィールド。ただし、これは、クライアントが表現を使用できることを意味しません。
| *Note:* A user agent sending these header fields makes it
| easier for a server to identify an individual by virtue of the
| user agent's request characteristics (Section 17.13).
The content negotiation fields defined by this specification use a common parameter, named "q" (case-insensitive), to assign a relative "weight" to the preference for that associated kind of content. This weight is referred to as a "quality value" (or "qvalue") because the same parameter name is often used within server configurations to assign a weight to the relative quality of the various representations that can be selected for a resource.
この仕様で定義されたコンテンツネゴシエーションフィールドは、「Q」（ケース非感受性）という名前の共通パラメーターを使用して、関連するコンテンツの好みに相対的な「重み」を割り当てます。同じパラメーター名がサーバー構成内でよく使用され、リソース用に選択できるさまざまな表現の相対的な品質に重みを割り当てるため、この重みは「品質値」（または「QValue」）と呼ばれます。
The weight is normalized to a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; a value of 0 means "not acceptable". If no "q" parameter is present, the default weight is 1.
重量は0〜1の範囲の実数に正規化され、0.001は最も好ましくなく、1が最も好まれます。0の値は「受け入れられない」を意味します。「Q」パラメーターが存在しない場合、デフォルトの重みは1です。
weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
A sender of qvalue MUST NOT generate more than three digits after the decimal point. User configuration of these values ought to be limited in the same fashion.
QValueの送信者は、小数点の後に3桁以上を生成してはなりません。これらの値のユーザー構成は、同じ方法で制限されるべきです。
Most of these header fields, where indicated, define a wildcard value ("*") to select unspecified values. If no wildcard is present, values that are not explicitly mentioned in the field are considered unacceptable. Within Vary, the wildcard value means that the variance is unlimited.
示されているこれらのヘッダーフィールドのほとんどは、不特定の値を選択するためにワイルドカード値（ "*"）を定義します。ワイルドカードが存在しない場合、フィールドで明示的に言及されていない値は受け入れられないと見なされます。さまざまな状態で、ワイルドカード値は、分散が無制限であることを意味します。
| *Note:* In practice, using wildcards in content negotiation has
| limited practical value because it is seldom useful to say, for
| example, "I prefer image/* more or less than (some other
| specific value)". By sending Accept: */*;q=0, clients can
| explicitly request a 406 (Not Acceptable) response if a more
| preferred format is not available, but they still need to be
| able to handle a different response since the server is allowed
| to ignore their preference.
The "Accept" header field can be used by user agents to specify their preferences regarding response media types. For example, Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.
「Accept」ヘッダーフィールドは、ユーザーエージェントが応答メディアタイプに関する好みを指定するために使用できます。たとえば、受け入れヘッダーフィールドを使用して、インライン画像のリクエストの場合のように、リクエストが目的のタイプの小さなセットに特に制限されていることを示すことができます。
When sent by a server in a response, Accept provides information about which content types are preferred in the content of a subsequent request to the same resource.
サーバーによって応答で送信されると、Acceptは、同じリソースへの後続の要求のコンテンツでどのコンテンツタイプが優先されるかについての情報を提供します。
Accept = #( media-range [ weight ] )
media-range = ( "*/*"
/ ( type "/" "*" )
/ ( type "/" subtype )
) parameters
The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type. The media-range can include media type parameters that are applicable to that range.
アスタリスク「*」文字は、メディアタイプを範囲にグループ化するために使用され、「*/*」はすべてのメディアタイプを示し、「type/*」はそのタイプのすべてのサブタイプを示します。メディアレンジには、その範囲に適用可能なメディアタイプパラメーターを含めることができます。
Each media-range might be followed by optional applicable media type parameters (e.g., charset), followed by an optional "q" parameter for indicating a relative weight (Section 12.4.2).
各メディアレンジの後に、オプションの適用可能なメディアタイプパラメーター（charsetなど）が続く場合があり、その後に相対的な重みを示すためのオプションの「q」パラメーターが続きます（セクション12.4.2）。
Previous specifications allowed additional extension parameters to appear after the weight parameter. The accept extension grammar (accept-params, accept-ext) has been removed because it had a complicated definition, was not being used in practice, and is more easily deployed through new header fields. Senders using weights SHOULD send "q" last (after all media-range parameters). Recipients SHOULD process any parameter named "q" as weight, regardless of parameter ordering.
以前の仕様により、重量パラメーターの後に追加の拡張パラメーターが表示されました。Accept Extension Grammar（Accept-Params、Accept-Ext）は、複雑な定義があり、実際には使用されておらず、新しいヘッダーフィールドを通じてより簡単に展開されるため、削除されました。ウェイトを使用している送信者は、「Q」を最後に送信する必要があります（すべてのメディア範囲パラメーターの後）。受信者は、パラメーターの順序に関係なく、「Q」という名前のパラメーターを重量として処理する必要があります。
| *Note:* Use of the "q" parameter name to control content
| negotiation would interfere with any media type parameter
| having the same name. Hence, the media type registry disallows
| parameters named "q".
The example
例
Accept: audio/*; q=0.2, audio/basic
is interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% markdown in quality".
「オーディオ/ベーシックを好むが、品質が80％のマークダウンの後に利用可能な場合はオーディオタイプを送ってください」と解釈されます。
A more elaborate example is
より精巧な例はそうです
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are the equally preferred media types, but if they do not exist, then send the text/x-dvi representation, and if that does not exist, send the text/plain representation".
口頭では、これは「Text/HTMLおよびText/X-Cは同様に好ましいメディアタイプですが、それらが存在しない場合は、テキスト/X-DVI表現を送信し、それが存在しない場合はテキスト/送信/平易な表現」。
Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence. For example,
メディア範囲は、より特定のメディア範囲または特定のメディアタイプによってオーバーライドできます。複数のメディア範囲が特定のタイプに適用される場合、最も具体的な参照が優先されます。例えば、
Accept: text/*, text/plain, text/plain;format=flowed, */*
have the following precedence:
次の優先順位があります。
1. text/plain;format=flowed
1. Text/Plain; Format = Flowed
2. text/plain
2. テキスト/プレーン
3. text/*
3. 文章/*
4. */*
The media type quality factor associated with a given type is determined by finding the media range with the highest precedence that matches the type. For example,
特定のタイプに関連付けられたメディアタイプの品質係数は、タイプと一致する最高の優先順位を持つメディア範囲を見つけることによって決定されます。例えば、
Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
text/plain;format=fixed;q=0.4, */*;q=0.5
would cause the following values to be associated:
次の値を関連付けます。
+==========================+===============+
| Media Type | Quality Value |
+==========================+===============+
| text/plain;format=flowed | 1 |
+--------------------------+---------------+
| text/plain | 0.7 |
+--------------------------+---------------+
| text/html | 0.3 |
+--------------------------+---------------+
| image/jpeg | 0.5 |
+--------------------------+---------------+
| text/plain;format=fixed | 0.4 |
+--------------------------+---------------+
| text/html;level=3 | 0.7 |
+--------------------------+---------------+
Table 5
表5
| *Note:* A user agent might be provided with a default set of
| quality values for certain media ranges. However, unless the
| user agent is a closed system that cannot interact with other
| rendering agents, this default set ought to be configurable by
| the user.
The "Accept-Charset" header field can be sent by a user agent to indicate its preferences for charsets in textual response content. For example, this field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets.
「Accept-Charset」ヘッダーフィールドは、テキスト応答コンテンツの充電の好みを示すために、ユーザーエージェントによって送信できます。たとえば、このフィールドを使用すると、より包括的なまたは特別な充電充電を理解できるユーザーエージェントが、それらの充電器で情報を表すことができるOrigin Serverにその機能を示すことができます。
Accept-Charset = #( ( token / "*" ) [ weight ] )
Charset names are defined in Section 8.3.2. A user agent MAY associate a quality value with each charset to indicate the user's relative preference for that charset, as defined in Section 12.4.2. An example is
Charset名はセクション8.3.2で定義されています。ユーザーエージェントは、セクション12.4.2で定義されているように、そのチャーセットに対するユーザーの相対的な好みを示すために、各炭化値と品質値を関連付けることができます。例は次のとおりです
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset header field, matches every charset that is not mentioned elsewhere in the field.
特別な値「*」は、Accept-chharsetヘッダーフィールドに存在する場合、フィールドの他の場所で言及されていないすべての憲章と一致します。
| *Note:* Accept-Charset is deprecated because UTF-8 has become
| nearly ubiquitous and sending a detailed list of user-preferred
| charsets wastes bandwidth, increases latency, and makes passive
| fingerprinting far too easy (Section 17.13). Most general-
| purpose user agents do not send Accept-Charset unless
| specifically configured to do so.
The "Accept-Encoding" header field can be used to indicate preferences regarding the use of content codings (Section 8.4.1).
「Accept-Encoding」ヘッダーフィールドを使用して、コンテンツコーディングの使用に関する好みを示すことができます（セクション8.4.1）。
When sent by a user agent in a request, Accept-Encoding indicates the content codings acceptable in a response.
リクエストでユーザーエージェントから送信されると、Accept-Encodingは、応答で許容できるコンテンツコードを示します。
When sent by a server in a response, Accept-Encoding provides information about which content codings are preferred in the content of a subsequent request to the same resource.
サーバーによって応答で送信されると、Accept-Encodingは、同じリソースへの後続の要求のコンテンツでどのコンテンツコーディングが優先されるかについての情報を提供します。
An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred.
「アイデンティティ」トークンは、エンコードが好まない場合に通信するために「エンコードなし」の同義語として使用されます。
Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*"
Each codings value MAY be given an associated quality value (weight) representing the preference for that encoding, as defined in Section 12.4.2. The asterisk "*" symbol in an Accept-Encoding field matches any available content coding not explicitly listed in the field.
各コーディング値には、セクション12.4.2で定義されているように、そのエンコードの好みを表す関連する品質値（重量）が与えられる場合があります。Accept-Encodingフィールドのアスタリスク「*」シンボルは、フィールドに明示的にリストされていない利用可能なコンテンツコーディングと一致します。
Examples:
例：
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
A server tests whether a content coding for a given representation is acceptable using these rules:
サーバーは、これらのルールを使用して、特定の表現のコンテンツコーディングが許容できるかどうかをテストします。
1. If no Accept-Encoding header field is in the request, any content coding is considered acceptable by the user agent.
1. 受け入れエンコードヘッダーフィールドがリクエストにない場合、コンテンツコーディングはユーザーエージェントが許容できると見なされます。
2. If the representation has no content coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding header field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity".
2. 表現にコンテンツコーディングがない場合、「ID; q = 0」または「*; q = 0」を「アイデンティティ」のより具体的なエントリなしで「アイデンティティ」または「*; Q = 0」のいずれかを記載した受け入れエンコードヘッダーフィールドによって具体的に除外されない限り、デフォルトで許容されます。。
3. If the representation's content coding is one of the content codings listed in the Accept-Encoding field value, then it is acceptable unless it is accompanied by a qvalue of 0. (As defined in Section 12.4.2, a qvalue of 0 means "not acceptable".)
3. 表現のコンテンツコーディングが、受け入れエンコードフィールド値にリストされているコンテンツコーディングの1つである場合、0のqvalueを伴わない限り、それは許容されます（セクション12.4.2で定義されているように、0のqvalueは0を意味します」許容できる"。）
A representation could be encoded with multiple content codings. However, most content codings are alternative ways to accomplish the same purpose (e.g., data compression). When selecting between multiple content codings that have the same purpose, the acceptable content coding with the highest non-zero qvalue is preferred.
表現は、複数のコンテンツコーディングでエンコードできます。ただし、ほとんどのコンテンツコーディングは、同じ目的を達成するための代替方法（データ圧縮など）です。同じ目的を持つ複数のコンテンツコーディング間で選択する場合、最高の非ゼロQ値を持つ許容可能なコンテンツコーディングが推奨されます。
An Accept-Encoding header field with a field value that is empty implies that the user agent does not want any content coding in response. If a non-empty Accept-Encoding header field is present in a request and none of the available representations for the response have a content coding that is listed as acceptable, the origin server SHOULD send a response without any content coding unless the identity coding is indicated as unacceptable.
空のフィールド値を持つ受け入れエンコードヘッダーフィールドは、ユーザーエージェントがそれに応じてコンテンツコーディングを望まないことを意味します。非空白の受け入れエンコードヘッダーフィールドがリクエストに存在し、応答の利用可能な表現はいずれも許容できるとリストされているコンテンツコーディングを持っていない場合、IDのコーディングがない限り、Origin Serverはコンテンツコーディングなしで応答を送信する必要があります。容認できないことが示されています。
When the Accept-Encoding header field is present in a response, it indicates what content codings the resource was willing to accept in the associated request. The field value is evaluated the same way as in a request.
受け入れエンコードヘッダーフィールドが応答に存在する場合、関連するリクエストでリソースが喜んで受け入れるコンテンツコーディングを示します。フィールド値は、リクエストと同じ方法で評価されます。
Note that this information is specific to the associated request; the set of supported encodings might be different for other resources on the same server and could change over time or depend on other aspects of the request (such as the request method).
この情報は関連する要求に固有のものであることに注意してください。サポートされているエンコーディングのセットは、同じサーバー上の他のリソースで異なる場合があり、時間とともに変更されるか、リクエストの他の側面（リクエスト方法など）に依存する可能性があります。
Servers that fail a request due to an unsupported content coding ought to respond with a 415 (Unsupported Media Type) status and include an Accept-Encoding header field in that response, allowing clients to distinguish between issues related to content codings and media types. In order to avoid confusion with issues related to media types, servers that fail a request with a 415 status for reasons unrelated to content codings MUST NOT include the Accept-Encoding header field.
サポートされていないコンテンツコーディングのためにリクエストに失敗したサーバーは、415（サポートされていないメディアタイプ）ステータスで応答し、その応答に受け入れエンコードヘッダーフィールドを含めて、クライアントがコンテンツコーディングとメディアタイプに関連する問題を区別できるようにする必要があります。メディアタイプに関連する問題との混乱を避けるために、コンテンツコードとは無関係の理由で415ステータスでリクエストに失敗したサーバーは、受け入れエンコードヘッダーフィールドを含めてはなりません。
The most common use of Accept-Encoding is in responses with a 415 (Unsupported Media Type) status code, in response to optimistic use of a content coding by clients. However, the header field can also be used to indicate to clients that content codings are supported in order to optimize future interactions. For example, a resource might include it in a 2xx (Successful) response when the request content was big enough to justify use of a compression coding but the client failed do so.
受け入れエンコードの最も一般的な使用は、クライアントによるコンテンツコーディングの楽観的な使用に応じて、415（サポートされていないメディアタイプ）ステータスコードの応答です。ただし、ヘッダーフィールドを使用して、将来の相互作用を最適化するためにコンテンツコーディングがサポートされていることをクライアントに示すこともできます。たとえば、リソースには、リクエストコンテンツが圧縮コーディングの使用を正当化するのに十分な大きさであるが、クライアントが失敗した場合、2xx（成功）応答に含めることができます。
The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred in the response. Language tags are defined in Section 8.5.1.
「Accept-Language」ヘッダーフィールドは、ユーザーエージェントが使用して、応答で好まれる自然言語のセットを示すことができます。言語タグは、セクション8.5.1で定義されています。
Accept-Language = #( language-range [ weight ] )
language-range =
<language-range, see [RFC4647], Section 2.1>
Each language-range can be given an associated quality value representing an estimate of the user's preference for the languages specified by that range, as defined in Section 12.4.2. For example,
各言語範囲には、セクション12.4.2で定義されているように、その範囲で指定された言語に対するユーザーの好みの推定値を表す関連する品質値を与えることができます。例えば、
Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and other types of English".
「私はデンマーク語が好きですが、英国の英語やその他の種類の英語を受け入れます」という意味です。
Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly for tags that are assigned equal quality values (no value is the same as q=1). However, this behavior cannot be relied upon. For consistency and to maximize interoperability, many user agents assign each language tag a unique quality value while also listing them in order of decreasing quality. Additional discussion of language priority lists can be found in Section 2.3 of [RFC4647].
一部の受信者は、特に等しい品質値が割り当てられているタグに対して、言語タグが下降優先度の指標としてリストされる順序を扱うことに注意してください（q = 1と同じ値はありません）。ただし、この動作は依存することはできません。一貫性と相互運用性を最大化するために、多くのユーザーエージェントは各言語タグを一意の品質値を割り当てながら、品質を低下させる順にそれらをリストします。言語優先リストの追加の議論は、[RFC4647]のセクション2.3に記載されています。
For matching, Section 3 of [RFC4647] defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is identical to the matching scheme that was previously defined for HTTP in Section 14.4 of [RFC2616].
一致するために、[RFC4647]のセクション3では、いくつかの一致するスキームを定義します。実装は、要件に最も適したマッチングスキームを提供できます。「基本的なフィルタリング」スキーム（[RFC4647]、セクション3.3.1）は、[RFC2616]のセクション14.4でHTTPに対して以前に定義されていた一致スキームと同一です。
It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic preferences of the user in every request (Section 17.13).
すべての要求（セクション17.13）で、ユーザーの完全な言語的選好を備えた受け入れ言語ヘッダーフィールドを送信するというユーザーのプライバシーの期待に反するかもしれません。
Since intelligibility is highly dependent on the individual user, user agents need to allow user control over the linguistic preference (either through configuration of the user agent itself or by defaulting to a user controllable system setting). A user agent that does not provide such control to the user MUST NOT send an Accept-Language header field.
わかりやすさは個々のユーザーに大きく依存しているため、ユーザーエージェントは、ユーザーが言語の好みを制御できるようにする必要があります（ユーザーエージェント自体の構成を介して、またはデフォルトでユーザー制御可能なシステム設定にデフォルトで）。ユーザーにそのようなコントロールを提供しないユーザーエージェントは、承認言語ヘッダーフィールドを送信してはなりません。
| *Note:* User agents ought to provide guidance to users when
| setting a preference, since users are rarely familiar with the
| details of language matching as described above. For example,
| users might assume that on selecting "en-gb", they will be
| served any kind of English document if British English is not
| available. A user agent might suggest, in such a case, to add
| "en" to the list for better matching behavior.
The "Vary" header field in a response describes what parts of a request message, aside from the method and target URI, might have influenced the origin server's process for selecting the content of this response.
応答の「変化」ヘッダーフィールドは、メソッドとターゲットURIを除いて、リクエストメッセージの部分が、この応答のコンテンツを選択するためのOrigin Serverのプロセスに影響を与えた可能性があることを説明しています。
Vary = #( "*" / field-name )
A Vary field value is either the wildcard member "*" or a list of request field names, known as the selecting header fields, that might have had a role in selecting the representation for this response. Potential selecting header fields are not limited to fields defined by this specification.
フィールド値の変化は、WildCardメンバー「*」または選択ヘッダーフィールドと呼ばれるリクエストフィールド名のリストが、この応答の表現を選択するのに役割を果たしていた可能性があります。潜在的な選択ヘッダーフィールドは、この仕様で定義されたフィールドに限定されません。
A list containing the member "*" signals that other aspects of the request might have played a role in selecting the response representation, possibly including aspects outside the message syntax (e.g., the client's network address). A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server. A proxy MUST NOT generate "*" in a Vary field value.
メンバー「*」を含むリストは、リクエストの他の側面が応答表現を選択する際に役割を果たしている可能性があることを示しています。おそらくメッセージ構文外の側面（クライアントのネットワークアドレスなど）。受信者は、リクエストをOrigin Serverに転送せずに、この応答が後の要求に適しているかどうかを判断できません。プロキシは、さまざまなフィールド値で「*」を生成してはなりません。
For example, a response that contains
たとえば、含む応答
Vary: accept-encoding, accept-language
Vary：Accept-Encoding、Accept-Language
indicates that the origin server might have used the request's Accept-Encoding and Accept-Language header fields (or lack thereof) as determining factors while choosing the content for this response.
Origin Serverが、この応答のコンテンツを選択しながら、要因を決定する因子として、リクエストの承認エンコードおよび受け入れのヘッダーフィールド（またはその欠如）を使用した可能性があることを示します。
A Vary field containing a list of field names has two purposes:
フィールド名のリストを含むさまざまなフィールドには、次の2つの目的があります。
1. To inform cache recipients that they MUST NOT use this response to satisfy a later request unless the later request has the same values for the listed header fields as the original request (Section 4.1 of [CACHING]) or reuse of the response has been validated by the origin server. In other words, Vary expands the cache key required to match a new request to the stored cache entry.
1. 後の要求が元の要求（[キャッシュ]のセクション4.1）または応答の再利用が検証されている場合、後のリクエストがリストされたヘッダーフィールドに同じ値を持っている場合を除き、後の要求を満たすためにこの応答を使用してはならないことを受信者に通知するためにOrigin Server。言い換えれば、Varyは、新しい要求を保存されたキャッシュエントリに一致させるために必要なキャッシュキーを拡張します。
2. To inform user agent recipients that this response was subject to content negotiation (Section 12) and a different representation might be sent in a subsequent request if other values are provided in the listed header fields (proactive negotiation).
2. この応答がコンテンツネゴシエーションの対象であることをユーザーエージェントの受信者に通知するために（セクション12）、およびリストされたヘッダーフィールドに他の値が提供されている場合、その後のリクエストで異なる表現が送信される場合があります（プロアクティブネゴシエーション）。
An origin server SHOULD generate a Vary header field on a cacheable response when it wishes that response to be selectively reused for subsequent requests. Generally, that is the case when the response content has been tailored to better fit the preferences expressed by those selecting header fields, such as when an origin server has selected the response's language based on the request's Accept-Language header field.
Origin Serverは、その後のリクエストに対して選択的に再利用することを望んでいる場合、キャッシュ可能な応答で異なるヘッダーフィールドを生成する必要があります。一般的に、それは、リクエストの受け入れ言語ヘッダーフィールドに基づいてOrigin Serverが応答の言語を選択した場合など、ヘッダーフィールドを選択する人によって表現された設定に適合するように応答コンテンツが調整された場合です。
Vary might be elided when an origin server considers variance in content selection to be less significant than Vary's performance impact on caching, particularly when reuse is already limited by cache response directives (Section 5.2 of [CACHING]).
Origin Serverがコンテンツの選択の差異がキャッシュに対する変化のパフォーマンスへの影響よりも重要でないと考えている場合、特に再利用がすでにキャッシュ応答ディレクティブによって制限されている場合（[キャッシュ]セクション5.2）、変化が除外される場合があります。
There is no need to send the Authorization field name in Vary because reuse of that response for a different user is prohibited by the field definition (Section 11.6.2). Likewise, if the response content has been selected or influenced by network region, but the origin server wants the cached response to be reused even if recipients move from one region to another, then there is no need for the origin server to indicate such variance in Vary.
別のユーザーのその応答の再利用は、フィールドの定義によって禁止されているため、承認フィールド名をさまざまに送信する必要はありません（セクション11.6.2）。同様に、応答コンテンツがネットワーク領域の選択または影響を受けているが、Origin Serverは、受信者がある領域から別の領域に移動してもキャッシュされた応答を再利用する必要がある場合、Origin Serverがそのような分散を示す必要はありません。変化。
A conditional request is an HTTP request with one or more request header fields that indicate a precondition to be tested before applying the request method to the target resource. Section 13.2 defines when to evaluate preconditions and their order of precedence when more than one precondition is present.
条件付き要求は、ターゲットリソースにリクエストメソッドを適用する前にテストする前提条件を示す1つ以上の要求ヘッダーフィールドを備えたHTTPリクエストです。セクション13.2では、複数の前提条件が存在する場合、前提条件と優先順位を評価するタイミングを定義します。
Conditional GET requests are the most efficient mechanism for HTTP cache updates [CACHING]. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: one client accidentally overwriting the work of another client that has been acting in parallel.
条件付きGETリクエストは、HTTPキャッシュの更新[キャッシュ]の最も効率的なメカニズムです。条件は、PutやDeleteなどの状態変化する方法にも適用して、「紛失した更新」の問題を防ぐことができます。あるクライアントは、並行して行動している別のクライアントの作業を誤って上書きします。
Preconditions are usually defined with respect to a state of the target resource as a whole (its current value set) or the state as observed in a previously obtained representation (one value in that set). If a resource has multiple current representations, each with its own observable state, a precondition will assume that the mapping of each request to a selected representation (Section 3.2) is consistent over time. Regardless, if the mapping is inconsistent or the server is unable to select an appropriate representation, then no harm will result when the precondition evaluates to false.
前提条件は通常、ターゲットリソース全体の状態（現在の値セット）または以前に得られた表現（そのセットで1つの値）で観察された状態に関して定義されます。リソースに複数の電流表現がある場合、それぞれが独自の観察可能な状態を持つ場合、前提条件により、選択した表現（セクション3.2）への各要求のマッピングが時間の経過とともに一貫していると想定します。とにかく、マッピングが一貫性がない場合、またはサーバーが適切な表現を選択できない場合、前提条件がfalseと評価されると、害は生じません。
Each precondition defined below consists of a comparison between a set of validators obtained from prior representations of the target resource to the current state of validators for the selected representation (Section 8.8). Hence, these preconditions evaluate whether the state of the target resource has changed since a given state known by the client. The effect of such an evaluation depends on the method semantics and choice of conditional, as defined in Section 13.2.
以下に定義されている各前処理は、ターゲットリソースの以前の表現から取得したバリデーターのセットと、選択された表現の現在のバリデーターの状態との比較で構成されています（セクション8.8）。したがって、これらの前提条件は、クライアントが知っている特定の状態以来、ターゲットリソースの状態が変化したかどうかを評価します。このような評価の効果は、セクション13.2で定義されているように、メソッドセマンティクスと条件付きの選択に依存します。
Other preconditions, defined by other specifications as extension fields, might place conditions on all recipients, on the state of the target resource in general, or on a group of resources. For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field ([WEBDAV], Section 10.4).
拡張フィールドとして他の仕様によって定義されるその他の前提条件は、すべての受信者、一般的なターゲットリソースの状態、またはリソースのグループに条件を配置する可能性があります。たとえば、WebDavの「IF」ヘッダーフィールドは、受信者がそのフィールド（[WebDav]、セクション10.4）を理解し、実装した場合、ロックなどの複数のリソースのさまざまな側面を条件とする要求を行うことができます。
Extensibility of preconditions is only possible when the precondition can be safely ignored if unknown (like If-Modified-Since), when deployment can be assumed for a given use case, or when implementation is signaled by some other property of the target resource. This encourages a focus on mutually agreed deployment of common standards.
前提条件の拡張性は、前提条件を安全に無視できる場合にのみ可能です（変更された場合など）、特定のユースケースで展開を想定できる場合、またはターゲットリソースの他のプロパティによって実装が通知された場合。これは、相互に合意された共通基準の展開に焦点を当てることを奨励します。
The "If-Match" header field makes the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field value is "*", or having a current representation of the target resource that has an entity tag matching a member of the list of entity tags provided in the field value.
「if-match」ヘッダーフィールドは、フィールド値が「*」の場合、ターゲットリソースの少なくとも1つの現在の表現を持つか、またはターゲットリソースの現在の表現を持つターゲットリソースの少なくとも1つの現在の表現を備えたレシピエントオリジンサーバーを条件とした要求方法を作成します。フィールド値で提供されるエンティティタグのリストのメンバーに一致するエンティティタグ。
An origin server MUST use the strong comparison function when comparing entity tags for If-Match (Section 8.8.3.2), since the client intends this precondition to prevent the method from being applied if there have been any changes to the representation data.
クライアントは、表現データに変更があった場合にメソッドが適用されないようにこの前提条件を意図しているため、Origin ServerはIFマッチのエンティティタグを比較するときに強力な比較関数を使用する必要があります（セクション8.8.3.2）。
If-Match = "*" / #entity-tag
Examples:
例：
If-Match: "xyzzy" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: *
if-match： "xyzzy" if-match： "xyzzy"、 "r2d2xxxx"、 "c3piozzzz" if-match： *
If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to prevent the "lost update" problem). In general, it can be used with any method that involves the selection or modification of a representation to abort the request if the selected representation's current entity tag is not a member within the If-Match field value.
If-Matchは、複数のユーザーエージェントが同じリソースで並行して作用している場合に偶発的な上書きを防ぐために、状態変更メソッド（例：put、put、削除）で最も頻繁に使用されます（つまり、「lost update」問題を防ぐため）。一般に、選択した表現の現在のエンティティタグがIFマッチフィールド値内のメンバーではない場合、リクエストを中止するために表現の選択または変更を含む任意の方法で使用できます。
When an origin server receives a request that selects a representation and that request includes an If-Match header field, the origin server MUST evaluate the If-Match condition per Section 13.2 prior to performing the method.
Origin Serverが表現を選択する要求を受信し、その要求にIFマッチヘッダーフィールドが含まれる場合、Origin Serverは、メソッドを実行する前にセクション13.2ごとにIFマッチ条件を評価する必要があります。
To evaluate a received If-Match header field:
受信したif-matchヘッダーフィールドを評価するには：
1. If the field value is "*", the condition is true if the origin server has a current representation for the target resource.
1. フィールド値が「*」の場合、Origin Serverにターゲットリソースの現在の表現がある場合、条件は真です。
2. If the field value is a list of entity tags, the condition is true if any of the listed tags match the entity tag of the selected representation.
2. フィールド値がエンティティタグのリストである場合、リストされたタグのいずれかが選択した表現のエンティティタグと一致する場合、条件は真です。
3. Otherwise, the condition is false.
3. それ以外の場合、条件は偽です。
An origin server that evaluates an If-Match condition MUST NOT perform the requested method if the condition evaluates to false. Instead, the origin server MAY indicate that the conditional request failed by responding with a 412 (Precondition Failed) status code. Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected representation, the origin server MAY respond with a 2xx (Successful) status code (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or an equivalent change was made by some other user agent).
IFマッチ条件を評価するOrigin Serverは、条件がFalseと評価された場合、要求された方法を実行してはなりません。代わりに、Origin Serverは、412（前提条件に失敗した）ステータスコードで応答することで条件付き要求が失敗したことを示している場合があります。あるいは、リクエストが選択された表現にすでに適用されていると思われる状態変更操作である場合、Origin Serverは2xx（成功）ステータスコードで応答する場合があります（つまり、ユーザーエージェントが要求した変更はすでに成功しています。しかし、おそらく以前の応答が失われたか、他のユーザーエージェントによって同等の変更が行われたため、ユーザーエージェントはそれを認識していないかもしれません。
Allowing an origin server to send a success response when a change request appears to have already been applied is more efficient for many authoring use cases, but comes with some risk if multiple user agents are making change requests that are very similar but not cooperative. For example, multiple user agents writing to a common resource as a semaphore (e.g., a nonatomic increment) are likely to collide and potentially lose important state transitions. For those kinds of resources, an origin server is better off being stringent in sending 412 for every failed precondition on an unsafe method. In other cases, excluding the ETag field from a success response might encourage the user agent to perform a GET as its next request to eliminate confusion about the resource's current state.
Origin Serverが変更要求が既に適用されているように見える場合に成功応答を送信できるようにすることは、多くのオーサリングユースケースでより効率的ですが、複数のユーザーエージェントが非常に類似しているが協力的ではない変更要求を行っている場合、ある程度のリスクがあります。たとえば、複数のユーザーエージェントがセマフォとして共通のリソースに書き込む（例：非原子的増分）が衝突する可能性が高く、重要な状態移行を失う可能性があります。これらの種類のリソースの場合、Origin Serverは、安全でない方法で失敗した前提条件ごとに412を送信する方が厳しい方が良いでしょう。それ以外の場合、成功応答からETAGフィールドを除外すると、ユーザーエージェントがリソースの現在の状態に関する混乱を排除する次の要求としてGETを実行することを促進する場合があります。
A client MAY send an If-Match header field in a GET request to indicate that it would prefer a 412 (Precondition Failed) response if the selected representation does not match. However, this is only useful in range requests (Section 14) for completing a previously received partial representation when there is no desire for a new representation. If-Range (Section 13.1.5) is better suited for range requests when the client prefers to receive a new representation.
クライアントは、選択した表現が一致しない場合、412（前提条件に失敗した）応答を好むことを示すために、IFマッチヘッダーフィールドをGETリクエストで送信できます。ただし、これは、新しい表現を望んでいない場合に、以前に受け取った部分表現を完了するための範囲要求（セクション14）でのみ役立ちます。if-range（セクション13.1.5）は、クライアントが新しい表現を受信することを好む場合、範囲要求に適しています。
A cache or intermediary MAY ignore If-Match because its interoperability features are only necessary for an origin server.
キャッシュまたは仲介者は、その相互運用性機能がOrigin Serverにのみ必要であるため、IFマッチを無視する場合があります。
Note that an If-Match header field with a list value containing "*" and other values (including other instances of "*") is syntactically invalid (therefore not allowed to be generated) and furthermore is unlikely to be interoperable.
「*」とその他の値（「*」の他のインスタンスを含む）を含むリスト値を持つIFマッチヘッダーフィールドは、構文的に無効であり（したがって生成することは許可されていません）、さらに相互運用可能である可能性は低いことに注意してください。
The "If-None-Match" header field makes the request method conditional on a recipient cache or origin server either not having any current representation of the target resource, when the field value is "*", or having a selected representation with an entity tag that does not match any of those listed in the field value.
「if-none-match」ヘッダーフィールドは、フィールド値が「*」の場合、またはエンティティを使用して選択された表現を持つ場合、ターゲットリソースの現在の表現を持っていないレシピエントキャッシュまたはオリジンサーバーを条件とする要求方法を作成します。フィールド値にリストされているもののいずれも一致しないタグ。
A recipient MUST use the weak comparison function when comparing entity tags for If-None-Match (Section 8.8.3.2), since weak entity tags can be used for cache validation even if there have been changes to the representation data.
IF-NONE-MATCH（セクション8.8.3.2）のエンティティタグを比較するときに、受信者は弱い比較関数を使用する必要があります。
If-None-Match = "*" / #entity-tag
Examples:
例：
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *
If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information with a minimum amount of transaction overhead. When a client desires to update one or more stored responses that have entity tags, the client SHOULD generate an If-None-Match header field containing a list of those entity tags when making a GET request; this allows recipient servers to send a 304 (Not Modified) response to indicate when one of those stored responses matches the selected representation.
IF-None-Matchは、最小限のトランザクションオーバーヘッドでキャッシュされた情報の効率的な更新を有効にするために、条件付きGETリクエストで主に使用されます。クライアントがエンティティタグを持つ1つ以上の保存された応答を更新したい場合、クライアントは、GETリクエストを行うときにそれらのエンティティタグのリストを含むIF-Noneマッチヘッダーフィールドを生成する必要があります。これにより、受信者サーバーは304（変更されていない）応答を送信して、これらの保存されている応答の1つが選択された表現と一致するときを示すことができます。
If-None-Match can also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation (Section 9.2.1). This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation for the target resource.
if-none-matchを「*」の値で使用して、安全でないリクエスト方法（例えば、put）がターゲットリソースの既存の表現を不注意に変更するのを防ぐこともできます。（セクション9.2.1）。これは、複数のクライアントがターゲットリソースの初期表現を作成しようとする場合に発生する可能性のある「Lost Update」問題のバリエーションです。
When an origin server receives a request that selects a representation and that request includes an If-None-Match header field, the origin server MUST evaluate the If-None-Match condition per Section 13.2 prior to performing the method.
Origin Serverが表現を選択する要求を受信し、その要求にIF-Noneマッチヘッダーフィールドが含まれる場合、Origin Serverはメソッドを実行する前に、セクション13.2ごとにIF-None条件を評価する必要があります。
To evaluate a received If-None-Match header field:
受信したIF-None-Matchヘッダーフィールドを評価するには：
1. If the field value is "*", the condition is false if the origin server has a current representation for the target resource.
1. フィールド値が「*」の場合、Origin Serverがターゲットリソースの現在の表現を持っている場合、条件は偽です。
2. If the field value is a list of entity tags, the condition is false if one of the listed tags matches the entity tag of the selected representation.
2. フィールド値がエンティティタグのリストである場合、リストされているタグの1つが選択した表現のエンティティタグと一致する場合、条件は誤りです。
3. Otherwise, the condition is true.
3. それ以外の場合、条件は真です。
An origin server that evaluates an If-None-Match condition MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond with either a) the 304 (Not Modified) status code if the request method is GET or HEAD or b) the 412 (Precondition Failed) status code for all other request methods.
条件がfalseと評価されている場合、if-none-match条件を評価するオリジンサーバーは、要求された方法を実行してはなりません。代わりに、Origin Serverは、a）要求方法がgetまたはheadまたはb）の場合、a）304（変更されていない）ステータスコードのいずれかで応答する必要があります。
Requirements on cache handling of a received If-None-Match header field are defined in Section 4.3.2 of [CACHING].
受信したIF-Noneマッチヘッダーフィールドのキャッシュ処理に関する要件は、[キャッシュ]のセクション4.3.2で定義されています。
Note that an If-None-Match header field with a list value containing "*" and other values (including other instances of "*") is syntactically invalid (therefore not allowed to be generated) and furthermore is unlikely to be interoperable.
「*」とその他の値（「*」の他のインスタンスを含む）を含むリスト値を持つIF-Noneマッチヘッダーフィールドは、構文的に無効であり（したがって生成することは許可されていません）、さらに相互運用可能である可能性は低いことに注意してください。
The "If-Modified-Since" header field makes a GET or HEAD request method conditional on the selected representation's modification date being more recent than the date provided in the field value. Transfer of the selected representation's data is avoided if that data has not changed.
「if-modified-since」ヘッダーフィールドは、選択した表現の変更日を条件としたGETまたはヘッドリクエストの方法を、フィールド値で提供される日付よりも最近のものです。選択した表現のデータの転送は、そのデータが変更されていない場合は回避されます。
If-Modified-Since = HTTP-date
An example of the field is:
フィールドの例は次のとおりです。
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Modified-Since if the request contains an If-None-Match header field; the condition in If-None-Match is considered to be a more accurate replacement for the condition in If-Modified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement If-None-Match.
受信者は、リクエストにIF-None-Matchヘッダーフィールドが含まれている場合、修正された場合を無視する必要があります。IF-NONE-MATCHの条件は、IF修正額の条件のより正確な代替品と見なされ、2つは、非試合を実装しない可能性のある古い仲介者と相互運用するためにのみ組み合わされます。
A recipient MUST ignore the If-Modified-Since header field if the received field value is not a valid HTTP-date, the field value has more than one member, or if the request method is neither GET nor HEAD.
受信者は、受信したフィールド値が有効なhttp-dateではない場合、フィールド値に複数のメンバーがある場合、またはリクエストメソッドが取得もヘッドもない場合、if修正ヘッダーフィールドを無視する必要があります。
A recipient MUST ignore the If-Modified-Since header field if the resource does not have a modification date available.
リソースに使用可能な変更日がない場合、受信者は、if修飾シネシークヘッダーフィールドを無視する必要があります。
A recipient MUST interpret an If-Modified-Since field value's timestamp in terms of the origin server's clock.
受信者は、Origin Serverのクロックの観点から、IFModified-Sinceフィールド値のタイムスタンプを解釈する必要があります。
If-Modified-Since is typically used for two distinct purposes: 1) to allow efficient updates of a cached representation that does not have an entity tag and 2) to limit the scope of a web traversal to resources that have recently changed.
if-midified-sinceは通常、2つの異なる目的に使用されます。1）エンティティタグを持たないキャッシュ表現の効率的な更新を許可し、2）Webトラバーサルの範囲を最近変更したリソースに制限します。
When used for cache updates, a cache will typically use the value of the cached message's Last-Modified header field to generate the field value of If-Modified-Since. This behavior is most interoperable for cases where clocks are poorly synchronized or when the server has chosen to only honor exact timestamp matches (due to a problem with Last-Modified dates that appear to go "back in time" when the origin server's clock is corrected or a representation is restored from an archived backup). However, caches occasionally generate the field value based on other data, such as the Date header field of the cached message or the clock time at which the message was received, particularly when the cached message does not contain a Last-Modified header field.
キャッシュの更新に使用すると、キャッシュは通常、キャッシュされたメッセージの永続化されたヘッダーフィールドの値を使用して、if修正型のフィールド値を生成します。この動作は、クロックが不十分に同期している場合や、サーバーが正確なタイムスタンプの一致のみを尊重することを選択した場合に最も相互運用可能です（Origin Serverのクロックが修正されたときに「時間内に戻る」ように見えるラスト変更された日付の問題のためにまたは、アーカイブされたバックアップから表現が復元されます）。ただし、キャッシュは、キャッシュされたメッセージの日付ヘッダーフィールドや、特にキャッシュされたメッセージにラスト修正ヘッダーフィールドが含まれていない場合、メッセージが受信された時計時間など、他のデータに基づいてフィールド値を生成することがあります。
When used for limiting the scope of retrieval to a recent time window, a user agent will generate an If-Modified-Since field value based on either its own clock or a Date header field received from the server in a prior response. Origin servers that choose an exact timestamp match based on the selected representation's Last-Modified header field will not be able to help the user agent limit its data transfers to only those changed during the specified window.
検索の範囲を最近のタイムウィンドウに制限するために使用される場合、ユーザーエージェントは、以前の応答でサーバーから受信した独自のクロックまたは日付ヘッダーフィールドに基づいて、if修飾シネシブフィールド値を生成します。選択した表現の永続化されたヘッダーフィールドに基づいて正確なタイムスタンプマッチを選択するオリジンサーバーは、ユーザーエージェントが指定されたウィンドウ中に変更されたもののみにデータ転送を制限するのに役立ちません。
When an origin server receives a request that selects a representation and that request includes an If-Modified-Since header field without an If-None-Match header field, the origin server SHOULD evaluate the If-Modified-Since condition per Section 13.2 prior to performing the method.
Origin Serverが表現を選択するリクエストを受信し、その要求がif-None-Matchヘッダーフィールドのないif修正シセントヘッダーフィールドを含む場合、Origin Serverは、セクション13.2ごとにif-Modified-since条件ごとにIFモジュエーションsince条件を評価する必要があります。メソッドの実行。
To evaluate a received If-Modified-Since header field:
受信したif修正済みのヘッダーフィールドを評価するには：
1. If the selected representation's last modification date is earlier or equal to the date provided in the field value, the condition is false.
1. 選択した表現の最後の変更日が、フィールド値で提供される日付と等しい場合、条件はfalsです。
2. Otherwise, the condition is true.
2. それ以外の場合、条件は真です。
An origin server that evaluates an If-Modified-Since condition SHOULD NOT perform the requested method if the condition evaluates to false; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response.
条件がfalseと評価されている場合、if修正条件を評価するオリジンサーバーは、要求された方法を実行してはなりません。代わりに、Origin Serverは、以前にキャッシュされた応答を識別または更新するのに役立つメタデータのみを含む、304（変更されていない）応答を生成する必要があります。
Requirements on cache handling of a received If-Modified-Since header field are defined in Section 4.3.2 of [CACHING].
受信されたif修正型ヘッダーフィールドのキャッシュ処理に関する要件は、[キャッシュ]のセクション4.3.2で定義されています。
The "If-Unmodified-Since" header field makes the request method conditional on the selected representation's last modification date being earlier than or equal to the date provided in the field value. This field accomplishes the same purpose as If-Match for cases where the user agent does not have an entity tag for the representation.
「If-Unmodified-Since」ヘッダーフィールドは、選択した表現の最後の変更日を、フィールド値で提供される日付以前と等しく、リクエスト方法を条件としています。このフィールドは、ユーザーエージェントが表現のエンティティタグを持っていない場合の場合と同じ目的を達成します。
If-Unmodified-Since = HTTP-date
An example of the field is:
フィールドの例は次のとおりです。
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Unmodified-Since if the request contains an If-Match header field; the condition in If-Match is considered to be a more accurate replacement for the condition in If-Unmodified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement If-Match.
受信者は、リクエストにif-matchヘッダーフィールドが含まれている場合、IF-unmodified-sinceを無視する必要があります。IF-Matchの条件は、IF-Unmodified-Sinceの条件のより正確な代替品であると見なされ、2つは、IF-Matchを実装しない可能性のある古い仲介者と相互運用するためにのみ組み合わされます。
A recipient MUST ignore the If-Unmodified-Since header field if the received field value is not a valid HTTP-date (including when the field value appears to be a list of dates).
受信したフィールド値が有効なHTTP-DATEではない場合、受信者はIF-Unmodified-SINCEヘッダーフィールドを無視する必要があります（フィールド値が日付のリストのように見える場合を含む）。
A recipient MUST ignore the If-Unmodified-Since header field if the resource does not have a modification date available.
リソースに使用可能な変更日がない場合、受信者はIF-UNMODIFIED-SINCEヘッダーフィールドを無視する必要があります。
A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.
受信者は、Origin Serverのクロックに関して、IF-Unmodified Field Valueのタイムスタンプを解釈する必要があります。
If-Unmodified-Since is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity tags with its representations (i.e., to prevent the "lost update" problem). In general, it can be used with any method that involves the selection or modification of a representation to abort the request if the selected representation's last modification date has changed since the date provided in the If-Unmodified-Since field value.
If-Unmodified-Sinceは、複数のユーザーエージェントがその表現（つまり、エンティティタグを提供しないリソース）に並行して作用している場合に偶発的な上書きを防ぐために、状態変化する方法（例：put、put、削除）で最も頻繁に使用されます。、「紛失した更新」の問題を防ぐため）。一般に、選択した表現の最後の変更日がIF-unModified-sinceのフィールド値で提供されてから変更された場合に変更された場合、リクエストを中止するために表現の選択または変更を含む任意の方法で使用できます。
When an origin server receives a request that selects a representation and that request includes an If-Unmodified-Since header field without an If-Match header field, the origin server MUST evaluate the If-Unmodified-Since condition per Section 13.2 prior to performing the method.
Origin Serverが表現を選択するリクエストを受信し、その要求がIFマッチヘッダーフィールドのないIF-Unmodified-Sinceヘッダーフィールドを含む場合、Origin Serverは、実行する前にセクション13.2ごとにIF-Unmodified-Since条件を評価する必要があります。方法。
To evaluate a received If-Unmodified-Since header field:
受信したIF-unmodified-Sibeヘッダーフィールドを評価するには：
1. If the selected representation's last modification date is earlier than or equal to the date provided in the field value, the condition is true.
1. 選択された表現の最後の変更日が、フィールド値で提供される日付以前と等しい場合、条件は真です。
2. Otherwise, the condition is false.
2. それ以外の場合、条件は偽です。
An origin server that evaluates an If-Unmodified-Since condition MUST NOT perform the requested method if the condition evaluates to false. Instead, the origin server MAY indicate that the conditional request failed by responding with a 412 (Precondition Failed) status code. Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected representation, the origin server MAY respond with a 2xx (Successful) status code (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or an equivalent change was made by some other user agent).
条件がfalseに評価された場合、IF-Unmodified-since条件を評価するOrigin Serverは、要求された方法を実行してはなりません。代わりに、Origin Serverは、412（前提条件に失敗した）ステータスコードで応答することで条件付き要求が失敗したことを示している場合があります。あるいは、リクエストが選択された表現にすでに適用されていると思われる状態変更操作である場合、Origin Serverは2xx（成功）ステータスコードで応答する場合があります（つまり、ユーザーエージェントが要求した変更はすでに成功しています。しかし、おそらく以前の応答が失われたか、他のユーザーエージェントによって同等の変更が行われたため、ユーザーエージェントはそれを認識していないかもしれません。
Allowing an origin server to send a success response when a change request appears to have already been applied is more efficient for many authoring use cases, but comes with some risk if multiple user agents are making change requests that are very similar but not cooperative. In those cases, an origin server is better off being stringent in sending 412 for every failed precondition on an unsafe method.
Origin Serverが変更要求が既に適用されているように見える場合に成功応答を送信できるようにすることは、多くのオーサリングユースケースでより効率的ですが、複数のユーザーエージェントが非常に類似しているが協力的ではない変更要求を行っている場合、ある程度のリスクがあります。そのような場合、Origin Serverは、安全でない方法で失敗した前提条件ごとに412を送信する方が厳しくなります。
A client MAY send an If-Unmodified-Since header field in a GET request to indicate that it would prefer a 412 (Precondition Failed) response if the selected representation has been modified. However, this is only useful in range requests (Section 14) for completing a previously received partial representation when there is no desire for a new representation. If-Range (Section 13.1.5) is better suited for range requests when the client prefers to receive a new representation.
クライアントは、選択した表現が変更されている場合、412（前提条件に失敗した）応答を好むことを示すために、IF-Unmodified-Since-Since SinceフィールドをGETリクエストで送信する場合があります。ただし、これは、新しい表現を望んでいない場合に、以前に受け取った部分表現を完了するための範囲要求（セクション14）でのみ役立ちます。if-range（セクション13.1.5）は、クライアントが新しい表現を受信することを好む場合、範囲要求に適しています。
A cache or intermediary MAY ignore If-Unmodified-Since because its interoperability features are only necessary for an origin server.
キャッシュまたは仲介者は、その相互運用性の機能がOrigin Serverにのみ必要であるため、If-Unmodified-Sinceを無視する場合があります。
The "If-Range" header field provides a special conditional request mechanism that is similar to the If-Match and If-Unmodified-Since header fields but that instructs the recipient to ignore the Range header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a 412 (Precondition Failed) response.
「if-range」ヘッダーフィールドは、if-matchおよびif-unmodified-siveヘッダーフィールドに類似した特別な条件付きリクエストメカニズムを提供しますが、それは、検証装置が一致しない場合にレンジヘッダーフィールドを無視するように受信者に指示します。412（前提条件に失敗した）応答の代わりに、新しい選択した表現の転送で。
If a client has a partial copy of a representation and wishes to have an up-to-date copy of the entire representation, it could use the Range header field with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the precondition fails because the representation has been modified, the client would then have to make a second request to obtain the entire current representation.
クライアントが表現の部分的なコピーを持っており、表現全体の最新のコピーを持ちたい場合、条件付きGETでレンジヘッダーフィールドを使用できます（if-unmodified-sinceのいずれかまたは両方を使用し、場合 - 試合。）ただし、表現が変更されたために前処理が失敗した場合、クライアントは現在の表現全体を取得するために2番目の要求を行う必要があります。
The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is as follows: if the representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation.
「if-range」ヘッダーフィールドにより、クライアントは2番目の要求を「短絡」することができます。非公式には、その意味は次のとおりです。表現が変更されていない場合は、私が範囲で要求している部分を送ってください。それ以外の場合は、表現全体を送ってください。
If-Range = entity-tag / HTTP-date
A valid entity-tag can be distinguished from a valid HTTP-date by examining the first three characters for a DQUOTE.
有効なエンティティタグは、Dquoteの最初の3文字を調べることにより、有効なHTTP-Dateと区別できます。
A client MUST NOT generate an If-Range header field in a request that does not contain a Range header field. A server MUST ignore an If-Range header field received in a request that does not contain a Range header field. An origin server MUST ignore an If-Range header field received in a request for a target resource that does not support Range requests.
クライアントは、範囲ヘッダーフィールドを含まないリクエストで、if-rangeヘッダーフィールドを生成してはなりません。サーバーは、範囲ヘッダーフィールドを含まないリクエストで受信したif-rangeヘッダーフィールドを無視する必要があります。Origin Serverは、範囲要求をサポートしていないターゲットリソースのリクエストで受信したIFレンジヘッダーフィールドを無視する必要があります。
A client MUST NOT generate an If-Range header field containing an entity tag that is marked as weak. A client MUST NOT generate an If-Range header field containing an HTTP-date unless the client has no entity tag for the corresponding representation and the date is a strong validator in the sense defined by Section 8.8.2.2.
クライアントは、弱いとマークされているエンティティタグを含むIFレンジヘッダーフィールドを生成してはなりません。クライアントは、クライアントが対応する表現のエンティティタグがなく、日付がセクション8.8.2.2で定義された意味で強力なバリデーターでない限り、HTTP-Dateを含むIFレンジヘッダーフィールドを生成してはなりません。
A server that receives an If-Range header field on a Range request MUST evaluate the condition per Section 13.2 prior to performing the method.
範囲要求でIFレンジヘッダーフィールドを受信するサーバーは、メソッドを実行する前にセクション13.2ごとに条件を評価する必要があります。
To evaluate a received If-Range header field containing an HTTP-date:
http-dateを含む受信if-rangeヘッダーフィールドを評価するには：
1. If the HTTP-date validator provided is not a strong validator in the sense defined by Section 8.8.2.2, the condition is false.
1. 提供されたHTTP-DATEバリデーターが、セクション8.8.2.2で定義されている意味で強力なバリデーターではない場合、条件は偽です。
2. If the HTTP-date validator provided exactly matches the Last-Modified field value for the selected representation, the condition is true.
2. HTTP-DATEバリーターが、選択した表現の永続修正フィールド値と正確に一致する場合、条件は真です。
3. Otherwise, the condition is false.
3. それ以外の場合、条件は偽です。
To evaluate a received If-Range header field containing an entity-tag:
エンティティタグを含む受信されたif-rangeヘッダーフィールドを評価するには：
1. If the entity-tag validator provided exactly matches the ETag field value for the selected representation using the strong comparison function (Section 8.8.3.2), the condition is true.
1. Entity-TAG Validatorが、強力な比較関数（セクション8.8.3.2）を使用して、選択した表現のETAGフィールド値と正確に一致する場合、条件は真です。
2. Otherwise, the condition is false.
2. それ以外の場合、条件は偽です。
A recipient of an If-Range header field MUST ignore the Range header field if the If-Range condition evaluates to false. Otherwise, the recipient SHOULD process the Range header field as requested.
if-rangeヘッダーフィールドの受信者は、if-range条件がfalseに評価された場合、範囲ヘッダーフィールドを無視する必要があります。それ以外の場合、受信者は要求に従って範囲ヘッダーフィールドを処理する必要があります。
Note that the If-Range comparison is by exact match, including when the validator is an HTTP-date, and so it differs from the "earlier than or equal to" comparison used when evaluating an If-Unmodified-Since conditional.
if-range比較は、有効化者がhttp-Dateである場合を含む正確な一致によるものであり、IF-unmodified-sinceを条件とするときに使用される「より早い」比較とは異なることに注意してください。
Except when excluded below, a recipient cache or origin server MUST evaluate received request preconditions after it has successfully performed its normal request checks and just before it would process the request content (if any) or perform the action associated with the request method. A server MUST ignore all received preconditions if its response to the same request without those conditions, prior to processing the request content, would have been a status code other than a 2xx (Successful) or 412 (Precondition Failed). In other words, redirects and failures that can be detected before significant processing occurs take precedence over the evaluation of preconditions.
以下を除外した場合を除き、受信者のキャッシュまたはOriginサーバーは、通常の要求チェックを正常に実行した後、および要求コンテンツを処理する直前（存在する場合）またはリクエストメソッドに関連付けられたアクションを実行する直前に受信要求の前提条件を評価する必要があります。リクエストコンテンツを処理する前に、これらの条件なしで同じ要求に対する応答が2xx（成功）または412（前提条件が失敗した）以外のステータスコードであった場合、サーバーはすべての受信前の前提条件を無視する必要があります。言い換えれば、重要な処理が行われる前に検出できるリダイレクトと障害は、前提条件の評価よりも優先されます。
A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource MUST NOT evaluate the conditional request header fields defined by this specification, and it MUST forward them if the request is forwarded, since the generating client intends that they be evaluated by a server that can provide a current representation. Likewise, a server MUST ignore the conditional request header fields defined by this specification when received with a request method that does not involve the selection or modification of a selected representation, such as CONNECT, OPTIONS, or TRACE.
ターゲットリソースのOrigin Serverではなく、ターゲットリソースの要求のキャッシュとして機能できないサーバーは、この仕様で定義された条件付きリクエストヘッダーフィールドを評価してはなりません。生成クライアントは、現在の表現を提供できるサーバーによって評価されることを意図しています。同様に、サーバーは、接続、オプション、トレースなどの選択された表現の選択または変更を伴わない要求方法で受信した場合、この仕様によって定義された条件付きリクエストヘッダーフィールドを無視する必要があります。
Note that protocol extensions can modify the conditions under which preconditions are evaluated or the consequences of their evaluation. For example, the immutable cache directive (defined by [RFC8246]) instructs caches to forgo forwarding conditional requests when they hold a fresh response.
プロトコル拡張は、前提条件が評価される条件または評価の結果を変更できることに注意してください。たとえば、不変のキャッシュ指令（[RFC8246]で定義）は、新しい応答を保持したときに条件付き要求を転送するようにキャッシュに指示します。
Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent with those of GET), there is no point in sending a conditional HEAD because a successful response is around the same size as a 304 (Not Modified) response and more useful than a 412 (Precondition Failed) response.
条件付きリクエストヘッダーフィールドは、ヘッドメソッドで使用可能であると定義されていますが（HeadのセマンティクスをGETのセマンティクスと一致させるため）、成功した応答は304とほぼ同じサイズであるため、条件付きヘッドを送信することには意味がありません（変更されていません。）応答と412（前提条件の失敗）応答よりも有用です。
When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes important. In practice, the fields defined in this document are consistently implemented in a single, logical order, since "lost update" preconditions have more strict requirements than cache validation, a validated cache is more efficient than a partial response, and entity tags are presumed to be more accurate than date validators.
要求に複数の条件付き要求ヘッダーフィールドが存在する場合、フィールドが評価される順序が重要になります。実際には、このドキュメントで定義されているフィールドは、「Lost Update」の前提条件にはキャッシュ検証よりも厳格な要件があり、検証済みのキャッシュは部分的な応答よりも効率的であり、エンティティタグは次のとおりです。日付のバリッタよりも正確になります。
A recipient cache or origin server MUST evaluate the request preconditions defined by this specification in the following order:
受信者のキャッシュまたはOrigin Serverは、次の順序でこの仕様で定義されたリクエストの前提条件を評価する必要があります。
1. When recipient is the origin server and If-Match is present, evaluate the If-Match precondition:
1. 受信者がOrigin Serverであり、IF-Matchが存在する場合、IFマッチの前提条件を評価します。
* if true, continue to step 3
* 本当なら、ステップ3に進みます
* if false, respond 412 (Precondition Failed) unless it can be determined that the state-changing request has already succeeded (see Section 13.1.1)
* falseの場合、状態を変える要求がすでに成功していると判断できない限り、412（前提条件が失敗しました）（セクション13.1.1を参照）
2. When recipient is the origin server, If-Match is not present, and If-Unmodified-Since is present, evaluate the If-Unmodified-Since precondition:
2. 受信者がOrigin Serverである場合、If-Matchが存在しない場合、If-Unmodified-Sinceが存在する場合、If-Unmodified-Sinceの前提条件を評価します。
* if true, continue to step 3
* 本当なら、ステップ3に進みます
* if false, respond 412 (Precondition Failed) unless it can be determined that the state-changing request has already succeeded (see Section 13.1.4)
* falseの場合、状態を変える要求がすでに成功していると判断できない限り、412（前提条件が失敗しました）（セクション13.1.4を参照）
3. When If-None-Match is present, evaluate the If-None-Match precondition:
3. if-none-matchが存在する場合、if-none-matchの前提条件を評価します。
* if true, continue to step 5
* 本当なら、ステップ5を続けます
* if false for GET/HEAD, respond 304 (Not Modified)
* get/headのfalseの場合、304に応答します（変更されていません）
* if false for other methods, respond 412 (Precondition Failed)
* 他の方法でfalseの場合、412に応答します（前提条件が失敗しました）
4. When the method is GET or HEAD, If-None-Match is not present, and If-Modified-Since is present, evaluate the If-Modified-Since precondition:
4. メソッドが取得またはヘッドである場合、IF-NONE-MATCHが存在しない場合、およびIF修正-Sinceが存在する場合、IFMODIFIED-SINCEの前提条件を評価します。
* if true, continue to step 5
* 本当なら、ステップ5を続けます
* if false, respond 304 (Not Modified)
* falseの場合、304に応答します（変更されていません）
5. When the method is GET and both Range and If-Range are present, evaluate the If-Range precondition:
5. メソッドが取得され、範囲とif-rangeの両方が存在する場合、if-range Preconditionを評価します。
* if true and the Range is applicable to the selected representation, respond 206 (Partial Content)
* trueと範囲が選択された表現に適用できる場合は、応答206（部分コンテンツ）
* otherwise, ignore the Range header field and respond 200 (OK)
* それ以外の場合は、レンジヘッダーフィールドを無視して200（OK）に応答します
6. Otherwise,
6. さもないと、
* perform the requested method and respond according to its success or failure.
* 要求された方法を実行し、その成功または失敗に応じて応答します。
Any extension to HTTP that defines additional conditional request header fields ought to define the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice.
追加の条件付きリクエストヘッダーフィールドを定義するHTTPへの拡張は、このドキュメントで定義されているものと実際に見られる可能性のある他の条件に関連して、そのようなフィールドを評価するための順序を定義する必要があります。
Clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. When a client has stored a partial representation, it is desirable to request the remainder of that representation in a subsequent request rather than transfer the entire representation. Likewise, devices with limited local storage might benefit from being able to request only a subset of a larger representation, such as a single page of a very large document, or the dimensions of an embedded image.
クライアントは、キャンセルされた要求または接続の削除の結果として、中断されたデータ転送に遭遇することがよくあります。クライアントが部分表現を保存した場合、表現全体を転送するのではなく、その後の要求でその表現の残りを要求することが望ましい。同様に、ローカルストレージが限られているデバイスは、非常に大きなドキュメントの単一ページや埋め込み画像の寸法など、より大きな表現のサブセットのみを要求できることから利益を得ることができます。
Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability. Partial responses are indicated by a distinct status code to not be mistaken for full responses by caches that might not implement the feature.
範囲要求は、この機能を実装していない（またはターゲットリソースのサポートではない）受信者が相互運用性に影響を与えることなく通常のGETリクエストであるかのように設計されているHTTPのオプション機能です。部分的な応答は、特徴を実装しないキャッシュによる完全な応答と間違えられないという明確なステータスコードによって示されます。
Representation data can be partitioned into subranges when there are addressable structural units inherent to that data's content coding or media type. For example, octet (a.k.a. byte) boundaries are a structural unit common to all representation data, allowing partitions of the data to be identified as a range of bytes at some offset from the start or end of that data.
表現データは、そのデータのコンテンツコーディングまたはメディアタイプに固有のアドレス指定可能な構造単位がある場合、サブレンジに分割できます。たとえば、Octet（A.K.A。BYTE）の境界は、すべての表現データに共通する構造単位であり、データのパーティションを、そのデータの開始または終了から何らかのオフセットでバイトの範囲として識別できるようにします。
This general notion of a "range unit" is used in the Accept-Ranges (Section 14.3) response header field to advertise support for range requests, the Range (Section 14.2) request header field to delineate the parts of a representation that are requested, and the Content-Range (Section 14.4) header field to describe which part of a representation is being transferred.
「レンジユニット」のこの一般的な概念は、範囲要求のサポートを宣伝するための受け入れ範囲（セクション14.3）応答ヘッダーフィールドで使用されています。コンテンツレンジ（セクション14.4）ヘッダーフィールドは、表現のどの部分が転送されているかを説明します。
range-unit = token
All range unit names are case-insensitive and ought to be registered within the "HTTP Range Unit Registry", as defined in Section 16.5.1.
すべての範囲ユニット名はケース非感受性であり、セクション16.5.1で定義されているように、「HTTPレンジユニットレジストリ」内に登録する必要があります。
Range units are intended to be extensible, as described in Section 16.5.
セクション16.5で説明されているように、レンジユニットは拡張可能であることを目的としています。
Ranges are expressed in terms of a range unit paired with a set of range specifiers. The range unit name determines what kinds of range-spec are applicable to its own specifiers. Hence, the following grammar is generic: each range unit is expected to specify requirements on when int-range, suffix-range, and other-range are allowed.
範囲は、一連の範囲仕様と組み合わせた範囲ユニットで表されます。範囲ユニット名は、独自の指定器に適用可能なレンジスペックの種類を決定します。したがって、次の文法は一般的なものです。各レンジユニットは、int-range、suffix-range、およびその他の範囲が許可される時期に関する要件を指定することが期待されます。
A range request can specify a single range or a set of ranges within a single representation.
範囲要求は、単一の表現内の単一の範囲または一連の範囲を指定できます。
ranges-specifier = range-unit "=" range-set
range-set = 1#range-spec
range-spec = int-range
/ suffix-range
/ other-range
An int-range is a range expressed as two non-negative integers or as one non-negative integer through to the end of the representation data. The range unit specifies what the integers mean (e.g., they might indicate unit offsets from the beginning, inclusive numbered parts, etc.).
Int-Rangeは、2つの非陰性整数として表される範囲、または表現データの最後まで1つの非陰性整数として表される範囲です。範囲ユニットは、整数の意味を指定します（たとえば、最初からユニットのオフセット、包括的番号付き部品などを示す場合があります）。
int-range = first-pos "-" [ last-pos ]
first-pos = 1*DIGIT
last-pos = 1*DIGIT
An int-range is invalid if the last-pos value is present and less than the first-pos.
最後のPOS値が存在し、最初のPOよりも少ない場合、int-rangeは無効です。
A suffix-range is a range expressed as a suffix of the representation data with the provided non-negative integer maximum length (in range units). In other words, the last N units of the representation data.
接尾辞範囲は、提供された非陰性整数最大長（範囲単位）を持つ表現データの接尾辞として表される範囲です。言い換えれば、表現データの最後のn単位。
suffix-range = "-" suffix-length suffix-length = 1*DIGIT
suffix-range = " - "接尾辞長suffix-length = 1*digit
To provide for extensibility, the other-range rule is a mostly unconstrained grammar that allows application-specific or future range units to define additional range specifiers.
拡張性を提供するために、他の範囲のルールは、アプリケーション固有または将来の範囲ユニットが追加の範囲仕様を定義できるようにするほとんど制約のない文法です。
other-range = 1*( %x21-2B / %x2D-7E )
; 1*(VCHAR excluding comma)
A ranges-specifier is invalid if it contains any range-spec that is invalid or undefined for the indicated range-unit.
指定された範囲ユニットに対して無効または未定義である範囲スペックが含まれている場合、範囲配分は無効です。
A valid ranges-specifier is "satisfiable" if it contains at least one range-spec that is satisfiable, as defined by the indicated range-unit. Otherwise, the ranges-specifier is "unsatisfiable".
有効な範囲配分は、示された範囲ユニットで定義されているように、少なくとも1つの範囲スペックが満たされる場合、「満足できる」ものです。それ以外の場合、範囲指定器は「不満」です。
The "bytes" range unit is used to express subranges of a representation data's octet sequence. Each byte range is expressed as an integer range at some offset, relative to either the beginning (int-range) or end (suffix-range) of the representation data. Byte ranges do not use the other-range specifier.
「バイト」範囲ユニットは、表現データのオクテットシーケンスのサブレンジを表現するために使用されます。各バイト範囲は、表現データの開始（int-range）またはend（suffix-range）のいずれかに対して、ある程度のオフセットで整数範囲として表されます。バイト範囲は、他の範囲の仕様を使用しません。
The first-pos value in a bytes int-range gives the offset of the first byte in a range. The last-pos value gives the offset of the last byte in the range; that is, the byte positions specified are inclusive. Byte offsets start at zero.
バイトint-rangeの最初のPOS値は、範囲内の最初のバイトのオフセットを与えます。最後のPOS値は、範囲内の最後のバイトのオフセットを与えます。つまり、指定されたバイト位置は包括的です。バイトオフセットはゼロから始まります。
If the representation data has a content coding applied, each byte range is calculated with respect to the encoded sequence of bytes, not the sequence of underlying bytes that would be obtained after decoding.
表現データにコンテンツコーディングが適用されている場合、各バイト範囲は、デコード後に得られる基礎となるバイトのシーケンスではなく、エンコードされたバイトシーケンスに対して計算されます。
Examples of bytes range specifiers:
バイト範囲の例の例：
* The first 500 bytes (byte offsets 0-499, inclusive):
* 最初の500バイト（バイトオフセット0-499、包括的）：
bytes=0-499
バイト= 0-499
* The second 500 bytes (byte offsets 500-999, inclusive):
* 2番目の500バイト（バイトオフセット500-999、包括的）：
bytes=500-999
バイト= 500-999
A client can limit the number of bytes requested without knowing the size of the selected representation. If the last-pos value is absent, or if the value is greater than or equal to the current length of the representation data, the byte range is interpreted as the remainder of the representation (i.e., the server replaces the value of last-pos with a value that is one less than the current length of the selected representation).
クライアントは、選択した表現のサイズを知らずに要求されたバイト数を制限できます。最後のPOS値がない場合、または値が表現データの現在の長さ以上の場合、バイト範囲は表現の残りの部分として解釈されます（つまり、サーバーはLast-Posの値を置き換えます。選択された表現の現在の長さよりも1つ少ない値があります）。
A client can refer to the last N bytes (N > 0) of the selected representation using a suffix-range. If the selected representation is shorter than the specified suffix-length, the entire representation is used.
クライアントは、接尾辞範囲を使用して、選択した表現の最後のnバイト（n> 0）を参照できます。選択した表現が指定された接尾辞長よりも短い場合、表現全体が使用されます。
Additional examples, assuming a representation of length 10000:
長さ10000の表現を仮定して、追加の例：
* The final 500 bytes (byte offsets 9500-9999, inclusive):
* 最後の500バイト（バイトオフセット9500-9999、包括的）：
bytes=-500
バイト= -500
Or:
または：
bytes=9500-
バイト= 9500-
* The first and last bytes only (bytes 0 and 9999):
* 最初と最後のバイトのみ（バイト0および9999）：
bytes=0-0,-1
バイト= 0-0、-1
* The first, middle, and last 1000 bytes:
* 最初、中央、最後の1000バイト：
bytes= 0-999, 4500-5499, -1000
バイト= 0-999、4500-5499、-1000
* Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):
* 2番目の500バイトのその他の有効な（標準的ではない）仕様（バイトオフセット500-999、包括的）：
bytes=500-600,601-999 bytes=500-700,601-999
バイト= 500-600,601-999バイト= 500-700,601-999
For a GET request, a valid bytes range-spec is satisfiable if it is either:
GETリクエストの場合、有効なバイト範囲スペックは次の場合に満足します。
* an int-range with a first-pos that is less than the current length of the selected representation or
* 選択した表現の現在の長さよりも少ない最初のPOSを持つINT-RANGEまたは
* a suffix-range with a non-zero suffix-length.
* ゼロ以外の接尾辞長を備えた接尾辞範囲。
When a selected representation has zero length, the only satisfiable form of range-spec in a GET request is a suffix-range with a non-zero suffix-length.
選択した表現の長さがゼロの場合、GETリクエストの範囲スペックの唯一の満足できる形式は、ゼロ以外の接尾辞長を備えた接尾辞範囲です。
In the byte-range syntax, first-pos, last-pos, and suffix-length are expressed as decimal number of octets. Since there is no predefined limit to the length of content, recipients MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.
バイト範囲の構文では、最初のPO、ラストPO、および接尾辞の長さは、10進数のオクテット数として表されます。コンテンツの長さに定義された制限がないため、受信者は潜在的に大きな小数数を予測し、整数変換のオーバーフローによる解析エラーを防ぐ必要があります。
The "Range" header field on a GET request modifies the method semantics to request transfer of only one or more subranges of the selected representation data (Section 8.1), rather than the entire selected representation.
GETリクエストの「範囲」ヘッダーフィールドは、選択した表現全体ではなく、選択した表現データの1つまたは複数のサブレンジのみのみの転送のみを要求するメソッドセマンティクスを変更します。
Range = ranges-specifier
A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since they support efficient recovery from partially failed transfers and partial retrieval of large representations.
サーバーは、レンジヘッダーフィールドを無視する場合があります。ただし、オリジンサーバーと中間キャッシュは、部分的に失敗した転送と大きな表現の部分的な検索からの効率的な回復をサポートするため、可能な場合はバイト範囲をサポートする必要があります。
A server MUST ignore a Range header field received with a request method that is unrecognized or for which range handling is not defined. For this specification, GET is the only method for which range handling is defined.
サーバーは、認識されていない、または範囲の取り扱いが定義されていない要求方法で受信した範囲ヘッダーフィールドを無視する必要があります。この仕様では、GETは範囲の取り扱いが定義される唯一の方法です。
An origin server MUST ignore a Range header field that contains a range unit it does not understand. A proxy MAY discard a Range header field that contains a range unit it does not understand.
Origin Serverは、理解できないレンジユニットを含む範囲ヘッダーフィールドを無視する必要があります。プロキシは、理解できないレンジユニットを含むレンジヘッダーフィールドを破棄する場合があります。
A server that supports range requests MAY ignore or reject a Range header field that contains an invalid ranges-specifier (Section 14.1.1), a ranges-specifier with more than two overlapping ranges, or a set of many small ranges that are not listed in ascending order, since these are indications of either a broken client or a deliberate denial-of-service attack (Section 17.15). A client SHOULD NOT request multiple ranges that are inherently less efficient to process and transfer than a single range that encompasses the same data.
範囲要求をサポートするサーバーは、無効な範囲指定機（セクション14.1.1）を含む範囲ヘッダーフィールド、2つ以上の重複する範囲を持つ範囲配置器、またはリストされていない多くの小さな範囲を含む範囲ヘッダーフィールドを無視または拒否する場合があります。昇順では、これらは壊れたクライアントまたは意図的なサービス拒否攻撃のいずれかの兆候であるためです（セクション17.15）。クライアントは、同じデータを含む単一の範囲よりも、プロセスと転送の効率が本質的に低い複数の範囲を要求してはなりません。
A server that supports range requests MAY ignore a Range header field when the selected representation has no content (i.e., the selected representation's data is of zero length).
範囲要求をサポートするサーバーは、選択した表現にコンテンツがない場合に範囲ヘッダーフィールドを無視する場合があります（つまり、選択した表現のデータはゼロの長さです）。
A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier. For example, a user agent processing a large representation with an internal catalog of parts might need to request later parts first, particularly if the representation consists of pages stored in reverse order and the user agent wishes to transfer one page at a time.
複数の範囲を要求しているクライアントは、それらの範囲を昇順でリスト（通常、完全な表現で受信する順序）をリストする必要があります。たとえば、パーツの内部カタログを使用して大規模な表現を処理するユーザーエージェントは、特に表現が逆順序で保存されているページで構成されており、ユーザーエージェントが一度に1ページを転送したい場合、最初に後のパーツを要求する必要がある場合があります。
The Range header field is evaluated after evaluating the precondition header fields defined in Section 13.1, and only if the result in absence of the Range header field would be a 200 (OK) response. In other words, Range is ignored when a conditional GET would result in a 304 (Not Modified) response.
範囲ヘッダーフィールドは、セクション13.1で定義されている前処理ヘッダーフィールドを評価した後に評価され、範囲ヘッダーフィールドの非存在下での結果が200（OK）応答になる場合のみです。言い換えれば、条件付きGETが304（変更されていない）応答が発生すると、範囲は無視されます。
The If-Range header field (Section 13.1.5) can be used as a precondition to applying the Range header field.
if-rangeヘッダーフィールド（セクション13.1.5）は、範囲ヘッダーフィールドの適用の前提条件として使用できます。
If all of the preconditions are true, the server supports the Range header field for the target resource, the received Range field-value contains a valid ranges-specifier with a range-unit supported for that target resource, and that ranges-specifier is satisfiable with respect to the selected representation, the server SHOULD send a 206 (Partial Content) response with content containing one or more partial representations that correspond to the satisfiable range-spec(s) requested.
すべての前提条件が真である場合、サーバーはターゲットリソースの範囲ヘッダーフィールドをサポートし、受信した範囲フィールド値には、そのターゲットリソースにサポートされている範囲ユニットを備えた有効な範囲配分が含まれ、その範囲の範囲は満足できます選択した表現に関して、サーバーは、要求された満足できる範囲スペックに対応する1つ以上の部分表現を含むコンテンツを含む206（部分コンテンツ）応答を送信する必要があります。
The above does not imply that a server will send all requested ranges. In some cases, it may only be possible (or efficient) to send a portion of the requested ranges first, while expecting the client to re-request the remaining portions later if they are still desired (see Section 15.3.7).
上記は、サーバーがすべての要求された範囲を送信することを意味するものではありません。場合によっては、要求された範囲の一部を最初に送信することが可能（または効率的）である可能性がありますが、クライアントがまだ望まれている場合は、残りの部分を後で再追跡することを期待します（セクション15.3.7を参照）。
If all of the preconditions are true, the server supports the Range header field for the target resource, the received Range field-value contains a valid ranges-specifier, and either the range-unit is not supported for that target resource or the ranges-specifier is unsatisfiable with respect to the selected representation, the server SHOULD send a 416 (Range Not Satisfiable) response.
すべての前提条件が真である場合、サーバーはターゲットリソースの範囲ヘッダーフィールドをサポートし、受信した範囲フィールド値には有効な範囲スペシファーが含まれ、範囲ユニットはそのターゲットリソースまたは範囲に対してサポートされていません。特定の表現に関して、仕様は不満であるため、サーバーは416（満足できない範囲）応答を送信する必要があります。
The "Accept-Ranges" field in a response indicates whether an upstream server supports range requests for the target resource.
応答の「受け入れ範囲」フィールドは、上流のサーバーがターゲットリソースの範囲要求をサポートするかどうかを示します。
Accept-Ranges = acceptable-ranges acceptable-ranges = 1#range-unit
Accept-ranges =受け入れ可能な範囲許容範囲= 1＃range-unit
For example, a server that supports byte-range requests (Section 14.1.2) can send the field
たとえば、バイトレンジ要求をサポートするサーバー（セクション14.1.2）はフィールドを送信できます
Accept-Ranges: bytes
Accept-ranges：バイト
to indicate that it supports byte range requests for that target resource, thereby encouraging its use by the client for future partial requests on the same request path. Range units are defined in Section 14.1.
そのターゲットリソースのバイト範囲要求をサポートしていることを示すため、同じ要求パスでの将来の部分リクエストに対するクライアントによる使用を促進します。範囲ユニットは、セクション14.1で定義されています。
A client MAY generate range requests regardless of having received an Accept-Ranges field. The information only provides advice for the sake of improving performance and reducing unnecessary network transfers.
クライアントは、受け入れ範囲のフィールドを受け取っていても、範囲要求を生成する場合があります。この情報は、パフォーマンスを改善し、不必要なネットワーク転送を減らすためのアドバイスのみを提供します。
Conversely, a client MUST NOT assume that receiving an Accept-Ranges field means that future range requests will return partial responses. The content might change, the server might only support range requests at certain times or under certain conditions, or a different intermediary might process the next request.
逆に、クライアントは、受け入れレンジフィールドを受信することは、将来の範囲要求が部分的な応答を返すことを意味すると仮定してはなりません。コンテンツが変更される可能性があります。サーバーは、特定の時間または特定の条件下でのみ範囲要求をサポートするか、別の仲介者が次のリクエストを処理する場合があります。
A server that does not support any kind of range request for the target resource MAY send
ターゲットリソースのいかなる種類の範囲要求をサポートしていないサーバーが送信される場合があります
Accept-Ranges: none
Accept-Ranges：なし
to advise the client not to attempt a range request on the same request path. The range unit "none" is reserved for this purpose.
同じ要求パスで範囲要求を試みないようクライアントに助言する。レンジユニット「なし」は、この目的のために予約されています。
The Accept-Ranges field MAY be sent in a trailer section, but is preferred to be sent as a header field because the information is particularly useful for restarting large information transfers that have failed in mid-content (before the trailer section is received).
受け入れレンジフィールドはトレーラーセクションで送信される場合がありますが、情報は中間コンテンツで失敗した大きな情報転送を再起動するのに特に役立つため、ヘッダーフィールドとして送信することをお勧めします（トレーラーセクションを受信する前）。
The "Content-Range" header field is sent in a single part 206 (Partial Content) response to indicate the partial range of the selected representation enclosed as the message content, sent in each part of a multipart 206 response to indicate the range enclosed within each body part (Section 14.6), and sent in 416 (Range Not Satisfiable) responses to provide information about the selected representation.
「コンテンツ範囲」ヘッダーフィールドは、単一のパート206（部分コンテンツ）応答で送信され、メッセージコンテンツとして囲まれた選択した表現の部分範囲を示すために、マルチパート206応答の各部分で送信され、内部に囲まれている範囲を示すために送信されます。各身体部分（セクション14.6）、および選択された表現に関する情報を提供するために、416（満足できない範囲ではない）応答で送信されます。
Content-Range = range-unit SP ( range-resp / unsatisfied-range )
Content-Range = Range-UnitSP（Range-Resp /不満の範囲）
range-resp = incl-range "/" ( complete-length / "*" )
incl-range = first-pos "-" last-pos
unsatisfied-range = "*/" complete-length
complete-length = 1*DIGIT
If a 206 (Partial Content) response contains a Content-Range header field with a range unit (Section 14.1) that the recipient does not understand, the recipient MUST NOT attempt to recombine it with a stored representation. A proxy that receives such a message SHOULD forward it downstream.
206（部分コンテンツ）応答に、受信者が理解していないレンジユニット（セクション14.1）を持つコンテンツレンジヘッダーフィールドが含まれている場合、受信者は保存された表現でそれを再結合しようとしてはなりません。そのようなメッセージを受信するプロキシは、それを下流に転送する必要があります。
Content-Range might also be sent as a request modifier to request a partial PUT, as described in Section 14.5, based on private agreements between client and origin server. A server MUST ignore a Content-Range header field received in a request with a method for which Content-Range support is not defined.
また、クライアントサーバーとOrigin Serverの間のプライベート契約に基づいて、セクション14.5で説明されているように、コンテンツレンジは、部分的なプットを要求するリクエスト修飾子として送信される場合があります。サーバーは、コンテンツレンジサポートが定義されていない方法を使用して、リクエストで受信したコンテンツレンジヘッダーフィールドを無視する必要があります。
For byte ranges, a sender SHOULD indicate the complete length of the representation from which the range has been extracted, unless the complete length is unknown or difficult to determine. An asterisk character ("*") in place of the complete-length indicates that the representation length was unknown when the header field was generated.
バイト範囲の場合、送信者は、完全な長さが不明または決定が困難でない限り、範囲が抽出された表現の完全な長さを示す必要があります。完全長の代わりにアスタリスク文字（ "*"）は、ヘッダーフィールドが生成されたときに表現長が不明であることを示します。
The following example illustrates when the complete length of the selected representation is known by the sender to be 1234 bytes:
次の例は、選択した表現の完全な長さが、送信者が1234バイトであることがわかっていることを示しています。
Content-Range: bytes 42-1233/1234
コンテンツレンジ：バイト42-1233/1234
and this second example illustrates when the complete length is unknown:
そして、この2番目の例は、完全な長さが不明なときを示しています。
Content-Range: bytes 42-1233/*
A Content-Range field value is invalid if it contains a range-resp that has a last-pos value less than its first-pos value, or a complete-length value less than or equal to its last-pos value. The recipient of an invalid Content-Range MUST NOT attempt to recombine the received content with a stored representation.
コンテンツレンジのフィールド値は、First-POS値よりも少ないLast-POS値を持つ範囲Resp、またはLast-Pos値以下の完全な長さの値を含む場合、無効です。無効なコンテンツレンジの受信者は、保存された表現で受信したコンテンツを再結合しようとしてはなりません。
A server generating a 416 (Range Not Satisfiable) response to a byte-range request SHOULD send a Content-Range header field with an unsatisfied-range value, as in the following example:
次の例のように、バイトレンジ要求に対する416（満足できない範囲ではない）応答を生成するサーバーは、不満の値でコンテンツレンジヘッダーフィールドを送信する必要があります。
Content-Range: bytes */1234
The complete-length in a 416 response indicates the current length of the selected representation.
416応答の完全な長さは、選択した表現の現在の長さを示します。
The Content-Range header field has no meaning for status codes that do not explicitly describe its semantic. For this specification, only the 206 (Partial Content) and 416 (Range Not Satisfiable) status codes describe a meaning for Content-Range.
コンテンツレンジヘッダーフィールドには、セマンティックを明示的に説明していないステータスコードの意味はありません。この仕様では、206（部分コンテンツ）と416（範囲ではない範囲）ステータスコードのみが、コンテンツレンジの意味を説明しています。
The following are examples of Content-Range values in which the selected representation contains a total of 1234 bytes:
以下は、選択された表現に合計1234バイトが含まれるコンテンツレンジ値の例です。
* The first 500 bytes:
* 最初の500バイト：
Content-Range: bytes 0-499/1234
コンテンツレンジ：バイト0-499/1234
* The second 500 bytes:
* 2番目の500バイト：
Content-Range: bytes 500-999/1234
コンテンツレンジ：バイト500-999/1234
* All except for the first 500 bytes:
* 最初の500バイトを除くすべて：
Content-Range: bytes 500-1233/1234
コンテンツレンジ：バイト500-1233/1234
* The last 500 bytes:
* 最後の500バイト：
Content-Range: bytes 734-1233/1234
コンテンツレンジ：バイト734-1233/1234
Some origin servers support PUT of a partial representation when the user agent sends a Content-Range header field (Section 14.4) in the request, though such support is inconsistent and depends on private agreements with user agents. In general, it requests that the state of the target resource be partly replaced with the enclosed content at an offset and length indicated by the Content-Range value, where the offset is relative to the current selected representation.
一部のオリジンサーバーは、ユーザーエージェントがリクエストでコンテンツレンジヘッダーフィールド（セクション14.4）を送信するときに部分的な表現をサポートしますが、そのようなサポートは一貫性がなく、ユーザーエージェントとの民間契約に依存します。一般に、ターゲットリソースの状態は、オフセットが現在の選択された表現に関連しているコンテンツ範囲値で示されるオフセットと長さで囲まれたコンテンツに部分的に置き換えることを要求します。
An origin server SHOULD respond with a 400 (Bad Request) status code if it receives Content-Range on a PUT for a target resource that does not support partial PUT requests.
Origin Serverは、部分的なPUTリクエストをサポートしていないターゲットリソースのPUTでコンテンツ範囲を受信した場合、400（悪い要求）ステータスコードで応答する必要があります。
Partial PUT is not backwards compatible with the original definition of PUT. It may result in the content being written as a complete replacement for the current representation.
部分的なプットは、Putの元の定義と後方互換性がありません。その結果、コンテンツは現在の表現の完全な代替として記述される可能性があります。
Partial resource updates are also possible by targeting a separately identified resource with state that overlaps or extends a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for example, the PATCH method defined in [RFC5789]).
部分的なリソースの更新は、より大きなリソースの一部を重複または拡張する状態と個別に識別されたリソースをターゲットにするか、部分的な更新用に特異的に定義されている別の方法を使用して可能です（たとえば、[RFC5789で定義されたパッチ方法。]）。
When a 206 (Partial Content) response message includes the content of multiple ranges, they are transmitted as body parts in a multipart message body ([RFC2046], Section 5.1) with the media type of "multipart/byteranges".
206（部分コンテンツ）応答メッセージに複数の範囲のコンテンツが含まれる場合、それらはマルチパートメッセージ本文（[RFC2046]、セクション5.1）のボディ部分として、「マルチパート/バイテージ」のメディアタイプで送信されます。
The "multipart/byteranges" media type includes one or more body parts, each with its own Content-Type and Content-Range fields. The required boundary parameter specifies the boundary string used to separate each body part.
「MultiPart/Byteranges」メディアタイプには、それぞれが独自のコンテンツタイプとコンテンツレンジフィールドを備えた1つ以上のボディパーツが含まれています。必要な境界パラメーターは、各体の部分を分離するために使用される境界文字列を指定します。
Implementation Notes:
実装メモ：
1. Additional CRLFs might precede the first boundary string in the body.
1. 追加のCRLFは、ボディの最初の境界文字列に先行する可能性があります。
2. Although [RFC2046] permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.
2. [RFC2046]は境界文字列を引用することを許可していますが、一部の既存の実装は、引用された境界文字列を誤って処理します。
3. A number of clients and servers were coded to an early draft of the byteranges specification that used a media type of "multipart/x-byteranges", which is almost (but not quite) compatible with this type.
3. 多くのクライアントとサーバーは、このタイプとほぼ互換性があるメディアタイプの「マルチパート/Xバイタレンジ」を使用するByteranges仕様の初期ドラフトにコード化されました。
Despite the name, the "multipart/byteranges" media type is not limited to byte ranges. The following example uses an "exampleunit" range unit:
名前にもかかわらず、「MultiPart/Byteranges」メディアタイプは、バイト範囲に限定されません。次の例では、「ExampleUnit」範囲ユニットを使用します。
HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 2331785
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type: video/example
Content-Range: exampleunit 1.2-4.3/25
...the first range...
--THIS_STRING_SEPARATES
Content-Type: video/example
Content-Range: exampleunit 11.2-14.3/25
...the second range --THIS_STRING_SEPARATES--
... 2番目の範囲-this_string_separates--
The following information serves as the registration form for the "multipart/byteranges" media type.
次の情報は、「MultiPart/Byteranges」メディアタイプの登録フォームとして機能します。
Type name: multipart
タイプ名：MultiPart
Subtype name: byteranges
サブタイプ名：Byteranges
Required parameters: boundary
必要なパラメーター：境界
Optional parameters: N/A
オプションのパラメーター：n/a
Encoding considerations: only "7bit", "8bit", or "binary" are permitted
考慮事項のエンコード：「7ビット」、「8ビット」、または「バイナリ」のみが許可されています
Security considerations: see Section 17
セキュリティ上の考慮事項：セクション17を参照してください
Interoperability considerations: N/A
相互運用性の考慮事項：n/a
Published specification: RFC 9110 (see Section 14.6)
公開された仕様：RFC 9110（セクション14.6を参照）
Applications that use this media type: HTTP components supporting multiple ranges in a single request
このメディアタイプを使用するアプリケーション：単一のリクエストで複数の範囲をサポートするHTTPコンポーネント
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：n/a
Additional information: Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Aut hors' Addresses section.
詳細については、個人とメールアドレスをお問い合わせください：Aut Horsのアドレスセクションを参照してください。
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: N/A
使用に関する制限：n/a
Author: See Authors' Addresses section.
著者：著者のアドレスセクションを参照してください。
Change controller: IESG
Change Controller：IESG
The status code of a response is a three-digit integer code that describes the result of the request and the semantics of the response, including whether the request was successful and what content is enclosed (if any). All valid status codes are within the range of 100 to 599, inclusive.
応答のステータスコードは、リクエストの結果と応答のセマンティクスを説明する3桁の整数コードです。これには、リクエストが成功したかどうか、どのコンテンツが囲まれているか（もしあれば）が含まれます。すべての有効なステータスコードは、包括的100〜599の範囲内です。
The first digit of the status code defines the class of response. The last two digits do not have any categorization role. There are five values for the first digit:
ステータスコードの最初の数字は、応答のクラスを定義します。最後の2桁には分類の役割がありません。最初の数字には5つの値があります。
* 1xx (Informational): The request was received, continuing process
* 1XX（情報）：リクエストが受信され、継続的なプロセス
* 2xx (Successful): The request was successfully received, understood, and accepted
* 2xx（成功）：リクエストは正常に受信、理解、受け入れられました
* 3xx (Redirection): Further action needs to be taken in order to complete the request
* 3XX（リダイレクト）：リクエストを完了するには、さらなるアクションを実行する必要があります
* 4xx (Client Error): The request contains bad syntax or cannot be fulfilled
* 4XX（クライアントエラー）：リクエストには悪い構文が含まれているか、履行できません
* 5xx (Server Error): The server failed to fulfill an apparently valid request
* 5XX（サーバーエラー）：サーバーは明らかに有効なリクエストを満たすことができませんでした
HTTP status codes are extensible. A client is not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class.
HTTPステータスコードは拡張可能です。クライアントは、登録されたすべてのステータスコードの意味を理解する必要はありませんが、そのような理解は明らかに望ましいものです。ただし、最初の数字で示されるように、クライアントはステータスコードのクラスを理解し、認識されていないステータスコードをそのクラスのX00ステータスコードに相当するものとして扱う必要があります。
For example, if a client receives an unrecognized status code of 471, it can see from the first digit that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) status code. The response message will usually contain a representation that explains the status.
たとえば、クライアントが471の認識されていないステータスコードを受信した場合、最初の数字から、要求に何か問題があることがわかり、400（悪い要求）ステータスコードを受け取ったかのように応答を扱うことができます。応答メッセージには、通常、ステータスを説明する表現が含まれます。
Values outside the range 100..599 are invalid. Implementations often use three-digit integer values outside of that range (i.e., 600..999) for internal communication of non-HTTP status (e.g., library errors). A client that receives a response with an invalid status code SHOULD process the response as if it had a 5xx (Server Error) status code.
範囲100..599以外の値は無効です。実装は、非HTTPステータス（ライブラリエラーなど）の内部通信のために、その範囲外（つまり、600..999）の外側の3桁の整数値を使用することがよくあります。無効なステータスコードで応答を受信するクライアントは、5xx（サーバーエラー）ステータスコードがあるかのように応答を処理する必要があります。
A single request can have multiple associated responses: zero or more "interim" (non-final) responses with status codes in the "informational" (1xx) range, followed by exactly one "final" response with a status code in one of the other ranges.
単一のリクエストには、「情報」（1xx）範囲のステータスコードを使用したゼロ以上の「暫定」（非ファイナル）応答の複数の関連する応答を持つことができ、その後に1つのステータスコードを使用した1つの「最終」応答が続きます。他の範囲。
The status codes listed below are defined in this specification. The reason phrases listed here are only recommendations -- they can be replaced by local equivalents or left out altogether without affecting the protocol.
以下にリストされているステータスコードは、この仕様で定義されています。ここにリストされている理由は、推奨事項のみです。これらは、ローカル同等物に置き換えられたり、プロトコルに影響を与えることなく完全に除外したりすることができます。
Responses with status codes that are defined as heuristically cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls [CACHING]; all other status codes are not heuristically cacheable.
ヒューリスティックなキャッシュ可能であると定義されるステータスコードを使用した応答（例：200、203、204、206、300、301、308、404、405、410、414、および501）は、Heuristic Expationでキャッシュによって再利用できます。メソッド定義または明示的なキャッシュコントロール[キャッシュ]で特に示されない限り。他のすべてのステータスコードは、ヒューリスティックにキャッシュ可能ではありません。
Additional status codes, outside the scope of this specification, have been specified for use in HTTP. All such status codes ought to be registered within the "Hypertext Transfer Protocol (HTTP) Status Code Registry", as described in Section 16.2.
この仕様の範囲外の追加ステータスコードは、HTTPで使用するために指定されています。このようなステータスコードはすべて、セクション16.2で説明されているように、「ハイパーテキスト転送プロトコル（HTTP）ステータスコードレジストリ」に登録する必要があります。
The 1xx (Informational) class of status code indicates an interim response for communicating connection status or request progress prior to completing the requested action and sending a final response. Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client.
1XX（情報）クラスのステータスコードは、要求されたアクションを完了して最終的な応答を送信する前に、接続ステータスまたは要求の進捗を通知するための暫定的な応答を示します。HTTP/1.0は1xxステータスコードを定義していないため、サーバーはHTTP/1.0クライアントに1xx応答を送信してはなりません。
A 1xx response is terminated by the end of the header section; it cannot contain content or trailers.
1xx応答は、ヘッダーセクションの終わりによって終了します。コンテンツやトレーラーを含めることはできません。
A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent MAY ignore unexpected 1xx responses.
クライアントは、クライアントがそれを期待していなくても、最終的な応答の前に受け取った1つ以上の1XX応答を解析できる必要があります。ユーザーエージェントは、予期しない1XX応答を無視する場合があります。
A proxy MUST forward 1xx responses unless the proxy itself requested the generation of the 1xx response. For example, if a proxy adds an "Expect: 100-continue" header field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).
プロキシ自体が1XX応答の生成を要求しない限り、プロキシは1XX応答を転送する必要があります。たとえば、プロキシがリクエストを転送するときに「予想：100コントン」ヘッダーフィールドを追加する場合、対応する100（継続）応答を転送する必要はありません。
The 100 (Continue) status code indicates that the initial part of a request has been received and has not yet been rejected by the server. The server intends to send a final response after the request has been fully received and acted upon.
100（継続）ステータスコードは、リクエストの最初の部分が受信されており、サーバーによってまだ拒否されていないことを示しています。サーバーは、リクエストが完全に受信され、行動した後に最終的な応答を送信する予定です。
When the request contains an Expect header field that includes a 100-continue expectation, the 100 response indicates that the server wishes to receive the request content, as described in Section 10.1.1. The client ought to continue sending the request and discard the 100 response.
リクエストに100を融合した期待値を含む期待ヘッダーフィールドが含まれている場合、セクション10.1.1で説明されているように、100回の応答は、サーバーがリクエストコンテンツを受信したいことを示します。クライアントは、リクエストの送信を続け、100の応答を破棄する必要があります。
If the request did not contain an Expect header field containing the 100-continue expectation, the client can simply discard this interim response.
リクエストに100を含む予想を含む期待ヘッダーフィールドが含まれていない場合、クライアントはこの暫定的な応答を単純に破棄できます。
The 101 (Switching Protocols) status code indicates that the server understands and is willing to comply with the client's request, via the Upgrade header field (Section 7.8), for a change in the application protocol being used on this connection. The server MUST generate an Upgrade header field in the response that indicates which protocol(s) will be in effect after this response.
101（スイッチングプロトコル）ステータスコードは、この接続で使用されているアプリケーションプロトコルの変更について、アップグレードヘッダーフィールド（セクション7.8）を介して、サーバーがクライアントの要求を理解し、喜んで遵守することを示しています。サーバーは、この応答後に有効になるプロトコルを示す応答でアップグレードヘッダーフィールドを生成する必要があります。
It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching to a newer version of HTTP might be advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.
サーバーは、それを行うことが有利な場合にのみ、プロトコルを切り替えることに同意すると想定されています。たとえば、HTTPの新しいバージョンに切り替えることは、古いバージョンよりも有利になる可能性があり、リアルタイムに切り替えることは、そのような機能を使用するリソースを配信する場合に有利になる可能性があります。
The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.
2XX（成功）クラスのステータスコードは、クライアントの要求が正常に受信、理解、受け入れられたことを示しています。
The 200 (OK) status code indicates that the request has succeeded. The content sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the content can be summarized as:
200（OK）ステータスコードは、リクエストが成功したことを示しています。200の応答で送信されたコンテンツは、リクエストメソッドによって異なります。この仕様で定義された方法については、コンテンツの意図された意味を次のように要約できます。
+================+============================================+
| Request Method | Response content is a representation of: |
+================+============================================+
| GET | the target resource |
+----------------+--------------------------------------------+
| HEAD | the target resource, like GET, but without |
| | transferring the representation data |
+----------------+--------------------------------------------+
| POST | the status of, or results obtained from, |
| | the action |
+----------------+--------------------------------------------+
| PUT, DELETE | the status of the action |
+----------------+--------------------------------------------+
| OPTIONS | communication options for the target |
| | resource |
+----------------+--------------------------------------------+
| TRACE | the request message as received by the |
| | server returning the trace |
+----------------+--------------------------------------------+
Table 6
表6
Aside from responses to CONNECT, a 200 response is expected to contain message content unless the message framing explicitly indicates that the content has zero length. If some aspect of the request indicates a preference for no content upon success, the origin server ought to send a 204 (No Content) response instead. For CONNECT, there is no content because the successful result is a tunnel, which begins immediately after the 200 response header section.
Connectへの応答とは別に、メッセージのフレーミングがコンテンツの長さがゼロであることを明示的に示す場合を除き、200の応答にメッセージコンテンツが含まれると予想されます。リクエストのある側面が、成功時にコンテンツがないことの好みを示している場合、Origin Serverは代わりに204（コンテンツなし）応答を送信する必要があります。Connectの場合、成功した結果はトンネルであるため、コンテンツはありません。トンネルは200回の応答ヘッダーセクションの直後に始まります。
A 200 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
200の応答はヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
In 200 responses to GET or HEAD, an origin server SHOULD send any available validator fields (Section 8.8) for the selected representation, with both a strong entity tag and a Last-Modified date being preferred.
GetまたはHeadに対する200の応答では、Origin Serverは、選択した表現に対して利用可能なVALIBATORフィールド（セクション8.8）を送信する必要があります。
In 200 responses to state-changing methods, any validator fields (Section 8.8) sent in the response convey the current validators for the new representation formed as a result of successfully applying the request semantics. Note that the PUT method (Section 9.3.4) has additional requirements that might preclude sending such validators.
状態変更方法に対する200の応答では、応答で送信されたバリデーターフィールド（セクション8.8）は、リクエストセマンティクスを正常に適用した結果として形成された新しい表現の現在のバリデーターを伝えます。PUTメソッド（セクション9.3.4）には、そのようなバリデーターの送信を妨げる可能性のある追加要件があることに注意してください。
The 201 (Created) status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The primary resource created by the request is identified by either a Location header field in the response or, if no Location header field is received, by the target URI.
201（作成）ステータスコードは、リクエストが満たされており、1つ以上の新しいリソースが作成されたことを示しています。リクエストによって作成された主要なリソースは、応答の位置ヘッダーフィールド、またはロケーションヘッダーフィールドがない場合は、ターゲットURIによって識別されます。
The 201 response content typically describes and links to the resource(s) created. Any validator fields (Section 8.8) sent in the response convey the current validators for a new representation created by the request. Note that the PUT method (Section 9.3.4) has additional requirements that might preclude sending such validators.
通常、201の応答コンテンツは、作成されたリソースを説明し、リンクします。応答で送信されたバリデーターフィールド（セクション8.8）は、リクエストによって作成された新しい表現のために現在のバリデーターを伝えます。PUTメソッド（セクション9.3.4）には、そのようなバリデーターの送信を妨げる可能性のある追加要件があることに注意してください。
The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation.
202（受け入れられた）ステータスコードは、リクエストが処理に受け入れられたことを示していますが、処理は完了していません。リクエストは、実際に処理が行われたときに許可される可能性があるため、最終的に行動する場合があります。HTTPには、非同期操作からステータスコードを再配置する施設はありません。
The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.
202の応答は、意図的に非コミットルです。その目的は、ユーザーエージェントのサーバーへの接続がプロセスが完了するまで持続することを要求することなく、サーバーが他のプロセス（おそらく1日1回だけ実行されるバッチ指向プロセス）のリクエストを受け入れることを許可することです。この応答で送信された表現は、リクエストの現在のステータスを記述し、リクエストがいつ満たされるかの見積もりをユーザーに提供できるステータスモニターを指す（または埋め込む）必要があります。
The 203 (Non-Authoritative Information) status code indicates that the request was successful but the enclosed content has been modified from that of the origin server's 200 (OK) response by a transforming proxy (Section 7.7). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might impact later decisions regarding the content. For example, future cache validation requests for the content might only be applicable along the same request path (through the same proxies).
203（非承認情報）ステータスコードは、要求が成功したことを示していますが、囲まれたコンテンツは、変換プロキシ（セクション7.7）によってOrigin Serverの200（OK）応答のコンテンツから変更されています。このステータスコードにより、変換が適用されたときにプロキシが受信者に通知することができます。その知識は、コンテンツに関する後の決定に影響を与える可能性があるためです。たとえば、コンテンツの将来のキャッシュ検証要求は、同じリクエストパスに沿って（同じプロキシを介して）適用できる場合があります。
A 203 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
203の応答はヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response content. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.
204（コンテンツなし）ステータスコードは、サーバーがリクエストを正常に満たしたこと、および応答コンテンツを送信する追加のコンテンツがないことを示しています。応答ヘッダーフィールドのメタデータは、要求されたアクションが適用された後のターゲットリソースと選択した表現を指します。
For example, if a 204 status code is received in response to a PUT request and the response contains an ETag field, then the PUT was successful and the ETag field value contains the entity tag for the new representation of that target resource.
たとえば、204ステータスコードがPUTリクエストに応じて受信され、応答にETAGフィールドが含まれている場合、Putは成功し、ETAGフィールド値にはそのターゲットリソースの新しい表現のエンティティタグが含まれています。
The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.
204の応答により、サーバーはアクションがターゲットリソースに正常に適用されていることを示すことができますが、ユーザーエージェントは現在の「ドキュメントビュー」（存在する場合）から遠ざける必要がないことを意味します。サーバーは、ユーザーエージェントが独自のインターフェイスに従って、ユーザーに成功の兆候を提供し、アクティブな表現に対する応答に新しいまたは更新されたメタデータを適用すると想定しています。
For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.
たとえば、204のステータスコードは、「保存」アクションに対応するドキュメント編集インターフェイスで一般的に使用されます。また、分散バージョン制御システム内など、自動化されたデータ転送が一般的であると予想されるインターフェイスで頻繁に使用されます。
A 204 response is terminated by the end of the header section; it cannot contain content or trailers.
204の応答は、ヘッダーセクションの終わりによって終了します。コンテンツやトレーラーを含めることはできません。
A 204 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
204の応答はヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
The 205 (Reset Content) status code indicates that the server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server.
205（コンテンツのリセット）ステータスコードは、サーバーがリクエストを満たしていることを示し、ユーザーエージェントが「ドキュメントビュー」をリセットすることを望みます。
This response is intended to support a common data entry use case where the user receives content that supports data entry (a form, notepad, canvas, etc.), enters or manipulates data in that space, causes the entered data to be submitted in a request, and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action.
この応答は、ユーザーがデータ入力（フォーム、メモ帳、キャンバスなど）をサポートするコンテンツを受信し、そのスペースにデータを入力または操作するコンテンツを受け取る一般的なデータ入力の使用ケースをサポートすることを目的としています。要求し、次にデータ入力メカニズムが次のエントリにリセットされ、ユーザーが別の入力アクションを簡単に開始できるようにします。
Since the 205 status code implies that no additional content will be provided, a server MUST NOT generate content in a 205 response.
205ステータスコードは、追加のコンテンツが提供されないことを示唆しているため、サーバーは205応答でコンテンツを生成してはなりません。
The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation.
206（部分コンテンツ）ステータスコードは、選択した表現の1つ以上の部分を転送することにより、サーバーがターゲットリソースの範囲要求を正常に満たしていることを示します。
A server that supports range requests (Section 14) will usually attempt to satisfy all of the requested ranges, since sending less data will likely result in another client request for the remainder. However, a server might want to send only a subset of the data requested for reasons of its own, such as temporary unavailability, cache efficiency, load balancing, etc. Since a 206 response is self-descriptive, the client can still understand a response that only partially satisfies its range request.
範囲要求（セクション14）をサポートするサーバーは、通常、要求されたすべての範囲を満たすことを試みます。なぜなら、データを送信すると、残りが別のクライアント要求が発生する可能性が高いためです。ただし、サーバーは、一時的な利用不能、キャッシュ効率、ロードバランシングなど、独自の理由で要求されたデータのサブセットのみを送信したい場合があります。206応答は自己記述的であるため、クライアントは応答を理解できます。それはその範囲の要求を部分的に満たすだけです。
A client MUST inspect a 206 response's Content-Type and Content-Range field(s) to determine what parts are enclosed and whether additional requests are needed.
クライアントは、206の応答のコンテンツタイプとコンテンツレンジフィールドを検査して、どのパーツが囲まれているか、追加のリクエストが必要かどうかを判断する必要があります。
A server that generates a 206 response MUST generate the following header fields, in addition to those required in the subsections below, if the field would have been sent in a 200 (OK) response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and Vary.
206の応答を生成するサーバーは、以下のサブセクションで必要なものに加えて、次のヘッダーフィールドを生成する必要があります。、期限切れ、コンテンツロケーション、さまざまです。
A Content-Length header field present in a 206 response indicates the number of octets in the content of this message, which is usually not the complete length of the selected representation. Each Content-Range header field includes information about the selected representation's complete length.
206応答に存在するコンテンツレングスヘッダーフィールドは、このメッセージの内容のオクテットの数を示します。これは通常、選択された表現の完全な長さではありません。各コンテンツレンジヘッダーフィールドには、選択した表現の完全な長さに関する情報が含まれています。
A sender that generates a 206 response to a request with an If-Range header field SHOULD NOT generate other representation header fields beyond those required because the client already has a prior response containing those header fields. Otherwise, a sender MUST generate all of the representation header fields that would have been sent in a 200 (OK) response to the same request.
if-rangeヘッダーフィールドを使用してリクエストに対する206の応答を生成する送信者は、クライアントがそれらのヘッダーフィールドを含む以前の応答をすでに持っているため、必要なものを超えて他の表現ヘッダーフィールドを生成してはなりません。それ以外の場合、送信者は、同じリクエストに対して200（OK）応答で送信されていたすべての表現ヘッダーフィールドを生成する必要があります。
A 206 response is heuristically cacheable; i.e., unless otherwise indicated by explicit cache controls (see Section 4.2.2 of [CACHING]).
206の応答はヒューリスティックにキャッシュ可能です。つまり、明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
If a single part is being transferred, the server generating the 206 response MUST generate a Content-Range header field, describing what range of the selected representation is enclosed, and a content consisting of the range. For example:
単一の部分が転送されている場合、206応答を生成するサーバーは、選択した表現の範囲が囲まれている範囲と範囲からなるコンテンツを記述するコンテンツレンジヘッダーフィールドを生成する必要があります。例えば：
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
... 26012 bytes of partial image data ...
... 26012部分の画像データのバイト...
If multiple parts are being transferred, the server generating the 206 response MUST generate "multipart/byteranges" content, as defined in Section 14.6, and a Content-Type header field containing the "multipart/byteranges" media type and its required boundary parameter. To avoid confusion with single-part responses, a server MUST NOT generate a Content-Range header field in the HTTP header section of a multiple part response (this field will be sent in each part instead).
複数の部品が転送されている場合、206の応答を生成するサーバーは、セクション14.6で定義されているように、「マルチパート/バイテリア」コンテンツを生成する必要があります。単一部品の応答との混乱を避けるために、サーバーは複数のパーツ応答のHTTPヘッダーセクションにコンテンツレンジヘッダーフィールドを生成してはなりません（このフィールドは、代わりに各部品で送信されます）。
Within the header area of each body part in the multipart content, the server MUST generate a Content-Range header field corresponding to the range being enclosed in that body part. If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type header field in the header area of each body part. For example:
マルチパートコンテンツの各ボディ部分のヘッダー領域内で、サーバーは、そのボディ部分に囲まれている範囲に対応するコンテンツレンジヘッダーフィールドを生成する必要があります。選択した表現が200（OK）応答でコンテンツタイプのヘッダーフィールドを持っていた場合、サーバーは各ボディパーツのヘッダー領域に同じコンテンツタイプのヘッダーフィールドを生成する必要があります。例えば：
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000
...the second range --THIS_STRING_SEPARATES--
... 2番目の範囲-this_string_separates--
When multiple ranges are requested, a server MAY coalesce any of the ranges that overlap, or that are separated by a gap that is smaller than the overhead of sending multiple parts, regardless of the order in which the corresponding range-spec appeared in the received Range header field. Since the typical overhead between each part of a "multipart/byteranges" is around 80 bytes, depending on the selected representation's media type and the chosen boundary parameter length, it can be less efficient to transfer many small disjoint parts than it is to transfer the entire selected representation.
複数の範囲が要求されると、サーバーは、対応する範囲スペックが受信された順序に関係なく、複数の部品を送信するオーバーヘッドよりも小さいギャップによって分離されている範囲のいずれかを合体する場合があります。レンジヘッダーフィールド。「マルチパート/バイタレンジ」の各部分間の典型的なオーバーヘッドは、選択した表現のメディアタイプと選択した境界パラメーターの長さに応じて、約80バイトであるため、多くの小さな分離部品を転送するよりも多くの小さな分離部品を転送する方が効率が低くなる可能性があります。選択された表現全体。
A server MUST NOT generate a multipart response to a request for a single range, since a client that does not request multiple parts might not support multipart responses. However, a server MAY generate a "multipart/byteranges" response with only a single body part if multiple ranges were requested and only one range was found to be satisfiable or only one range remained after coalescing. A client that cannot process a "multipart/byteranges" response MUST NOT generate a request that asks for multiple ranges.
複数の部品を要求しないクライアントがマルチパートの応答をサポートしない可能性があるため、サーバーは単一の範囲の要求に対するマルチパート応答を生成してはなりません。ただし、サーバーは、複数の範囲が要求され、1つの範囲のみが満足できるか、合体後に1つの範囲のみが残っている場合、単一のボディパーツのみで「マルチパート/バイテリア」応答を生成する場合があります。「MultiPart/Byteranges」応答を処理できないクライアントは、複数の範囲を要求するリクエストを生成してはなりません。
A server that generates a multipart response SHOULD send the parts in the same order that the corresponding range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges. A client that receives a multipart response MUST inspect the Content-Range header field present in each body part in order to determine which range is contained in that body part; a client cannot rely on receiving the same ranges that it requested, nor the same order that it requested.
マルチパート応答を生成するサーバーは、対応する範囲スペックが受信された範囲ヘッダーフィールドに表示されたのと同じ順序でパーツを送信する必要があります。マルチパート応答を受信するクライアントは、その身体部分に含まれる範囲を決定するために、各身体部分に存在するコンテンツレンジヘッダーフィールドを検査する必要があります。クライアントは、要求したのと同じ範囲を受け取ることも、要求したのと同じ順序を受け取ることもできません。
A response might transfer only a subrange of a representation if the connection closed prematurely or if the request used one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation. These ranges can only be safely combined if they all have in common the same strong validator (Section 8.8.1).
応答は、接続が早期に閉じた場合、または要求が1つ以上の範囲仕様を使用した場合、表現のサブランジのみを転送する場合があります。このような転送の後、クライアントは同じ表現のいくつかの範囲を受け取った可能性があります。これらの範囲は、すべてが同じ強力なバリデーターを共通している場合にのみ安全に組み合わせることができます（セクション8.8.1）。
A client that has received multiple partial responses to GET requests on a target resource MAY combine those responses into a larger continuous range if they share the same strong validator.
ターゲットリソースでリクエストを取得するための複数の部分的な応答を受け取ったクライアントは、同じ強力なバリーターを共有する場合、それらの応答をより大きな連続範囲に組み合わせることができます。
If the most recent response is an incomplete 200 (OK) response, then the header fields of that response are used for any combined response and replace those of the matching stored responses.
最新の応答が不完全な200（OK）応答である場合、その応答のヘッダーフィールドは、任意の応答に使用され、一致する保存された応答の応答を置き換えます。
If the most recent response is a 206 (Partial Content) response and at least one of the matching stored responses is a 200 (OK), then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching stored responses are 206 responses, then the stored response with the most recent header fields is used as the source of header fields for the combined response, except that the client MUST use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding header fields in the stored response.
最新の応答が206（部分コンテンツ）応答であり、一致する保存された応答の少なくとも1つが200（OK）である場合、複合応答ヘッダーフィールドは最新の200応答のヘッダーフィールドで構成されます。一致する保存された応答のすべてが206の応答である場合、クライアントが新しい応答で提供されている他のヘッダーフィールドを使用する必要があることを除いて、最新のヘッダーフィールドを使用して保存された応答が複合応答のヘッダーフィールドのソースとして使用されます。コンテンツレンジから、保存された応答の対応するヘッダーフィールドのすべてのインスタンスを置き換えます。
The combined response content consists of the union of partial content ranges within the new response and all of the matching stored responses. If the union consists of the entire range of the representation, then the client MUST process the combined response as if it were a complete 200 (OK) response, including a Content-Length header field that reflects the complete length. Otherwise, the client MUST process the set of continuous ranges as one of the following: an incomplete 200 (OK) response if the combined response is a prefix of the representation, a single 206 (Partial Content) response containing "multipart/byteranges" content, or multiple 206 (Partial Content) responses, each with one continuous range that is indicated by a Content-Range header field.
結合された応答コンテンツは、新しい応答内の部分コンテンツの範囲と一致するすべての保存された応答の範囲で構成されています。組合が表現の全範囲で構成されている場合、クライアントは、完全な長さを反映するコンテンツ長ヘッダーフィールドを含む、完全な200（OK）応答であるかのように組み合わせた応答を処理する必要があります。それ以外の場合、クライアントは、連続範囲のセットを次のいずれかのいずれかとして処理する必要があります。複合応答が表現のプレフィックスである場合、「MultiPart/Byteranges」コンテンツを含む単一の206（部分コンテンツ）応答の場合、不完全な200（OK）応答を処理する必要があります。、または複数の206（部分コンテンツ）応答。それぞれがコンテンツレンジヘッダーフィールドで示される1つの連続範囲を備えています。
The 3xx (Redirection) class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. There are several types of redirects:
3XX（リダイレクト）クラスのステータスコードは、リクエストを満たすためにユーザーエージェントがさらなるアクションを実行する必要があることを示しています。リダイレクトにはいくつかのタイプがあります：
1. Redirects that indicate this resource might be available at a different URI, as provided by the Location header field, as in the status codes 301 (Moved Permanently), 302 (Found), 307 (Temporary Redirect), and 308 (Permanent Redirect).
1. このリソースを示すリダイレクトは、ステータスコード301（永続的に移動）、302（発見）、307（一時リダイレクト）、および308（永続的リダイレクト）のように、ロケーションヘッダーフィールドで提供されるように、別のURIで利用可能である可能性があります。
2. Redirection that offers a choice among matching resources capable of representing this resource, as in the 300 (Multiple Choices) status code.
2. 300（複数の選択肢）ステータスコードのように、このリソースを表すことができるマッチングリソースの中から選択を提供するリダイレクト。
3. Redirection to a different resource, identified by the Location header field, that can represent an indirect response to the request, as in the 303 (See Other) status code.
3. 303（他の）ステータスコードのように、リクエストに対する間接的な応答を表す可能性のあるロケーションヘッダーフィールドによって識別される別のリソースへのリダイレクト。
4. Redirection to a previously stored result, as in the 304 (Not Modified) status code.
4. 304（変更されていない）ステータスコードのように、以前に保存された結果へのリダイレクト。
| *Note:* In HTTP/1.0, the status codes 301 (Moved Permanently)
| and 302 (Found) were originally defined as method-preserving
| ([HTTP/1.0], Section 9.3) to match their implementation at
| CERN; 303 (See Other) was defined for a redirection that
| changed its method to GET. However, early user agents split on
| whether to redirect POST requests as POST (according to then-
| current specification) or as GET (the safer alternative when
| redirected to a different site). Prevailing practice
| eventually converged on changing the method to GET. 307
| (Temporary Redirect) and 308 (Permanent Redirect) [RFC7538]
| were later added to unambiguously indicate method-preserving
| redirects, and status codes 301 and 302 have been adjusted to
| allow a POST request to be redirected as GET.
If a Location header field (Section 10.2.2) is provided, the user agent MAY automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is not understood. Automatic redirection needs to be done with care for methods not known to be safe, as defined in Section 9.2.1, since the user might not wish to redirect an unsafe request.
位置ヘッダーフィールド（セクション10.2.2）が提供されている場合、ユーザーエージェントは、特定のステータスコードが理解されていなくても、ロケーションフィールド値で参照されるURIにリクエストを自動的にリダイレクトできます。セクション9.2.1で定義されているように、安全でないことが知られていない方法については、自動リダイレクトを行う必要があります。これは、ユーザーが安全でないリクエストをリダイレクトしたくない場合があるためです。
When automatically following a redirected request, the user agent SHOULD resend the original request message with the following modifications:
リダイレクトされた要求に自動的に追跡する場合、ユーザーエージェントは次の変更を使用して元のリクエストメッセージを再送信する必要があります。
1. Replace the target URI with the URI referenced by the redirection response's Location header field value after resolving it relative to the original request's target URI.
1. ターゲットURIを、元のリクエストのターゲットURIに対して解決した後、リダイレクト応答の位置ヘッダーフィールド値を参照するURIに置き換えます。
2. Remove header fields that were automatically generated by the implementation, replacing them with updated values as appropriate to the new request. This includes:
2. 実装によって自動的に生成されたヘッダーフィールドを削除し、新しいリクエストに適した場合に更新された値に置き換えます。これも：
1. Connection-specific header fields (see Section 7.6.1),
1. 接続固有のヘッダーフィールド（セクション7.6.1を参照）、
2. Header fields specific to the client's proxy configuration, including (but not limited to) Proxy-Authorization,
2. クライアントのプロキシ構成に固有のヘッダーフィールド。
3. Origin-specific header fields (if any), including (but not limited to) Host,
3. ホストを含む（ただしこれらに限定されない）オリジン固有のヘッダーフィールド（もしあれば）、
4. Validating header fields that were added by the implementation's cache (e.g., If-None-Match, If-Modified-Since), and
4. 実装のキャッシュによって追加されたヘッダーフィールドの検証（例：if-none-match、if modified-since）、および
5. Resource-specific header fields, including (but not limited to) Referer, Origin, Authorization, and Cookie.
5. リソース固有のヘッダーフィールドには、参照、起源、承認、およびCookieを含む（ただしこれらに限定されません）。
3. Consider removing header fields that were not automatically generated by the implementation (i.e., those present in the request because they were added by the calling context) where there are security implications; this includes but is not limited to Authorization and Cookie.
3. セキュリティの意味がある場合、実装によって自動的に生成されなかったヘッダーフィールド（つまり、呼び出しコンテキストによって追加されたために存在するもの）を削除することを検討してください。これには、認可とCookieが含まれますが、これらに限定されません。
4. Change the request method according to the redirecting status code's semantics, if applicable.
4. 該当する場合は、リダイレクトステータスコードのセマンティクスに従って要求方法を変更します。
5. If the request method has been changed to GET or HEAD, remove content-specific header fields, including (but not limited to) Content-Encoding, Content-Language, Content-Location, Content-Type, Content-Length, Digest, Last-Modified.
5. リクエストメソッドが取得またはヘッドに変更された場合、コンテンツエンコード、コンテンツ言語、コンテンツロケージ、コンテンツタイプ、コンテンツレングス、ダイジェスト、ラストなど、コンテンツ固有のヘッダーフィールドを削除します（ただし、これらに限定されません）。修正。
A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).
クライアントは、周期的なリダイレクト（つまり、「無限」リダイレクトループ）を検出して介入する必要があります。
| *Note:* An earlier version of this specification recommended a
| maximum of five redirections ([RFC2068], Section 10.3).
| Content developers need to be aware that some clients might
| implement such a fixed limitation.
The 300 (Multiple Choices) status code indicates that the target resource has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers. In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs (Section 12).
300（複数の選択肢）ステータスコードは、ターゲットリソースにそれぞれが独自のより具体的な識別子を持つ複数の表現があることを示し、ユーザー（またはユーザーエージェント）が優先表現を選択できるように、代替案に関する情報が提供されています。その要求を1つ以上の識別子にリダイレクトします。言い換えれば、サーバーは、ユーザーエージェントがリアクティブな交渉に従事し、そのニーズに合った最も適切な表現を選択することを望んでいます（セクション12）。
If the server has a preferred choice, the server SHOULD generate a Location header field containing a preferred choice's URI reference. The user agent MAY use the Location field value for automatic redirection.
サーバーに優先選択がある場合、サーバーは、優先選択のURIリファレンスを含むロケーションヘッダーフィールドを生成する必要があります。ユーザーエージェントは、自動リダイレクトにロケーションフィールド値を使用できます。
For request methods other than HEAD, the server SHOULD generate content in the 300 response containing a list of representation metadata and URI reference(s) from which the user or user agent can choose the one most preferred. The user agent MAY make a selection from that list automatically if it understands the provided media type. A specific format for automatic selection is not defined by this specification because HTTP tries to remain orthogonal to the definition of its content. In practice, the representation is provided in some easily parsed format believed to be acceptable to the user agent, as determined by shared design or content negotiation, or in some commonly accepted hypertext format.
ヘッド以外の要求方法の場合、サーバーは、ユーザーまたはユーザーエージェントが最も優先されるものを選択できる表現メタデータとURIリファレンスのリストを含む300応答でコンテンツを生成する必要があります。ユーザーエージェントは、提供されたメディアタイプを理解している場合、そのリストから自動的に選択することができます。HTTPはコンテンツの定義に直交しようとするため、自動選択の特定の形式はこの仕様によって定義されません。実際には、共有設計またはコンテンツの交渉によって決定されるように、ユーザーエージェントに受け入れられると思われる簡単に解析された形式で表現が提供されます。
A 300 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
300の応答はヒューリスト的にキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
| *Note:* The original proposal for the 300 status code defined
| the URI header field as providing a list of alternative
| representations, such that it would be usable for 200, 300, and
| 406 responses and be transferred in responses to the HEAD
| method. However, lack of deployment and disagreement over
| syntax led to both URI and Alternates (a subsequent proposal)
| being dropped from this specification. It is possible to
| communicate the list as a Link header field value [RFC8288]
| whose members have a relationship of "alternate", though
| deployment is a chicken-and-egg problem.
The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. The server is suggesting that a user agent with link-editing capability can permanently replace references to the target URI with one of the new references sent by the server. However, this suggestion is usually ignored unless the user agent is actively editing references (e.g., engaged in authoring content), the connection is secured, and the origin server is a trusted authority for the content being edited.
301（永続的に移動）ステータスコードは、ターゲットリソースに新しい永続的なURIが割り当てられており、このリソースへの将来の参照が囲まれたURIの1つを使用する必要があることを示しています。サーバーは、リンク編集機能を備えたユーザーエージェントが、ターゲットURIへの参照をサーバーから送信した新しい参照の1つに永続的に置き換えることができることを示唆しています。ただし、ユーザーエージェントが参照を積極的に編集していない限り（たとえば、執筆コンテンツに従事する）、接続が確保され、Origin Serverは編集されるコンテンツの信頼できる機関である場合を除き、通常、この提案は無視されます。
The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection. The server's response content usually contains a short hypertext note with a hyperlink to the new URI(s).
サーバーは、新しい永続的なURIの優先URI参照を含む応答に位置ヘッダーフィールドを生成する必要があります。ユーザーエージェントは、自動リダイレクトにロケーションフィールド値を使用できます。サーバーの応答コンテンツには、通常、新しいURIへのハイパーリンクを備えた短いハイパーテキストノートが含まれています。
| *Note:* For historical reasons, a user agent MAY change the
| request method from POST to GET for the subsequent request. If
| this behavior is undesired, the 308 (Permanent Redirect) status
| code can be used instead.
A 301 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
301の応答はヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
The 302 (Found) status code indicates that the target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the target URI for future requests.
302（見つかった）ステータスコードは、ターゲットリソースが異なるURIの下に一時的に存在することを示します。リダイレクトが時々変更される可能性があるため、クライアントは将来のリクエストにターゲットURIを引き続き使用する必要があります。
The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response content usually contains a short hypertext note with a hyperlink to the different URI(s).
サーバーは、異なるURIのURI参照を含む応答に位置ヘッダーフィールドを生成する必要があります。ユーザーエージェントは、自動リダイレクトにロケーションフィールド値を使用できます。サーバーの応答コンテンツには、通常、異なるURIへのハイパーリンクを備えた短いハイパーテキストノートが含まれています。
| *Note:* For historical reasons, a user agent MAY change the
| request method from POST to GET for the subsequent request. If
| this behavior is undesired, the 307 (Temporary Redirect) status
| code can be used instead.
The 303 (See Other) status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which is intended to provide an indirect response to the original request. A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the target URI.
303（その他を参照）ステータスコードは、元のリクエストに間接的な応答を提供することを目的としたロケーションヘッダーフィールドのURIで示されるように、サーバーがユーザーエージェントを別のリソースにリダイレクトしていることを示しています。ユーザーエージェントは、URI（HTTPを使用している場合はGETまたはヘッドリクエスト）をターゲットとする検索要求を実行できます。ロケーションヘッダーフィールドの新しいURIは、ターゲットURIに相当するものではないことに注意してください。
This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a different resource, since doing so provides the information corresponding to the POST response as a resource that can be separately identified, bookmarked, and cached.
このステータスコードは、任意のHTTPメソッドに適用できます。これは主に、ポストアクションの出力が異なるリソースにユーザーエージェントをリダイレクトするために使用されるために使用されます。これは、ポスト応答に対応する情報を個別に識別、ブックマーク、およびキャッシュできるリソースとして提供するためです。
A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.
GETリクエストに対する303の応答は、Origin ServerにHTTPを介してサーバーが転送できるターゲットリソースの表現がないことを示しています。ただし、位置フィールド値とは、ターゲットリソースを説明するリソースを指します。そのため、他のリソースを検索すると、元のターゲットリソースを表すことなく受信者にとって有用な表現が得られる可能性があります。表現できるもの、適切な表現、および有用な説明がHTTPの範囲外であることの質問に対する回答に注意してください。
Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with a hyperlink to the same URI reference provided in the Location header field.
ヘッドリクエストへの応答を除き、303応答の表現は、ロケーションヘッダーフィールドに提供される同じURI参照とのハイパーリンクを備えた短いハイパーテキストノートを含める必要があります。
The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false. In other words, there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response.
304（変更されていない）ステータスコードは、条件付きGETまたはヘッドリクエストが受信されたことを示しており、falseに評価された条件ではない場合、200（OK）応答が発生したことを示しています。言い換えれば、リクエストが条件付きになったクライアントがすでに有効な表現を持っていることを要求が示すため、サーバーがターゲットリソースの表現を転送する必要はありません。したがって、サーバーは、200（OK）応答のコンテンツであるかのように、その保存された表現を使用するようにクライアントをリダイレクトしています。
The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request:
304応答を生成するサーバーは、同じリクエストに対して200（OK）応答で送信されていた次のヘッダーフィールドのいずれかを生成する必要があります。
* Content-Location, Date, ETag, and Vary
* コンテンツロケーション、日付、ETAG、およびさまざま
* Cache-Control and Expires (see [CACHING])
* キャッシュ制御と期限切れ（[キャッシュ]を参照）
Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender SHOULD NOT generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., Last-Modified might be useful if the response does not have an ETag field).
304応答の目標は、受信者がすでに1つ以上のキャッシュ表現を持っている場合の情報転送を最小限に抑えることであるため、送信者は、キャッシュの更新をガイドする目的でメタデータが存在しない限り、上記のフィールド以外の表現メタデータを生成してはなりません（例えば、ラスト修飾は、応答にETAGフィールドがない場合に役立つ可能性があります）。
Requirements on a cache that receives a 304 response are defined in Section 4.3.4 of [CACHING]. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional GET to a shared proxy, then the proxy SHOULD forward the 304 response to that client.
304応答を受信するキャッシュの要件は、[キャッシュ]のセクション4.3.4で定義されています。条件付きリクエストが、独自のキャッシュを持つユーザーエージェントなどのアウトバウンドクライアントから発信された場合、共有プロキシに条件付きゲットを送信する場合、プロキシはそのクライアントに304応答を転送する必要があります。
A 304 response is terminated by the end of the header section; it cannot contain content or trailers.
304の応答は、ヘッダーセクションの終わりによって終了します。コンテンツやトレーラーを含めることはできません。
The 305 (Use Proxy) status code was defined in a previous version of this specification and is now deprecated (Appendix B of [RFC7231]).
305（Proxyの使用）ステータスコードは、この仕様の以前のバージョンで定義されており、現在は廃止されています（[RFC7231]の付録B）。
The 306 status code was defined in a previous version of this specification, is no longer used, and the code is reserved.
306ステータスコードは、この仕様の以前のバージョンで定義され、使用されなくなり、コードは予約されています。
The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time, the client ought to continue using the original target URI for future requests.
307（一時リダイレクト）ステータスコードは、ターゲットリソースが異なるURIの下で一時的に存在することを示し、ユーザーエージェントはそのURIに対して自動リダイレクトを実行する場合、リクエスト方法を変更してはなりません。リダイレクトは時間の経過とともに変化する可能性があるため、クライアントは将来のリクエストのために元のターゲットURIを使用し続ける必要があります。
The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response content usually contains a short hypertext note with a hyperlink to the different URI(s).
サーバーは、異なるURIのURI参照を含む応答に位置ヘッダーフィールドを生成する必要があります。ユーザーエージェントは、自動リダイレクトにロケーションフィールド値を使用できます。サーバーの応答コンテンツには、通常、異なるURIへのハイパーリンクを備えた短いハイパーテキストノートが含まれています。
The 308 (Permanent Redirect) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. The server is suggesting that a user agent with link-editing capability can permanently replace references to the target URI with one of the new references sent by the server. However, this suggestion is usually ignored unless the user agent is actively editing references (e.g., engaged in authoring content), the connection is secured, and the origin server is a trusted authority for the content being edited.
308（永続的なリダイレクト）ステータスコードは、ターゲットリソースに新しい永続的なURIが割り当てられており、このリソースへの将来の参照が囲まれたURIの1つを使用する必要があることを示しています。サーバーは、リンク編集機能を備えたユーザーエージェントが、ターゲットURIへの参照をサーバーから送信した新しい参照の1つに永続的に置き換えることができることを示唆しています。ただし、ユーザーエージェントが参照を積極的に編集していない限り（たとえば、執筆コンテンツに従事する）、接続が確保され、Origin Serverは編集されるコンテンツの信頼できる機関である場合を除き、通常、この提案は無視されます。
The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection. The server's response content usually contains a short hypertext note with a hyperlink to the new URI(s).
サーバーは、新しい永続的なURIの優先URI参照を含む応答に位置ヘッダーフィールドを生成する必要があります。ユーザーエージェントは、自動リダイレクトにロケーションフィールド値を使用できます。サーバーの応答コンテンツには、通常、新しいURIへのハイパーリンクを備えた短いハイパーテキストノートが含まれています。
A 308 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
308の応答は、ヒューリスト的にキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
| *Note:* This status code is much younger (June 2014) than its
| sibling codes and thus might not be recognized everywhere. See
| Section 4 of [RFC7538] for deployment considerations.
The 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included representation to the user.
4XX（クライアントエラー）クラスのステータスコードは、クライアントがエラーしているように見えることを示しています。ヘッドリクエストに応答する場合を除き、サーバーはエラー状況の説明を含む表現を送信する必要があります。これらのステータスコードは、任意の要求方法に適用できます。ユーザーエージェントは、含まれている表現をユーザーに表示する必要があります。
The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
400（悪い要求）ステータスコードは、クライアントエラーであると認識されているもの（例えば、不正な要求構文、リクエストメッセージフレーミング、または欺ceptiveリクエストルーティング）のためにサーバーが要求を処理できないか、または処理しないことを示します。
The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 11.6.1) containing at least one challenge applicable to the target resource.
401（不正）ステータスコードは、ターゲットリソースの有効な認証資格情報がないため、リクエストが適用されていないことを示しています。401応答を生成するサーバーは、ターゲットリソースに適用される少なくとも1つのチャレンジを含むwww-authenticateヘッダーフィールド（セクション11.6.1）を送信する必要があります。
If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 11.6.2). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.
リクエストに認証資格情報が含まれている場合、401応答は、これらの資格情報に対して承認が拒否されたことを示します。ユーザーエージェントは、新しいまたは交換された認証ヘッダーフィールド（セクション11.6.2）でリクエストを繰り返すことができます。401応答に以前の応答と同じ課題が含まれており、ユーザーエージェントが既に認証を少なくとも1回試みている場合、ユーザーエージェントは通常、関連する診断情報が含まれているため、ユーザーに囲まれた表現を提示する必要があります。
The 402 (Payment Required) status code is reserved for future use.
402（支払いが必要）ステータスコードは、将来の使用のために予約されています。
The 403 (Forbidden) status code indicates that the server understood the request but refuses to fulfill it. A server that wishes to make public why the request has been forbidden can describe that reason in the response content (if any).
403（禁止）ステータスコードは、サーバーがリクエストを理解したが、それを満たすことを拒否したことを示します。リクエストが禁止されている理由を公開したいサーバーは、応答コンテンツ（もしあれば）でその理由を説明できます。
If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
リクエストで認証資格情報が提供された場合、サーバーはアクセスを付与するのに不十分であると考えます。クライアントは、同じ資格情報でリクエストを自動的に繰り返すべきではありません。クライアントは、新規または異なる資格情報でリクエストを繰り返すことができます。ただし、資格とは関係のない理由で要求が禁止される場合があります。
An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
禁止されているターゲットリソースの現在の存在を「非表示」したいOrigin Serverは、代わりに404のステータスコードで応答する場合があります（見つかりません）。
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.
404（見つからない）ステータスコードは、Origin Serverがターゲットリソースの現在の表現を見つけられなかったか、存在することを開示する意思がないことを示しています。404ステータスコードは、この表現の欠如が一時的なものか永続的かを示していません。Origin Serverが条件が永続的である可能性が高いというOrigin Serverがおそらく構成可能な手段を通じて知っている場合、410（GONE）ステータスコードは404よりも推奨されます。
A 404 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
404の応答は、ヒューリスト的にキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource. The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.
405（許可されていない方法）ステータスコードは、リクエストラインで受信されたメソッドがOrigin Serverで知られているが、ターゲットリソースではサポートされていないことを示します。Origin Serverは、ターゲットリソースの現在サポートされているメソッドのリストを含む405応答で許容ヘッダーフィールドを生成する必要があります。
A 405 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
405の応答はヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
The 406 (Not Acceptable) status code indicates that the target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request (Section 12.1), and the server is unwilling to supply a default representation.
406（許容されない）ステータスコードは、ターゲットリソースに、リクエストで受け取ったプロアクティブネゴシエーションヘッダーフィールド（セクション12.1）によると、ユーザーエージェントに受け入れられる現在の表現がないことを示しています。デフォルトの表現を提供します。
The server SHOULD generate content containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate. A user agent MAY automatically select the most appropriate choice from that list. However, this specification does not define any standard for such automatic selection, as described in Section 15.4.1.
サーバーは、利用可能な表現特性のリストと、ユーザーまたはユーザーエージェントが最も適切なものを選択できる対応するリソース識別子を含むコンテンツを生成する必要があります。ユーザーエージェントは、そのリストから最も適切な選択肢を自動的に選択できます。ただし、この仕様では、セクション15.4.1で説明されているように、このような自動選択の標準を定義しません。
The 407 (Proxy Authentication Required) status code is similar to 401 (Unauthorized), but it indicates that the client needs to authenticate itself in order to use a proxy for this request. The proxy MUST send a Proxy-Authenticate header field (Section 11.7.1) containing a challenge applicable to that proxy for the request. The client MAY repeat the request with a new or replaced Proxy-Authorization header field (Section 11.7.2).
407（プロキシ認証が必要）ステータスコードは401（不正）に似ていますが、クライアントはこのリクエストにプロキシを使用するために自らを認証する必要があることを示しています。プロキシは、リクエストのプロキシに適用される課題を含む、プロキシと認識ヘッダーフィールド（セクション11.7.1）を送信する必要があります。クライアントは、新規または交換されたプロキシ承認ヘッダーフィールド（セクション11.7.2）でリクエストを繰り返すことができます。
The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait.
408（リクエストタイムアウト）ステータスコードは、サーバーが待機する準備ができた時間内に完全な要求メッセージを受信しなかったことを示します。
If the client has an outstanding request in transit, it MAY repeat that request. If the current connection is not usable (e.g., as it would be in HTTP/1.1 because request delimitation is lost), a new connection will be used.
クライアントが輸送中に未解決のリクエストを持っている場合、そのリクエストを繰り返す可能性があります。現在の接続が使用できない場合（たとえば、リクエストの削除が失われているため、HTTP/1.1であるように）、新しい接続が使用されます。
The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate content that includes enough information for a user to recognize the source of the conflict.
409（競合）ステータスコードは、ターゲットリソースの現在の状態との競合のために要求を完了できなかったことを示しています。このコードは、ユーザーが競合を解決し、リクエストを再提出できる状況で使用されます。サーバーは、ユーザーが競合のソースを認識するのに十分な情報を含むコンテンツを生成する必要があります。
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely contain information useful for merging the differences based on the revision history.
競合は、PUTリクエストに応じて発生する可能性が最も高くなります。たとえば、バージョンの使用が使用されており、表現が含まれている場合、以前の（サードパーティ）リクエストによって作成されたリソースと競合するリソースの変更が含まれている場合、Origin Serverは409の応答を使用して、完了できないことを示す場合があります。リクエスト。この場合、応答表現には、改訂履歴に基づいて違いをマージするのに役立つ情報が含まれている可能性があります。
The 410 (Gone) status code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) ought to be used instead.
410（GONE）ステータスコードは、ターゲットリソースへのアクセスがOrigin Serverで利用できなくなり、この条件が永続的である可能性が高いことを示しています。Origin Serverが条件が永続的であるかどうかを知らない、または決定する機能がない場合、代わりにステータスコード404（見つかりません）を使用する必要があります。
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer associated with the origin server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
410の応答は、主に、リソースが意図的に利用できないこと、およびサーバーの所有者がそのリソースへのリモートリンクを削除することを望んでいることを受信者に通知することにより、Webメンテナンスのタスクを支援することを目的としています。このようなイベントは、限られた時間、プロモーションサービス、およびOrigin Serverのサイトに関連付けられなくなった個人に属するリソースで一般的です。永久に利用できないすべてのリソースを「なくなった」とマークしたり、サーバーの所有者の裁量に任されている長さのマークを維持する必要はありません。
A 410 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
410の応答はヒューリスティックにキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
The 411 (Length Required) status code indicates that the server refuses to accept the request without a defined Content-Length (Section 8.6). The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the request content.
411（長さ必須）ステータスコードは、サーバーが定義されたコンテンツレングスなしでリクエストを受け入れることを拒否したことを示しています（セクション8.6）。クライアントは、リクエストコンテンツの長さを含む有効なコンテンツレングスヘッダーフィールドを追加すると、リクエストを繰り返すことができます。
The 412 (Precondition Failed) status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the server (Section 13). This response status code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state.
412（前提条件に失敗した）ステータスコードは、サーバーでテストされたときにfalseに評価されたリクエストヘッダーフィールドに与えられた1つ以上の条件（セクション13）を示します。この応答ステータスコードにより、クライアントは現在のリソース状態（現在の表現とメタデータ）に前提条件を配置することができ、したがって、ターゲットリソースが予期しない状態にある場合、リクエストメソッドが適用されないようにします。
The 413 (Content Too Large) status code indicates that the server is refusing to process a request because the request content is larger than the server is willing or able to process. The server MAY terminate the request, if the protocol version in use allows it; otherwise, the server MAY close the connection.
413（コンテンツが大きすぎる）ステータスコードは、リクエストコンテンツがサーバーが喜んで処理できるか、処理できるよりも大きいため、サーバーがリクエストの処理を拒否していることを示しています。使用中のプロトコルバージョンが許可されている場合、サーバーは要求を終了する場合があります。それ以外の場合、サーバーは接続を閉じることができます。
If the condition is temporary, the server SHOULD generate a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.
条件が一時的な場合、サーバーは一時的なヘッダーアフターヘッダーフィールドを生成し、一時的なものであり、クライアントが再試行できることを示します。
The 414 (URI Too Long) status code indicates that the server is refusing to service the request because the target URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into an infinite loop of redirection (e.g., a redirected URI prefix that points to a suffix of itself) or when the server is under attack by a client attempting to exploit potential security holes.
414（URI Too Long）ステータスコードは、ターゲットURIがサーバーが喜んで解釈するよりも長いため、サーバーがリクエストのサービスを拒否していることを示しています。このまれな条件は、クライアントがリダイレクトの無限のループ（例えば、サフィックスを指すリダイレクトされたURIプレフィックス）に下降した場合、クライアントが長いクエリ情報を使用してgetリクエストに不適切にポストリクエストを変換した場合にのみ発生する可能性があります。それ自体）またはサーバーが潜在的なセキュリティ穴を悪用しようとするクライアントによって攻撃を受けているとき。
A 414 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
414の応答はヒューリスト的にキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the content is in a format not supported by this method on the target resource.
415（サポートされていないメディアタイプ）ステータスコードは、コンテンツがターゲットリソースのこのメソッドでサポートされていない形式であるため、Origin Serverがリクエストのサービスを拒否していることを示しています。
The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.
フォーマットの問題は、リクエストの指定されたコンテンツタイプまたはコンテンツエンコードによるもの、またはデータを直接検査した結果である可能性があります。
If the problem was caused by an unsupported content coding, the Accept-Encoding response header field (Section 12.5.3) ought to be used to indicate which (if any) content codings would have been accepted in the request.
問題がサポートされていないコンテンツコーディングによって引き起こされた場合、受け入れエンコード応答ヘッダーフィールド（セクション12.5.3）を使用して、（もしあれば）コンテンツコーディングがリクエストで受け入れられていたかを示す必要があります。
On the other hand, if the cause was an unsupported media type, the Accept response header field (Section 12.5.1) can be used to indicate which media types would have been accepted in the request.
一方、原因がサポートされていないメディアタイプである場合、Accept Response Headerフィールド（セクション12.5.1）を使用して、リクエストでどのメディアタイプが受け入れられていたかを示すことができます。
The 416 (Range Not Satisfiable) status code indicates that the set of ranges in the request's Range header field (Section 14.2) has been rejected either because none of the requested ranges are satisfiable or because the client has requested an excessive number of small or overlapping ranges (a potential denial of service attack).
416（範囲が満たさない）ステータスコードは、リクエストの範囲ヘッダーフィールド（セクション14.2）の範囲のセットが拒否されたことを示しています。範囲（潜在的なサービス拒否攻撃）。
Each range unit defines what is required for its own range sets to be satisfiable. For example, Section 14.1.2 defines what makes a bytes range set satisfiable.
各レンジユニットは、独自の範囲セットが満足できるように必要なものを定義します。たとえば、セクション14.1.2では、バイト範囲の設定を満たすものを定義します。
A server that generates a 416 response to a byte-range request SHOULD generate a Content-Range header field specifying the current length of the selected representation (Section 14.4).
バイトレンジ要求に対する416の応答を生成するサーバーは、選択した表現の現在の長さを指定するコンテンツレンジヘッダーフィールドを生成するはずです（セクション14.4）。
For example:
例えば：
HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022
| *Note:* Because servers are free to ignore Range, many
| implementations will respond with the entire selected
| representation in a 200 (OK) response. That is partly because
| most clients are prepared to receive a 200 (OK) to complete the
| task (albeit less efficiently) and partly because clients might
| not stop making an invalid range request until they have
| received a complete representation. Thus, clients cannot
| depend on receiving a 416 (Range Not Satisfiable) response even
| when it is most appropriate.
The 417 (Expectation Failed) status code indicates that the expectation given in the request's Expect header field (Section 10.1.1) could not be met by at least one of the inbound servers.
417（期待に失敗した）ステータスコードは、リクエストの予想ヘッダーフィールド（セクション10.1.1）に与えられた期待が、少なくとも1つのインバウンドサーバーの1つによって満たされなかったことを示しています。
[RFC2324] was an April 1 RFC that lampooned the various ways HTTP was abused; one such abuse was the definition of an application-specific 418 status code, which has been deployed as a joke often enough for the code to be unusable for any future use.
[RFC2324]は、httpが乱用されたさまざまな方法を妨げた4月1日のRFCでした。そのような虐待の1つは、アプリケーション固有の418ステータスコードの定義でした。これは、コードが将来の使用に使用できないほど頻繁にジョークとして展開されています。
Therefore, the 418 status code is reserved in the IANA HTTP Status Code Registry. This indicates that the status code cannot be assigned to other applications currently. If future circumstances require its use (e.g., exhaustion of 4NN status codes), it can be re-assigned to another use.
したがって、418ステータスコードはIANA HTTPステータスコードレジストリに予約されています。これは、ステータスコードを現在他のアプリケーションに割り当てることができないことを示しています。将来の状況がその使用（4NNステータスコードの消耗など）が必要な場合、別の使用に再割り当てすることができます。
The 421 (Misdirected Request) status code indicates that the request was directed at a server that is unable or unwilling to produce an authoritative response for the target URI. An origin server (or gateway acting on behalf of the origin server) sends 421 to reject a target URI that does not match an origin for which the server has been configured (Section 4.3.1) or does not match the connection context over which the request was received (Section 7.4).
421（誤った要求）ステータスコードは、リクエストがターゲットURIの権威ある応答を作成できない、または不本意なサーバーに向けられたことを示しています。Origin Server（またはOrigin Serverに代わって作用するGateway）は、421を送信して、サーバーが構成されている起源（セクション4.3.1）または接続コンテキストと一致しないターゲットURIを拒否します。リクエストが受信されました（セクション7.4）。
A client that receives a 421 (Misdirected Request) response MAY retry the request, whether or not the request method is idempotent, over a different connection, such as a fresh connection specific to the target resource's origin, or via an alternative service [ALTSVC].
421（誤った要求）応答を受信したクライアントは、リクエストメソッドがiDempotentであるかどうか、ターゲットリソースのオリジンに固有の新鮮な接続など、別の接続、または代替サービス[AltSVC]を介してリクエストを再試行する場合があります。。
A proxy MUST NOT generate a 421 response.
プロキシは421応答を生成してはなりません。
The 422 (Unprocessable Content) status code indicates that the server understands the content type of the request content (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request content is correct, but it was unable to process the contained instructions. For example, this status code can be sent if an XML request content contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions.
422（処理できないコンテンツ）ステータスコードは、サーバーがリクエストコンテンツのコンテンツタイプ（415（サポートされていないメディアタイプ）ステータスコードが不適切です）を理解していることを示し、リクエストコンテンツの構文は正しいですが、含まれる命令を処理します。たとえば、このステータスコードは、XMLリクエストコンテンツによく形成された（つまり、構文的に正しい）が含まれているが、意味的に誤ったXML命令を含む場合に送信できます。
The 426 (Upgrade Required) status code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s) (Section 7.8).
426（アップグレード必須）ステータスコードは、サーバーが現在のプロトコルを使用してリクエストの実行を拒否していることを示していますが、クライアントが別のプロトコルにアップグレードした後、喜んでそうすることができます。サーバーは、必要なプロトコル（S）を示すために、426応答でアップグレードヘッダーフィールドを送信する必要があります（セクション7.8）。
Example:
例：
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain
This service requires use of the HTTP/3.0 protocol.
このサービスには、HTTP/3.0プロトコルの使用が必要です。
The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. A user agent SHOULD display any included representation to the user. These status codes are applicable to any request method.
5xx（サーバーエラー）ステータスコードのクラスは、サーバーが要求されているか、要求された方法を実行できないことを認識していることを示しています。ヘッドリクエストに応答する場合を除き、サーバーはエラー状況の説明を含む表現を送信する必要があります。ユーザーエージェントは、含まれている表現をユーザーに表示する必要があります。これらのステータスコードは、任意の要求方法に適用できます。
The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.
500（内部サーバーエラー）ステータスコードは、サーバーがリクエストを満たすことを妨げる予期しない条件に遭遇したことを示します。
The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.
501（実装されていない）ステータスコードは、リクエストを満たすために必要な機能をサーバーがサポートしていないことを示しています。これは、サーバーがリクエストメソッドを認識せず、リソースをサポートできない場合の適切な応答です。
A 501 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).
501の応答は、ヒューリスト的にキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュコントロールで特に示されない限り（[キャッシュ]のセクション4.2.2を参照）。
The 502 (Bad Gateway) status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.
502（悪いゲートウェイ）ステータスコードは、サーバーがゲートウェイまたはプロキシとして機能している間、リクエストを満たそうとしている間にアクセスしたインバウンドサーバーから無効な応答を受け取ったことを示しています。
The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field (Section 10.2.3) to suggest an appropriate amount of time for the client to wait before retrying the request.
503（サービスは利用できない）ステータスコードは、一時的な過負荷またはスケジュールされたメンテナンスにより、サーバーが現在リクエストを処理できないことを示しています。サーバーは、リクエストを再試行する前にクライアントが待機するのに適切な時間を提案するために、再試行後ヘッダーフィールド（セクション10.2.3）を送信する場合があります。
| *Note:* The existence of the 503 status code does not imply
| that a server has to use it when becoming overloaded. Some
| servers might simply refuse the connection.
The 504 (Gateway Timeout) status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request.
504（ゲートウェイタイムアウト）ステータスコードは、サーバーがゲートウェイまたはプロキシとして機能している間、リクエストを完了するためにアクセスする必要があるアップストリームサーバーからタイムリーな応答を受け取らなかったことを示しています。
The 505 (HTTP Version Not Supported) status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in Section 2.5, other than with this error message. The server SHOULD generate a representation for the 505 response that describes why that version is not supported and what other protocols are supported by that server.
505（HTTPバージョンがサポートされていない）ステータスコードは、リクエストメッセージで使用されたHTTPの主要バージョンをサーバーがサポートしていないか、サポートを拒否していないことを示しています。サーバーは、このエラーメッセージを除いて、セクション2.5で説明されているように、クライアントと同じメジャーバージョンを使用してリクエストを完了することができないか、またはリクエストを完了することができないことを示しています。サーバーは、そのバージョンがサポートされていない理由と、そのサーバーによって他のプロトコルがサポートされている理由を説明する505応答の表現を生成する必要があります。
HTTP defines a number of generic extension points that can be used to introduce capabilities to the protocol without introducing a new version, including methods, status codes, field names, and further extensibility points within defined fields, such as authentication schemes and cache directives (see Cache-Control extensions in Section 5.2.3 of [CACHING]). Because the semantics of HTTP are not versioned, these extension points are persistent; the version of the protocol in use does not affect their semantics.
HTTPは、メソッド、ステータスコード、フィールド名、および認証スキームやキャッシュディレクティブなどの定義されたフィールド内のさらなる拡張性ポイントを含む新しいバージョンを導入することなく、プロトコルに機能を導入するために使用できる多数の汎用拡張ポイントを定義します（参照[キャッシュ]のセクション5.2.3のキャッシュ制御拡張機能）。HTTPのセマンティクスはバージョンではないため、これらの拡張ポイントは永続的です。使用中のプロトコルのバージョンは、それらのセマンティクスに影響しません。
Version-independent extensions are discouraged from depending on or interacting with the specific version of the protocol in use. When this is unavoidable, careful consideration needs to be given to how the extension can interoperate across versions.
バージョンに依存しないエクステンションは、使用中のプロトコルの特定のバージョンに依存または相互作用することを思いとどまらせます。これが避けられない場合、拡張機能がバージョン間でどのように相互運用できるかについて、慎重に検討する必要があります。
Additionally, specific versions of HTTP might have their own extensibility points, such as transfer codings in HTTP/1.1 (Section 6.1 of [HTTP/1.1]) and HTTP/2 SETTINGS or frame types ([HTTP/2]). These extension points are specific to the version of the protocol they occur within.
さらに、HTTPの特定のバージョンには、HTTP/1.1（[HTTP/1.1]のセクション6.1）の転送コードやHTTP/2設定またはフレームタイプ（[http/2]）などの独自の拡張性ポイントがある場合があります。これらの拡張ポイントは、内部で発生するプロトコルのバージョンに固有です。
Version-specific extensions cannot override or modify the semantics of a version-independent mechanism or extension point (like a method or header field) without explicitly being allowed by that protocol element. For example, the CONNECT method (Section 9.3.6) allows this.
バージョン固有の拡張機能は、そのプロトコル要素によって明示的に許可されることなく、バージョンに依存しないメカニズムまたは拡張ポイント（メソッドまたはヘッダーフィールドなど）のセマンティクスをオーバーライドまたは変更することはできません。たとえば、Connectメソッド（セクション9.3.6）を使用すると、これが許可されています。
These guidelines assure that the protocol operates correctly and predictably, even when parts of the path implement different versions of HTTP.
これらのガイドラインは、パスの一部がHTTPの異なるバージョンを実装した場合でも、プロトコルが正しく予測可能に動作することを保証します。
The "Hypertext Transfer Protocol (HTTP) Method Registry", maintained by IANA at <https://www.iana.org/assignments/http-methods>, registers method names.
IANAが<https://www.iana.org/assignments/http-methods>で維持している「ハイパーテキスト転送プロトコル（HTTP）メソッドレジストリ」は、メソッド名をレジスターします。
HTTP method registrations MUST include the following fields:
HTTPメソッド登録には、次のフィールドを含める必要があります。
* Method Name (see Section 9)
* メソッド名（セクション9を参照）
* Safe ("yes" or "no", see Section 9.2.1)
* 安全（「はい」または「いいえ」、セクション9.2.1を参照）
* Idempotent ("yes" or "no", see Section 9.2.2)
* idempotent（ "yes"または "no"、セクション9.2.2を参照）
* Pointer to specification text
* 仕様テキストへのポインタ
Values to be added to this namespace require IETF Review (see [RFC8126], Section 4.8).
この名前空間に追加する値には、IETFレビューが必要です（[RFC8126]、セクション4.8を参照）。
Standardized methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, kind of resource, or application. As such, it is preferred that new methods be registered in a document that isn't specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.
標準化された方法は汎用です。つまり、特定のメディアタイプ、種類のリソース、またはアプリケーションだけでなく、あらゆるリソースに適用される可能性があります。そのため、直交技術は直交仕様に値するため、単一のアプリケーションまたはデータ形式に固有のドキュメントに新しい方法を登録することが推奨されます。
Since message parsing (Section 6) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of content on either the request or the response message. Definitions of new methods can specify that only a zero-length content is allowed by requiring a Content-Length header field with a value of "0".
メッセージの解析（セクション6）はメソッドセマンティクス（ヘッドへの応答は別として）とは独立している必要があるため、新しい方法の定義は解析アルゴリズムを変更したり、要求または応答メッセージのいずれかでコンテンツの存在を禁止したりすることはできません。新しいメソッドの定義では、「0」の値を持つコンテンツ長ヘッダーフィールドを必要とすることにより、ゼロの長さのコンテンツのみが許可されることを指定できます。
Likewise, new methods cannot use the special host:port and asterisk forms of request target that are allowed for CONNECT and OPTIONS, respectively (Section 7.1). A full URI in absolute form is needed for the target URI, which means either the request target needs to be sent in absolute form or the target URI will be reconstructed from the request context in the same way it is for other methods.
同様に、新しい方法では、それぞれ接続とオプションに許可されているリクエストターゲットのポートとアスタリスクの特別なホストを使用できません（セクション7.1）。ターゲットURIには絶対形式の完全なURIが必要です。つまり、要求ターゲットを絶対形式で送信する必要があるか、ターゲットURIが他の方法と同じ方法でリクエストコンテキストから再構築されます。
A new method definition needs to indicate whether it is safe (Section 9.2.1), idempotent (Section 9.2.2), cacheable (Section 9.2.3), what semantics are to be associated with the request content (if any), and what refinements the method makes to header field or status code semantics. If the new method is cacheable, its definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy a subsequent request. The new method ought to describe whether it can be made conditional (Section 13.1) and, if so, how a server responds when the condition is false. Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too.
新しいメソッド定義では、安全である（セクション9.2.1）、iDempotent（セクション9.2.2）、キャッシュ可能（セクション9.2.3）、リクエストコンテンツに関連するセマンティクス（存在する場合）、およびメソッドがヘッダーフィールドまたはステータスコードセマンティクスに対して作成するもの。新しい方法がキャッシュ可能な場合、その定義は、どのように、どの条件下で、キャッシュが応答を保存し、それを使用してその後の要求を満たすことができるかを説明する必要があります。新しい方法では、条件付き（セクション13.1）にすることができるかどうか、およびもしそうなら、条件が誤っているときにサーバーがどのように応答するかを説明する必要があります。同様に、新しい方法が部分的な応答セマンティクスに何らかの使用（セクション14.2）に使用される可能性がある場合、これも文書化する必要があります。
| *Note:* Avoid defining a method name that starts with "M-",
| since that prefix might be misinterpreted as having the
| semantics assigned to it by [RFC2774].
The "Hypertext Transfer Protocol (HTTP) Status Code Registry", maintained by IANA at <https://www.iana.org/assignments/http-status-codes>, registers status code numbers.
IANAが<https://www.iana.org/assignments/http-status-codes>で維持した「ハイパーテキスト転送プロトコル（http）ステータスコードレジストリ」、ステータスコード番号をレジスタします。
A registration MUST include the following fields:
登録には、次のフィールドを含める必要があります。
* Status Code (3 digits)
* ステータスコード（3桁）
* Short Description
* 簡単な説明
* Pointer to specification text
* 仕様テキストへのポインタ
Values to be added to the HTTP status code namespace require IETF Review (see [RFC8126], Section 4.8).
HTTPステータスコード名空間に追加する値は、IETFレビューが必要です（[RFC8126]、セクション4.8を参照）。
When it is necessary to express semantics for a response that are not defined by current status codes, a new status code can be registered. Status codes are generic; they are potentially applicable to any resource, not just one particular media type, kind of resource, or application of HTTP. As such, it is preferred that new status codes be registered in a document that isn't specific to a single application.
現在のステータスコードで定義されていない応答のセマンティクスを表現する必要がある場合、新しいステータスコードを登録できます。ステータスコードは汎用です。これらは、特定のメディアタイプ、種類のリソース、またはHTTPのアプリケーションだけでなく、あらゆるリソースに適用できる可能性があります。そのため、新しいステータスコードを単一のアプリケーションに固有のドキュメントに登録することが推奨されます。
New status codes are required to fall under one of the categories defined in Section 15. To allow existing parsers to process the response message, new status codes cannot disallow content, although they can mandate a zero-length content.
新しいステータスコードは、セクション15で定義されているカテゴリのいずれかに該当するために必要です。既存のパーサーが応答メッセージを処理できるようにするために、新しいステータスコードはコンテンツを許可できませんが、ゼロレングスのコンテンツを義務付けることができます。
Proposals for new status codes that are not yet widely deployed ought to avoid allocating a specific number for the code until there is clear consensus that it will be registered; instead, early drafts can use a notation such as "4NN", or "3N0" .. "3N9", to indicate the class of the proposed status code(s) without consuming a number prematurely.
まだ広く展開されていない新しいステータスコードの提案は、登録されるという明確なコンセンサスが発生するまで、コードの特定の番号を割り当てることを避けるべきです。代わりに、初期のドラフトでは、「4NN」や「3N0」などの表記を使用して、提案されたステータスコードのクラスを時期尚早に消費せずに示すことができます。
The definition of a new status code ought to explain the request conditions that would cause a response containing that status code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields (e.g., what fields are required, what fields can modify the semantics, and what field semantics are further refined when used with the new status code).
新しいステータスコードの定義は、そのステータスコード（例：リクエストヘッダーフィールドおよび/またはメソッドの組み合わせ）を含む応答を引き起こすリクエスト条件を説明する必要があります。フィールドが必要です。どのフィールドがセマンティクスを変更できるか、および新しいステータスコードで使用するとさらに洗練されるフィールドセマンティクスがさらに洗練されます）。
By default, a status code applies only to the request corresponding to the response it occurs within. If a status code applies to a larger scope of applicability -- for example, all requests to the resource in question or all requests to a server -- this must be explicitly specified. When doing so, it should be noted that not all clients can be expected to consistently apply a larger scope because they might not understand the new status code.
デフォルトでは、ステータスコードは、内部で発生する応答に対応する要求にのみ適用されます。ステータスコードが適用可能性のより大きな範囲に適用される場合（たとえば、問題のリソースへのすべての要求またはサーバーへのすべての要求）、これを明示的に指定する必要があります。そうする場合、すべてのクライアントが新しいステータスコードを理解していない可能性があるため、より大きなスコープを一貫して適用することが期待できるわけではないことに注意する必要があります。
The definition of a new final status code ought to specify whether or not it is heuristically cacheable. Note that any response with a final status code can be cached if the response has explicit freshness information. A status code defined as heuristically cacheable is allowed to be cached without explicit freshness information. Likewise, the definition of a status code can place constraints upon cache behavior if the must-understand cache directive is used. See [CACHING] for more information.
新しい最終ステータスコードの定義は、ヒョウリズム的にキャッシュ可能かどうかを指定する必要があります。応答が明示的な新鮮さ情報を持っている場合、最終的なステータスコードを使用した応答は、キャッシュできることに注意してください。ヒューリスト的にキャッシュ可能であると定義されたステータスコードは、明示的な新鮮さ情報なしでキャッシュされることが許可されています。同様に、ステータスコードの定義は、必須のキャッシュ指令が使用されている場合、キャッシュ動作に制約を配置できます。詳細については、[キャッシュ]を参照してください。
Finally, the definition of a new status code ought to indicate whether the content has any implied association with an identified resource (Section 6.4.2).
最後に、新しいステータスコードの定義は、コンテンツに特定されたリソースと暗黙の関連性があるかどうかを示す必要があります（セクション6.4.2）。
HTTP's most widely used extensibility point is the definition of new header and trailer fields.
HTTPで最も広く使用されている拡張性ポイントは、新しいヘッダーとトレーラーフィールドの定義です。
New fields can be defined such that, when they are understood by a recipient, they override or enhance the interpretation of previously defined fields, define preconditions on request evaluation, or refine the meaning of responses.
新しいフィールドは、受信者が理解すると、以前に定義されたフィールドの解釈をオーバーライドまたは強化したり、リクエスト評価に応じて前提条件を定義したり、応答の意味を改善するように定義できます。
However, defining a field doesn't guarantee its deployment or recognition by recipients. Most fields are designed with the expectation that a recipient can safely ignore (but forward downstream) any field not recognized. In other cases, the sender's ability to understand a given field might be indicated by its prior communication, perhaps in the protocol version or fields that it sent in prior messages, or its use of a specific media type. Likewise, direct inspection of support might be possible through an OPTIONS request or by interacting with a defined well-known URI [RFC8615] if such inspection is defined along with the field being introduced.
ただし、フィールドを定義することは、受信者による展開または認識を保証するものではありません。ほとんどのフィールドは、受信者が認識されていないフィールドを安全に無視する（ただし、下流で前方に）無視できるという期待で設計されています。それ以外の場合、特定のフィールドを理解する送信者の能力は、おそらく以前のメッセージで送信したプロトコルバージョンまたはフィールド、または特定のメディアタイプの使用によって、以前の通信によって示される可能性があります。同様に、オプションリクエストを通じて、またはそのような検査が導入されているフィールドとともに定義されている場合、定義された有名URI [RFC8615]と対話することにより、サポートの直接検査が可能になる場合があります。
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines the namespace for HTTP field names.
「HyperText Transfer Protocol（HTTP）フィールド名レジストリ」は、HTTPフィールド名の名前空間を定義します。
Any party can request registration of an HTTP field. See Section 16.3.2 for considerations to take into account when creating a new HTTP field.
どんな当事者も、HTTPフィールドの登録を要求できます。新しいHTTPフィールドを作成する際に考慮すべき考慮事項については、セクション16.3.2を参照してください。
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is located at <https://www.iana.org/assignments/http-fields/>. Registration requests can be made by following the instructions located there or by sending an email to the "ietf-http-wg@w3.org" mailing list.
「HyperText Transfer Protocol（HTTP）フィールド名レジストリ」は、<https://www.iana.org/assignments/http-fields/>にあります。登録リクエストは、そこにある指示に従って、または「ietf-http-wg@w3.org」メーリングリストにメールを送信することで行うことができます。
Field names are registered on the advice of a designated expert (appointed by the IESG or their delegate). Fields with the status 'permanent' are Specification Required ([RFC8126], Section 4.6).
フィールド名は、指定された専門家（IESGまたはその代表者によって任命された）のアドバイスに登録されています。ステータス「永久」のフィールドが必要な仕様です（[RFC8126]、セクション4.6）。
Registration requests consist of the following information:
登録リクエストは、次の情報で構成されています。
Field name: The requested field name. It MUST conform to the field-name syntax defined in Section 5.1, and it SHOULD be restricted to just letters, digits, and hyphen ('-') characters, with the first character being a letter.
フィールド名：要求されたフィールド名。セクション5.1で定義されているフィールド名構文に準拠する必要があり、最初の文字は文字である文字、数字、およびハイフン（ ' - '）文字だけに制限する必要があります。
Status: "permanent", "provisional", "deprecated", or "obsoleted".
ステータス：「永続的」、「暫定」、「非推奨」、または「廃止」。
Specification document(s): Reference to the document that specifies the field, preferably including a URI that can be used to retrieve a copy of the document. Optional but encouraged for provisional registrations. An indication of the relevant section(s) can also be included, but is not required.
仕様文書：フィールドを指定するドキュメントへの参照、できればドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。オプションですが、暫定登録が奨励されています。関連するセクションの表示も含めることができますが、必要ありません。
And optionally:
そしてオプション：
Comments: Additional information, such as about reserved entries.
コメント：予約されたエントリに関する追加情報。
The expert(s) can define additional fields to be collected in the registry, in consultation with the community.
専門家は、コミュニティと相談して、レジストリで収集される追加のフィールドを定義できます。
Standards-defined names have a status of "permanent". Other names can also be registered as permanent if the expert(s) finds that they are in use, in consultation with the community. Other names should be registered as "provisional".
標準定義の名前には、「永久」のステータスがあります。コミュニティと協議して、専門家が使用中であることが判明した場合、他の名前は永続的に登録することもできます。他の名前は「仮」として登録する必要があります。
Provisional entries can be removed by the expert(s) if -- in consultation with the community -- the expert(s) find that they are not in use. The expert(s) can change a provisional entry's status to permanent at any time.
暫定的なエントリは、コミュニティと協議して、専門家が使用されていないことがある場合、専門家によって削除できます。専門家は、暫定的なエントリのステータスをいつでも永久に変更できます。
Note that names can be registered by third parties (including the expert(s)) if the expert(s) determines that an unregistered name is widely deployed and not likely to be registered in a timely manner otherwise.
専門家が未登録の名前が広く展開されており、それ以外の場合はタイムリーに登録される可能性が高いと判断した場合、名前は第三者（専門家を含む）が登録できることに注意してください。
HTTP header and trailer fields are a widely used extension point for the protocol. While they can be used in an ad hoc fashion, fields that are intended for wider use need to be carefully documented to ensure interoperability.
HTTPヘッダーとトレーラーフィールドは、プロトコルに広く使用されている拡張ポイントです。それらはアドホックな方法で使用できますが、より広範な使用を目的としたフィールドは、相互運用性を確保するために慎重に文書化する必要があります。
In particular, authors of specifications defining new fields are advised to consider and, where appropriate, document the following aspects:
特に、新しいフィールドを定義する仕様の著者は、次の側面を考慮し、必要に応じて文書化することをお勧めします。
* Under what conditions the field can be used; e.g., only in responses or requests, in all messages, only on responses to a particular request method, etc.
* どの条件下でフィールドを使用できるか。たとえば、応答または要求のみ、すべてのメッセージにおいて、特定のリクエスト方法への応答についてのみ。
* Whether the field semantics are further refined by their context, such as their use with certain request methods or status codes.
* 特定の要求方法やステータスコードでの使用など、フィールドセマンティクスがコンテキストによってさらに洗練されるかどうか。
* The scope of applicability for the information conveyed. By default, fields apply only to the message they are associated with, but some response fields are designed to apply to all representations of a resource, the resource itself, or an even broader scope. Specifications that expand the scope of a response field will need to carefully consider issues such as content negotiation, the time period of applicability, and (in some cases) multi-tenant server deployments.
* 伝えられた情報への適用性の範囲。デフォルトでは、フィールドは関連付けられているメッセージにのみ適用されますが、一部の応答フィールドは、リソース、リソース自体、またはさらに広い範囲のすべての表現に適用するように設計されています。応答フィールドの範囲を拡張する仕様は、コンテンツネゴシエーション、適用の期間、（場合によっては）マルチテナントサーバーの展開などの問題を慎重に検討する必要があります。
* Under what conditions intermediaries are allowed to insert, delete, or modify the field's value.
* どの条件下で、仲介者はフィールドの値を挿入、削除、または変更することが許可されています。
* If the field is allowable in trailers; by default, it will not be (see Section 6.5.1).
* フィールドがトレーラーで許容される場合。デフォルトでは、そうではありません（セクション6.5.1を参照）。
* Whether it is appropriate or even required to list the field name in the Connection header field (i.e., if the field is to be hop-by-hop; see Section 7.6.1).
* 接続ヘッダーフィールドにフィールド名をリストすることが適切かどうか（つまり、フィールドがホップバイホップである場合、セクション7.6.1を参照）。
* Whether the field introduces any additional security considerations, such as disclosure of privacy-related data.
* このフィールドが、プライバシー関連データの開示など、追加のセキュリティ上の考慮事項を導入するかどうか。
Request header fields have additional considerations that need to be documented if the default behavior is not appropriate:
リクエストヘッダーフィールドには、デフォルトの動作が適切でない場合に文書化する必要がある追加の考慮事項があります。
* If it is appropriate to list the field name in a Vary response header field (e.g., when the request header field is used by an origin server's content selection algorithm; see Section 12.5.5).
* さまざまな応答ヘッダーフィールドにフィールド名をリストすることが適切な場合（たとえば、リクエストヘッダーフィールドがOrigin Serverのコンテンツ選択アルゴリズムによって使用される場合、セクション12.5.5を参照）。
* If the field is intended to be stored when received in a PUT request (see Section 9.3.4).
* PUTリクエストで受信したときにフィールドを保存することを意図している場合（セクション9.3.4を参照）。
* If the field ought to be removed when automatically redirecting a request due to security concerns (see Section 15.4).
* セキュリティの懸念によりリクエストを自動的にリダイレクトするときにフィールドを削除する必要がある場合（セクション15.4を参照）。
Authors of specifications defining new fields are advised to choose a short but descriptive field name. Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on names that might have broader uses.
新しいフィールドを定義する仕様の著者は、短いが説明的なフィールド名を選択することをお勧めします。短い名前は不必要なデータ送信を避けます。説明的な名前は、より広い用途があるかもしれない名前の混乱や「しゃがむ」ことを避けます。
To that end, limited-use fields (such as a header confined to a single application or use case) are encouraged to use a name that includes that use (or an abbreviation) as a prefix; for example, if the Foo Application needs a Description field, it might use "Foo-Desc"; "Description" is too generic, and "Foo-Description" is needlessly long.
そのために、限られた使用フィールド（単一のアプリケーションまたはユースケースに限定されているヘッダーなど）は、その使用（または略語）をプレフィックスとして含む名前を使用することをお勧めします。たとえば、FOOアプリケーションに説明フィールドが必要な場合、「foo-desc」を使用する場合があります。「説明」はあまりにも一般的で、「foo-desscription」は不必要に長いです。
While the field-name syntax is defined to allow any token character, in practice some implementations place limits on the characters they accept in field-names. To be interoperable, new field names SHOULD constrain themselves to alphanumeric characters, "-", and ".", and SHOULD begin with a letter. For example, the underscore ("_") character can be problematic when passed through non-HTTP gateway interfaces (see Section 17.10).
フィールド名の構文は、トークン文字を許可するように定義されていますが、実際には、一部の実装は、フィールド名で受け入れる文字に制限を設けています。相互運用可能であるために、新しいフィールド名は英数字の文字「 - 」に自分自身を制約する必要があります。たとえば、非HTTPゲートウェイインターフェイスを通過すると、アンダースコア（ "_"）文字に問題があります（セクション17.10を参照）。
Field names ought not be prefixed with "X-"; see [BCP178] for further information.
フィールド名に「x-」が付いていないはずです。詳細については、[BCP178]を参照してください。
Other prefixes are sometimes used in HTTP field names; for example, "Accept-" is used in many content negotiation headers, and "Content-" is used as explained in Section 6.4. These prefixes are only an aid to recognizing the purpose of a field and do not trigger automatic processing.
他のプレフィックスは、HTTPフィールド名で使用されることがあります。たとえば、「Accept-」は多くのコンテンツネゴシエーションヘッダーで使用され、「コンテンツ」はセクション6.4で説明されているように使用されます。これらの接頭辞は、フィールドの目的を認識するための支援にすぎず、自動処理をトリガーしません。
A major task in the definition of a new HTTP field is the specification of the field value syntax: what senders should generate, and how recipients should infer semantics from what is received.
新しいHTTPフィールドの定義における主要なタスクは、フィールド値の構文の仕様です。送信者が生成すべきもの、および受信者が受信したものからセマンティクスを推測する方法です。
Authors are encouraged (but not required) to use either the ABNF rules in this specification or those in [RFC8941] to define the syntax of new field values.
著者は、この仕様のABNFルールまたは[RFC8941]のABNFルールを使用して、新しいフィールド値の構文を定義することを奨励されています（必要ありません）。
Authors are advised to carefully consider how the combination of multiple field lines will impact them (see Section 5.3). Because senders might erroneously send multiple values, and both intermediaries and HTTP libraries can perform combination automatically, this applies to all field values -- even when only a single value is anticipated.
著者は、複数のフィールドラインの組み合わせがどのように影響するかを慎重に検討することをお勧めします（セクション5.3を参照）。送信者は複数の値を誤って送信する可能性があり、仲介者とHTTPライブラリの両方が自動的に組み合わせを実行できるため、これはすべてのフィールド値に適用されます - 単一の値のみが予想される場合でも。
Therefore, authors are advised to delimit or encode values that contain commas (e.g., with the quoted-string rule of Section 5.6.4, the String data type of [RFC8941], or a field-specific encoding). This ensures that commas within field data are not confused with the commas that delimit a list value.
したがって、著者は、コンマを含む値を区切るか、エンコードすることをお勧めします（たとえば、セクション5.6.4の引用されたストリングルール、[RFC8941]の文字列データ型、またはフィールド固有のエンコーディング）。これにより、フィールドデータ内のコンマがリスト値を区切るコンマと混同しないようにします。
For example, the Content-Type field value only allows commas inside quoted strings, which can be reliably parsed even when multiple values are present. The Location field value provides a counter-example that should not be emulated: because URIs can include commas, it is not possible to reliably distinguish between a single value that includes a comma from two values.
たとえば、コンテンツタイプのフィールド値では、引用符で囲まれた文字列内のコンマのみが許可されます。これは、複数の値が存在する場合でも確実に解析できます。位置フィールド値は、エミュレートすべきではないカウンターエクサムを提供します。URISはコンマを含めることができるため、2つの値からコンマを含む単一の値を確実に区別することはできません。
Authors of fields with a singleton value (see Section 5.5) are additionally advised to document how to treat messages where the multiple members are present (a sensible default would be to ignore the field, but this might not always be the right choice).
Singleton Value（セクション5.5を参照）を持つFieldsの著者は、複数のメンバーが存在する場所でメッセージを扱う方法を文書化することをお勧めします（賢明なデフォルトはフィールドを無視することですが、これは必ずしも正しい選択ではないかもしれません）。
The "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defines the namespace for the authentication schemes in challenges and credentials. It is maintained at <https://www.iana.org/assignments/http-authschemes>.
「HyperText Transfer Protocol（HTTP）認証スキームレジストリ」は、課題と資格情報の認証スキームの名前空間を定義します。<https://www.iana.org/assignments/http-authschemes>に維持されています。
Registrations MUST include the following fields:
登録には、次のフィールドを含める必要があります。
* Authentication Scheme Name
* 認証スキーム名
* Pointer to specification text
* 仕様テキストへのポインタ
* Notes (optional)
* メモ（オプション）
Values to be added to this namespace require IETF Review (see [RFC8126], Section 4.8).
この名前空間に追加する値には、IETFレビューが必要です（[RFC8126]、セクション4.8を参照）。
There are certain aspects of the HTTP Authentication framework that put constraints on how new authentication schemes can work:
HTTP認証フレームワークには、新しい認証スキームがどのように機能するかに制約をかける特定の側面があります。
* HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken to ensure that the connection cannot be used by any party other than the authenticated user (see Section 3.3).
* HTTP認証は、ステートレスであると推定されます。リクエストを認証するために必要なすべての情報は、以前のリクエストを覚えているサーバーに依存するのではなく、リクエストで提供される必要があります。基礎となる接続に基づいて、または拘束された認証は、この仕様の範囲外であり、認証されたユーザー以外の当事者が接続を使用できないことを確認するための手順が取られない限り、本質的に欠陥があります（セクション3.3を参照）。
* The authentication parameter "realm" is reserved for defining protection spaces as described in Section 11.5. New schemes MUST NOT use it in a way incompatible with that definition.
* 認証パラメーター「Realm」は、セクション11.5で説明されているように保護空間を定義するために予約されています。新しいスキームは、その定義と互換性のない方法でそれを使用してはなりません。
* The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per challenge or credential. Thus, new schemes ought to use the auth-param syntax instead, because otherwise future extensions will be impossible.
* 「token68」表記は、既存の認証スキームとの互換性のために導入され、チャレンジまたは資格情報ごとに1回しか使用できません。したがって、新しいスキームは代わりにAuth-Param構文を使用する必要があります。
* The parsing of challenges and credentials is defined by this specification and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes.
* 課題と資格情報の解析は、この仕様によって定義され、新しい認証スキームでは変更できません。Auth-Paramの構文を使用する場合、すべてのパラメーターはトークンと引用のストリング構文の両方をサポートする必要があり、解析後（つまり、引用されたストリング処理）後のフィールド値で構文的な制約を定義する必要があります。これは、受信者がすべての認証スキームに適用される汎用パーサーを使用できるようにする必要があります。
*Note:* The fact that the value syntax for the "realm" parameter is restricted to quoted-string was a bad design choice not to be repeated for new parameters.
*注：*「Realm」パラメーターの値構文が引用されたストリングに制限されているという事実は、新しいパラメーターに対して繰り返されないという悪い設計の選択でした。
* Definitions of new schemes ought to define the treatment of unknown extension parameters. In general, a "must-ignore" rule is preferable to a "must-understand" rule, because otherwise it will be hard to introduce new parameters in the presence of legacy recipients. Furthermore, it's good to describe the policy for defining new parameters (such as "update the specification" or "use this registry").
* 新しいスキームの定義は、未知の拡張パラメーターの処理を定義する必要があります。一般に、「必須の」ルールは、「必見」ルールよりも好ましいです。そうしないと、レガシー受信者の存在下で新しいパラメーターを導入するのは難しいからです。さらに、新しいパラメーターを定義するためのポリシー（「仕様の更新」や「このレジストリの使用」など）を説明することは良いことです。
* Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate), and/ or proxy authentication (i.e., using Proxy-Authenticate).
* 認証スキームは、Origin-Server認証（すなわち、www-authenticateを使用）および/またはプロキシ認証（つまり、プロキシ - authenticateを使用）で使用できるかどうかを文書化する必要があります。
* The credentials carried in an Authorization header field are specific to the user agent and, therefore, have the same effect on HTTP caches as the "private" cache response directive (Section 5.2.2.7 of [CACHING]), within the scope of the request in which they appear.
* 承認ヘッダーフィールドに搭載されている資格情報はユーザーエージェントに固有であるため、リクエストの範囲内で、「プライベート」キャッシュ応答指令（[キャッシュ]のセクション5.2.2.7）と同じ効果があります。それらが現れる。
Therefore, new authentication schemes that choose not to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of cache response directives (e.g., "private").
したがって、認証ヘッダーフィールド（たとえば、新たに定義されたヘッダーフィールドを使用するなど）に資格情報を運ばないことを選択する新しい認証スキームは、キャッシュ応答ディレクティブ（例：「プライベート」）の使用を義務付けることにより、キャッシュを明示的に禁止する必要があります。
* Schemes using Authentication-Info, Proxy-Authentication-Info, or any other authentication related response header field need to consider and document the related security considerations (see Section 17.16.4).
* Authentication-INFO、Proxy-Authentication-INFO、またはその他の認証関連の応答ヘッダーフィールドを使用したスキームは、関連するセキュリティに関する考慮事項を考慮して文書化する必要があります（セクション17.16.4を参照）。
The "HTTP Range Unit Registry" defines the namespace for the range unit names and refers to their corresponding specifications. It is maintained at <https://www.iana.org/assignments/http-parameters>.
「HTTPレンジユニットレジストリ」は、範囲ユニット名の名前空間を定義し、対応する仕様を参照します。<https://www.iana.org/assignments/http-parameters>に維持されています。
Registration of an HTTP Range Unit MUST include the following fields:
HTTPレンジユニットの登録には、次のフィールドを含める必要があります。
* Name
* 名前
* Description
* 説明
* Pointer to specification text
* 仕様テキストへのポインタ
Values to be added to this namespace require IETF Review (see [RFC8126], Section 4.8).
この名前空間に追加する値には、IETFレビューが必要です（[RFC8126]、セクション4.8を参照）。
Other range units, such as format-specific boundaries like pages, sections, records, rows, or time, are potentially usable in HTTP for application-specific purposes, but are not commonly used in practice. Implementors of alternative range units ought to consider how they would work with content codings and general-purpose intermediaries.
ページ、セクション、レコード、行、または時間などの形式固有の境界などの他の範囲ユニットは、アプリケーション固有の目的でHTTPで使用可能ですが、実際には一般的には使用されていません。代替レンジユニットの実装者は、コンテンツのコーディングと汎用仲介業者をどのように操作するかを検討する必要があります。
The "HTTP Content Coding Registry", maintained by IANA at <https://www.iana.org/assignments/http-parameters/>, registers content-coding names.
IANAが<https://www.iana.org/assignments/http-parameters/>で維持している「HTTPコンテンツコーディングレジストリ」は、コンテンツコーディング名を登録します。
Content coding registrations MUST include the following fields:
コンテンツコーディング登録には、次のフィールドを含める必要があります。
* Name
* 名前
* Description
* 説明
* Pointer to specification text
* 仕様テキストへのポインタ
Names of content codings MUST NOT overlap with names of transfer codings (per the "HTTP Transfer Coding Registry" located at <https://www.iana.org/assignments/http-parameters/>) unless the encoding transformation is identical (as is the case for the compression codings defined in Section 8.4.1).
コンテンツコードの名前は、転送コーディングの名前と重複してはいけません（<https://www.iana.org/assignments/http-parameters/>にある「http転送コーディングレジストリ」に従って）エンコード変換が同一でない限り（セクション8.4.1で定義されている圧縮コーディングの場合です。
Values to be added to this namespace require IETF Review (see Section 4.8 of [RFC8126]) and MUST conform to the purpose of content coding defined in Section 8.4.1.
この名前空間に追加する値は、IETFレビューが必要であり（[RFC8126]のセクション4.8を参照）、セクション8.4.1で定義されたコンテンツコーディングの目的に準拠する必要があります。
New content codings ought to be self-descriptive whenever possible, with optional parameters discoverable within the coding format itself, rather than rely on external metadata that might be lost during transit.
新しいコンテンツコーディングは、可能な限り自己記述的である必要があります。オプションのパラメーターは、通過中に失われる可能性のある外部メタデータに依存するのではなく、コーディング形式自体で発見できます。
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" defines the namespace for protocol-name tokens used to identify protocols in the Upgrade header field. The registry is maintained at <https://www.iana.org/assignments/http-upgrade-tokens>.
「HyperText Transfer Protocol（HTTP）アップグレードトークンレジストリ」は、アップグレードヘッダーフィールドのプロトコルを識別するために使用されるプロトコル名のトークンの名前空間を定義します。レジストリは、<https://www.iana.org/assignments/http-upgrade-tokens>に維持されています。
Each registered protocol name is associated with contact information and an optional set of specifications that details how the connection will be processed after it has been upgraded.
登録された各プロトコル名は、連絡先情報と、アップグレード後に接続の処理方法を詳述するオプションの仕様セットに関連付けられています。
Registrations happen on a "First Come First Served" basis (see Section 4.4 of [RFC8126]) and are subject to the following rules:
登録は「最初に来る」ベース（[RFC8126]のセクション4.4を参照）で行われ、次の規則の対象となります。
1. A protocol-name token, once registered, stays registered forever.
1. 一度登録されると、プロトコル名のトークンは永遠に登録されたままです。
2. A protocol-name token is case-insensitive and registered with the preferred case to be generated by senders.
2. プロトコル名のトークンはケースではなく、送信者が生成する優先ケースに登録されています。
3. The registration MUST name a responsible party for the registration.
3. 登録は、登録の責任者に名前を付ける必要があります。
4. The registration MUST name a point of contact.
4. 登録は、連絡先に名前を付ける必要があります。
5. The registration MAY name a set of specifications associated with that token. Such specifications need not be publicly available.
5. 登録は、そのトークンに関連付けられた一連の仕様に名前を付けることができます。このような仕様は、公開される必要はありません。
6. The registration SHOULD name a set of expected "protocol-version" tokens associated with that token at the time of registration.
6. 登録は、登録時にそのトークンに関連付けられた予想される「プロトコルバージョン」トークンのセットに名前を付ける必要があります。
7. The responsible party MAY change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
7. 責任者はいつでも登録を変更する場合があります。IANAは、そのような変更のすべての記録を保持し、リクエストに応じてそれらを利用できるようにします。
8. The IESG MAY reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot be contacted.
8. IESGは、プロトコルトークンの責任を再割り当てする場合があります。これは通常、責任者に連絡できない場合にのみ使用されます。
This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP semantics and its use for transferring information over the Internet. Considerations related to caching are discussed in Section 7 of [CACHING], and considerations related to HTTP/1.1 message syntax and parsing are discussed in Section 11 of [HTTP/1.1].
このセクションは、HTTPセマンティクスに関連する既知のセキュリティ懸念の開発者、情報提供者、およびインターネットを介して情報を転送するための使用に関連する既知のセキュリティ上の懸念事項を通知することを目的としています。キャッシュに関連する考慮事項は[キャッシュ]のセクション7で説明されており、HTTP/1.1メッセージの構文と解析に関連する考慮事項については、[HTTP/1.1]のセクション11で説明します。
The list of considerations below is not exhaustive. Most security concerns related to HTTP semantics are about securing server-side applications (code behind the HTTP interface), securing user agent processing of content received via HTTP, or secure use of the Internet in general, rather than security of the protocol. The security considerations for URIs, which are fundamental to HTTP operation, are discussed in Section 7 of [URI]. Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]).
以下の考慮事項のリストは網羅的ではありません。HTTPセマンティクスに関連するほとんどのセキュリティ上の懸念は、サーバー側のアプリケーション（HTTPインターフェイスの背後にあるコード）を保護すること、HTTPを介して受信したコンテンツのユーザーエージェント処理の保護、またはプロトコルのセキュリティではなく、インターネットの一般的な使用を確保することです。HTTP操作の基本であるURISのセキュリティ上の考慮事項については、[URI]のセクション7で説明しています。さまざまな組織が、Webアプリケーションのセキュリティに関する現在の研究（[OWASP]）に関する現在の研究へのリンクを維持しています。
HTTP relies on the notion of an "authoritative response": a response that has been determined by (or at the direction of) the origin server identified within the target URI to be the most appropriate response for that request given the state of the target resource at the time of response message origination.
HTTPは、「権威ある応答」の概念に依存しています。ターゲットURI内で識別されたオリジンサーバーによって決定された（または方向）、ターゲットリソースの状態を考慮してその要求の最も適切な応答であると識別された（または方向）。応答メッセージの起源の時点。
When a registered name is used in the authority component, the "http" URI scheme (Section 4.2.1) relies on the user's local name resolution service to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs. Likewise, the user's choice of server for Domain Name Service (DNS), and the hierarchy of servers from which it obtains resolution results, could impact the authenticity of address mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to improve authenticity, as are the various mechanisms for making DNS requests over more secure transfer protocols.
登録名が機関コンポーネントで使用される場合、「HTTP」URIスキーム（セクション4.2.1）は、ユーザーのローカル名解決サービスに依存して、権威ある応答を見つけることができる場所を決定します。これは、ユーザーのネットワークホストテーブル、キャッシュ名、または名前解像度ライブラリへの攻撃が、「HTTP」URIの権限を確立するための攻撃の道になることを意味します。同様に、ユーザーがドメイン名サービス（DNS）のサーバーの選択、および解像度結果を取得するサーバーの階層は、アドレスマッピングの信頼性に影響を与える可能性があります。DNSセキュリティ拡張機能（DNSSEC、[RFC4033]）は、より安全な転送プロトコルでDNS要求を作成するためのさまざまなメカニズムと同様に、信頼性を向上させる1つの方法です。
Furthermore, after an IP address is obtained, establishing authority for an "http" URI is vulnerable to attacks on Internet Protocol routing.
さらに、IPアドレスが取得された後、「HTTP」URIの権限を確立することは、インターネットプロトコルルーティングに対する攻撃に対して脆弱です。
The "https" scheme (Section 4.2.2) is intended to prevent (or at least reveal) many of these potential attacks on establishing authority, provided that the negotiated connection is secured and the client properly verifies that the communicating server's identity matches the target URI's authority component (Section 4.3.4). Correctly implementing such verification can be difficult (see [Georgiev]).
「HTTPS」スキーム（セクション4.2.2）は、交渉された接続が確保され、クライアントが通信サーバーのIDがターゲットと一致することをクライアントが適切に検証している場合、当局の確立に対するこれらの潜在的な攻撃の多くを防止する（または少なくとも明らかにする）ことを目的としています。URIの権限コンポーネント（セクション4.3.4）。このような検証を正しく実装することは難しい場合があります（[Georgiev]を参照）。
Authority for a given origin server can be delegated through protocol extensions; for example, [ALTSVC]. Likewise, the set of servers for which a connection is considered authoritative can be changed with a protocol extension like [RFC8336].
特定のOrigin Serverの権限は、プロトコル拡張を通じて委任できます。たとえば、[altsvc]。同様に、[RFC8336]のようなプロトコル拡張機能で、接続が権威あると見なされるサーバーのセットを変更できます。
Providing a response from a non-authoritative source, such as a shared proxy cache, is often useful to improve performance and availability, but only to the extent that the source can be trusted or the distrusted response can be safely used.
共有プロキシキャッシュなどの非認証ソースからの応答を提供することは、パフォーマンスと可用性を改善するのに役立つことがよくありますが、ソースを信頼できるか、不信感のある応答を安全に使用できる範囲でのみ役立ちます。
Unfortunately, communicating authority to users can be difficult. For example, "phishing" is an attack on the user's perception of authority, where that perception can be misled by presenting similar branding in hypertext, possibly aided by userinfo obfuscating the authority component (see Section 4.2.1). User agents can reduce the impact of phishing attacks by enabling users to easily inspect a target URI prior to making an action, by prominently distinguishing (or rejecting) userinfo when present, and by not sending stored credentials and cookies when the referring document is from an unknown or untrusted source.
残念ながら、ユーザーに権限を伝えることは難しい場合があります。たとえば、「フィッシング」とは、ユーザーの権限の認識に対する攻撃であり、その認識は、userinfoが権限コンポーネントを困らせることによって支援された可能性がある、ハイパーテキストで同様のブランディングを提示することで誤解される可能性があります（セクション4.2.1を参照）。ユーザーエージェントは、ユーザーがアクションを行う前にターゲットURIを簡単に検査できるようにし、存在するときにuserInfoを顕著に区別（または拒否する）し、紹介文書が紹介されたドキュメントがからのものである場合に保存された資格情報とCookieを送信しないことにより、フィッシング攻撃の影響を減らすことができます。不明または信頼されていないソース。
HTTP intermediaries are inherently situated for on-path attacks. Compromise of the systems on which the intermediaries run can result in serious security and privacy problems. Intermediaries might have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers. A compromised intermediary, or an intermediary implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.
HTTP仲介者は、本質的にパス攻撃のために位置しています。仲介者が実行するシステムの妥協は、深刻なセキュリティとプライバシーの問題をもたらす可能性があります。仲介者は、セキュリティ関連の情報、個々のユーザーと組織に関する個人情報、およびユーザーやコンテンツプロバイダーに属する独自の情報にアクセスできる場合があります。侵害された仲介者、またはセキュリティとプライバシーの考慮事項に関係なく実装または構成された仲介者は、幅広い潜在的な攻撃の手数料で使用される場合があります。
Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks, as described in Section 7 of [CACHING].
[キャッシュ]のセクション7で説明されているように、共有キャッシュを含む仲介者は、特にキャッシュ中毒攻撃に対して脆弱です。
Implementers need to consider the privacy and security implications of their design and coding decisions, and of the configuration options they provide to operators (especially the default configuration).
実装者は、設計とコーディングの決定、およびオペレーターに提供する構成オプション（特にデフォルトの構成）のプライバシーとセキュリティの意味を考慮する必要があります。
Intermediaries are no more trustworthy than the people and policies under which they operate; HTTP cannot solve this problem.
仲介者は、彼らが運営する人々や政策よりも信頼できるものではありません。HTTPはこの問題を解決できません。
Origin servers frequently make use of their local file system to manage the mapping from target URI to resource representations. Most file systems are not designed to protect against malicious file or path names. Therefore, an origin server needs to avoid accessing names that have a special significance to the system when mapping the target resource to files, folders, or directories.
Origin Serverは、ターゲットURIからリソース表現までのマッピングを管理するために、ローカルファイルシステムを頻繁に使用します。ほとんどのファイルシステムは、悪意のあるファイル名またはパス名から保護するように設計されていません。したがって、Origin Serverは、ターゲットリソースをファイル、フォルダー、またはディレクトリにマッピングする際に、システムに特に重要な名前にアクセスすることを避ける必要があります。
For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one, and they use specially named paths or file names to send data to system devices. Similar naming conventions might exist within other types of storage systems. Likewise, local storage systems have an annoying tendency to prefer user-friendliness over security when handling invalid or unexpected characters, recomposition of decomposed characters, and case-normalization of case-insensitive names.
たとえば、UNIX、Microsoft Windows、およびその他のオペレーティングシステムは、「..」をパスコンポーネントとして使用して、現在のレベルよりもディレクトリレベルを示すパスコンポーネントとして使用し、特別に名前が付けられたパスまたはファイル名を使用してシステムデバイスにデータを送信します。同様の命名規則は、他のタイプのストレージシステム内に存在する可能性があります。同様に、ローカルストレージシステムは、無効または予期しない文字を処理する際にセキュリティよりもユーザーフレンドリーを好む迷惑な傾向があり、分解された文字の再構成、およびケース非感受性名のケース正規化があります。
Attacks based on such special names tend to focus on either denial-of-service (e.g., telling the server to read from a COM port) or disclosure of configuration and source files that are not meant to be served.
このような特別な名前に基づく攻撃は、サービスの拒否（たとえば、サーバーにcomポートから読み取るように指示する）または、提供されていない構成ファイルとソースファイルの開示のいずれかに焦点を当てる傾向があります。
Origin servers often use parameters within the URI as a means of identifying system services, selecting database entries, or choosing a data source. However, data received in a request cannot be trusted. An attacker could construct any of the request data elements (method, target URI, header fields, or content) to contain data that might be misinterpreted as a command, code, or query when passed through a command invocation, language interpreter, or database interface.
Origin Serverは、多くの場合、システムサービスを識別し、データベースエントリを選択する、またはデータソースの選択を識別する手段としてURI内のパラメーターを使用します。ただし、リクエストで受信したデータは信頼できません。攻撃者は、コマンドの呼び出し、言語通訳、またはデータベースインターフェイスを通過したときにコマンド、コード、またはクエリとして誤って解釈される可能性のあるデータを含めるために、要求データ要素（メソッド、ターゲットURI、ヘッダーフィールド、またはコンテンツ）のいずれかを構築できます。。
For example, SQL injection is a common attack wherein additional query language is inserted within some part of the target URI or header fields (e.g., Host, Referer, etc.). If the received data is used directly within a SELECT statement, the query language might be interpreted as a database command instead of a simple string value. This type of implementation vulnerability is extremely common, in spite of being easy to prevent.
たとえば、SQLインジェクションは、ターゲットURIまたはヘッダーフィールド（ホスト、参照など）の一部に追加のクエリ言語が挿入される一般的な攻撃です。受信したデータがSELECTステートメント内で直接使用される場合、クエリ言語は単純な文字列値の代わりにデータベースコマンドとして解釈される場合があります。このタイプの実装の脆弱性は、予防しやすいにもかかわらず、非常に一般的です。
In general, resource implementations ought to avoid use of request data in contexts that are processed or interpreted as instructions. Parameters ought to be compared to fixed strings and acted upon as a result of that comparison, rather than passed through an interface that is not prepared for untrusted data. Received data that isn't based on fixed parameters ought to be carefully filtered or encoded to avoid being misinterpreted.
一般に、リソースの実装は、指示として処理または解釈されるコンテキストでのリクエストデータの使用を避ける必要があります。パラメーターは、固定された文字列と比較され、信頼されていないデータ用に準備されていないインターフェイスを通過するのではなく、その比較の結果として作用する必要があります。固定パラメーターに基づいていない受信したデータは、誤って解釈されないように、慎重にフィルタリングまたはエンコードする必要があります。
Similar considerations apply to request data when it is stored and later processed, such as within log files, monitoring tools, or when included within a data format that allows embedded scripts.
同様の考慮事項は、ログファイル内、監視ツール、または組み込みスクリプトを許可するデータ形式に含まれるなど、保存されて後で処理された場合にデータを要求することに適用されます。
Because HTTP uses mostly textual, character-delimited fields, parsers are often vulnerable to attacks based on sending very long (or very slow) streams of data, particularly where an implementation is expecting a protocol element with no predefined length (Section 2.3).
HTTPはほとんどテキストで文字格化されたフィールドを使用するため、特に実装が事前定義された長さのないプロトコル要素を期待している場合、パーサーは非常に長い（または非常に遅い）データのストリームを送信することに基づいて攻撃に対して脆弱です（セクション2.3）。
To promote interoperability, specific recommendations are made for minimum size limits on fields (Section 5.4). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected that most implementations will choose substantially higher limits.
相互運用性を促進するために、フィールドの最小サイズ制限に対して特定の推奨事項が作成されます（セクション5.4）。これらは最小限の推奨事項であり、リソースが限られている実装でもサポートできるように選択されます。ほとんどの実装は、大幅に高い制限を選択することが期待されています。
A server can reject a message that has a target URI that is too long (Section 15.5.15) or request content that is too large (Section 15.5.14). Additional status codes related to capacity limits have been defined by extensions to HTTP [RFC6585].
サーバーは、長すぎるターゲットURI（セクション15.5.15）または大きすぎるコンテンツ（セクション15.5.14）を要求するメッセージを拒否できます。容量制限に関連する追加のステータスコードは、HTTP [RFC6585]への拡張によって定義されています。
Recipients ought to carefully limit the extent to which they process other protocol elements, including (but not limited to) request methods, response status phrases, field names, numeric values, and chunk lengths. Failure to limit such processing can result in arbitrary code execution due to buffer or arithmetic overflows, and increased vulnerability to denial-of-service attacks.
受信者は、要求方法、応答ステータスフレーズ、フィールド名、数値、およびチャンク長を含む（ただし限定的ではない）他のプロトコル要素を処理する範囲を慎重に制限する必要があります。そのような処理を制限しないと、バッファーまたは算術的なオーバーフローによる任意のコード実行、およびサービス拒否攻撃に対する脆弱性が増加する可能性があります。
Some attacks on encrypted protocols use the differences in size created by dynamic compression to reveal confidential information; for example, [BREACH]. These attacks rely on creating a redundancy between attacker-controlled content and the confidential information, such that a dynamic compression algorithm using the same dictionary for both content will compress more efficiently when the attacker-controlled content matches parts of the confidential content.
暗号化されたプロトコルに対する一部の攻撃では、動的圧縮によって作成されたサイズの違いを使用して、機密情報を明らかにします。たとえば、[違反]。これらの攻撃は、攻撃者が制御するコンテンツと機密情報との間に冗長性を作成することに依存しているため、両方のコンテンツに同じ辞書を使用する動的圧縮アルゴリズムは、攻撃者が制御するコンテンツが機密コンテンツの一部と一致するとより効率的に圧縮されます。
HTTP messages can be compressed in a number of ways, including using TLS compression, content codings, transfer codings, and other extension or version-specific mechanisms.
HTTPメッセージは、TLS圧縮、コンテンツコーディング、転送コーディング、その他の拡張機能またはバージョン固有のメカニズムの使用など、さまざまな方法で圧縮できます。
The most effective mitigation for this risk is to disable compression on sensitive data, or to strictly separate sensitive data from attacker-controlled data so that they cannot share the same compression dictionary. With careful design, a compression scheme can be designed in a way that is not considered exploitable in limited use cases, such as HPACK ([HPACK]).
このリスクの最も効果的な緩和は、機密データの圧縮を無効にするか、同じ圧縮辞書を共有できないように攻撃者が制御するデータから厳密に分離することです。慎重な設計では、HPACK（[HPACK]）などの限られたユースケースでは搾取可能とは見なされない方法で圧縮スキームを設計できます。
Clients are often privy to large amounts of personal information, including both information provided by the user to interact with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information about the user's browsing activity over time (e.g., history, bookmarks, etc.). Implementations need to prevent unintentional disclosure of personal information.
クライアントは、多くの場合、リソース（ユーザーの名前、場所、メールアドレス、パスワード、暗号化キーなど）と対話するためにユーザーが提供する情報と、ユーザーの閲覧アクティビティに関する情報に関する情報の両方を含む、大量の個人情報を知っています。時間（例：履歴、ブックマークなど）。実装は、個人情報の意図しない開示を防ぐ必要があります。
A server is in the position to save personal data about a user's requests over time, which might identify their reading patterns or subjects of interest. In particular, log information gathered at an intermediary often contains a history of user agent interaction, across a multitude of sites, that can be traced to individual users.
サーバーは、ユーザーの要求に関する個人データを時間の経過とともに保存する立場にあります。特に、仲介者に収集されたログ情報には、多くのサイトでユーザーエージェントの相互作用の履歴が含まれており、個々のユーザーにトレースされる可能性があります。
HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within individual entries helps, but it is generally not sufficient to prevent real log traces from being re-identified based on correlation with other access characteristics. As such, access traces that are keyed to a specific client are unsafe to publish even if the key is pseudonymous.
HTTPログ情報は自然界で機密です。その取り扱いは、多くの場合、法律や規制によって制約されます。ログ情報は安全に保存され、その分析のために適切なガイドラインに従う必要があります。個々のエントリ内の個人情報の匿名化は役立ちますが、一般に、他のアクセス特性との相関に基づいて実際のログトレースが再識別されるのを防ぐのに十分ではありません。そのため、特定のクライアントに鍵をかけているアクセストレースは、キーが仮名であっても公開するのに安全ではありません。
To minimize the risk of theft or accidental publication, log information ought to be purged of personally identifiable information, including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary to support operational needs for security, auditing, or fraud control.
盗難や偶発的な公開のリスクを最小限に抑えるために、ログ情報は、ユーザー識別子、IPアドレス、ユーザーが提供するクエリパラメーターを含む個人的に識別可能な情報を削除する必要があります。、監査、または詐欺管理。
URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added to templates when a page is printed, and stored in a variety of unprotected bookmark lists. Many servers, proxies, and user agents log or display the target URI in places where it might be visible to third parties. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose.
URIは、安全なリソースを特定したとしても、保護されていない共有されることを目的としています。ウリはディスプレイに表示され、ページが印刷されたときにテンプレートに追加され、さまざまな保護されていないブックマークリストに保存されます。多くのサーバー、プロキシ、およびユーザーエージェントは、サードパーティに表示される可能性のある場所でターゲットURIをログまたは表示または表示します。したがって、URI内に敏感な、個人的に識別可能な、または開示するリスクを含む情報を含めることは賢明ではありません。
When an application uses client-side mechanisms to construct a target URI out of user-provided information, such as the query fields of a form using GET, potentially sensitive data might be provided that would not be appropriate for disclosure within a URI. POST is often preferred in such cases because it usually doesn't construct a URI; instead, POST of a form transmits the potentially sensitive data in the request content. However, this hinders caching and uses an unsafe method for what would otherwise be a safe request. Alternative workarounds include transforming the user-provided data prior to constructing the URI or filtering the data to only include common values that are not sensitive. Likewise, redirecting the result of a query to a different (server-generated) URI can remove potentially sensitive data from later links and provide a cacheable response for later reuse.
アプリケーションがクライアント側のメカニズムを使用して、GETを使用してフォームのクエリフィールドなど、ユーザーが提供する情報からターゲットURIを構築する場合、URI内の開示には適していない潜在的に機密データが提供される場合があります。通常、URIを構築しないため、そのような場合には投稿が好まれます。代わりに、フォームの投稿は、リクエストコンテンツに潜在的に機密性の高いデータを送信します。ただし、これによりキャッシュが妨げられ、安全なリクエストとなるために安全でない方法を使用します。代替の回避策には、URIを構築する前にユーザーが提供するデータを変換するか、データをフィルタリングして、感度のない共通値のみを含めるように含まれます。同様に、クエリの結果を別の（サーバーで生成した）URIにリダイレクトすると、潜在的に機密性の高いデータを後のリンクから削除し、後の再利用のためのキャッシュ可能な応答を提供できます。
Since the Referer header field tells a target site about the context that resulted in a request, it has the potential to reveal information about the user's immediate browsing history and any personal information that might be found in the referring resource's URI. Limitations on the Referer header field are described in Section 10.1.3 to address some of its security considerations.
参照ヘッダーフィールドは、リクエストをもたらしたコンテキストについてターゲットサイトに伝えているため、ユーザーの即時閲覧履歴に関する情報と、参照リソースのURIにある個人情報を明らかにする可能性があります。参照ヘッダーフィールドの制限については、セクション10.1.3で説明して、セキュリティ上の考慮事項の一部に対処します。
Servers often use non-HTTP gateway interfaces and frameworks to process a received request and produce content for the response. For historical reasons, such interfaces often pass received field names as external variable names, using a name mapping suitable for environment variables.
サーバーは、多くの場合、非HTTPゲートウェイインターフェイスとフレームワークを使用して、受信した要求を処理し、応答用のコンテンツを作成します。歴史的な理由から、そのようなインターフェイスは、環境変数に適した名前のマッピングを使用して、受信したフィールド名を外部変数名として渡すことがよくあります。
For example, the Common Gateway Interface (CGI) mapping of protocol-specific meta-variables, defined by Section 4.1.18 of [RFC3875], is applied to received header fields that do not correspond to one of CGI's standard variables; the mapping consists of prepending "HTTP_" to each name and changing all instances of hyphen ("-") to underscore ("_"). This same mapping has been inherited by many other application frameworks in order to simplify moving applications from one platform to the next.
たとえば、[RFC3875]のセクション4.1.18で定義されたプロトコル固有のメタ変数の共通ゲートウェイインターフェイス（CGI）マッピングは、CGIの標準変数の1つに対応しない受信ヘッダーフィールドに適用されます。マッピングは、各名前に「http_」を準備し、ハイフン（ " - "）のすべてのインスタンスを変更して（ "_"）を変更することで構成されています。この同じマッピングは、移動アプリケーションをあるプラットフォームから次のプラットフォームに簡素化するために、他の多くのアプリケーションフレームワークに継承されています。
In CGI, a received Content-Length field would be passed as the meta-variable "CONTENT_LENGTH" with a string value matching the received field's value. In contrast, a received "Content_Length" header field would be passed as the protocol-specific meta-variable "HTTP_CONTENT_LENGTH", which might lead to some confusion if an application mistakenly reads the protocol-specific meta-variable instead of the default one. (This historical practice is why Section 16.3.2.1 discourages the creation of new field names that contain an underscore.)
CGIでは、受信したコンテンツレングスフィールドは、受信したフィールドの値に一致する文字列値を持つメタ変数「content_length」として渡されます。対照的に、受信した「content_length」ヘッダーフィールドは、プロトコル固有のメタバリゼーション「http_content_length」として渡されます。これは、アプリケーションがデフォルトのものの代わりにプロトコル固有のメタ変数を誤って読み取ると、いくらかの混乱につながる可能性があります。（この歴史的慣行は、セクション16.3.2.1がアンダースコアを含む新しいフィールド名の作成を思いとどまらせる理由です。）
Unfortunately, mapping field names to different interface names can lead to security vulnerabilities if the mapping is incomplete or ambiguous. For example, if an attacker were to send a field named "Transfer_Encoding", a naive interface might map that to the same variable name as the "Transfer-Encoding" field, resulting in a potential request smuggling vulnerability (Section 11.2 of [HTTP/1.1]).
残念ながら、フィールド名を異なるインターフェイス名にマッピングすると、マッピングが不完全または曖昧な場合、セキュリティの脆弱性につながる可能性があります。たとえば、攻撃者が「Transfer_Encoding」という名前のフィールドを送信した場合、素朴なインターフェイスは、それを「転送エンコード」フィールドと同じ変数名にマッピングし、脆弱性を密輸する可能性のある要求をもたらす可能性があります（[http/のセクション11.21.1]）。
To mitigate the associated risks, implementations that perform such mappings are advised to make the mapping unambiguous and complete for the full range of potential octets received as a name (including those that are discouraged or forbidden by the HTTP grammar). For example, a field with an unusual name character might result in the request being blocked, the specific field being removed, or the name being passed with a different prefix to distinguish it from other fields.
関連するリスクを軽減するために、そのようなマッピングを実行する実装は、名前として受信したすべての潜在的なオクテット（HTTP文法によって落胆または禁止されているものを含む）について明確かつ完全にすることをお勧めします。たとえば、異常な名前の文字を持つフィールドは、リクエストがブロックされたり、特定のフィールドが削除されたり、他のフィールドと区別するために別の接頭辞で渡されたりする可能性があります。
Although fragment identifiers used within URI references are not sent in requests, implementers ought to be aware that they will be visible to the user agent and any extensions or scripts running as a result of the response. In particular, when a redirect occurs and the original request's fragment identifier is inherited by the new reference in Location (Section 10.2.2), this might have the effect of disclosing one site's fragment to another site. If the first site uses personal information in fragments, it ought to ensure that redirects to other sites include a (possibly empty) fragment component in order to block that inheritance.
URI参照内で使用されるフラグメント識別子はリクエストで送信されませんが、実装者は、ユーザーエージェントと応答の結果として実行されている拡張機能またはスクリプトに表示されることに注意する必要があります。特に、リダイレクトが発生し、元のリクエストのフラグメント識別子が場所（セクション10.2.2）の新しい参照によって継承されると、これはあるサイトのフラグメントを別のサイトに開示する効果がある可能性があります。最初のサイトがフラグメント内の個人情報を使用している場合、その継承をブロックするために、他のサイトへのリダイレクトに（おそらく空の）フラグメントコンポーネントが含まれるようにする必要があります。
The User-Agent (Section 10.1.5), Via (Section 7.6.3), and Server (Section 10.2.4) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the apparent software versions being used.
ユーザーエージェント（セクション10.1.5）、via（セクション7.6.3）、およびサーバー（セクション10.2.4）ヘッダーフィールドは、しばしばそれぞれの送信者のソフトウェアシステムに関する情報を明らかにします。理論的には、これにより、攻撃者が既知のセキュリティホールを容易にすることができます。実際には、攻撃者は、使用されている見かけのソフトウェアバージョンに関係なく、すべての潜在的な穴を試す傾向があります。
Proxies that serve as a portal through a network firewall ought to take special precautions regarding the transfer of header information that might identify hosts behind the firewall. The Via header field allows intermediaries to replace sensitive machine names with pseudonyms.
ネットワークファイアウォールを介してポータルとして機能するプロキシは、ファイアウォールの背後にあるホストを識別する可能性のあるヘッダー情報の転送に関して特別な予防措置を講じる必要があります。Via Headerフィールドにより、仲介者は敏感な機械名を仮名に置き換えることができます。
Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics. These characteristics might include information related to how it uses the underlying transport protocol, feature capabilities, and scripting environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP. Fingerprinting is considered a privacy concern because it enables tracking of a user agent's behavior over time ([Bujlow]) without the corresponding controls that the user might have over other forms of data collection (e.g., cookies). Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints.
ブラウザフィンガープリントは、一意の特性セットを通じて、特定のユーザーエージェントを時間の経過とともに識別するための一連の手法です。これらの特性には、基礎となる輸送プロトコル、機能機能、およびスクリプト環境を使用する方法に関連する情報が含まれる場合がありますが、特に興味深いのは、HTTPを介して伝達される固有の特性のセットです。フィンガープリントは、ユーザーが他の形式のデータ収集（Cookieなど）よりも対応するコントロールなしで、ユーザーエージェントの動作（[Bujlow]）の経過に伴う（[Bujlow]）の動作を追跡できるため、プライバシーの懸念と考えられています。多くの汎用ユーザーエージェント（つまり、Webブラウザー）は、指紋を減らすための措置を講じています。
There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable fingerprinting. The From header field is the most obvious, though it is expected that From will only be sent when self-identification is desired by the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so fingerprinting concerns only apply to situations where cookies are disabled or restricted by the user agent's configuration.
フィンガープリントを有効にするのに十分なユニークなサーバーに情報を明らかにする可能性のあるリクエストヘッダーフィールドがいくつかあります。From Headerフィールドは最も明白ですが、ユーザーが自己識別が望まれる場合にのみ送信されることが予想されます。同様に、Cookieヘッダーフィールドは、再識別を可能にするように意図的に設計されているため、フィンガープリントの懸念は、ユーザーエージェントの構成によってCookieが無効または制限されている状況にのみ適用されます。
The User-Agent header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique information that is least expected by users is proactive negotiation (Section 12.1), including the Accept, Accept-Charset, Accept-Encoding, and Accept-Language header fields.
ユーザーエージェントヘッダーフィールドには、通常、他の特性と組み合わせると、特にユーザーエージェントがユーザーのシステムまたは拡張機能に関する過剰な詳細を送信する場合、特定のデバイスを一意に識別するのに十分な情報が含まれている場合があります。ただし、ユーザーが最も期待していないユニークな情報のソースは、受け入れ、受け入れ、受け入れ、承認、および承認のヘッダーフィールドを含む、積極的な交渉（セクション12.1）です。
In addition to the fingerprinting concern, detailed use of the Accept-Language header field can reveal information the user might consider to be of a private nature. For example, understanding a given language set might be strongly correlated to membership in a particular ethnic group. An approach that limits such loss of privacy would be for a user agent to omit the sending of Accept-Language except for sites that have been explicitly permitted, perhaps via interaction after detecting a Vary header field that indicates language negotiation might be useful.
フィンガープリントの懸念に加えて、受け入れ言語ヘッダーフィールドの詳細な使用は、ユーザーが私的な性質であると考える可能性のある情報を明らかにすることができます。たとえば、特定の言語セットを理解することは、特定の民族グループのメンバーシップと強く相関している可能性があります。このようなプライバシーの損失を制限するアプローチは、ユーザーエージェントが、おそらく言語の交渉が有用であることを示すさまざまなヘッダーフィールドを検出した後の相互作用を介して、明示的に許可されているサイトを除いて、受け入れられる言語の送信を省略することです。
In environments where proxies are used to enhance privacy, user agents ought to be conservative in sending proactive negotiation header fields. General-purpose user agents that provide a high degree of header field configurability ought to inform users about the loss of privacy that might result if too much detail is provided. As an extreme privacy measure, proxies could filter the proactive negotiation header fields in relayed requests.
プロキシがプライバシーを強化するために使用される環境では、ユーザーエージェントは積極的なネゴシエーションヘッダーフィールドを送信する際に保守的でなければなりません。高度なヘッダーフィールドの構成可能性を提供する汎用ユーザーエージェントは、詳細が多すぎると生じる可能性のあるプライバシーの損失についてユーザーに通知する必要があります。極端なプライバシー尺度として、プロキシはリレーした要求でプロアクティブなネゴシエーションヘッダーフィールドをフィルタリングできます。
The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious changes, or detect on-path attacks. At best, they enable more efficient cache updates and optimistic concurrent writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response that is no more harmful than an HTTP exchange without conditional requests.
この仕様で定義されたバリデーターは、表現の妥当性を確保したり、悪意のある変更を防ぎたり、パス上の攻撃を検出することを目的としていません。せいぜい、すべての参加者がうまく振る舞っている場合、より効率的なキャッシュの更新と楽観的な同時の書き込みを可能にします。最悪の場合、条件は失敗し、クライアントは条件付き要求なしにHTTP交換よりも有害でない応答を受け取ります。
An entity tag can be abused in ways that create privacy risks. For example, a site might deliberately construct a semantically invalid entity tag that is unique to the user or user agent, send it in a cacheable response with a long freshness time, and then read that entity tag in later conditional requests as a means of re-identifying that user or user agent. Such an identifying tag would become a persistent identifier for as long as the user agent retained the original cache entry. User agents that cache representations ought to ensure that the cache is cleared or replaced whenever the user performs privacy-maintaining actions, such as clearing stored cookies or changing to a private browsing mode.
エンティティタグは、プライバシーリスクを作成する方法で乱用することができます。たとえば、サイトは、ユーザーまたはユーザーエージェントに固有のセマンティックな無効なエンティティタグを意図的に構築し、長い新鮮さの時間でキャッシュ可能な応答で送信し、そのエンティティタグを後の条件付きリクエストで読み取ります。 - そのユーザーまたはユーザーエージェントの特定。このような識別タグは、ユーザーエージェントが元のキャッシュエントリを保持している限り、永続的な識別子になります。キャッシュ表現をキャッシュするユーザーエージェントは、保存されたCookieのクリアやプライベートブラウジングモードへの変更など、ユーザーがプライバシーメンテインアクションを実行するたびにキャッシュがクリアまたは交換されるようにする必要があります。
Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts. Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason. Multipart range requests are not designed to support random access.
制約のない複数の範囲要求は、同じデータの多くの重複範囲を要求するために必要な努力が、多くの部分で要求されたデータを提供しようとすることによって消費される時間、メモリ、および帯域幅に比べて小さいため、サービス拒否攻撃の影響を受けやすいです。サーバーは、2つ以上の重複範囲のリクエストや、特に明白な理由なしに範囲が順不同で要求されている場合、単一のセットの多くの小さな範囲のリクエストなど、ひどい範囲のリクエストを無視、合体、または拒否する必要があります。マルチパート範囲の要求は、ランダムアクセスをサポートするようには設計されていません。
Everything about the topic of HTTP authentication is a security consideration, so the list of considerations below is not exhaustive. Furthermore, it is limited to security considerations regarding the authentication framework, in general, rather than discussing all of the potential considerations for specific authentication schemes (which ought to be documented in the specifications that define those schemes). Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]), including common pitfalls for implementing and using the authentication schemes found in practice.
HTTP認証のトピックに関するすべてはセキュリティに関する考慮事項であるため、以下の考慮事項のリストは網羅的ではありません。さらに、一般に、認証フレームワークに関するセキュリティに関する考慮事項に限定されています。特定の認証スキームのすべての潜在的な考慮事項（これらのスキームを定義する仕様に文書化する必要があります）を議論するのではありません。さまざまな組織は、実際に見つかった認証スキームを実装および使用するための一般的な落とし穴を含む、Webアプリケーションのセキュリティに関する現在の研究（[OWASP]など）に関する現在の研究へのリンクを維持しています。
The HTTP authentication framework does not define a single mechanism for maintaining the confidentiality of credentials; instead, each authentication scheme defines how the credentials are encoded prior to transmission. While this provides flexibility for the development of future authentication schemes, it is inadequate for the protection of existing schemes that provide no confidentiality on their own, or that do not sufficiently protect against replay attacks. Furthermore, if the server expects credentials that are specific to each individual user, the exchange of those credentials will have the effect of identifying that user even if the content within credentials remains confidential.
HTTP認証フレームワークは、資格情報の機密性を維持するための単一のメカニズムを定義しません。代わりに、各認証スキームは、送信前に資格情報がエンコードされる方法を定義します。これにより、将来の認証スキームの開発に柔軟性が提供されますが、独自に機密性を提供しない、またはリプレイ攻撃から十分に保護しない既存のスキームの保護には不十分です。さらに、サーバーが個々のユーザーに固有の資格情報を期待している場合、それらの資格情報の交換は、資格情報内のコンテンツが機密のままであっても、ユーザーを識別する効果があります。
HTTP depends on the security properties of the underlying transport-or session-level connection to provide confidential transmission of fields. Services that depend on individual user authentication require a secured connection prior to exchanging credentials (Section 4.2.2).
HTTPは、基礎となる輸送またはセッションレベルの接続のセキュリティプロパティに依存して、フィールドの機密送信を提供します。個々のユーザー認証に依存するサービスには、資格情報を交換する前に、保護された接続が必要です（セクション4.2.2）。
Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP does not provide a mechanism for the origin server to direct clients to discard these cached credentials, since the protocol has no awareness of how credentials are obtained or managed by the user agent. The mechanisms for expiring or revoking credentials can be specified as part of an authentication scheme definition.
既存のHTTPクライアントとユーザーエージェントは、通常、認証情報を無期限に保持します。HTTPは、プロトコルがユーザーエージェントによって資格情報がどのように取得または管理されるかについての認識を持たないため、オリジナルサーバーがこれらのキャッシュされた資格を破棄するようクライアントに指示するメカニズムを提供しません。資格情報を期限切れまたは取り消すメカニズムは、認証スキーム定義の一部として指定できます。
Circumstances under which credential caching can interfere with the application's security model include but are not limited to:
資格のキャッシュがアプリケーションのセキュリティモデルを妨げる可能性がある状況には、以下が含まれますが、これらに限定されません。
* Clients that have been idle for an extended period, following which the server might wish to cause the client to re-prompt the user for credentials.
* 長期間アイドル状態になっているクライアントは、サーバーがクライアントに資格情報をユーザーに再構成させたいと考えている可能性があります。
* Applications that include a session termination indication (such as a "logout" or "commit" button on a page) after which the server side of the application "knows" that there is no further reason for the client to retain the credentials.
* セッション終了表示（ページ上の「ログアウト」または「コミット」ボタンなど）を含むアプリケーションが含まれ、その後、アプリケーションのサーバー側がクライアントが資格情報を保持する理由がないことを「知っています」。
User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.
資格情報をキャッシュするユーザーエージェントは、ユーザーコントロールの下でキャッシュされた資格情報を破棄するための容易にアクセス可能なメカニズムを提供することをお勧めします。
Authentication schemes that solely rely on the "realm" mechanism for establishing a protection space will expose credentials to all resources on an origin server. Clients that have successfully made authenticated requests with a resource can use the same authentication credentials for other resources on the same origin server. This makes it possible for a different resource to harvest authentication credentials for other resources.
保護スペースを確立するための「レルム」メカニズムにのみ依存する認証スキームは、Origin Server上のすべてのリソースに資格情報を公開します。リソースを使用して認証されたリクエストを正常に作成したクライアントは、同じOrigin Server上の他のリソースに同じ認証資格情報を使用できます。これにより、別のリソースが他のリソースの認証資格情報を収穫することが可能になります。
This is of particular concern when an origin server hosts resources for multiple parties under the same origin (Section 11.5). Possible mitigation strategies include restricting direct access to authentication credentials (i.e., not making the content of the Authorization request header field available), and separating protection spaces by using a different host name (or port number) for each party.
これは、Origin Serverが同じ起源の下で複数の関係者のリソースをホストする場合に特に懸念されます（セクション11.5）。可能な緩和戦略には、認証資格情報への直接アクセスを制限する（つまり、承認要求ヘッダーフィールドのコンテンツを利用可能にしない）、および各パーティーの別のホスト名（またはポート番号）を使用して保護スペースを分離することが含まれます。
Adding information to responses that are sent over an unencrypted channel can affect security and privacy. The presence of the Authentication-Info and Proxy-Authentication-Info header fields alone indicates that HTTP authentication is in use. Additional information could be exposed by the contents of the authentication-scheme specific parameters; this will have to be considered in the definitions of these schemes.
暗号化されていないチャネルを介して送信される応答に情報を追加すると、セキュリティとプライバシーに影響を与える可能性があります。Authentication-INFOおよびProxy-Authentication-INFOヘッダーフィールドの存在は、HTTP認証が使用されていることを示しています。追加情報は、認証スキーム固有のパラメーターの内容によって公開される可能性があります。これは、これらのスキームの定義で考慮する必要があります。
The change controller for the following registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
次の登録の変更コントローラーは、「IETF（iesg@ietf.org） - インターネットエンジニアリングタスクフォース」です。
IANA has updated the "Uniform Resource Identifier (URI) Schemes" registry [BCP35] at <https://www.iana.org/assignments/uri-schemes/> with the permanent schemes listed in Table 2 in Section 4.2.
IANAは、<https://www.iana.org/assignments/uri-schemes/> <https://www.iana.org/>で「均一なリソース識別子（URI）スキーム」レジストリ[BCP35]を更新しました。
IANA has updated the "Hypertext Transfer Protocol (HTTP) Method Registry" at <https://www.iana.org/assignments/http-methods> with the registration procedure of Section 16.1.1 and the method names summarized in the following table.
IANAは、<https://www.iana.org/assignments/http-methods> <https://www.iana.org/assignments/http-methods> <https://www.iana.org/assignments/http-methods> <https://www.iana.org/assignments/http-methods> <https://www.iana.org/assignments/http-methods>を更新し、次の表にまとめたメソッド名を更新しました。。
+=========+======+============+=========+
| Method | Safe | Idempotent | Section |
+=========+======+============+=========+
| CONNECT | no | no | 9.3.6 |
+---------+------+------------+---------+
| DELETE | no | yes | 9.3.5 |
+---------+------+------------+---------+
| GET | yes | yes | 9.3.1 |
+---------+------+------------+---------+
| HEAD | yes | yes | 9.3.2 |
+---------+------+------------+---------+
| OPTIONS | yes | yes | 9.3.7 |
+---------+------+------------+---------+
| POST | no | no | 9.3.3 |
+---------+------+------------+---------+
| PUT | no | yes | 9.3.4 |
+---------+------+------------+---------+
| TRACE | yes | yes | 9.3.8 |
+---------+------+------------+---------+
| * | no | no | 18.2 |
+---------+------+------------+---------+
Table 7
表7
The method name "*" is reserved because using "*" as a method name would conflict with its usage as a wildcard in some fields (e.g., "Access-Control-Request-Method").
メソッド名「*」は、メソッド名として「*」を使用すると、一部のフィールドのワイルドカードとしての使用と競合するため、予約されています（例：「アクセスコントロール - レクエストメソッド」）。
IANA has updated the "Hypertext Transfer Protocol (HTTP) Status Code Registry" at <https://www.iana.org/assignments/http-status-codes> with the registration procedure of Section 16.2.1 and the status code values summarized in the following table.
IANAは、<https://www.iana.org/assignments/http-status-codes> <https://www.iana.org/assignments/http-status-codes>「HyperText Transfer Protocol（HTTP）ステータスコードレジストリ」をセクション16.2.1の登録手順とステータスコード値を概要更新しました。次の表で。
+=======+===============================+=========+
| Value | Description | Section |
+=======+===============================+=========+
| 100 | Continue | 15.2.1 |
+-------+-------------------------------+---------+
| 101 | Switching Protocols | 15.2.2 |
+-------+-------------------------------+---------+
| 200 | OK | 15.3.1 |
+-------+-------------------------------+---------+
| 201 | Created | 15.3.2 |
+-------+-------------------------------+---------+
| 202 | Accepted | 15.3.3 |
+-------+-------------------------------+---------+
| 203 | Non-Authoritative Information | 15.3.4 |
+-------+-------------------------------+---------+
| 204 | No Content | 15.3.5 |
+-------+-------------------------------+---------+
| 205 | Reset Content | 15.3.6 |
+-------+-------------------------------+---------+
| 206 | Partial Content | 15.3.7 |
+-------+-------------------------------+---------+
| 300 | Multiple Choices | 15.4.1 |
+-------+-------------------------------+---------+
| 301 | Moved Permanently | 15.4.2 |
+-------+-------------------------------+---------+
| 302 | Found | 15.4.3 |
+-------+-------------------------------+---------+
| 303 | See Other | 15.4.4 |
+-------+-------------------------------+---------+
| 304 | Not Modified | 15.4.5 |
+-------+-------------------------------+---------+
| 305 | Use Proxy | 15.4.6 |
+-------+-------------------------------+---------+
| 306 | (Unused) | 15.4.7 |
+-------+-------------------------------+---------+
| 307 | Temporary Redirect | 15.4.8 |
+-------+-------------------------------+---------+
| 308 | Permanent Redirect | 15.4.9 |
+-------+-------------------------------+---------+
| 400 | Bad Request | 15.5.1 |
+-------+-------------------------------+---------+
| 401 | Unauthorized | 15.5.2 |
+-------+-------------------------------+---------+
| 402 | Payment Required | 15.5.3 |
+-------+-------------------------------+---------+
| 403 | Forbidden | 15.5.4 |
+-------+-------------------------------+---------+
| 404 | Not Found | 15.5.5 |
+-------+-------------------------------+---------+
| 405 | Method Not Allowed | 15.5.6 |
+-------+-------------------------------+---------+
| 406 | Not Acceptable | 15.5.7 |
+-------+-------------------------------+---------+
| 407 | Proxy Authentication Required | 15.5.8 |
+-------+-------------------------------+---------+
| 408 | Request Timeout | 15.5.9 |
+-------+-------------------------------+---------+
| 409 | Conflict | 15.5.10 |
+-------+-------------------------------+---------+
| 410 | Gone | 15.5.11 |
+-------+-------------------------------+---------+
| 411 | Length Required | 15.5.12 |
+-------+-------------------------------+---------+
| 412 | Precondition Failed | 15.5.13 |
+-------+-------------------------------+---------+
| 413 | Content Too Large | 15.5.14 |
+-------+-------------------------------+---------+
| 414 | URI Too Long | 15.5.15 |
+-------+-------------------------------+---------+
| 415 | Unsupported Media Type | 15.5.16 |
+-------+-------------------------------+---------+
| 416 | Range Not Satisfiable | 15.5.17 |
+-------+-------------------------------+---------+
| 417 | Expectation Failed | 15.5.18 |
+-------+-------------------------------+---------+
| 418 | (Unused) | 15.5.19 |
+-------+-------------------------------+---------+
| 421 | Misdirected Request | 15.5.20 |
+-------+-------------------------------+---------+
| 422 | Unprocessable Content | 15.5.21 |
+-------+-------------------------------+---------+
| 426 | Upgrade Required | 15.5.22 |
+-------+-------------------------------+---------+
| 500 | Internal Server Error | 15.6.1 |
+-------+-------------------------------+---------+
| 501 | Not Implemented | 15.6.2 |
+-------+-------------------------------+---------+
| 502 | Bad Gateway | 15.6.3 |
+-------+-------------------------------+---------+
| 503 | Service Unavailable | 15.6.4 |
+-------+-------------------------------+---------+
| 504 | Gateway Timeout | 15.6.5 |
+-------+-------------------------------+---------+
| 505 | HTTP Version Not Supported | 15.6.6 |
+-------+-------------------------------+---------+
Table 8
表8
This specification updates the HTTP-related aspects of the existing registration procedures for message header fields defined in [RFC3864]. It replaces the old procedures as they relate to HTTP by defining a new registration procedure and moving HTTP field definitions into a separate registry.
この仕様は、[RFC3864]で定義されているメッセージヘッダーフィールドの既存の登録手順のHTTP関連の側面を更新します。新しい登録手順を定義し、HTTPフィールドの定義を別のレジストリに移動することにより、HTTPに関連する古い手順を置き換えます。
IANA has created a new registry titled "Hypertext Transfer Protocol (HTTP) Field Name Registry" as outlined in Section 16.3.1.
IANAは、セクション16.3.1で概説されているように、「HyperText Transfer Protocol（HTTP）フィールド名レジストリ」というタイトルの新しいレジストリを作成しました。
IANA has moved all entries in the "Permanent Message Header Field Names" and "Provisional Message Header Field Names" registries (see <https://www.iana.org/assignments/message-headers/>) with the protocol 'http' to this registry and has applied the following changes:
IANAはすべてのエントリを「永続的なメッセージヘッダーフィールド名」および「暫定メッセージヘッダーフィールド名」レジストリに移動しました（<https://www.iana.org/assignments/message-headers/>を参照）。このレジストリに、次の変更を適用しました。
1. The 'Applicable Protocol' field has been omitted.
1. 「該当するプロトコル」フィールドは省略されています。
2. Entries that had a status of 'standard', 'experimental', 'reserved', or 'informational' have been made to have a status of 'permanent'.
2. 「標準」、「実験的」、「予約された」、または「情報」のステータスがあるエントリが「永続的」のステータスを持つようになりました。
3. Provisional entries without a status have been made to have a status of 'provisional'.
3. ステータスのない暫定的なエントリは、「暫定」のステータスを持つように行われています。
4. Permanent entries without a status (after confirmation that the registration document did not define one) have been made to have a status of 'provisional'. The expert(s) can choose to update the entries' status if there is evidence that another is more appropriate.
4. ステータスのない恒久的なエントリ（登録文書が定義されていないことを確認した後）は、「暫定」のステータスを持つようになりました。専門家は、別のものがより適切であるという証拠がある場合、エントリのステータスを更新することを選択できます。
IANA has annotated the "Permanent Message Header Field Names" and "Provisional Message Header Field Names" registries with the following note to indicate that HTTP field name registrations have moved:
IANAには、「永続的なメッセージヘッダーフィールド名」と「暫定メッセージヘッダーフィールド名」レジストリを次のメモと注釈して、HTTPフィールド名登録が移動したことを示しています。
| *Note*
|
| HTTP field name registrations have been moved to
| [https://www.iana.org/assignments/http-fields] per [RFC9110].
IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name Registry" with the field names listed in the following table.
IANAは、次の表にリストされているフィールド名で「ハイパーテキスト転送プロトコル（HTTP）フィールド名レジストリ」を更新しました。
+===========================+============+=========+============+
| Field Name | Status | Section | Comments |
+===========================+============+=========+============+
| Accept | permanent | 12.5.1 | |
+---------------------------+------------+---------+------------+
| Accept-Charset | deprecated | 12.5.2 | |
+---------------------------+------------+---------+------------+
| Accept-Encoding | permanent | 12.5.3 | |
+---------------------------+------------+---------+------------+
| Accept-Language | permanent | 12.5.4 | |
+---------------------------+------------+---------+------------+
| Accept-Ranges | permanent | 14.3 | |
+---------------------------+------------+---------+------------+
| Allow | permanent | 10.2.1 | |
+---------------------------+------------+---------+------------+
| Authentication-Info | permanent | 11.6.3 | |
+---------------------------+------------+---------+------------+
| Authorization | permanent | 11.6.2 | |
+---------------------------+------------+---------+------------+
| Connection | permanent | 7.6.1 | |
+---------------------------+------------+---------+------------+
| Content-Encoding | permanent | 8.4 | |
+---------------------------+------------+---------+------------+
| Content-Language | permanent | 8.5 | |
+---------------------------+------------+---------+------------+
| Content-Length | permanent | 8.6 | |
+---------------------------+------------+---------+------------+
| Content-Location | permanent | 8.7 | |
+---------------------------+------------+---------+------------+
| Content-Range | permanent | 14.4 | |
+---------------------------+------------+---------+------------+
| Content-Type | permanent | 8.3 | |
+---------------------------+------------+---------+------------+
| Date | permanent | 6.6.1 | |
+---------------------------+------------+---------+------------+
| ETag | permanent | 8.8.3 | |
+---------------------------+------------+---------+------------+
| Expect | permanent | 10.1.1 | |
+---------------------------+------------+---------+------------+
| From | permanent | 10.1.2 | |
+---------------------------+------------+---------+------------+
| Host | permanent | 7.2 | |
+---------------------------+------------+---------+------------+
| If-Match | permanent | 13.1.1 | |
+---------------------------+------------+---------+------------+
| If-Modified-Since | permanent | 13.1.3 | |
+---------------------------+------------+---------+------------+
| If-None-Match | permanent | 13.1.2 | |
+---------------------------+------------+---------+------------+
| If-Range | permanent | 13.1.5 | |
+---------------------------+------------+---------+------------+
| If-Unmodified-Since | permanent | 13.1.4 | |
+---------------------------+------------+---------+------------+
| Last-Modified | permanent | 8.8.2 | |
+---------------------------+------------+---------+------------+
| Location | permanent | 10.2.2 | |
+---------------------------+------------+---------+------------+
| Max-Forwards | permanent | 7.6.2 | |
+---------------------------+------------+---------+------------+
| Proxy-Authenticate | permanent | 11.7.1 | |
+---------------------------+------------+---------+------------+
| Proxy-Authentication-Info | permanent | 11.7.3 | |
+---------------------------+------------+---------+------------+
| Proxy-Authorization | permanent | 11.7.2 | |
+---------------------------+------------+---------+------------+
| Range | permanent | 14.2 | |
+---------------------------+------------+---------+------------+
| Referer | permanent | 10.1.3 | |
+---------------------------+------------+---------+------------+
| Retry-After | permanent | 10.2.3 | |
+---------------------------+------------+---------+------------+
| Server | permanent | 10.2.4 | |
+---------------------------+------------+---------+------------+
| TE | permanent | 10.1.4 | |
+---------------------------+------------+---------+------------+
| Trailer | permanent | 6.6.2 | |
+---------------------------+------------+---------+------------+
| Upgrade | permanent | 7.8 | |
+---------------------------+------------+---------+------------+
| User-Agent | permanent | 10.1.5 | |
+---------------------------+------------+---------+------------+
| Vary | permanent | 12.5.5 | |
+---------------------------+------------+---------+------------+
| Via | permanent | 7.6.3 | |
+---------------------------+------------+---------+------------+
| WWW-Authenticate | permanent | 11.6.1 | |
+---------------------------+------------+---------+------------+
| * | permanent | 12.5.5 | (reserved) |
+---------------------------+------------+---------+------------+
Table 9
表9
The field name "*" is reserved because using that name as an HTTP header field might conflict with its special semantics in the Vary header field (Section 12.5.5).
フィールド名「*」は、その名前をHTTPヘッダーフィールドとして使用すると、Varyヘッダーフィールドでの特別なセマンティクスと競合する可能性があるため、予約されています（セクション12.5.5）。
IANA has updated the "Content-MD5" entry in the new registry to have a status of 'obsoleted' with references to Section 14.15 of [RFC2616] (for the definition of the header field) and Appendix B of [RFC7231] (which removed the field definition from the updated specification).
IANAは、新しいレジストリの「Content-MD5」エントリを更新し、[RFC2616]のセクション14.15（ヘッダーフィールドの定義の場合）および[RFC7231]の付録B（削除された」（削除された付録Bへの参照を含む「廃止」のステータスを持つようにしました。更新された仕様からのフィールド定義）。
IANA has updated the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" at <https://www.iana.org/assignments/ http-authschemes> with the registration procedure of Section 16.4.1. No authentication schemes are defined in this document.
IANAは、セクション16.4.1の登録手順で、<https://www.iana.org/assignments/ http-authschemes> <https://www.iana.org/assignments/ <https://www.iana.org/assignments/で「ハイパーテキスト転送プロトコル（HTTP）認証スキームレジストリ」を更新しました。このドキュメントでは、認証スキームは定義されていません。
IANA has updated the "HTTP Content Coding Registry" at <https://www.iana.org/assignments/http-parameters/> with the registration procedure of Section 16.6.1 and the content coding names summarized in the table below.
IANAは、「https://www.iana.org/assignments/http-parameters/> <https://www.iana.org/http-parameters/>」で「HTTPコンテンツコーディングレジストリ」を更新しました。
+============+===========================================+=========+
| Name | Description | Section |
+============+===========================================+=========+
| compress | UNIX "compress" data format [Welch] | 8.4.1.1 |
+------------+-------------------------------------------+---------+
| deflate | "deflate" compressed data ([RFC1951]) | 8.4.1.2 |
| | inside the "zlib" data format ([RFC1950]) | |
+------------+-------------------------------------------+---------+
| gzip | GZIP file format [RFC1952] | 8.4.1.3 |
+------------+-------------------------------------------+---------+
| identity | Reserved | 12.5.3 |
+------------+-------------------------------------------+---------+
| x-compress | Deprecated (alias for compress) | 8.4.1.1 |
+------------+-------------------------------------------+---------+
| x-gzip | Deprecated (alias for gzip) | 8.4.1.3 |
+------------+-------------------------------------------+---------+
Table 10
表10
IANA has updated the "HTTP Range Unit Registry" at <https://www.iana.org/assignments/http-parameters/> with the registration procedure of Section 16.5.1 and the range unit names summarized in the table below.
IANAは、セクション16.5.1の登録手順で「https://www.iana.org/assignments/http-parameters/> <https://www.iana.org/assignments/http-parameters/>」の「HTTP Range Unit Registry」を更新し、以下の表にまとめました。
+=================+==================================+=========+
| Range Unit Name | Description | Section |
+=================+==================================+=========+
| bytes | a range of octets | 14.1.2 |
+-----------------+----------------------------------+---------+
| none | reserved as keyword to indicate | 14.3 |
| | range requests are not supported | |
+-----------------+----------------------------------+---------+
Table 11
表11
IANA has updated the "Media Types" registry at <https://www.iana.org/assignments/media-types> with the registration information in Section 14.6 for the media type "multipart/ byteranges".
IANAは、<https://www.iana.org/assignments/media-types> <https://www.iana.org>の「メディアタイプ」レジストリを更新しました。
IANA has updated the registry note about "q" parameters with a link to Section 12.5.1 of this document.
IANAは、このドキュメントのセクション12.5.1へのリンクを持つ「Q」パラメーターに関するレジストリノートを更新しました。
IANA has updated the "Service Name and Transport Protocol Port Number Registry" at <https://www.iana.org/assignments/service-names-port-numbers/> for the services on ports 80 and 443 that use UDP or TCP to:
IANAは、UDPまたはTCPを使用するポート80および443のサービスについて、<https://www.iana.org/service-names-numbers/> <https://www.iana.org/service-names-numbers/>の「サービス名と輸送プロトコルのポート番号レジストリ」を更新しました。に：
1. use this document as "Reference", and
1. このドキュメントを「参照」として使用します
2. when currently unspecified, set "Assignee" to "IESG" and "Contact" to "IETF_Chair".
2. 現在特定されていない場合は、「IESG」に「譲受人」を「IETF_CHAIR」に「接触」に設定します。
IANA has updated the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" at <https://www.iana.org/assignments/http-upgrade-tokens> with the registration procedure described in Section 16.7 and the upgrade token names summarized in the following table.
IANAは、「HyperText Transfer Protocol（HTTP）アップグレードトークンレジストリ」を<https://www.iana.org/assignments/http-upgrade-tokens>に更新しました。次の表。
+======+===================+=========================+=========+
| Name | Description | Expected Version Tokens | Section |
+======+===================+=========================+=========+
| HTTP | Hypertext | any DIGIT.DIGIT (e.g., | 2.5 |
| | Transfer Protocol | "2.0") | |
+------+-------------------+-------------------------+---------+
Table 12
表12
[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>.
[キャッシュ]フィールディング、R。、編、ノッティンガム、M.、編、J。レスケ、編、「HTTPキャッシュ」、STD 98、RFC 9111、DOI 10.17487/RFC9111、2022年6月、<https：//www.rfc-editor.org/info/rfc9111>。
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, DOI 10.17487/RFC1950, May 1996, <https://www.rfc-editor.org/info/rfc1950>.
[RFC1950] Deutsch、P。およびJ-L。Gailly、「Zlib圧縮データ形式の仕様バージョン3.3」、RFC 1950、DOI 10.17487/RFC1950、1996年5月、<https://www.rfc-editor.org/info/rfc1950>。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, <https://www.rfc-editor.org/info/rfc1951>.
[RFC1951] Deutsch、P。、「圧縮データ形式の仕様バージョン1.3」、RFC 1951、DOI 10.17487/RFC1951、1996年5月、<https://www.rfc-editor.org/info/rfc1951>。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, <https://www.rfc-editor.org/info/rfc1952>.
[RFC1952] Deutsch、P。、「GZIPファイル形式の仕様バージョン4.3」、RFC 1952、DOI 10.17487/RFC1952、1996年5月、<https://www.rfc-editor.org/info/rfc1952>。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、DOI 10.17487/RFC2046、1996年11月、<https://www.rfc-editor.orgg/info/rfc2046>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, <https://www.rfc-editor.org/info/rfc4647>.
[RFC4647]フィリップス、A。、編およびM.デイビス編、「言語タグのマッチング」、BCP 47、RFC 4647、DOI 10.17487/RFC4647、2006年9月、<https://www.rfc-editor.org/info/rfc4647>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、RFC 4648、DOI 10.17487/RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ed。P. Overell、「構文仕様のためのBNFの増強：ABNF：STD 68、RFC 5234、DOI 10.17487/RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509 Public Key Infrastructure Certificate and Certificate Recocation List（CRL）プロファイル"、RFC 5280、DOI 10.17487/RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージフォーマット」、RFC 5322、DOI 10.17487/RFC5322、2008年10月、<https://www.rfc-editor.org/info/rfc5321。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646]フィリップス、A。、編およびM.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、DOI 10.17487/RFC5646、2009年9月、<https://www.rfc-editor.org/info/rfc5646>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「輸送層のセキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開キーインフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、RFC 6125、DOI 10.17487/RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.
[RFC6365]ホフマン、P。およびJ.クレンシン、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、DOI 10.17487/RFC6365、2011年9月、<https://www.rfc-editor.org/info/RFC6365>。
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405] Kyzivat、P。、「ABNFでのケースセンシティブストリングサポート」、RFC 7405、DOI 10.17487/RFC7405、2014年12月、<https://www.rfc-editor.org/info/rfc7405>
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[TCP] Postel、J。、「伝送制御プロトコル」、STD 7、RFC 793、DOI 10.17487/RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[TLS13] 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>.
[TLS13] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
[URI] 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>.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[USASCII] American National Standards Institute、「コード化された文字セット - 情報交換のための7ビットアメリカ標準コード」、ANSI X3.4、1986。
[Welch] Welch, T., "A Technique for High-Performance Data Compression", IEEE Computer 17(6), DOI 10.1109/MC.1984.1659158, June 1984, <https://ieeexplore.ieee.org/document/1659158/>.
[ウェルチ]ウェルチ、T。、「高性能データ圧縮の手法」、IEEEコンピューター17（6）、DOI 10.1109/MC.1984.1659158、1984年6月、<https://ieeexplore.ieee.org/document/165915888/>。
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[Altsvc] Nottingham、M.、McManus、P。、およびJ. Reschke、「HTTP代替サービス」、RFC 7838、DOI 10.17487/RFC7838、2016年4月、<https://www.rfc-editor.org/info/RFC7838>。
[BCP13] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
[BCP13] Freed、N。およびJ. Klensin、「多目的インターネットメールエクステンション（MIME）パート4：登録手順」、BCP 13、RFC 4289、2005年12月。
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、2013年1月。
<https://www.rfc-editor.org/info/bcp13>
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012.
[BCP178] Saint-Andre、P.、Crocker、D。、およびM. Nottingham、「アプリケーションプロトコルにおける「X」のプレフィックスと同様のコンストラクトを非難する」、BCP 178、RFC 6648、2012年6月。
<https://www.rfc-editor.org/info/bcp178>
[BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, June 2015.
[BCP35] Thaler、D.、Ed。、Hansen、T.、およびT. Hardie、「URIスキームのガイドラインと登録手順」、BCP 35、RFC 7595、2015年6月。
<https://www.rfc-editor.org/info/bcp35>
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the CRIME Attack", July 2013, <http://breachattack.com/resources/ BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
[違反] Gluck、Y.、Harris、N.、A。Prado、「違反：犯罪攻撃の復活」、2013年7月、<http://breeachatcack.com/resources/ Breach％20-％20SSL、％20GONE％20in％2030％20seconds.pdf>。
[Bujlow] Bujlow, T., Carela-Español, V., Solé-Pareta, J., and P. Barlet-Ros, "A Survey on Web Tracking: Mechanisms, Implications, and Defenses", In Proceedings of the IEEE 105(8), DOI 10.1109/JPROC.2016.2637878, August 2017, <https://doi.org/10.1109/JPROC.2016.2637878>.
[Bujlow] Bujlow、T.、Carela-Español、V.、Solé-Pareta、J。、およびP. Barlet-Ros、「Webトラッキングに関する調査：メカニズム、意味、および防御」、IEEE 105の議事録」（8）、doi 10.1109/jproc.2016.2637878、2017年8月、<https://doi.org/10.1109/jproc.2016.2637878>。
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[Cookie] Barth、A。、「HTTP状態管理メカニズム」、RFC 6265、DOI 10.17487/RFC6265、2011年4月、<https://www.rfc-editor.org/info/rfc6265>。
[Err1912] RFC Errata, Erratum ID 1912, RFC 2978, <https://www.rfc-editor.org/errata/eid1912>.
[ERR1912] RFC ERRATA、ERRATUM ID 1912、RFC 2978、<https://www.rfc-editor.org/errata/eid1912>。
[Err5433] RFC Errata, Erratum ID 5433, RFC 2978, <https://www.rfc-editor.org/errata/eid5433>.
[ERR5433] RFC ERRATA、ERRATUM ID 5433、RFC 2978、<https://www.rfc-editor.org/errata/eid5433>。
[Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D., and V. Shmatikov, "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software", In Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS '12), pp. 38-49, DOI 10.1145/2382196.2382204, October 2012, <https://doi.org/10.1145/2382196.2382204>.
[Georgiev] Georgiev、M.、Iyengar、S.、Jana、S.、Anubhai、R.、Boneh、D。、およびV. Shmatikov、「世界で最も危険なコード：非ブラウザーソフトウェアのSSL証明書の検証"、コンピューターおよび通信セキュリティに関する2012 ACM会議（CCS '12）、pp。38-49、DOI 10.1145/2382196.2382204、2012年10月、<https://doi.org/10.1145/2382196.2382204>
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <https://www.rfc-editor.org/info/rfc7541>.
[HPack] Peon、R。and H. Ruellan、 "HPack：HTTP/2のヘッダー圧縮、RFC 7541、DOI 10.17487/RFC7541、2015年5月、<https://www.rfc-editor.org/info/RFC7541>。
[HTTP/1.0] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 10.17487/RFC1945, May 1996, <https://www.rfc-editor.org/info/rfc1945>.
[HTTP/1.0] Berners-Lee、T.、Fielding、R。、およびH. Frystyk、「HyperText Transfer Protocol-HTTP/1.0」、RFC 1945、DOI 10.17487/RFC1945、1996年5月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc1945>。
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/1.1] Fielding、R.、ed。、Nottingham、M.、ed。、およびJ. Reschke、ed。、 "Http/1.1"、Std 99、RFC 9112、DOI 10.17487/RFC9112、2022年6月、<<https://www.rfc-editor.org/info/rfc9112>。
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.
[HTTP/2] Thomson、M.、ed。and C. Benfield、ed。、「HTTP/2」、RFC 9113、DOI 10.17487/RFC9113、2022年6月、<https://www.rfc-editor.org/info/rfc9113>。
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[HTTP/3] Bishop、M.、ed。、 "HTTP/3"、RFC 9114、DOI 10.17487/RFC9114、2022年6月、<https://www.rfc-editor.org/info/rfc9114>。
[ISO-8859-1] International Organization for Standardization, "Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1", ISO/ IEC 8859-1:1998, 1998.
[ISO-8859-1]国際標準化機関、「情報技術 - 8ビットシングルバイトコード化されたグラフィック文字セット - パート1：ラテンアルファベットNo. 1」、ISO/ IEC 8859-1：1998、1998。
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and Politics", ACM Transactions on Internet Technology 1(2), November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
[Kri2001] Kristol、D。、「HTTP Cookies：標準、プライバシー、政治」、インターネットテクノロジーに関するACMトランザクション1（2）、<http://arxiv.org/abs/cs.se/0105018>。
[OWASP] The Open Web Application Security Project, <https://www.owasp.org/>.
[OWASP] Open Webアプリケーションセキュリティプロジェクト、<https://www.owasp.org/>。
[REST] Fielding, R.T., "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Dissertation, University of California, Irvine, September 2000, <https://roy.gbiv.com/pubs/dissertation/top.htm>.
[REST] Fielding、R.T。、「アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計」、博士論文、カリフォルニア大学アーバイン大学、2000年9月、<https://roy.gbiv.com/pubs/dissertation/top。htm>。
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, DOI 10.17487/RFC1919, March 1996, <https://www.rfc-editor.org/info/rfc1919>.
[RFC1919] Chatel、M。、「古典的と透明なIPプロキシ」、RFC 1919、DOI 10.17487/RFC1919、1996年3月、<https://www.rfc-editor.org/info/rfc1919>。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, <https://www.rfc-editor.org/info/rfc2047>.
[RFC2047]ムーア、K。、「MIME（多目的インターネットメールエクステンション）パート3：非ASCIIテキスト用のメッセージヘッダー拡張機能」、RFC 2047、DOI 10.17487/RFC2047、1996年11月、<https：//www.rfc-editor.org/info/rfc2047>。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, DOI 10.17487/RFC2068, January 1997, <https://www.rfc-editor.org/info/rfc2068>.
[RFC2068] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2068、DOI 10.17487/RFC2068、1月1997、<https://www.rfc-editor.org/info/rfc2068>。
[RFC2145] Mogul, J. C., Fielding, R., Gettys, J., and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, DOI 10.17487/RFC2145, May 1997, <https://www.rfc-editor.org/info/rfc2145>.
[RFC2145] Mogul、J。C.、Fielding、R.、Gettys、J。、およびH. Frystyk、「HTTPバージョン番号の使用と解釈」、RFC 2145、DOI 10.17487/RFC2145、1997年5月、<https：// ww。rfc-editor.org/info/rfc2145>。
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998, <https://www.rfc-editor.org/info/rfc2295>.
[RFC2295] Holtman、K。およびA. Mutz、「HTTPの透明なコンテンツ交渉」、RFC 2295、DOI 10.17487/RFC2295、1998年3月、<https://www.rfc-editor.org/info/rfc2295>
[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, 1 April 1998, <https://www.rfc-editor.org/info/rfc2324>.
[RFC2324] Masinter、L。、「Hyper Text Coffee Pot Control Protocol（HTCPCP/1.0）」、RFC 2324、DOI 10.17487/RFC2324、1998年4月1>。
[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, <https://www.rfc-editor.org/info/rfc2557>.
[RFC2557] Palme、J.、Hopmann、A。、およびN. Shelness、「HTML（MHTML）などの集計文書のMIMEカプセル化」、RFC 2557、DOI 10.17487/RFC2557、1999年3月、<HTTPS：//.rfc-editor.org/info/rfc2557>。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, <https://www.rfc-editor.org/info/rfc2616>.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、DOI 10.17487/RFC2616、1999年6月、<https://www.rfc-editor.org/info/rfc2616>。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, DOI 10.17487/RFC2617, June 1999, <https://www.rfc-editor.org/info/rfc2617>.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、DOI 10.17487/RFC2617、1999年6月、<https://www.rfc-editor.org/info/rfc2617>。
[RFC2774] Nielsen, H., Leach, P., and S. Lawrence, "An HTTP Extension Framework", RFC 2774, DOI 10.17487/RFC2774, February 2000, <https://www.rfc-editor.org/info/rfc2774>.
[RFC2774] Nielsen、H.、Leach、P。、およびS. Lawrence、「HTTP拡張フレームワーク」、RFC 2774、DOI 10.17487/RFC2774、2000年2月、<https://www.rfc-editor.org/info/RFC2774>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、DOI 10.17487/RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <https://www.rfc-editor.org/info/rfc2978>.
[RFC2978] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、DOI 10.17487/RFC2978、2000年10月、<https://www.rfc-editor.org/info/rfc2978>。
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, DOI 10.17487/RFC3040, January 2001, <https://www.rfc-editor.org/info/rfc3040>.
[RFC3040] Cooper、I.、Melve、I.、およびG. Tomlinson、「インターネットWebレプリケーションとキャッシュ分類法」、RFC 3040、DOI 10.17487/RFC3040、2001年1月、<https://www.rfc-editor.org/info/rfc3040>。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>.
[RFC3864] Klyne、G.、Nottingham、M.、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、DOI 10.17487/RFC3864、2004年9月、<https：//www.rfc-editor.org/info/rfc3864>。
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875, October 2004, <https://www.rfc-editor.org/info/rfc3875>.
[RFC3875] Robinson、D。およびK. Coar、「Common Gateway Interface（CGI）バージョン1.1」、RFC 3875、DOI 10.17487/RFC3875、2004年10月、<https://www.rfc-editor.org/info/RFC3875>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、DOI 10.17487/RFC4033、2005年3月、<https：//www.rfc-editor.org/info/rfc4033>。
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, <https://www.rfc-editor.org/info/rfc4559>.
[RFC4559] Jaganathan、K.、Zhu、L。、およびJ. Brezak、「SpnegoベースのKerberosおよびNTLM HTTP認証」、Microsoft Windows」、RFC 4559、DOI 10.17487/RFC4559、2006年6月、<https：// www。rfc-editor.org/info/rfc4559>。
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010, <https://www.rfc-editor.org/info/rfc5789>.
[RFC5789] Dusseault、L。およびJ. Snell、「HTTPのパッチ方法」、RFC 5789、DOI 10.17487/RFC5789、2010年3月、<https://www.rfc-editor.org/info/rfc5789>
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様」、RFC 5905、DOI 10.17487/RFC5905、2010年6月、<https://www.rfc-editor.org/info/rfc5905>。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.
[RFC6454] Barth、A。、「Web Origin Concept」、RFC 6454、DOI 10.17487/RFC6454、2011年12月、<https://www.rfc-editor.org/info/rfc6454>。
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, <https://www.rfc-editor.org/info/rfc6585>.
[RFC6585]ノッティンガム、M。およびR.フィールディング、「追加のHTTPステータスコード」、RFC 6585、DOI 10.17487/RFC6585、2012年4月、<https://www.rfc-editor.org/info/rfc6585>
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R.、ed。and J. Reschke、ed。、「HyperText Transfer Protocol（HTTP/1.1）：メッセージの構文とルーティング」、RFC 7230、DOI 10.17487/RFC7230、2014年6月、<https://www.rfc-editor.org/info/RFC7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、ed。and J. Reschke、ed。、「HyperText Transfer Protocol（HTTP/1.1）：Semantics and Content」、RFC 7231、DOI 10.17487/RFC7231、2014年6月、<https://www.rfc-editor.org/info/RFC7231>。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <https://www.rfc-editor.org/info/rfc7232>.
[RFC7232] Fielding、R.、ed。and J. Reschke、ed。、「HyperText Transfer Protocol（HTTP/1.1）：条件要求」、RFC 7232、DOI 10.17487/RFC7232、2014年6月、<https://www.rfc-editor.org/info/rfc7232>。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <https://www.rfc-editor.org/info/rfc7233>.
[RFC7233] Fielding、R.、Ed。、Ed。、Lafon、Y.、ed。、およびJ. Reschke、ed。、「HyperText Transfer Protocol（HTTP/1.1）：Range Requests」、RFC 7233、DOI 10.17487/RFC7233、6月2014、<https://www.rfc-editor.org/info/rfc7233>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、「HyperText Transfer Protocol（HTTP/1.1）：キャッシュ」、RFC 7234、DOI 10.17487/RFC7234、2014年6月、<https://www.rfc-editor.org/info/rfc7234>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
[RFC7235] Fielding、R.、ed。およびJ. Reschke、ed。、「HyperText Transfer Protocol（HTTP/1.1）：認証」、RFC 7235、DOI 10.17487/RFC7235、2014年6月、<https://www.rfc-editor.org/info/rfc7235>
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, April 2015, <https://www.rfc-editor.org/info/rfc7538>.
[RFC7538] Reschke、J。、「ハイパーテキスト転送プロトコルステータスコード308（永久リダイレクト）」、RFC 7538、DOI 10.17487/RFC7538、2015年4月、<https://www.rfc-editor.org/info/rfc7538>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、ed。、「HyperText Transfer Protocolバージョン2（HTTP/2）」、RFC 7540、DOI 10.17487/RFC7540、2015年5月、<https：///www.rfc-editor.org/info/rfc7540>。
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015, <https://www.rfc-editor.org/info/rfc7578>.
[RFC7578] Masinter、L。、「フォームから値を返す：MultiPart/Form-Data」、RFC 7578、DOI 10.17487/RFC7578、2015年7月、<https://www.rfc-editor.org/info/rfc7578>
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields", RFC 7615, DOI 10.17487/RFC7615, September 2015, <https://www.rfc-editor.org/info/rfc7615>.
[RFC7615] Reschke、J。、「HTTP Authentication-INFOおよびProxy-Authentication-INFO Response Headerフィールド」、RFC 7615、DOI 10.17487/RFC7615、2015年9月、<https：//www.rfc-editor.org/info//RFC7615>。
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC7616] Shekh-Yusef、R.、Ed。、Ahrens、D.、およびS. Bremer、「HTTP Digest Access Authentication」、RFC 7616、DOI 10.17487/RFC7616、2015年9月、<https：//www.rfc-editor.org/info/rfc7616>。
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <https://www.rfc-editor.org/info/rfc7617>.
[RFC7617] Reschke、J。、「「基本」HTTP認証スキーム」、RFC 7617、DOI 10.17487/RFC7617、2015年9月、<https://www.rfc-editor.org/info/rfc7617>
[RFC7694] Reschke, J., "Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding", RFC 7694, DOI 10.17487/RFC7694, November 2015, <https://www.rfc-editor.org/info/rfc7694>.
[RFC7694] Reschke、J。、「ハイパーテキスト転送プロトコル（HTTP）クライアント開始コンテンツエンコード」、RFC 7694、DOI 10.17487/RFC7694、2015年11月、<https：//www.rfc-editor.org/info/rfc7694>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC8187] Reschke, J., "Indicating Character Encoding and Language for HTTP Header Field Parameters", RFC 8187, DOI 10.17487/RFC8187, September 2017, <https://www.rfc-editor.org/info/rfc8187>.
[RFC8187] Reschke、J。、「HTTPヘッダーフィールドパラメーターの文字エンコードと言語を示す」、RFC 8187、DOI 10.17487/RFC8187、2017年9月、<https://www.rfc-editor.org/info/rfc8187>。
[RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246, DOI 10.17487/RFC8246, September 2017, <https://www.rfc-editor.org/info/rfc8246>.
[RFC8246] McManus、P。、「HTTP不変の応答」、RFC 8246、DOI 10.17487/RFC8246、2017年9月、<https://www.rfc-editor.org/info/rfc8246>。
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]ノッティンガム、M。、「Webリンク」、RFC 8288、DOI 10.17487/RFC8288、2017年10月、<https://www.rfc-editor.org/info/rfc8288>。
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", RFC 8336, DOI 10.17487/RFC8336, March 2018, <https://www.rfc-editor.org/info/rfc8336>.
[RFC8336]ノッティンガム、M。およびE.ナイグレン、「オリジンHTTP/2フレーム」、RFC 8336、DOI 10.17487/RFC8336、2018年3月、<https://www.rfc-editor.org/info/rfc8336>
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.
[RFC8615]ノッティンガム、M。、「よく知られているユニフォームリソース識別子（URIS）」、RFC 8615、DOI 10.17487/RFC8615、2019年5月、<https://www.rfc-editor.org/info/rfc8615>
[RFC8941] 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>.
[RFC8941]ノッティンガム、M。およびP-H。Kamp、「HTTPの構造化されたフィールド値」、RFC 8941、DOI 10.17487/RFC8941、2021年2月、<https://www.rfc-editor.org/info/rfc8941>。
[Sniffing] WHATWG, "MIME Sniffing", <https://mimesniff.spec.whatwg.org>.
[スニッフィング] Whatwg、「Mime Sniffing」、<https://mimesniff.spec.whatwg.org>。
[WEBDAV] 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>.
[WebDav] Dusseault、L.、ed。、「Web分散オーサリングおよびバージョン化（WebDav）のHTTP拡張機能」、RFC 4918、DOI 10.17487/RFC4918、2007年6月、<https://www.rfc-editor.org/info/rfc4918>。
In the collected ABNF below, list rules are expanded per Section 5.6.1.
以下の収集されたABNFでは、セクション5.6.1に従ってリストルールが拡張されています。
Accept = [ ( media-range [ weight ] ) *( OWS "," OWS ( media-range [
weight ] ) ) ]
Accept-Charset = [ ( ( token / "*" ) [ weight ] ) *( OWS "," OWS ( (
token / "*" ) [ weight ] ) ) ]
Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [
weight ] ) ) ]
Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS (
language-range [ weight ] ) ) ]
Accept-Ranges = acceptable-ranges
Allow = [ method *( OWS "," OWS method ) ]
Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) ]
Authorization = credentials
BWS = OWS
Connection = [ connection-option *( OWS "," OWS connection-option )
]
Content-Encoding = [ content-coding *( OWS "," OWS content-coding )
]
Content-Language = [ language-tag *( OWS "," OWS language-tag ) ]
Content-Length = 1*DIGIT
Content-Location = absolute-URI / partial-URI
Content-Range = range-unit SP ( range-resp / unsatisfied-range )
Content-Type = media-type
Date = HTTP-date
ETag = entity-tag
Expect = [ expectation *( OWS "," OWS expectation ) ]
From = mailbox
GMT = %x47.4D.54 ; GMT
HTTP-date = IMF-fixdate / obs-date
Host = uri-host [ ":" port ]
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
If-Match = "*" / [ entity-tag *( OWS "," OWS entity-tag ) ]
If-Modified-Since = HTTP-date
If-None-Match = "*" / [ entity-tag *( OWS "," OWS entity-tag ) ]
If-Range = entity-tag / HTTP-date
If-Unmodified-Since = HTTP-date
Last-Modified = HTTP-date Location = URI-reference
last-modified = http-date location = uri-reference
Max-Forwards = 1*DIGIT
OWS = *( SP / HTAB )
Proxy-Authenticate = [ challenge *( OWS "," OWS challenge ) ]
Proxy-Authentication-Info = [ auth-param *( OWS "," OWS auth-param )
]
Proxy-Authorization = credentials
RWS = 1*( SP / HTAB )
Range = ranges-specifier
Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-seconds
Server = product *( RWS ( product / comment ) )
TE = [ t-codings *( OWS "," OWS t-codings ) ]
Trailer = [ field-name *( OWS "," OWS field-name ) ]
URI-reference = <URI-reference, see [URI], Section 4.1>
Upgrade = [ protocol *( OWS "," OWS protocol ) ]
User-Agent = product *( RWS ( product / comment ) )
Vary = [ ( "*" / field-name ) *( OWS "," OWS ( "*" / field-name ) )
]
Via = [ ( received-protocol RWS received-by [ RWS comment ] ) *( OWS
"," OWS ( received-protocol RWS received-by [ RWS comment ] ) ) ]
WWW-Authenticate = [ challenge *( OWS "," OWS challenge ) ]
absolute-URI = <absolute-URI, see [URI], Section 4.3>
absolute-path = 1*( "/" segment )
acceptable-ranges = range-unit *( OWS "," OWS range-unit )
asctime-date = day-name SP date3 SP time-of-day SP year
auth-param = token BWS "=" BWS ( token / quoted-string )
auth-scheme = token
authority = <authority, see [URI], Section 3.2>
challenge = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS ","
OWS auth-param ) ] ) ]
codings = content-coding / "identity" / "*"
comment = "(" *( ctext / quoted-pair / comment ) ")"
complete-length = 1*DIGIT
connection-option = token
content-coding = token
credentials = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS ","
OWS auth-param ) ] ) ]
ctext = HTAB / SP / %x21-27 ; '!'-'''
/ %x2A-5B ; '*'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
date1 = day SP month SP year
date2 = day "-" month "-" 2DIGIT
date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
day = 2DIGIT
day-name = %x4D.6F.6E ; Mon
/ %x54.75.65 ; Tue
/ %x57.65.64 ; Wed
/ %x54.68.75 ; Thu
/ %x46.72.69 ; Fri
/ %x53.61.74 ; Sat
/ %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday
delay-seconds = 1*DIGIT
entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text
expectation = token [ "=" ( token / quoted-string ) parameters ]
field-content = field-vchar [ 1*( SP / HTAB / field-vchar )
field-vchar ]
field-name = token
field-value = *field-content
field-vchar = VCHAR / obs-text
first-pos = 1*DIGIT
hour = 2DIGIT
http-URI = "http://" authority path-abempty [ "?" query ]
https-URI = "https://" authority path-abempty [ "?" query ]
incl-range = first-pos "-" last-pos int-range = first-pos "-" [ last-pos ]
incl-range = first-pos " - " last-pos int-range = first-pos " - " [last-pos]
language-range = <language-range, see [RFC4647], Section 2.1>
language-tag = <Language-Tag, see [RFC5646], Section 2.1>
last-pos = 1*DIGIT
mailbox = <mailbox, see [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) )
parameters
media-type = type "/" subtype parameters
method = token
minute = 2DIGIT
month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar
/ %x41.70.72 ; Apr
/ %x4D.61.79 ; May
/ %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug
/ %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec
obs-date = rfc850-date / asctime-date
obs-text = %x80-FF
opaque-tag = DQUOTE *etagc DQUOTE
other-range = 1*( %x21-2B ; '!'-'+'
/ %x2D-7E ; '-'-'~'
)
parameter = parameter-name "=" parameter-value
parameter-name = token
parameter-value = ( token / quoted-string )
parameters = *( OWS ";" OWS [ parameter ] )
partial-URI = relative-part [ "?" query ]
path-abempty = <path-abempty, see [URI], Section 3.3>
port = <port, see [URI], Section 3.2.3>
product = token [ "/" product-version ]
product-version = token
protocol = protocol-name [ "/" protocol-version ]
protocol-name = token
protocol-version = token
pseudonym = token
qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~'
/ obs-text
query = <query, see [URI], Section 3.4>
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
range-resp = incl-range "/" ( complete-length / "*" )
range-set = range-spec *( OWS "," OWS range-spec )
range-spec = int-range / suffix-range / other-range
range-unit = token
ranges-specifier = range-unit "=" range-set
received-by = pseudonym [ ":" port ]
received-protocol = [ protocol-name "/" ] protocol-version
relative-part = <relative-part, see [URI], Section 4.2>
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
second = 2DIGIT
segment = <segment, see [URI], Section 3.3>
subtype = token
suffix-length = 1*DIGIT
suffix-range = "-" suffix-length
t-codings = "trailers" / ( transfer-coding [ weight ] )
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
time-of-day = hour ":" minute ":" second
token = 1*tchar
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
*"="
transfer-coding = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )
type = token
unsatisfied-range = "*/" complete-length
uri-host = <host, see [URI], Section 3.2.2>
weak = %x57.2F ; W/
weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT
None.
なし。
The sections introducing HTTP's design goals, history, architecture, conformance criteria, protocol versioning, URIs, message routing, and header fields have been moved here.
HTTPの設計目標、履歴、アーキテクチャ、適合基準、プロトコルバージョン、URIS、メッセージルーティング、ヘッダーフィールドを紹介するセクションがここに移動されました。
The requirement on semantic conformance has been replaced with permission to ignore or work around implementation-specific failures. (Section 2.2)
セマンティックコンフォーマンスに関する要件は、実装固有の障害を無視または回避する許可に置き換えられています。（セクション2.2）
The description of an origin and authoritative access to origin servers has been extended for both "http" and "https" URIs to account for alternative services and secured connections that are not necessarily based on TCP. (Sections 4.2.1, 4.2.2, 4.3.1, and 7.3.3)
Originの説明とOriginサーバーへの権威あるアクセスは、「HTTP」と「HTTPS」URIの両方が、必ずしもTCPに基づいていない代替サービスと保護された接続を考慮して拡張されています。（セクション4.2.1、4.2.2、4.3.1、および7.3.3）
Explicit requirements have been added to check the target URI scheme's semantics and reject requests that don't meet any associated requirements. (Section 7.4)
ターゲットURIスキームのセマンティクスをチェックし、関連する要件を満たさない要求を拒否する明示的な要件が追加されています。（セクション7.4）
Parameters in media type, media range, and expectation can be empty via one or more trailing semicolons. (Section 5.6.6)
メディアタイプ、メディア範囲、および期待のパラメーターは、1つ以上の後続のセミコロンを介して空になる可能性があります。（セクション5.6.6）
"Field value" now refers to the value after multiple field lines are combined with commas -- by far the most common use. To refer to a single header line's value, use "field line value". (Section 6.3)
「フィールド値」とは、複数のフィールドラインがコンマと組み合わされた後の値を指し、最も一般的な使用です。単一のヘッダーラインの値を参照するには、「フィールドライン値」を使用します。（セクション6.3）
Trailer field semantics now transcend the specifics of chunked transfer coding. The use of trailer fields has been further limited to allow generation as a trailer field only when the sender knows the field defines that usage and to allow merging into the header section only if the recipient knows the corresponding field definition permits and defines how to merge. In all other cases, implementations are encouraged either to store the trailer fields separately or to discard them instead of merging. (Section 6.5.1)
トレーラーフィールドセマンティクスは、チャンク転送コーディングの詳細を超越しました。予告編フィールドの使用は、フィールドがその使用法を定義していることを知っている場合にのみ、トレーラーフィールドとして生成を許可し、受信者が対応するフィールド定義が許可され、マージする方法を定義する場合にのみ、ヘッダーセクションにマージすることを許可する場合にのみ、さらに制限されています。他のすべての場合、実装は、トレーラーフィールドを個別に保存するか、マージする代わりにそれらを破棄することをお勧めします。（セクション6.5.1）
The priority of the absolute form of the request URI over the Host header field by origin servers has been made explicit to align with proxy handling. (Section 7.2)
Origin Serversによるホストヘッダーフィールドに対するリクエストURIの絶対形式の優先順位は、プロキシ処理と一致するように明示されています。（セクション7.2）
The grammar definition for the Via field's "received-by" was expanded in RFC 7230 due to changes in the URI grammar for host [URI] that are not desirable for Via. For simplicity, we have removed uri-host from the received-by production because it can be encompassed by the existing grammar for pseudonym. In particular, this change removed comma from the allowed set of characters for a host name in received-by. (Section 7.6.3)
VIAの「受信」の文法定義は、VIAには望ましくないホスト[URI]のURI文法の変更により、RFC 7230で拡張されました。簡単にするために、既存の文法が仮名のために包囲できるため、URI-Hostを受信した制作から削除しました。特に、この変更により、受信者のホスト名の許可された文字セットからコンマが削除されました。（セクション7.6.3）
Minimum URI lengths to be supported by implementations are now recommended. (Section 4.1)
実装によってサポートされる最小URIの長さが推奨されます。（セクション4.1）
The following have been clarified: CR and NUL in field values are to be rejected or mapped to SP, and leading and trailing whitespace needs to be stripped from field values before they are consumed. (Section 5.5)
以下は明確にされています。フィールド値のCRとNULは、SPに拒否またはマッピングされることになり、導入された後続の白文学は、消費される前にフィールド値から剥奪する必要があります。（セクション5.5）
Parameters in media type, media range, and expectation can be empty via one or more trailing semicolons. (Section 5.6.6)
メディアタイプ、メディア範囲、および期待のパラメーターは、1つ以上の後続のセミコロンを介して空になる可能性があります。（セクション5.6.6）
An abstract data type for HTTP messages has been introduced to define the components of a message and their semantics as an abstraction across multiple HTTP versions, rather than in terms of the specific syntax form of HTTP/1.1 in [HTTP/1.1], and reflect the contents after the message is parsed. This makes it easier to distinguish between requirements on the content (what is conveyed) versus requirements on the messaging syntax (how it is conveyed) and avoids baking limitations of early protocol versions into the future of HTTP. (Section 6)
[HTTP/1.1]のHTTP/1.1の特定の構文形式ではなく、メッセージのコンポーネントとそれらのセマンティクスを複数のHTTPバージョンにわたって抽象化として定義するために、HTTPメッセージの抽象データ型が導入され、反映されます。メッセージの後の内容は解析されます。これにより、コンテンツの要件（伝達されるもの）とメッセージング構文の要件（伝達方法）を簡単に区別し、初期プロトコルバージョンのベーキング制限をHTTPの将来に回避できます。（セクション6）
The terms "payload" and "payload body" have been replaced with "content", to better align with its usage elsewhere (e.g., in field names) and to avoid confusion with frame payloads in HTTP/2 and HTTP/3. (Section 6.4)
「ペイロード」と「ペイロード本体」という用語は、「コンテンツ」に置き換えられ、他の場所（たとえば、フィールド名で）の使用とより適切に整合し、HTTP/2およびHTTP/3のフレームペイロードとの混乱を避けます。（セクション6.4）
The term "effective request URI" has been replaced with "target URI". (Section 7.1)
「効果的なリクエストURI」という用語は、「ターゲットURI」に置き換えられました。（セクション7.1）
Restrictions on client retries have been loosened to reflect implementation behavior. (Section 9.2.2)
クライアントレトリの制限は、実装の動作を反映するように緩められています。（セクション9.2.2）
The fact that request bodies on GET, HEAD, and DELETE are not interoperable has been clarified. (Sections 9.3.1, 9.3.2, and 9.3.5)
Get、Head、および削除のリクエスト機が相互運用できないという事実が明確にされています。（セクション9.3.1、9.3.2、および9.3.5）
The use of the Content-Range header field (Section 14.4) as a request modifier on PUT is allowed. (Section 9.3.4)
Putのリクエスト修飾子としてのコンテンツレンジヘッダーフィールド（セクション14.4）の使用が許可されています。（セクション9.3.4）
A superfluous requirement about setting Content-Length has been removed from the description of the OPTIONS method. (Section 9.3.7)
コンテンツレングスの設定に関する余分な要件は、オプションメソッドの説明から削除されました。（セクション9.3.7）
The normative requirement to use the "message/http" media type in TRACE responses has been removed. (Section 9.3.8)
トレース応答で「メッセージ/HTTP」メディアタイプを使用するための規範的要件が削除されました。（セクション9.3.8）
List-based grammar for Expect has been restored for compatibility with RFC 2616. (Section 10.1.1)
RFC 2616との互換性のために、予想のためのリストベースの文法が復元されました。（セクション10.1.1）
Accept and Accept-Encoding are allowed in response messages; the latter was introduced by [RFC7694]. (Section 12.3)
応答メッセージでは、受け入れおよび受け入れエンコードが許可されています。後者は[RFC7694]によって導入されました。（セクション12.3）
"Accept Parameters" (accept-params and accept-ext ABNF production) have been removed from the definition of the Accept field. (Section 12.5.1)
「受け入れパラメーター」（Accept-ParamsおよびAccept-Ext ABNF生産）は、Acceptフィールドの定義から削除されました。（セクション12.5.1）
The Accept-Charset field is now deprecated. (Section 12.5.2)
受け入れられたフィールドは現在廃止されました。（セクション12.5.2）
The semantics of "*" in the Vary header field when other values are present was clarified. (Section 12.5.5)
他の値が存在するときの変化するヘッダーフィールドの「*」のセマンティクスが明確になりました。（セクション12.5.5）
Range units are compared in a case-insensitive fashion. (Section 14.1)
レンジユニットは、ケースに依存しない方法で比較されます。（セクション14.1）
The use of the Accept-Ranges field is not restricted to origin servers. (Section 14.3)
Accept-Rangesフィールドの使用は、Origin Serversに制限されていません。（セクション14.3）
The process of creating a redirected request has been clarified. (Section 15.4)
リダイレクトされたリクエストを作成するプロセスは明らかにされています。（セクション15.4）
Status code 308 (previously defined in [RFC7538]) has been added so that it's defined closer to status codes 301, 302, and 307. (Section 15.4.9)
ステータスコード308（[RFC7538]で以前に定義）が追加されているため、ステータスコード301、302、および307に近いと定義されています。（セクション15.4.9）
Status code 421 (previously defined in Section 9.1.2 of [RFC7540]) has been added because of its general applicability. 421 is no longer defined as heuristically cacheable since the response is specific to the connection (not the target resource). (Section 15.5.20)
ステータスコード421（[RFC7540]のセクション9.1.2で以前に定義）は、その一般的な適用性のために追加されました。421は、応答が接続に固有の（ターゲットリソースではない）ため、ヒューリスト的にキャッシュ可能であると定義されなくなります。（セクション15.5.20）
Status code 422 (previously defined in Section 11.2 of [WEBDAV]) has been added because of its general applicability. (Section 15.5.21)
ステータスコード422（[WebDav]のセクション11.2で以前に定義されていた）は、その一般的な適用性のために追加されました。（セクション15.5.21）
Previous revisions of HTTP imposed an arbitrary 60-second limit on the determination of whether Last-Modified was a strong validator to guard against the possibility that the Date and Last-Modified values are generated from different clocks or at somewhat different times during the preparation of the response. This specification has relaxed that to allow reasonable discretion. (Section 8.8.2.2)
HTTPの以前の改訂版は、ラスト修飾が行われたかどうかの決定に60秒の制限が課され、日付とラスト修飾値が異なる時計から生成される可能性を防ぐための強力なバリデーターであるか、または幾分異なる時期に生成される可能性を守ることができました。応答。この仕様は、合理的な裁量を可能にするためにそれを緩和しました。（セクション8.8.2.2）
An edge-case requirement on If-Match and If-Unmodified-Since has been removed that required a validator not to be sent in a 2xx response if validation fails because the change request has already been applied. (Sections 13.1.1 and 13.1.4)
If-MatchおよびIf-Unmodified-Sinceのエッジケースの要件は、変更要求が既に適用されているために検証が失敗した場合、検証が2xx応答で送信されないように検証装置を必要とする必要があるため、削除されました。（セクション13.1.1および13.1.4）
The fact that If-Unmodified-Since does not apply to a resource without a concept of modification time has been clarified. (Section 13.1.4)
If-Unmodified-Sinceが変更時間の概念なしにリソースに適用されないという事実は明らかにされています。（セクション13.1.4）
Preconditions can now be evaluated before the request content is processed rather than waiting until the response would otherwise be successful. (Section 13.2)
リクエストコンテンツが処理される前に、応答が成功するまで待機するのではなく、前提条件を評価できるようになりました。（セクション13.2）
Refactored the range-unit and ranges-specifier grammars to simplify and reduce artificial distinctions between bytes and other (extension) range units, removing the overlapping grammar of other-range-unit by defining range units generically as a token and placing extensions within the scope of a range-spec (other-range). This disambiguates the role of list syntax (commas) in all range sets, including extension range units, for indicating a range-set of more than one range. Moving the extension grammar into range specifiers also allows protocol specific to byte ranges to be specified separately.
レンジユニットと範囲の範囲の文法をリファクタリングして、バイトと他の（拡張）範囲ユニット間の人工的な区別を簡素化および削減し、トークンとしてレンジユニットを一般的に定義し、スコープ内に拡張機能を配置することにより、他の範囲ユニットの重複文法を削除しますレンジスペック（その他範囲）の。これは、複数の範囲の範囲セットを示すために、拡張レンジユニットを含むすべての範囲セットにおけるリスト構文（コンマ）の役割を曖昧にします。拡張文法を範囲仕様に移動すると、バイト範囲に固有のプロトコルを個別に指定することもできます。
It is now possible to define Range handling on extension methods. (Section 14.2)
現在、拡張メソッドの範囲処理を定義することができます。（セクション14.2）
Described use of the Content-Range header field (Section 14.4) as a request modifier to perform a partial PUT. (Section 14.5)
部分的なプットを実行するための要求修飾子として、コンテンツレンジヘッダーフィールド（セクション14.4）の使用を説明しました。（セクション14.5）
None.
なし。
None.
なし。
None.
なし。
This specification includes the extension defined in [RFC7694] but leaves out examples and deployment considerations.
この仕様には、[RFC7694]で定義されている拡張機能が含まれますが、例と展開の考慮事項を除外します。
Acknowledgements
謝辞
Aside from the current editors, the following individuals deserve special recognition for their contributions to early aspects of HTTP and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys, Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris, Henrik Frystyk Nielsen, Dave Raggett, Eric Rescorla, Tony Sanders, Lawrence C. Stewart, Marc VanHeyningen, and Steve Zilles.
現在の編集者とは別に、次の個人は、HTTPの初期の側面とそのコア仕様への貢献に対して特別な認識に値します：Marc Andreessen、Tim Berners-Lee、Robert Cailliau、Daniel W. Connolly、Bob Denny、John Franks、Jim Gettys、ジャン・フランソワ・グロフ、フィリップ・M・ハラム・ベーカー、ケーン・ホルトマン、ジェフリー・L・ホステラー、シェル・カパン、デイブ・クリストル、イヴ・ラフォン、スコット・D・ローレンス、ポール・J・リーチ、ホーコン・Wロブ・マックール、ジェフリー・C・モーグル、ルー・モントゥリ、デビッド・モリス、ヘンリック・フライスティク・ニールセン、デイブ・ラゲット、エリック・レスカラ、トニー・サンダース、ローレンス・C・スチュワート、マーク・ヴァンヘイニンン、スティーブ・ジレス。
This document builds on the many contributions that went into past specifications of HTTP, including [HTTP/1.0], [RFC2068], [RFC2145], [RFC2616], [RFC2617], [RFC2818], [RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235]. The acknowledgements within those documents still apply.
このドキュメントは、[HTTP/1.0]、[RFC2068]、[RFC2145]、[RFC2616]、[RFC2617]、[RFC2818]、[RFC2818]、[RFC7230]、[RFC7231]、[RFC2818]、[RFC2818]、[RFC7231]を含む、HTTPの過去の仕様になった多くの貢献に基づいて構築されています。[RFC7232]、[RFC7233]、[RFC7234]、および[RFC7235]。これらのドキュメント内の謝辞は引き続き適用されます。
Since 2014, the following contributors have helped improve this specification by reporting bugs, asking smart questions, drafting or reviewing text, and evaluating issues:
2014年以来、次の貢献者は、バグを報告し、スマートな質問をし、テキストの起草やレビュー、問題の評価により、この仕様の改善に役立ちます。
Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron Duby, Asanka Herath, Asbjørn Ulsberg, Asta Olofsson, Attila Gulyas, Austin Wright, Barry Pollard, Ben Burkert, Benjamin Kaduk, Björn Höhrmann, Brad Fitzpatrick, Chris Pacejo, Colin Bendell, Cory Benfield, Cory Nelson, Daisuke Miyakawa, Dale Worley, Daniel Stenberg, Danil Suits, David Benjamin, David Matson, David Schinazi, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric Rescorla, Éric Vyncke, Erik Kline, Erwin Pe, Etan Kissling, Evert Pot, Evgeny Vrublevsky, Florian Best, Francesca Palombini, Igor Lubashev, James Callahan, James Peach, Jeffrey Yasskin, Kalin Gyokov, Kannan Goundan, 奥 一穂 (Kazuho Oku), Ken Murchison, Krzysztof Maczyński, Lars Eggert, Lucas Pardue, Martin Duke, Martin Dürst, Martin Thomson, Martynas Jusevičius, Matt Menke, Matthias Pigulla, Mattias Grenfeldt, Michael Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Mohit Sethi, Murray Kucherawy, Nathaniel J. Smith, Nicholas Hurley, Nikita Prokhorov, Patrick McManus, Piotr Sikora, Poul-Henning Kamp, Rick van Rein, Robert Wilton, Roberto Polli, Roman Danyliw, Samuel Williams, Semyon Kholodnov, Simon Pieters, Simon Schüppel, Stefan Eissing, Taylor Hunt, Todd Greer, Tommy Pauly, Vasiliy Faronov, Vladimir Lashchev, Wenbo Zhu, William A. Rowe Jr., Willy Tarreau, Xingwei Liu, Yishuai Li, and Zaheduzzaman Sarker.
アラン・エガートン、アレックス・ルウスコフ、アミチャイ・ロスマン、アモス・ジェフリーズ、アンダース・カセオルグ、アンドレアス・ゲバルト、アン・ヴァン・ケスター、アーミン・アブファルター、アロン・デュービー、アサンカ・ヘラート、アスビョルン・ウルスバーグ、アスタ・オロフスソン、ベン・ライト、ベン・ライト、ベン・ライト、ベン・ライト。 Kaduk、BjörnHöhrmann、Brad Fitzpatrick、Chris Pacejo、Colin Bendell、Cory Benfield、Cory Nelson、Miyakawa、Dale Worley、Daniel Stenberg、Danil Suit、David Benjamin、David Matson、David Schinazi 、エリック・レスコルラ、エリック・ヴィンケ、エリック・クライン、アーウィン・PE、エタン・キスリング、エバート・ポット、エヴゲニー・ヴゲニー・ヴルーブスキー、フロリアン・ベスト、フランチェスカ・パロンビニ、イゴール・ルバシェフ、ジェームズ・キャラハン、ジェームズ・ピーチ、ジェフリー・ヤスキン、カリン・ギョンコフ、カンナン・ギンダン、 Oku）、Ken Murchison、KrzysztofMaczyński、Lars Eggert、Lucas Pardue、Martin Duke、MartinDürst、Martin Thomson、Martynas Jusevichius、Matt Menke、Matthias Pigulla、Mattias Grenfeldt、Mike Bishopov、Mike Bishopov、Mike Bishopov、Mike Bishopov、Mike Bishopov、Mike Bishopov 、モヒトセティ、マレー・クチェラウィー、ナサニエル・J・スミス、ニコラス・ハーレー、ニキータ・プロホロフ、パトリック・マクマナス、ピオトル・シコラ、ポール・ヘニング・カンプ、リック・ヴァン・レイン、ロバート・ウィルトン、ロベルト・ポリ、ローマ・ダニエル、サミュエル・ウィリアムズ、セミオン・クロドノフ、シモン・ペイタンSchüppel、Stefan Eissing、Taylor Hunt、Todd Greer、Tommy Pauly、Vasiliy Faronov、Vladimir Lashchev、Wenbo Zhu、William A. Rowe Jr.、Willy Tarreau、Xingwei Liu、Yishuai Li、Zaheduzzaman Sarkerer。
Index
索引
1 2 3 4 5 A B C D E F G H I L M N O P R S T U V W X
1 2 3 4 5 a b c d e f g h i l m n o p r s t u v w x
1
1
100 Continue (status code) *_Section 15.2.1_*
100-continue (expect value) *_Section 10.1.1_*
101 Switching Protocols (status code) *_Section 15.2.2_*
1xx Informational (status code class) *_Section 15.2_*
2
2
200 OK (status code) *_Section 15.3.1_*
201 Created (status code) *_Section 15.3.2_*
202 Accepted (status code) *_Section 15.3.3_*
203 Non-Authoritative Information (status code) *_Section 15.3
.4_*
204 No Content (status code) *_Section 15.3.5_*
205 Reset Content (status code) *_Section 15.3.6_*
206 Partial Content (status code) *_Section 15.3.7_*
2xx Successful (status code class) *_Section 15.3_*
3
3
300 Multiple Choices (status code) *_Section 15.4.1_*
301 Moved Permanently (status code) *_Section 15.4.2_*
302 Found (status code) *_Section 15.4.3_*
303 See Other (status code) *_Section 15.4.4_*
304 Not Modified (status code) *_Section 15.4.5_*
305 Use Proxy (status code) *_Section 15.4.6_*
306 (Unused) (status code) *_Section 15.4.7_*
307 Temporary Redirect (status code) *_Section 15.4.8_*
308 Permanent Redirect (status code) *_Section 15.4.9_*
3xx Redirection (status code class) *_Section 15.4_*
4
4
400 Bad Request (status code) *_Section 15.5.1_*
401 Unauthorized (status code) *_Section 15.5.2_*
402 Payment Required (status code) *_Section 15.5.3_*
403 Forbidden (status code) *_Section 15.5.4_*
404 Not Found (status code) *_Section 15.5.5_*
405 Method Not Allowed (status code) *_Section 15.5.6_*
406 Not Acceptable (status code) *_Section 15.5.7_*
407 Proxy Authentication Required (status code) *_Section 15.5
.8_*
408 Request Timeout (status code) *_Section 15.5.9_*
409 Conflict (status code) *_Section 15.5.10_*
410 Gone (status code) *_Section 15.5.11_*
411 Length Required (status code) *_Section 15.5.12_*
412 Precondition Failed (status code) *_Section 15.5.13_*
413 Content Too Large (status code) *_Section 15.5.14_*
414 URI Too Long (status code) *_Section 15.5.15_*
415 Unsupported Media Type (status code) *_Section 15.5.16_*
416 Range Not Satisfiable (status code) *_Section 15.5.17_*
417 Expectation Failed (status code) *_Section 15.5.18_*
418 (Unused) (status code) *_Section 15.5.19_*
421 Misdirected Request (status code) *_Section 15.5.20_*
422 Unprocessable Content (status code) *_Section 15.5.21_*
426 Upgrade Required (status code) *_Section 15.5.22_*
4xx Client Error (status code class) *_Section 15.5_*
5
5
500 Internal Server Error (status code) *_Section 15.6.1_*
501 Not Implemented (status code) *_Section 15.6.2_*
502 Bad Gateway (status code) *_Section 15.6.3_*
503 Service Unavailable (status code) *_Section 15.6.4_*
504 Gateway Timeout (status code) *_Section 15.6.5_*
505 HTTP Version Not Supported (status code) *_Section 15.6.6_
*
5xx Server Error (status code class) *_Section 15.6_*
A
a
accelerator *_Section 3.7, Paragraph 6_*
Accept header field *_Section 12.5.1_*
Accept-Charset header field *_Section 12.5.2_*
Accept-Encoding header field *_Section 12.5.3_*
Accept-Language header field *_Section 12.5.4_*
Accept-Ranges header field *_Section 14.3_*
Allow header field *_Section 10.2.1_*
Authentication-Info header field *_Section 11.6.3_*
authoritative response *_Section 17.1_*
Authorization header field *_Section 11.6.2_*
B
b
browser *_Section 3.5_*
ブラウザ *_Section 3.5_ *
C
c
cache *_Section 3.8_*
cacheable *_Section 3.8, Paragraph 4_*
client *_Section 3.3_*
clock *_Section 5.6.7_*
complete *_Section 6.1_*
compress (Coding Format) Section 8.4.1.1
compress (content coding) *_Section 8.4.1_*
conditional request *_Section 13_*
CONNECT method *_Section 9.3.6_*
connection *_Section 3.3_*
Connection header field *_Section 7.6.1_*
content Section 6.4
content coding *_Section 8.4.1_*
content negotiation Section 1.3, Paragraph 4
Content-Encoding header field *_Section 8.4_*
Content-Language header field *_Section 8.5_*
Content-Length header field *_Section 8.6_*
Content-Location header field *_Section 8.7_*
Content-MD5 header field *_Section 18.4, Paragraph 10_*
Content-Range header field *_Section 14.4_*; Section 14.5
Content-Type header field *_Section 8.3_*
control data *_Section 6.2_*
D
d
Date header field *_Section 6.6.1_*
deflate (Coding Format) Section 8.4.1.2
deflate (content coding) *_Section 8.4.1_*
DELETE method *_Section 9.3.5_*
Delimiters Section 5.6.2, Paragraph 3
downstream *_Section 3.7, Paragraph 4_*
E
e
effective request URI *_Section 7.1, Paragraph 8.1_*
ETag field *_Section 8.8.3_*
Expect header field *_Section 10.1.1_*
F
f
field *_Section 5_*; Section 6.3
field line Section 5.2, Paragraph 1
field line value Section 5.2, Paragraph 1
field name Section 5.2, Paragraph 1
field value Section 5.2, Paragraph 2
Fields
* *_Section 18.4, Paragraph 9_*
Accept *_Section 12.5.1_*
Accept-Charset *_Section 12.5.2_*
Accept-Encoding *_Section 12.5.3_*
Accept-Language *_Section 12.5.4_*
Accept-Ranges *_Section 14.3_*
Allow *_Section 10.2.1_*
Authentication-Info *_Section 11.6.3_*
Authorization *_Section 11.6.2_*
Connection *_Section 7.6.1_*
Content-Encoding *_Section 8.4_*
Content-Language *_Section 8.5_*
Content-Length *_Section 8.6_*
Content-Location *_Section 8.7_*
Content-MD5 *_Section 18.4, Paragraph 10_*
Content-Range *_Section 14.4_*; Section 14.5
Content-Type *_Section 8.3_*
Date *_Section 6.6.1_*
ETag *_Section 8.8.3_*
Expect *_Section 10.1.1_*
From *_Section 10.1.2_*
Host *_Section 7.2_*
If-Match *_Section 13.1.1_*
If-Modified-Since *_Section 13.1.3_*
If-None-Match *_Section 13.1.2_*
If-Range *_Section 13.1.5_*
If-Unmodified-Since *_Section 13.1.4_*
Last-Modified *_Section 8.8.2_*
Location *_Section 10.2.2_*
Max-Forwards *_Section 7.6.2_*
Proxy-Authenticate *_Section 11.7.1_*
Proxy-Authentication-Info *_Section 11.7.3_*
Proxy-Authorization *_Section 11.7.2_*
Range *_Section 14.2_*
Referer *_Section 10.1.3_*
Retry-After *_Section 10.2.3_*
Server *_Section 10.2.4_*
TE *_Section 10.1.4_*
Trailer *_Section 6.6.2_*
Upgrade *_Section 7.8_*
User-Agent *_Section 10.1.5_*
Vary *_Section 12.5.5_*
Via *_Section 7.6.3_*
WWW-Authenticate *_Section 11.6.1_*
Fragment Identifiers Section 4.2.5
From header field *_Section 10.1.2_*
G
g
gateway *_Section 3.7, Paragraph 6_*
GET method *_Section 9.3.1_*
Grammar
ALPHA *_Section 2.1_*
Accept *_Section 12.5.1_*
Accept-Charset *_Section 12.5.2_*
Accept-Encoding *_Section 12.5.3_*
Accept-Language *_Section 12.5.4_*
Accept-Ranges *_Section 14.3_*
Allow *_Section 10.2.1_*
Authentication-Info *_Section 11.6.3_*
Authorization *_Section 11.6.2_*
BWS *_Section 5.6.3_*
CR *_Section 2.1_*
CRLF *_Section 2.1_*
CTL *_Section 2.1_*
Connection *_Section 7.6.1_*
Content-Encoding *_Section 8.4_*
Content-Language *_Section 8.5_*
Content-Length *_Section 8.6_*
Content-Location *_Section 8.7_*
Content-Range *_Section 14.4_*
Content-Type *_Section 8.3_*
DIGIT *_Section 2.1_*
DQUOTE *_Section 2.1_*
Date *_Section 6.6.1_*
ETag *_Section 8.8.3_*
Expect *_Section 10.1.1_*
From *_Section 10.1.2_*
GMT *_Section 5.6.7_*
HEXDIG *_Section 2.1_*
HTAB *_Section 2.1_*
HTTP-date *_Section 5.6.7_*
Host *_Section 7.2_*
IMF-fixdate *_Section 5.6.7_*
If-Match *_Section 13.1.1_*
If-Modified-Since *_Section 13.1.3_*
If-None-Match *_Section 13.1.2_*
If-Range *_Section 13.1.5_*
If-Unmodified-Since *_Section 13.1.4_*
LF *_Section 2.1_*
Last-Modified *_Section 8.8.2_*
Location *_Section 10.2.2_*
Max-Forwards *_Section 7.6.2_*
OCTET *_Section 2.1_*
OWS *_Section 5.6.3_*
Proxy-Authenticate *_Section 11.7.1_*
Proxy-Authentication-Info *_Section 11.7.3_*
Proxy-Authorization *_Section 11.7.2_*
RWS *_Section 5.6.3_*
Range *_Section 14.2_*
Referer *_Section 10.1.3_*
Retry-After *_Section 10.2.3_*
SP *_Section 2.1_*
Server *_Section 10.2.4_*
TE *_Section 10.1.4_*
Trailer *_Section 6.6.2_*
URI-reference *_Section 4.1_*
Upgrade *_Section 7.8_*
User-Agent *_Section 10.1.5_*
VCHAR *_Section 2.1_*
Vary *_Section 12.5.5_*
Via *_Section 7.6.3_*
WWW-Authenticate *_Section 11.6.1_*
absolute-URI *_Section 4.1_*
absolute-path *_Section 4.1_*
acceptable-ranges *_Section 14.3_*
asctime-date *_Section 5.6.7_*
auth-param *_Section 11.2_*
auth-scheme *_Section 11.1_*
authority *_Section 4.1_*
challenge *_Section 11.3_*
codings *_Section 12.5.3_*
comment *_Section 5.6.5_*
complete-length *_Section 14.4_*
connection-option *_Section 7.6.1_*
content-coding *_Section 8.4.1_*
credentials *_Section 11.4_*
ctext *_Section 5.6.5_*
date1 *_Section 5.6.7_*
day *_Section 5.6.7_*
day-name *_Section 5.6.7_*
day-name-l *_Section 5.6.7_*
delay-seconds *_Section 10.2.3_*
entity-tag *_Section 8.8.3_*
etagc *_Section 8.8.3_*
field-content *_Section 5.5_*
field-name *_Section 5.1_*; Section 6.6.2
field-value *_Section 5.5_*
field-vchar *_Section 5.5_*
first-pos *_Section 14.1.1_*; Section 14.4
hour *_Section 5.6.7_*
http-URI *_Section 4.2.1_*
https-URI *_Section 4.2.2_*
incl-range *_Section 14.4_*
int-range *_Section 14.1.1_*
language-range *_Section 12.5.4_*
language-tag *_Section 8.5.1_*
last-pos *_Section 14.1.1_*; Section 14.4
media-range *_Section 12.5.1_*
media-type *_Section 8.3.1_*
method *_Section 9.1_*
minute *_Section 5.6.7_*
month *_Section 5.6.7_*
obs-date *_Section 5.6.7_*
obs-text *_Section 5.5_*
opaque-tag *_Section 8.8.3_*
other-range *_Section 14.1.1_*
parameter *_Section 5.6.6_*
parameter-name *_Section 5.6.6_*
parameter-value *_Section 5.6.6_*
parameters *_Section 5.6.6_*
partial-URI *_Section 4.1_*
port *_Section 4.1_*
product *_Section 10.1.5_*
product-version *_Section 10.1.5_*
protocol-name *_Section 7.6.3_*
protocol-version *_Section 7.6.3_*
pseudonym *_Section 7.6.3_*
qdtext *_Section 5.6.4_*
query *_Section 4.1_*
quoted-pair *_Section 5.6.4_*
quoted-string *_Section 5.6.4_*
qvalue *_Section 12.4.2_*
range-resp *_Section 14.4_*
range-set *_Section 14.1.1_*
range-spec *_Section 14.1.1_*
range-unit *_Section 14.1_*
ranges-specifier *_Section 14.1.1_*
received-by *_Section 7.6.3_*
received-protocol *_Section 7.6.3_*
rfc850-date *_Section 5.6.7_*
second *_Section 5.6.7_*
segment *_Section 4.1_*
subtype *_Section 8.3.1_*
suffix-length *_Section 14.1.1_*
suffix-range *_Section 14.1.1_*
t-codings *_Section 10.1.4_*
tchar *_Section 5.6.2_*
time-of-day *_Section 5.6.7_*
token *_Section 5.6.2_*
token68 *_Section 11.2_*
transfer-coding *_Section 10.1.4_*
transfer-parameter *_Section 10.1.4_*
type *_Section 8.3.1_*
unsatisfied-range *_Section 14.4_*
uri-host *_Section 4.1_*
weak *_Section 8.8.3_*
weight *_Section 12.4.2_*
year *_Section 5.6.7_*
gzip (Coding Format) Section 8.4.1.3
gzip (content coding) *_Section 8.4.1_*
H
h
HEAD method *_Section 9.3.2_*
Header Fields
Accept *_Section 12.5.1_*
Accept-Charset *_Section 12.5.2_*
Accept-Encoding *_Section 12.5.3_*
Accept-Language *_Section 12.5.4_*
Accept-Ranges *_Section 14.3_*
Allow *_Section 10.2.1_*
Authentication-Info *_Section 11.6.3_*
Authorization *_Section 11.6.2_*
Connection *_Section 7.6.1_*
Content-Encoding *_Section 8.4_*
Content-Language *_Section 8.5_*
Content-Length *_Section 8.6_*
Content-Location *_Section 8.7_*
Content-MD5 *_Section 18.4, Paragraph 10_*
Content-Range *_Section 14.4_*; Section 14.5
Content-Type *_Section 8.3_*
Date *_Section 6.6.1_*
ETag *_Section 8.8.3_*
Expect *_Section 10.1.1_*
From *_Section 10.1.2_*
Host *_Section 7.2_*
If-Match *_Section 13.1.1_*
If-Modified-Since *_Section 13.1.3_*
If-None-Match *_Section 13.1.2_*
If-Range *_Section 13.1.5_*
If-Unmodified-Since *_Section 13.1.4_*
Last-Modified *_Section 8.8.2_*
Location *_Section 10.2.2_*
Max-Forwards *_Section 7.6.2_*
Proxy-Authenticate *_Section 11.7.1_*
Proxy-Authentication-Info *_Section 11.7.3_*
Proxy-Authorization *_Section 11.7.2_*
Range *_Section 14.2_*
Referer *_Section 10.1.3_*
Retry-After *_Section 10.2.3_*
Server *_Section 10.2.4_*
TE *_Section 10.1.4_*
Trailer *_Section 6.6.2_*
Upgrade *_Section 7.8_*
User-Agent *_Section 10.1.5_*
Vary *_Section 12.5.5_*
Via *_Section 7.6.3_*
WWW-Authenticate *_Section 11.6.1_*
header section *_Section 6.3_*
Host header field *_Section 7.2_*
http URI scheme *_Section 4.2.1_*
https URI scheme *_Section 4.2.2_*
I
私
idempotent *_Section 9.2.2_*
If-Match header field *_Section 13.1.1_*
If-Modified-Since header field *_Section 13.1.3_*
If-None-Match header field *_Section 13.1.2_*
If-Range header field *_Section 13.1.5_*
If-Unmodified-Since header field *_Section 13.1.4_*
inbound *_Section 3.7, Paragraph 4_*
incomplete *_Section 6.1_*
interception proxy *_Section 3.7, Paragraph 10_*
intermediary *_Section 3.7_*
L
l
Last-Modified header field *_Section 8.8.2_* list-based field Section 5.5, Paragraph 7 Location header field *_Section 10.2.2_*
ラスト変更ヘッダーフィールド *_Section 8.8.2_ *リストベースのフィールドセクション5.5、パラグラフ7ロケーションヘッダーフィールド *_Section 10.2.2_ *
M
m
Max-Forwards header field *_Section 7.6.2_*
Media Type
multipart/byteranges *_Section 14.6_*
multipart/x-byteranges Section 14.6, Paragraph 4, Item 3
message Section 3.4; *_Section 6_*
message abstraction *_Section 6_*
messages *_Section 3.4_*
metadata *_Section 8.8_*
Method
* *_Section 18.2, Paragraph 3_*
CONNECT *_Section 9.3.6_*
DELETE *_Section 9.3.5_*
GET *_Section 9.3.1_*
HEAD *_Section 9.3.2_*
OPTIONS *_Section 9.3.7_*
POST *_Section 9.3.3_*
PUT *_Section 9.3.4_*
TRACE *_Section 9.3.8_*
multipart/byteranges Media Type *_Section 14.6_*
multipart/x-byteranges Media Type Section 14.6, Paragraph 4,
Item 3
N
n
non-transforming proxy *_Section 7.7_*
非変換プロキシ *_Section 7.7_ *
O
o
OPTIONS method *_Section 9.3.7_*
origin *_Section 4.3.1_*; Section 11.5
origin server *_Section 3.6_*
outbound *_Section 3.7, Paragraph 4_*
P
p
phishing *_Section 17.1_*
POST method *_Section 9.3.3_*
Protection Space Section 11.5
proxy *_Section 3.7, Paragraph 5_*
Proxy-Authenticate header field *_Section 11.7.1_*
Proxy-Authentication-Info header field *_Section 11.7.3_*
Proxy-Authorization header field *_Section 11.7.2_*
PUT method *_Section 9.3.4_*
R
r
Range header field *_Section 14.2_*
Realm Section 11.5
recipient *_Section 3.4_*
Referer header field *_Section 10.1.3_*
representation *_Section 3.2_*
request *_Section 3.4_*
request target *_Section 7.1_*
resource *_Section 3.1_*; Section 4
response *_Section 3.4_*
Retry-After header field *_Section 10.2.3_*
reverse proxy *_Section 3.7, Paragraph 6_*
S
s
safe *_Section 9.2.1_*
satisfiable range *_Section 14.1.1_*
secured *_Section 4.2.2_*
selected representation *_Section 3.2, Paragraph 4_*;
Section 8.8; Section 13.1
self-descriptive *_Section 6_*
sender *_Section 3.4_*
server *_Section 3.3_*
Server header field *_Section 10.2.4_*
singleton field Section 5.5, Paragraph 6
spider *_Section 3.5_*
Status Code Section 15
Status Codes
Final Section 15, Paragraph 7
Informational Section 15, Paragraph 7
Interim Section 15, Paragraph 7
Status Codes Classes
1xx Informational *_Section 15.2_*
2xx Successful *_Section 15.3_*
3xx Redirection *_Section 15.4_*
4xx Client Error *_Section 15.5_*
5xx Server Error *_Section 15.6_*
T
t
target resource *_Section 7.1_*
target URI *_Section 7.1_*
TE header field *_Section 10.1.4_*
TRACE method *_Section 9.3.8_*
Trailer Fields *_Section 6.5_*
ETag *_Section 8.8.3_*
Trailer header field *_Section 6.6.2_*
trailer section *_Section 6.5_*
trailers *_Section 6.5_*
transforming proxy *_Section 7.7_*
transparent proxy *_Section 3.7, Paragraph 10_*
tunnel *_Section 3.7, Paragraph 8_*
U
u
unsatisfiable range *_Section 14.1.1_*
Upgrade header field *_Section 7.8_*
upstream *_Section 3.7, Paragraph 4_*
URI *_Section 4_*
origin *_Section 4.3.1_*
URI reference *_Section 4.1_*
URI scheme
http *_Section 4.2.1_*
https *_Section 4.2.2_*
user agent *_Section 3.5_*
User-Agent header field *_Section 10.1.5_*
V
v
validator *_Section 8.8_*
strong *_Section 8.8.1_*
weak *_Section 8.8.1_*
Vary header field *_Section 12.5.5_*
Via header field *_Section 7.6.3_*
W
w
WWW-Authenticate header field *_Section 11.6.1_*
www-authenticateヘッダーフィールド *_セクション11.6.1_ *
X
バツ
x-compress (content coding) *_Section 8.4.1_*
x-gzip (content coding) *_Section 8.4.1_*
Authors' Addresses
著者のアドレス
Roy T. Fielding (editor) Adobe 345 Park Ave San Jose, CA 95110 United States of America Email: fielding@gbiv.com URI: https://roy.gbiv.com/
Roy T. Fielding（編集者）Adobe 345 Park Ave San Jose、CA 95110アメリカ合衆国電子メール：Fielding@gbiv.com URI：https：//roy.gbiv.com/
Mark Nottingham (editor) Fastly Prahran Australia Email: mnot@mnot.net URI: https://www.mnot.net/
マーク・ノッティンガム（編集者）急速にPrahran Australiaメール：mnot@mnot.net uri：https：//www.mnot.net/
Julian Reschke (editor)
greenbytes GmbH
Hafenweg 16
48155 Münster
Germany
Email: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/