[要約] RFC 7231は、Hypertext Transfer Protocol (HTTP/1.1)に関するセマンティクス（意味論）とコンテンツに焦点を当てた文書です。このRFCは、HTTPプロトコルがどのようにリソースの表現を定義し、転送するかについての基本的なルールと概念を提供します。主に、HTTPメソッド（GET, POSTなど）、ステータスコード（200 OK, 404 Not Foundなど）、メッセージの構造と意味論について定義しています。このRFCは、Web開発者やアプリケーション設計者がHTTPを正しく理解し、効果的に利用するための基礎を築きます。関連するRFCには、RFC 7230（HTTP/1.1のメッセージ構文とルーティング）、RFC 7232（条件付きリクエスト）、RFC 7233（範囲リクエスト）、RFC 7234（キャッシュ）、RFC 7235（認証）などがあります。
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7231 Adobe
Obsoletes: 2616 J. Reschke, Ed.
Updates: 2817 greenbytes
Category: Standards Track June 2014
ISSN: 2070-1721
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
ハイパーテキスト転送プロトコル（HTTP / 1.1）：セマンティクスとコンテンツ
Abstract
概要
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.
ハイパーテキスト転送プロトコル（HTTP）は、分散型の協調型ハイパーテキスト情報システム用のステートレスアプリケーションレベルプロトコルです。このドキュメントでは、リクエストメソッド、リクエストヘッダーフィールド、レスポンスステータスコード、レスポンスヘッダーフィールドで表されるHTTP / 1.1メッセージのセマンティクスを、メッセージのペイロード（メタデータと本文のコンテンツ）とコンテンツネゴシエーションのメカニズムとともに定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7231.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7231で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................6
1.1. Conformance and Error Handling .............................6
1.2. Syntax Notation ............................................6
2. Resources .......................................................7
3. Representations .................................................7
3.1. Representation Metadata ....................................8
3.1.1. Processing Representation Data ......................8
3.1.2. Encoding for Compression or Integrity ..............11
3.1.3. Audience Language ..................................13
3.1.4. Identification .....................................14
3.2. Representation Data .......................................17
3.3. Payload Semantics .........................................17
3.4. Content Negotiation .......................................18
3.4.1. Proactive Negotiation ..............................19
3.4.2. Reactive Negotiation ...............................20
4. Request Methods ................................................21
4.1. Overview ..................................................21
4.2. Common Method Properties ..................................22
4.2.1. Safe Methods .......................................22
4.2.2. Idempotent Methods .................................23
4.2.3. Cacheable Methods ..................................24
4.3. Method Definitions ........................................24
4.3.1. GET ................................................24
4.3.2. HEAD ...............................................25
4.3.3. POST ...............................................25
4.3.4. PUT ................................................26
4.3.5. DELETE .............................................29
4.3.6. CONNECT ............................................30
4.3.7. OPTIONS ............................................31
4.3.8. TRACE ..............................................32
5. Request Header Fields ..........................................33
5.1. Controls ..................................................33
5.1.1. Expect .............................................34
5.1.2. Max-Forwards .......................................36
5.2. Conditionals ..............................................36
5.3. Content Negotiation .......................................37
5.3.1. Quality Values .....................................37
5.3.2. Accept .............................................38
5.3.3. Accept-Charset .....................................40
5.3.4. Accept-Encoding ....................................41
5.3.5. Accept-Language ....................................42
5.4. Authentication Credentials ................................44
5.5. Request Context ...........................................44
5.5.1. From ...............................................44
5.5.2. Referer ............................................45
5.5.3. User-Agent .........................................46
6. Response Status Codes ..........................................47
6.1. Overview of Status Codes ..................................48
6.2. Informational 1xx .........................................50
6.2.1. 100 Continue .......................................50
6.2.2. 101 Switching Protocols ............................50
6.3. Successful 2xx ............................................51
6.3.1. 200 OK .............................................51
6.3.2. 201 Created ........................................52
6.3.3. 202 Accepted .......................................52
6.3.4. 203 Non-Authoritative Information ..................52
6.3.5. 204 No Content .....................................53
6.3.6. 205 Reset Content ..................................53
6.4. Redirection 3xx ...........................................54
6.4.1. 300 Multiple Choices ...............................55
6.4.2. 301 Moved Permanently ..............................56
6.4.3. 302 Found ..........................................56
6.4.4. 303 See Other ......................................57
6.4.5. 305 Use Proxy ......................................58
6.4.6. 306 (Unused) .......................................58
6.4.7. 307 Temporary Redirect .............................58
6.5. Client Error 4xx ..........................................58
6.5.1. 400 Bad Request ....................................58
6.5.2. 402 Payment Required ...............................59
6.5.3. 403 Forbidden ......................................59
6.5.4. 404 Not Found ......................................59
6.5.5. 405 Method Not Allowed .............................59
6.5.6. 406 Not Acceptable .................................60
6.5.7. 408 Request Timeout ................................60
6.5.8. 409 Conflict .......................................60
6.5.9. 410 Gone ...........................................60
6.5.10. 411 Length Required ...............................61
6.5.11. 413 Payload Too Large .............................61
6.5.12. 414 URI Too Long ..................................61
6.5.13. 415 Unsupported Media Type ........................62
6.5.14. 417 Expectation Failed ............................62
6.5.15. 426 Upgrade Required ..............................62
6.6. Server Error 5xx ..........................................62
6.6.1. 500 Internal Server Error ..........................63
6.6.2. 501 Not Implemented ................................63
6.6.3. 502 Bad Gateway ....................................63
6.6.4. 503 Service Unavailable ............................63
6.6.5. 504 Gateway Timeout ................................63
6.6.6. 505 HTTP Version Not Supported .....................64
7. Response Header Fields .........................................64
7.1. Control Data ..............................................64
ed 7.1.1. Origination Date ...................................65
7.1.2. Location ...........................................68
7.1.3. Retry-After ........................................69
7.1.4. Vary ...............................................70
7.2. Validator Header Fields ...................................71
7.3. Authentication Challenges .................................72
7.4. Response Context ..........................................72
7.4.1. Allow ..............................................72
7.4.2. Server .............................................73
8. IANA Considerations ............................................73
8.1. Method Registry ...........................................73
8.1.1. Procedure ..........................................74
8.1.2. Considerations for New Methods .....................74
8.1.3. Registrations ......................................75
8.2. Status Code Registry ......................................75
8.2.1. Procedure ..........................................75
8.2.2. Considerations for New Status Codes ................76
8.2.3. Registrations ......................................76
8.3. Header Field Registry .....................................77
8.3.1. Considerations for New Header Fields ...............78
8.3.2. Registrations ......................................80
8.4. Content Coding Registry ...................................81
8.4.1. Procedure ..........................................81
8.4.2. Registrations ......................................81
9. Security Considerations ........................................81
9.1. Attacks Based on File and Path Names ......................82
9.2. Attacks Based on Command, Code, or Query Injection ........82
9.3. Disclosure of Personal Information ........................83
9.4. Disclosure of Sensitive Information in URIs ...............83
9.5. Disclosure of Fragment after Redirects ....................84
9.6. Disclosure of Product Information .........................84
9.7. Browser Fingerprinting ....................................84
10. Acknowledgments ...............................................85
11. References ....................................................85
11.1. Normative References .....................................85
11.2. Informative References ...................................86
Appendix A. Differences between HTTP and MIME .....................89
A.1. MIME-Version ..............................................89
A.2. Conversion to Canonical Form ..............................89
A.3. Conversion of Date Formats ................................90
A.4. Conversion of Content-Encoding ............................90
A.5. Conversion of Content-Transfer-Encoding ...................90
A.6. MHTML and Line Length Limitations .........................90
Appendix B. Changes from RFC 2616 .................................91
Appendix C. Imported ABNF .........................................93
Appendix D. Collected ABNF ........................................94
Index .............................................................97
Each Hypertext Transfer Protocol (HTTP) message is either a request or a response. A server listens on a connection for a request, parses each message received, interprets the message semantics in relation to the identified request target, and responds to that request with one or more response messages. A client constructs request messages to communicate specific intentions, examines received responses to see if the intentions were carried out, and determines how to interpret the results. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in [RFC7230].
各ハイパーテキスト転送プロトコル（HTTP）メッセージは、要求または応答のいずれかです。サーバーは接続の要求をリッスンし、受信した各メッセージを解析し、識別された要求ターゲットに関連してメッセージのセマンティクスを解釈し、1つ以上の応答メッセージでその要求に応答します。クライアントは、特定の意図を伝える要求メッセージを作成し、受信した応答を調べて意図が実行されたかどうかを確認し、結果を解釈する方法を決定します。このドキュメントは、[RFC7230]で定義されたアーキテクチャの観点から、HTTP / 1.1の要求と応答のセマンティクスを定義しています。
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (Section 3).
HTTPは、表現の操作と転送（セクション3）を介して、そのタイプ、性質、または実装に関係なく、リソース（セクション2）と対話するための統一されたインターフェースを提供します。
HTTP semantics include the intentions defined by each request method (Section 4), extensions to those semantics that might be described in request header fields (Section 5), the meaning of status codes to indicate a machine-readable response (Section 6), and the meaning of other control data and resource metadata that might be given in response header fields (Section 7).
HTTPセマンティクスには、各リクエストメソッドで定義された意図（セクション4）、リクエストヘッダーフィールドで説明される可能性があるセマンティクスの拡張（セクション5）、機械可読応答を示すステータスコードの意味（セクション6）、および応答ヘッダーフィールドで提供される可能性のある他の制御データとリソースメタデータの意味（セクション7）。
This document also defines representation metadata that describe how a payload is intended to be interpreted by a recipient, the request header fields that might influence content selection, and the various selection algorithms that are collectively referred to as "content negotiation" (Section 3.4).
このドキュメントでは、ペイロードが受信者によってどのように解釈されるかを表す表現メタデータ、コンテンツの選択に影響を与える可能性のあるリクエストヘッダーフィールド、および「コンテンツネゴシエーション」と総称されるさまざまな選択アルゴリズムも定義しています（セクション3.4）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].
エラー処理に関する適合基準と考慮事項は、[RFC7230]のセクション2.5で定義されています。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix C describes rules imported from other documents. Appendix D shows the collected grammar with all list operators expanded to standard ABNF notation.
この仕様では、[RFC7230]のセクション7で定義されているリスト拡張子付きの[RFC5234]の拡張バッカスナウア記法（ABNF）表記を使用して、「＃」演算子を使用したコンマ区切りリストのコンパクトな定義を可能にしています（ 「*」演算子が繰り返しを示す方法）。付録Cでは、他のドキュメントからインポートされたルールについて説明します。付録Dは、すべてのリスト演算子が標準のABNF表記に拡張された、収集された文法を示しています。
This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in [RFC6365].
この仕様では、[RFC6365]で定義されている「文字」、「文字コード化スキーム」、「charset」、「プロトコル要素」という用語を使用しています。
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. Each resource is identified by a Uniform Resource Identifier (URI), as described in Section 2.7 of [RFC7230].
HTTPリクエストのターゲットは「リソース」と呼ばれます。 HTTPはリソースの性質を制限しません。リソースとの対話に使用される可能性のあるインターフェースを定義するだけです。 [RFC7230]のセクション2.7で説明されているように、各リソースはUniform Resource Identifier（URI）によって識別されます。
When a client constructs an HTTP/1.1 request message, it sends the target URI in one of various forms, as defined in (Section 5.3 of [RFC7230]). When a request is received, the server reconstructs an effective request URI for the target resource (Section 5.5 of [RFC7230]).
クライアントがHTTP / 1.1リクエストメッセージを作成すると、（[RFC7230]のセクション5.3）で定義されているように、さまざまな形式のいずれかでターゲットURIを送信します。リクエストを受信すると、サーバーはターゲットリソースの有効なリクエストURIを再構築します（[RFC7230]のセクション5.5）。
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 4) and a few request-modifying header fields (Section 5). If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in Section 4.2.1, the method semantics take precedence.
HTTPの設計目標の1つは、リソースの識別を要求のセマンティクスから分離することです。これは、要求のセマンティクスを要求メソッド（セクション4）といくつかの要求変更ヘッダーフィールド（セクション5）に付与することで可能になります。セクション4.2.1で説明されているように、メソッドのセマンティクスとURI自体が暗示するセマンティクスの間に矛盾がある場合、メソッドのセマンティクスが優先されます。
Considering that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through which one can observe and act upon such a thing only through the communication of messages to some independent actor on the other side, an abstraction is needed to represent ("take the place of") the current or desired state of that thing in our communications. That abstraction is called a representation [REST].
リソースは何でもかまいませんし、HTTPによって提供される統一されたインターフェースは、反対側の独立したアクターへのメッセージの通信を通じてのみそのような事柄を観察および操作できるウィンドウに似ていることを考えると、抽象化は私たちのコミュニケーションにおいて、その事物の現在の状態または望ましい状態を表す（「代わる」）必要があります。その抽象化は表現[REST]と呼ばれます。
For the purposes of HTTP, 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, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.
HTTPの目的では、「表現」は、特定のリソースの過去、現在、または望ましい状態を反映することを目的とした情報であり、プロトコルを介して容易に通信できる形式であり、一連の表現で構成されます。メタデータと表現データの潜在的に無制限のストリーム。
An origin server might be provided with, or be capable of generating, multiple representations that are each intended to reflect the current state of a target resource. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to a given request, usually based on content negotiation. This "selected representation" is used to provide the data and metadata for evaluating conditional requests [RFC7232] and constructing the payload for 200 (OK) and 304 (Not Modified) responses to GET (Section 4.3.1).
オリジンサーバーには、ターゲットリソースの現在の状態を反映することを目的とした複数の表現が用意されているか、生成できる場合があります。このような場合、通常はコンテンツネゴシエーションに基づいて、特定のリクエストに最も適切なものとしてこれらの表現の1つを選択するために、オリジンサーバーが何らかのアルゴリズムを使用します。この「選択された表現」は、条件付きリクエスト[RFC7232]を評価し、GET（セクション4.3.1）に対する200（OK）および304（Not Modified）応答のペイロードを構築するためのデータとメタデータを提供するために使用されます。
Representation header fields provide metadata about the representation. When a message includes a payload body, the representation header fields describe how to interpret the representation data enclosed in the payload body. In a response to a HEAD request, the representation header fields describe the representation data that would have been enclosed in the payload body if the same request had been a GET.
表現ヘッダーフィールドは、表現に関するメタデータを提供します。メッセージにペイロード本体が含まれている場合、表現ヘッダーフィールドは、ペイロード本体で囲まれた表現データの解釈方法を記述します。 HEAD要求への応答では、表現ヘッダーフィールドは、同じ要求がGETであった場合にペイロード本体に含まれるであろう表現データを記述します。
The following header fields convey representation metadata:
次のヘッダーフィールドは、表現メタデータを伝達します。
+-------------------+-----------------+
| Header Field Name | Defined in... |
+-------------------+-----------------+
| Content-Type | Section 3.1.1.5 |
| Content-Encoding | Section 3.1.2.2 |
| Content-Language | Section 3.1.3.2 |
| Content-Location | Section 3.1.4.2 |
+-------------------+-----------------+
HTTP uses Internet media types [RFC2046] in the Content-Type (Section 3.1.1.5) and Accept (Section 5.3.2) 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 each context in which it is received.
HTTPは、Content-Type（セクション3.1.1.5）およびAccept（セクション5.3.2）ヘッダーフィールドでインターネットメディアタイプ[RFC2046]を使用して、オープンで拡張可能なデータタイプとタイプネゴシエーションを提供します。メディアタイプは、データ形式とさまざまな処理モデルの両方を定義します。つまり、受信した各コンテキストに従ってデータを処理する方法です。
media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token
subtype = token
The type/subtype MAY be followed by parameters in the form of name=value pairs.
タイプ/サブタイプの後には、名前=値のペアの形式のパラメータが続く場合があります。
parameter = token "=" ( token / quoted-string )
The type, subtype, and parameter name tokens are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. 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.
タイプ、サブタイプ、およびパラメータ名のトークンでは、大文字と小文字が区別されません。パラメータ名のセマンティクスに応じて、パラメータ値は大文字と小文字を区別する場合としない場合があります。メディアタイプレジストリ内の定義によっては、パラメータの有無がメディアタイプの処理にとって重要になる場合があります。
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. For example, the following examples are all equivalent, but the first is preferred for consistency:
トークン生成と一致するパラメーター値は、トークンとして、または引用文字列内で送信できます。引用符付きと引用符なしの値は同等です。たとえば、次の例はすべて同等ですが、一貫性を保つために最初の例が推奨されます。
text/html;charset=utf-8
text/html;charset=UTF-8
Text/HTML;Charset="utf-8"
text/html; charset="utf-8"
Internet media types ought to be registered with IANA according to the procedures defined in [BCP13].
インターネットメディアタイプは、[BCP13]で定義されている手順に従ってIANAに登録する必要があります。
Note: Unlike some similar constructs in other header fields, media type parameters do not allow whitespace (even "bad" whitespace) around the "=" character.
注：他のヘッダーフィールドのいくつかの同様の構成とは異なり、メディアタイプパラメーターでは、「=」文字の前後に空白（「悪い」空白であっても）を使用できません。
HTTP uses charset names to indicate or negotiate the character encoding scheme of a textual representation [RFC6365]. A charset is identified by a case-insensitive token.
HTTPは文字セット名を使用して、テキスト表現の文字エンコーディングスキームを示したり交渉したりします[RFC6365]。文字セットは、大文字と小文字を区別しないトークンによって識別されます。
charset = token
文字セット=トークン
Charset names ought to be registered in the IANA "Character Sets" registry (<http://www.iana.org/assignments/character-sets>) according to the procedures defined in [RFC2978].
文字セット名は、[RFC2978]で定義されている手順に従って、IANAの「文字セット」レジストリ（<http://www.iana.org/assignments/character-sets>）に登録する必要があります。
Internet media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see Appendix A).
インターネットメディアタイプは、さまざまなネイティブエンコーディング形式のシステム間で相互運用できるように、標準形式で登録されます。多目的インターネットメール拡張機能（MIME）[RFC2045]で説明されているのと同じ理由の多くにより、HTTP経由で選択または転送された表現は、正規の形式である必要があります。ただし、電子メールの展開（つまり、ピアへのメッセージの保存と転送）のパフォーマンス特性は、HTTPおよびWeb（サーバーベースの情報サービス）に共通するものとは大きく異なります。さらに、古いメール転送プロトコルとの互換性のためのMIMEの制約は、HTTPには適用されません（付録Aを参照）。
MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break. HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation. An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF. In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively. This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the payload body (e.g., header fields).
MIMEの標準形式では、「テキスト」タイプのメディアサブタイプでCRLFをテキストの改行として使用する必要があります。 HTTPは、改行が表現全体で一貫している場合に、改行を表すプレーンCRまたはLFのみのテキストメディアの転送を許可します。 HTTP送信者は生成でき、受信者はCRLF、ベアCR、またはベアLFで構成されるテキストメディアの改行を解析できる必要があります。さらに、HTTPのテキストメディアは、CRとLFにそれぞれオクテット13と10を使用する文字セットに限定されません。改行に関するこの柔軟性は、「テキスト」メディアタイプが割り当てられている表現内のテキストにのみ適用されます。 「マルチパート」タイプやペイロード本体の外部のHTTP要素（ヘッダーフィールドなど）には適用されません。
If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded.
表現がコンテンツコーディングでエンコードされている場合、基礎となるデータは、エンコードされる前に上記で定義された形式である必要があります。
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 payload. For example, the "multipart/form-data" type is often used for carrying form data in a request, as described in [RFC2388], and the "multipart/ byteranges" type is defined by this specification for use in some 206 (Partial Content) responses [RFC7233].
HTTPメッセージフレーミングでは、ペイロードを生成または処理する実装で使用される場合がありますが、マルチパート境界をメッセージ本文の長さのインジケータとして使用しません。たとえば、[RFC2388]で説明されているように、「multipart / form-data」タイプはリクエストでフォームデータを運ぶためによく使用され、「multipart / byteranges」タイプは一部の206（Partial内容）応答[RFC7233]。
The "Content-Type" header field indicates the media type of the associated representation: either the representation enclosed in the message payload 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」ヘッダーフィールドは、関連付けられた表現のメディアタイプを示します。メッセージペイロードで囲まれた表現または選択された表現のいずれかであり、メッセージセマンティクスによって決定されます。示されたメディアタイプは、Content-Encodingで示されたコンテンツコーディングがデコードされた後、受信したメッセージセマンティクスの範囲内で、データ形式と受信者によるデータの処理方法の両方を定義します。
Content-Type = media-type
Content-Type = media-type
Media types are defined in Section 3.1.1.1. An example of the field is
メディアタイプはセクション3.1.1.1で定義されています。フィールドの例は
Content-Type: text/html; charset=ISO-8859-4
A sender that generates a message containing a payload body 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.
ペイロード本体を含むメッセージを生成する送信者は、囲まれた表現の意図されたメディアタイプが送信者にとって不明でない限り、そのメッセージにContent-Typeヘッダーフィールドを生成する必要があります（SHOULD）。 Content-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, with the result that some clients will examine a payload's content and override the specified type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.
実際には、リソースの所有者は常に特定の表現に対して正しいContent-Typeを提供するように元のサーバーを適切に構成するわけではありません。その結果、一部のクライアントはペイロードのコンテンツを調べ、指定されたタイプをオーバーライドします。これを行うクライアントは、誤った結論を引き出すリスクがあり、追加のセキュリティリスク（「特権昇格」など）を露呈する可能性があります。さらに、データ形式を調べることによって送信者の意図を判断することは不可能です。多くのデータ形式は、処理の意味だけが異なる複数のメディアタイプと一致します。実装者は、このような「コンテンツスニッフィング」を使用するときに無効にする手段を提供することをお勧めします。
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.
コンテンツコーディングの値は、表現に適用された、または表現に適用できるエンコーディング変換を示します。コンテンツコーディングは主に、その基礎となるメディアタイプのIDを失うことなく、また情報を失うことなく、表現を圧縮またはその他の方法で有効に変換できるようにするために使用されます。多くの場合、表現はコード化された形式で保存され、直接送信され、最終的な受信者によってのみデコードされます。
content-coding = token
content-coding =トークン
All content-coding values are case-insensitive and ought to be registered within the "HTTP Content Coding Registry", as defined in Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) and Content-Encoding (Section 3.1.2.2) header fields.
すべてのコンテンツコーディング値は、大文字と小文字を区別せず、セクション8.4で定義されている「HTTPコンテンツコーディングレジストリ」内に登録する必要があります。これらはAccept-Encoding（セクション5.3.4）およびContent-Encoding（セクション3.1.2.2）ヘッダーフィールドで使用されます。
The following content-coding values are defined by this specification:
次のコンテンツコーディング値は、この仕様で定義されています。
compress (and x-compress): See Section 4.2.1 of [RFC7230].
圧縮（およびx-compress）：[RFC7230]のセクション4.2.1を参照してください。
deflate: See Section 4.2.2 of [RFC7230].
deflate：[RFC7230]のセクション4.2.2を参照してください。
gzip (and x-gzip): See Section 4.2.3 of [RFC7230].
gzip（およびx-gzip）：[RFC7230]のセクション4.2.3を参照してください。
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-によって参照されるメディアタイプのデータを取得するためにどのデコードメカニズムを適用する必要があるかを示します。タイプヘッダーフィールド。 Content-Encodingは主に、基になるメディアタイプのIDを失うことなく、表現のデータを圧縮できるようにするために使用されます。
Content-Encoding = 1#content-coding
Content-Encoding = 1＃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. Additional information about the encoding parameters can be provided by other header fields not defined by this specification.
1つ以上のエンコーディングが表現に適用されている場合、エンコーディングを適用した送信者は、コンテンツコーディングが適用された順序でリストするContent-Encodingヘッダーフィールドを生成する必要があります。エンコーディングパラメータに関する追加情報は、この仕様で定義されていない他のヘッダーフィールドから提供できます。
Unlike Transfer-Encoding (Section 3.3.1 of [RFC7230]), 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.
Transfer-Encoding（[RFC7230]のセクション3.3.1）とは異なり、Content-Encodingにリストされているコーディングは表現の特性です。表現はコード化された形式で定義され、表現に関する他のすべてのメタデータは、メタデータ定義で特に明記されていない限り、コード化された形式に関するものです。通常、表現は、レンダリングまたは類似の使用の直前にのみデコードされます。
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つと同じアルゴリズムであっても、そのエンコーディングはContent-Encodingで再表現されません。このようなコンテンツコーディングは、何らかの奇妙な理由により、2回目に適用されて表現を形成する場合にのみリストされます。同様に、オリジンサーバーは、コーディングがContent-TypeまたはContent-Encodingの一部として定義されているかどうかのみが異なる複数の表現として同じデータを公開することを選択する場合があります。 、コンテンツの自動解凍とレンダリングの代わりに「名前を付けて保存」ダイアログを開きます）。
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.
オリジンサーバーは、リクエストメッセージの表現に受け入れられないコンテンツコーディングがある場合、ステータスコード415（サポートされていないメディアタイプ）で応答してもよい（MAY）。
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 5.3.5, whereas Content-Language uses the language-tag production defined below.
HTTPはAccept-LanguageおよびContent-Languageヘッダーフィールド内の言語タグを使用します。 Accept-Languageは、セクション5.3.5で定義されているより広い言語範囲の生成を使用しますが、Content-Languageは、以下で定義されている言語タグの生成を使用します。
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:
言語タグは、1つ以上の大文字と小文字を区別しないサブタグのシーケンスであり、それぞれがハイフン文字（ "-"、％x2D）で区切られています。ほとんどの場合、言語タグは、関連する言語の幅広いファミリを識別する一次言語サブタグ（例： "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-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」ヘッダーフィールドは、表現の対象となる視聴者の自然言語を記述します。これは、表現内で使用されるすべての言語と同等ではない場合があることに注意してください。
Content-Language = 1#language-tag
Content-Language = 1＃language-tag
Language tags are defined in Section 3.1.3.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
言語タグはセクション3.1.3.1で定義されています。 Content-Languageの主な目的は、ユーザーが自分の好みの言語に従って表現を識別および区別できるようにすることです。したがって、コンテンツがデンマークの識字者向けである場合、適切なフィールドは
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.
Content-Languageが指定されていない場合、デフォルトでは、コンテンツはすべての言語の対象ユーザーを対象としています。これは、送信者がそれを自然言語に固有であると見なしていないこと、または送信者が意図する言語がわからないことを意味している可能性があります。
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
コンテンツ言語：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".
ただし、表現内に複数の言語が存在するからといって、それが複数の言語の対象者を対象としていることを意味するわけではありません。例としては、「ラテン語の最初のレッスン」などの初心者向けの言語入門がありますが、これは明らかに英語の知識のある読者が使用することを目的としています。この場合、Content-Languageには「en」のみが適切に含まれます。
Content-Language MAY be applied to any media type -- it is not limited to textual documents.
Content-Languageは、あらゆるメディアタイプに適用できます（テキストドキュメントに限定されません）。
When a complete or partial representation is transferred in a message payload, it is often desirable for the sender to supply, or the recipient to determine, an identifier for a resource corresponding to that representation.
完全または部分的な表現がメッセージペイロードで転送される場合、送信者がその表現に対応するリソースの識別子を提供するか、受信者が決定することが望ましい場合がよくあります。
For a request message:
リクエストメッセージの場合：
o If the request has a Content-Location header field, then the sender asserts that the payload 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.
o リクエストにContent-Locationヘッダーフィールドがある場合、送信者はペイロードがContent-Locationフィールドの値で識別されるリソースの表現であることを表明します。ただし、そのようなアサーションは、他の方法（この仕様では定義されていません）で検証できない限り信頼できません。この情報は、改訂履歴のリンクに役立つ場合があります。
o Otherwise, the payload is unidentified.
o それ以外の場合、ペイロードは識別されません。
For a response message, the following rules are applied in order until a match is found:
応答メッセージの場合、一致が見つかるまで、次のルールが順番に適用されます。
1. If the request method is GET or HEAD and the response status code is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not Modified), the payload is a representation of the resource identified by the effective request URI (Section 5.5 of [RFC7230]).
1. 要求メソッドがGETまたはHEADで、応答ステータスコードが200（OK）、204（コンテンツなし）、206（部分的コンテンツ）、または304（変更なし）の場合、ペイロードは、有効なリクエストURI（[RFC7230]のセクション5.5）。
2. If the request method is GET or HEAD and the response status code is 203 (Non-Authoritative Information), the payload is a potentially modified or enhanced representation of the target resource as provided by an intermediary.
2. リクエストメソッドがGETまたはHEADで、レスポンスステータスコードが203（非権威情報）の場合、ペイロードは、仲介者によって提供されるターゲットリソースの潜在的に変更または拡張された表現です。
3. If the response has a Content-Location header field and its field-value is a reference to the same URI as the effective request URI, the payload is a representation of the resource identified by the effective request URI.
3. 応答にContent-Locationヘッダーフィールドがあり、そのフィールド値が有効なリクエストURIと同じURIへの参照である場合、ペイロードは、有効なリクエストURIによって識別されるリソースの表現です。
4. If the response has a Content-Location header field and its field-value is a reference to a URI different from the effective request URI, then the sender asserts that the payload 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).
4. 応答にContent-Locationヘッダーフィールドがあり、そのフィールド値が有効な要求URIとは異なるURIへの参照である場合、送信者はペイロードがContent-Locationフィールド値によって識別されるリソースの表現であることを表明します。 。ただし、そのようなアサーションは、他の方法（この仕様では定義されていません）で検証できない限り信頼できません。
5. Otherwise, the payload is unidentified.
5. それ以外の場合、ペイロードは識別されません。
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 payload. 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 payload in this message.
「Content-Location」ヘッダーフィールドは、このメッセージのペイロードの表現に対応する特定のリソースの識別子として使用できるURIを参照します。つまり、このメッセージの生成時にこのURIでGET要求を実行した場合、200（OK）応答には、このメッセージのペイロードとして囲まれたものと同じ表現が含まれます。
Content-Location = absolute-URI / partial-URI
Content-Location =絶対URI /部分URI
The Content-Location value is not a replacement for the effective Request URI (Section 5.5 of [RFC7230]). 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.
Content-Location値は、有効なリクエストURIの代わりにはなりません（[RFC7230]のセクション5.5）。表現メタデータです。 [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 effective request URI, then the recipient MAY consider the payload to be a current representation of that resource at the time indicated by the message origination date. For a GET (Section 4.3.1) or HEAD (Section 4.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 4.3.4) or POST (Section 4.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.
Content-Locationが2xx（Successful）応答メッセージに含まれていて、その値が（絶対形式への変換後に）有効な要求URIと同じURIを参照している場合、受信者はペイロードを現在の表現と見なしてもよい（MAY）メッセージの作成日で示される時間におけるそのリソースの。 GET（セクション4.3.1）またはHEAD（セクション4.3.2）リクエストの場合、これはサーバーからContent-Locationが提供されない場合のデフォルトのセマンティクスと同じです。 PUT（セクション4.3.4）またはPOST（セクション4.3.3）のような状態変更リクエストの場合、サーバーの応答にそのリソースの新しい表現が含まれていることを意味し、それによりアクションについてのみレポートする可能性のある表現（例：「うまくいった！」）。これにより、オーサリングアプリケーションは、後続のGETリクエストを必要とせずにローカルコピーを更新できます。
If Content-Location is included in a 2xx (Successful) response message and its field-value refers to a URI that differs from the effective request 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.
Content-Locationが2xx（Successful）応答メッセージに含まれており、そのフィールド値が有効な要求URIとは異なるURIを参照している場合、オリジンサーバーは、URIが囲まれているに対応する別のリソースの識別子であると主張します。表現。このような要求は、両方の識別子が同じリソース所有者を共有している場合にのみ信頼できます。これは、HTTPを介してプログラムで決定することはできません。
o For a response to a GET or HEAD request, this is an indication that the effective request 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.
o GETまたはHEAD要求への応答の場合、これは、有効な要求URIがコンテンツネゴシエーションの対象となるリソースを参照しており、Content-Locationフィールド値が選択した表現のより具体的な識別子であることを示します。
o 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 payload is a current representation of the newly created resource.
o 状態変更メソッドに対する201（Created）応答の場合、Location-valueと同じContent-Locationフィールド値は、このペイロードが新しく作成されたリソースの現在の表現であることを示します。
o Otherwise, such a Content-Location indicates that this payload 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 payload of the 200 (OK) response; the Content-Location field-value provides an identifier for retrieving a copy of that same receipt in the future.
o それ以外の場合、このようなContent-Locationは、このペイロードが要求されたアクションのステータスを報告する表現であり、同じレポートが指定されたURIで（GETによる将来のアクセスのために）利用可能であることを示します。たとえば、POST要求を介して行われた購入トランザクションには、200（OK）応答のペイロードとして受領書が含まれる場合があります。 Content-Locationフィールド値は、将来同じレシートのコピーを取得するための識別子を提供します。
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.
リクエストメッセージでContent-Locationを送信するユーザーエージェントは、その値はユーザーエージェントが最初に囲まれた表現のコンテンツを取得した場所を参照していると述べています（そのユーザーエージェントによる変更の前）。つまり、ユーザーエージェントは、元の表現のソースへのバックリンクを提供しています。
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.
要求メッセージでContent-Locationフィールドを受け取るオリジンサーバーは、情報を表現の一部として逐語的に保存されるメタデータとしてではなく、一時的な要求コンテキストとして扱う必要があります。オリジンサーバーはそのコンテキストを使用して、リクエストの処理をガイドしたり、ソースリンクやバージョン管理メタデータ内などの他の用途のために保存したりできます。ただし、オリジンサーバーは、要求のセマンティクスを変更するためにそのようなコンテキスト情報を使用してはなりません（MUST NOT）。
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.
たとえば、クライアントがネゴシエートされたリソースでPUT要求を行い、オリジンサーバーがそのPUTを（リダイレクトせずに）受け入れる場合、そのリソースの新しい状態は、そのPUTで提供される1つの表現と一致すると予想されます。 Content-Locationは、ネゴシエートされた表現の1つだけを更新するための逆コンテンツ選択識別子の形式として使用できません。ユーザーエージェントが後者のセマンティクスを必要としていた場合、PUTをContent-Location URIに直接適用します。
The representation data associated with an HTTP message is either provided as the payload body of the message or referred to by the message semantics and the effective request 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:
表現データのデータ型は、ヘッダーフィールドContent-TypeおよびContent-Encodingを介して決定されます。これらは、2層の順序付きエンコーディングモデルを定義します。
representation-data := Content-Encoding( Content-Type( bits ) )
Some HTTP messages transfer a complete or partial representation as the message "payload". In some cases, a payload might contain only the associated representation's header fields (e.g., responses to HEAD) or only some part(s) of the representation data (e.g., the 206 (Partial Content) status code).
一部のHTTPメッセージは、メッセージの「ペイロード」として完全または部分的な表現を転送します。ペイロードには、関連付けられた表現のヘッダーフィールド（HEADへの応答など）のみ、または表現データの一部（206（Partial Content）ステータスコードなど）のみが含まれる場合があります。
The purpose of a payload in a request is defined by the method semantics. For example, a representation in the payload of a PUT request (Section 4.3.4) represents the desired state of the target resource if the request is successfully applied, whereas a representation in the payload of a POST request (Section 4.3.3) represents information to be processed by the target resource.
リクエスト内のペイロードの目的は、メソッドのセマンティクスによって定義されます。たとえば、PUTリクエストのペイロードの表現（セクション4.3.4）は、リクエストが正常に適用された場合のターゲットリソースの望ましい状態を表しますが、POSTリクエストのペイロードの表現（セクション4.3.3）は、ターゲットリソースによって処理される情報。
In a response, the payload's purpose is defined by both the request method and the response status code. For example, the payload of a 200 (OK) response to GET (Section 4.3.1) represents the current state of the target resource, as observed at the time of the message origination date (Section 7.1.1.2), whereas the payload 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. Response messages with an error status code usually contain a payload that represents the error condition, such that it describes the error state and what next steps are suggested for resolving it.
レスポンスでは、ペイロードの目的はリクエストメソッドとレスポンスステータスコードの両方で定義されます。たとえば、GET（セクション4.3.1）に対する200（OK）応答のペイロードは、メッセージの作成日（セクション7.1.1.2）の時点で観測されたターゲットリソースの現在の状態を表しますが、 POSTへの応答の同じステータスコードは、処理を適用した後の処理結果またはターゲットリソースの新しい状態のいずれかを表す場合があります。エラーステータスコードを含む応答メッセージには通常、エラー状態を表すペイロードが含まれています。これには、エラー状態と、それを解決するための次のステップが示されています。
Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload header fields". Payload header fields are defined in other parts of this specification, due to their impact on message parsing.
関連する表現ではなく、ペイロードを具体的に説明するヘッダーフィールドは、「ペイロードヘッダーフィールド」と呼ばれます。ペイロードヘッダーフィールドは、メッセージ解析への影響のため、この仕様の他の部分で定義されています。
+-------------------+----------------------------+
| Header Field Name | Defined in... |
+-------------------+----------------------------+
| Content-Length | Section 3.3.2 of [RFC7230] |
| Content-Range | Section 4.2 of [RFC7233] |
| Trailer | Section 4.4 of [RFC7230] |
| Transfer-Encoding | Section 3.3.1 of [RFC7230] |
+-------------------+----------------------------+
When responses convey payload information, 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.
応答がペイロード情報を伝えるとき、成功を示すかエラーを示すかに関係なく、オリジンサーバーはその情報を表すさまざまな方法を持っています。たとえば、さまざまな形式、言語、またはエンコーディング。同様に、ユーザーやユーザーエージェントが異なれば、機能、特性、または設定が異なる可能性があり、利用可能な表現のうち、どの表現が最適であるかに影響を与える可能性があります。このため、HTTPはコンテンツネゴシエーションのメカニズムを提供します。
This specification defines two patterns of content negotiation that can be made visible within the protocol: "proactive", where the server selects the representation based upon the user agent's stated preferences, and "reactive" negotiation, where the server provides a list of representations for the user agent to choose from. 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
この仕様は、プロトコル内で表示できるコンテンツネゴシエーションの2つのパターンを定義します。サーバーは、ユーザーエージェントの指定された設定に基づいて表現を選択する「プロアクティブ」と、サーバーが表現のリストを提供する「リアクティブ」ネゴシエーションです。選択するユーザーエージェント。コンテンツネゴシエーションのその他のパターンには、「条件付きコンテンツ」が含まれます。「条件付きコンテンツ」は、ユーザーエージェントパラメータに基づいて選択的にレンダリングされる複数の部分で構成されます。「アクティブコンテンツ」は、「アクティブコンテンツ」に含まれます。ユーザーエージェントの特性、および「透過的なコンテンツネゴシエーション」（[RFC2295]）、コンテンツ
selection is performed by an intermediary. These patterns are not mutually exclusive, and each has trade-offs in applicability and practicality.
選択は仲介者によって実行されます。これらのパターンは相互に排他的ではなく、それぞれに適用性と実用性のトレードオフがあります。
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 pays no attention to the man behind the curtain.
すべての場合において、HTTPはリソースのセマンティクスを認識しないことに注意してください。時間の経過とともにコンテンツネゴシエーションのさまざまな次元にわたって、オリジンサーバーがリクエストに応答する一貫性、したがってリソースの監視された表現の「同一性」は、エンティティまたはアルゴリズムがそれらの応答を選択または生成することによって完全に決定されます。 HTTPは、カーテンの後ろの人に注意を払いません。
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 fields of Section 5.3 and implicit characteristics, such as the client's network address or parts of the User-Agent field.
コンテンツネゴシエーションプリファレンスがリクエストでユーザーエージェントによって送信され、サーバーにあるアルゴリズムが優先表現を選択するように促す場合、それはプロアクティブネゴシエーション（別名、サーバー駆動のネゴシエーション）と呼ばれます。選択は、セクション5.3の明示的なネゴシエーションフィールドと暗黙的なフィールドの両方を含む、リクエストで提供されるさまざまな情報と比較した、応答で使用可能な表現（言語、コンテンツコーディングなど、変化する可能性のある次元）に基づいていますクライアントのネットワークアドレスやUser-Agentフィールドの一部などの特性。
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 (hoping to avoid the round trip delay of a subsequent request if the "best guess" is good enough for the user). In order to improve the server's guess, a user agent MAY send request header fields that describe its preferences.
プロアクティブネゴシエーションは、利用可能な表現の中から選択するアルゴリズムをユーザーエージェントに説明することが難しい場合、またはサーバーが最初の応答と一緒に「推測」をユーザーエージェントに送信することを望む場合に有利です（ラウンドを回避するため「最良の推測」がユーザーにとって十分である場合、後続のリクエストのトリップ遅延）。サーバーの推測を改善するために、ユーザーエージェントはその設定を説明するリクエストヘッダーフィールドを送信してもよい（MAY）。
Proactive negotiation has serious disadvantages:
積極的な交渉には重大な欠点があります。
o 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?);
o ユーザーエージェントの機能と応答の使用目的の両方に関する完全な知識が必要となるため（たとえば、ユーザーが表示したい場合）、サーバーが特定のユーザーにとって「最適」なものを正確に決定することは不可能です。画面に表示するか、紙に印刷しますか？）;
o 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;
o ユーザーエージェントにすべてのリクエストでその機能を説明させることは非常に非効率的であり（応答のごく一部のみが複数の表現を持っている場合）、ユーザーのプライバシーに対する潜在的なリスクです。
o It complicates the implementation of an origin server and the algorithms for generating responses to a request; and,
o オリジンサーバーの実装と、リクエストへの応答を生成するためのアルゴリズムが複雑になります。そして、
o It limits the reusability of responses for shared caching.
o 共有キャッシュの応答の再利用性を制限します。
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.
オリジンサーバーはリクエストされたリソースに対してプロアクティブネゴシエーションを実装しないか、ユーザーエージェントのプリファレンスに準拠しない応答を送信する方が406（不可）応答。
A Vary header field (Section 7.1.4) is often sent in a response subject to proactive negotiation to indicate what parts of the request information were used in the selection algorithm.
選択アルゴリズムで要求情報のどの部分が使用されたかを示すために、プロアクティブなネゴシエーションの対象となる応答でVaryヘッダーフィールド（セクション7.1.4）が送信されることがよくあります。
With reactive negotiation (a.k.a., agent-driven negotiation), selection of the best response representation (regardless of the status code) is performed by the user agent after receiving an initial response from the origin server that contains a list of resources for alternative representations. If the user agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to obtain a different form of representation for that response. Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated (possibly hypertext) menu.
リアクティブネゴシエーション（別名、エージェント主導のネゴシエーション）では、代替の表現のリソースのリストを含む元のサーバーから初期応答を受信した後、（ステータスコードに関係なく）最適な応答表現の選択がユーザーエージェントによって実行されます。ユーザーエージェントが初期応答表現に満足できない場合、リストに含まれるメタデータに基づいて選択された1つ以上の代替リソースに対してGET要求を実行し、その応答の異なる形式の表現を取得できます。選択肢の選択は、ユーザーエージェントによって自動的に実行されるか、ユーザーが生成された（おそらくハイパーテキストの）メニューから選択することによって手動で実行されます。
Note that the above refers to representations of the response, in general, not representations of the resource. The alternative representations are only considered representations of the target resource if the response in which those alternatives are provided has the semantics of being a representation of the target resource (e.g., a 200 (OK) response to a GET request) or has the semantics of providing links to alternative representations for the target resource (e.g., a 300 (Multiple Choices) response to a GET request).
上記は、一般的にリソースの表現ではなく、応答の表現に言及していることに注意してください。代替表現は、それらの代替が提供される応答がターゲットリソースの表現であるという意味論（たとえば、GET要求に対する200（OK）応答）を持つ場合、または以下の意味論を持つ場合にのみ、ターゲットリソースの表現と見なされます。ターゲットリソースの代替表現へのリンクを提供する（たとえば、GETリクエストに対する300（Multiple Choices）応答）。
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 the available representations so that the user or user agent can react by making a selection.
サーバーは、選択肢のリスト以外の初期表現を送信しないことを選択し、それによってユーザーエージェントによるリアクティブネゴシエーションが優先されることを示す場合があります。たとえば、300（Multiple Choices）および406（Not Acceptable）ステータスコードのレスポンスにリストされている選択肢には、ユーザーまたはユーザーエージェントが選択を行うことで反応できるように、利用可能な表現に関する情報が含まれています。
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 as an extension.
リアクティブネゴシエーションには、選択肢のリストをユーザーエージェントに送信するというデメリットがあり、ヘッダーセクションで送信された場合にユーザーが認識する遅延が低下し、別の表現を取得するために2番目の要求が必要になります。さらに、この仕様は、自動選択をサポートするメカニズムを定義していませんが、そのようなメカニズムが拡張機能として開発されるのを妨げるものではありません。
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 (Section 5) if those additional semantics do not conflict with the method. For example, a client can send conditional request header fields (Section 5.2) to make the requested action conditional on the current state of the target resource ([RFC7232]).
リクエストメソッドのセマンティクスは、リクエストに存在する場合（セクション5）、それらの追加のセマンティクスがメソッドと競合しない場合、一部のヘッダーフィールドのセマンティクスによってさらに特殊化される可能性があります。たとえば、クライアントは条件付きリクエストヘッダーフィールド（セクション5.2）を送信して、リクエストされたアクションをターゲットリソースの現在の状態（[RFC7232]）に条件付きにすることができます。
method = token
メソッド=トークン
HTTP was originally designed to be usable as an interface to distributed object systems. The request method was envisioned as applying semantics to a target resource in much the same way as invoking a defined method on an identified object would apply semantics. The method token is case-sensitive because it might be used as a gateway to object-based systems with case-sensitive method names.
HTTPは当初、分散オブジェクトシステムへのインターフェイスとして使用できるように設計されました。要求メソッドは、識別されたオブジェクトで定義されたメソッドを呼び出すとセマンティクスが適用されるのとほぼ同じ方法で、ターゲットリソースにセマンティクスを適用するものと想定されていました。メソッドトークンは、大文字と小文字を区別するメソッド名を持つオブジェクトベースのシステムへのゲートウェイとして使用される可能性があるため、大文字と小文字を区別します。
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の標準化されたリクエストメソッドはリソース固有ではありません。これは、統一されたインターフェイスがネットワークベースのシステムでの可視性と再利用を改善するためです[REST]いったん定義されると、標準化されたメソッドは、リソースに適用されるときに同じセマンティクスを持つ必要がありますが、各リソースは、それらのセマンティクスが実装または許可されるかどうかを自分自身で決定します。
This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table. By convention, standardized methods are defined in all-uppercase US-ASCII letters.
この仕様では、次の表に示すように、HTTPで一般的に使用される標準化されたメソッドをいくつか定義しています。慣例により、標準化された方法はすべて大文字のUS-ASCII文字で定義されます。
+---------+-------------------------------------------------+-------+
| Method | Description | Sec. |
+---------+-------------------------------------------------+-------+
| GET | Transfer a current representation of the target | 4.3.1 |
| | resource. | |
| HEAD | Same as GET, but only transfer the status line | 4.3.2 |
| | and header section. | |
| POST | Perform resource-specific processing on the | 4.3.3 |
| | request payload. | |
| PUT | Replace all current representations of the | 4.3.4 |
| | target resource with the request payload. | |
| DELETE | Remove all current representations of the | 4.3.5 |
| | target resource. | |
| CONNECT | Establish a tunnel to the server identified by | 4.3.6 |
| | the target resource. | |
| OPTIONS | Describe the communication options for the | 4.3.7 |
| | target resource. | |
| TRACE | Perform a message loop-back test along the path | 4.3.8 |
| | to the target resource. | |
+---------+-------------------------------------------------+-------+
All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL.
すべての汎用サーバーは、メソッドGETおよびHEADをサポートする必要があります。他のすべての方法はオプションです。
Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought to be registered within the "Hypertext Transfer Protocol (HTTP) Method Registry" maintained by IANA, as defined in Section 8.1.
この仕様の範囲外の追加のメソッドは、HTTPで使用するために標準化されています。そのようなメソッドはすべて、セクション8.1で定義されているように、IANAによって維持される「ハイパーテキスト転送プロトコル（HTTP）メソッドレジストリ」内に登録する必要があります。
The set of methods allowed by a target resource can be listed in an Allow header field (Section 7.4.1). However, the set of allowed methods can change dynamically. When a request method is received that is unrecognized or not implemented by an origin server, the origin server SHOULD respond with the 501 (Not Implemented) status code. When a request method is received that is known by an origin server but not allowed for the target resource, the origin server SHOULD respond with the 405 (Method Not Allowed) status code.
ターゲットリソースによって許可されたメソッドのセットは、Allowヘッダーフィールドにリストできます（セクション7.4.1）。ただし、許可されたメソッドのセットは動的に変更できます。認識されていないか、配信元サーバーで実装されていないリクエストメソッドを受信すると、配信元サーバーは501（未実装）ステータスコードで応答する必要があります（SHOULD）。オリジンサーバーによって認識されているがターゲットリソースに対して許可されていないリクエストメソッドが受信されると、オリジンサーバーは405（メソッドは許可されていません）ステータスコードで応答する必要があります（SHOULD）。
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.
定義されたセマンティクスが本質的に読み取り専用である場合、リクエストメソッドは「安全」と見なされます。つまり、ターゲットリソースに安全なメソッドを適用した結果として、クライアントは、オリジンサーバーの状態変化を要求したり、期待したりしません。同様に、安全な方法を適切に使用しても、元のサーバーに害、財産の損失、または異常な負担が発生することはありません。
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 crash the server. 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、HEAD、OPTIONS、およびTRACEメソッドが安全であると定義されています。
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 effective request 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ベースのコンテンツ編集ソフトウェアでは、「page？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、DELETE、および安全な要求メソッドはべき等です。
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.
安全の定義と同様に、べき等プロパティはユーザーが要求したものにのみ適用されます。サーバーは、各要求を個別にログに記録したり、リビジョン管理履歴を保持したり、べき等の要求ごとに他のべき等でない副作用を実装したりできます。
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.
べき等メソッドは区別されます。これは、クライアントがサーバーの応答を読み取る前に通信障害が発生した場合に、要求を自動的に繰り返すことができるためです。たとえば、クライアントがPUT要求を送信し、応答が受信される前に基礎となる接続が閉じられた場合、クライアントは新しい接続を確立してべき等要求を再試行できます。応答は異なる場合がありますが、元の要求が成功した場合でも、要求を繰り返すと同じ効果が得られることがわかっています。
Request methods can be defined as "cacheable" to indicate that responses to them are allowed to be stored for future reuse; for specific requirements see [RFC7234]. In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD.
リクエストメソッドを「キャッシュ可能」として定義すると、リクエストメソッドへの応答を将来の再利用のために保存できるようになります。特定の要件については、[RFC7234]を参照してください。一般に、現在の応答または信頼できる応答に依存しない安全なメソッドは、キャッシュ可能として定義されます。この仕様では、GET、HEAD、およびPOSTをキャッシュ可能として定義していますが、圧倒的多数のキャッシュ実装はGETおよびHEADのみをサポートしています。
The GET method requests transfer of a current selected representation for the target resource. GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.
GETメソッドは、ターゲットリソースの現在選択されている表現の転送を要求します。 GETは情報検索の主要なメカニズムであり、ほとんどすべてのパフォーマンス最適化の焦点です。したがって、人々がHTTPを介して特定可能な情報を取得することについて話すとき、彼らは一般にGETリクエストを行うことを指します。
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 9.1 for related security considerations). However, there are no such limitations in practice. 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 of its resource identifiers corresponds to an implementation and how each implementation manages to select and send a current representation of the target resource in a response to GET.
リソース識別子をリモートファイルシステムのパス名として、表現をそのようなファイルの内容のコピーとして考えるのは魅力的です。実際、これが実装されるリソースの数です（関連するセキュリティの考慮事項については、セクション9.1を参照してください）。ただし、実際にはそのような制限はありません。リソースのHTTPインターフェースは、コンテンツオブジェクトのツリー、さまざまなデータベースレコードのプログラムビュー、または他の情報システムへのゲートウェイとして実装される可能性が高いです。 URIマッピングメカニズムがファイルシステムに関連付けられている場合でも、ファイルを直接転送するのではなく、要求を入力としてファイルを実行し、表現として出力を送信するようにオリジンサーバーが構成されている場合があります。いずれにせよ、オリジンサーバーだけが、そのリソース識別子のそれぞれが実装にどのように対応するか、および各実装がGETへの応答でターゲットリソースの現在の表現を選択して送信する方法を知る必要があります。
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 ([RFC7233]).
クライアントは、リクエストのRangeヘッダーフィールドを送信することで、GETのセマンティクスを「範囲リクエスト」に変更し、選択された表現の一部のみの転送をリクエストできます（[RFC7233]）。
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
GETリクエストメッセージ内のペイロードには、セマンティクスが定義されていません。 GETリクエストでペイロードボディを送信すると、一部の既存の実装がリクエストを拒否する可能性があります。
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 [RFC7234]).
GET要求への応答はキャッシュ可能です。キャッシュは、Cache-Controlヘッダーフィールドで指定されていない限り（[RFC7234]のセクション5.2）、それを使用して後続のGETおよびHEADリクエストを満たすことができます（MAY）。
The HEAD method is identical to GET except that the server MUST NOT send a message body in the response (i.e., the response terminates at the end of the header section). The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 3.3) MAY be omitted. This method can be used for obtaining metadata about the selected representation without transferring the representation data and is often used for testing hypertext links for validity, accessibility, and recent modification.
HEADメソッドは、サーバーが応答でメッセージ本文を送信してはならないことを除いて、GETと同じです（つまり、応答はヘッダーセクションの最後で終了します）。サーバーは、リクエストがGETであった場合に送信されたのと同じヘッダーフィールドをHEADリクエストへの応答として送信する必要があります（ただし、ペイロードヘッダーフィールド（セクション3.3）は省略可能です）。このメソッドは、表現データを転送せずに選択した表現に関するメタデータを取得するために使用でき、ハイパーテキストリンクの有効性、アクセシビリティ、および最近の変更をテストするためによく使用されます。
A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request.
HEADリクエストメッセージ内のペイロードには、セマンティクスが定義されていません。 HEADリクエストでペイロードボディを送信すると、一部の既存の実装がリクエストを拒否する可能性があります。
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 [RFC7234]). A HEAD response might also have an effect on previously cached responses to GET; see Section 4.3.5 of [RFC7234].
HEAD要求への応答はキャッシュ可能です。キャッシュは、Cache-Controlヘッダーフィールドで指定されていない限り（[RFC7234]のセクション5.2）、それを使用して後続のHEADリクエストを満たすことができます（MAY）。 HEAD応答は、以前にキャッシュされたGETへの応答にも影響を与える可能性があります。 [RFC7234]のセクション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は（特に）次の機能に使用されます。
o Providing a block of data, such as the fields entered into an HTML form, to a data-handling process;
o HTMLフォームに入力されたフィールドなどのデータのブロックをデータ処理プロセスに提供します。
o Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
o 掲示板、ニュースグループ、メーリングリスト、ブログ、または同様の記事グループにメッセージを投稿する。
o Creating a new resource that has yet to be identified by the origin server; and
o オリジンサーバーによってまだ識別されていない新しいリソースを作成します。そして
o Appending data to a resource's existing representation(s).
o リソースの既存の表現にデータを追加します。
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 might be received in a response to POST (the exceptions being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not Satisfiable)).
オリジンサーバーは、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 7.1.2) and a representation that describes the status of the request while referring to the new resource(s).
POSTリクエストを正常に処理した結果、1つ以上のリソースがオリジンサーバーで作成された場合、オリジンサーバーは、作成されたプライマリリソースの識別子を提供するLocationヘッダーフィールドを含む201（Created）応答を送信する必要があります（セクション7.1）。 .2）および新しいリソースを参照しながらリクエストのステータスを説明する表現。
Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2).
POSTリクエストへの応答は、明示的な鮮度情報が含まれている場合にのみキャッシュできます（[RFC7234]のセクション4.2.1を参照）。ただし、POSTキャッシングは広く実装されていません。オリジンサーバーがクライアントがPOSTの結果を後のGETで再利用できる方法でキャッシュできるようにしたい場合、オリジンサーバーは結果とContent-Locationを含む200（OK）応答を送信できます（MAY）。 POSTの有効なリクエストURIと同じ値を持つヘッダーフィールド（セクション3.1.4.2）。
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.
POSTの処理結果が既存のリソースの表現と同等である場合、オリジンサーバーは、Locationフィールドに既存のリソースの識別子を含む303（その他を参照）応答を送信することにより、ユーザーエージェントをそのリソースにリダイレクトできます（MAY）。これには、ユーザーエージェントにリソース識別子を提供し、共有キャッシュに適した方法で表現を転送するという利点がありますが、ユーザーエージェントが表現をまだキャッシュしていない場合は追加の要求が発生します。
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 payload. 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メソッドは、ターゲットリソースの状態を作成するか、要求メッセージのペイロードで囲まれた表現で定義された状態に置き換えることを要求します。特定の表現のPUTが成功した場合、その同じターゲットリソースで後続のGETを実行すると、同等の表現が200（OK）応答で送信されます。ただし、後続のGETが受信される前に、ターゲットリソースが他のユーザーエージェントによって同時に処理されるか、元のサーバーによる動的処理の対象となる可能性があるため、このような状態変化が観察可能である保証はありません。成功した応答は、元のサーバーによる処理時にユーザーエージェントの意図が達成されたことを意味します。
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がそれを正常に作成した場合、オリジンサーバーは201（Created）応答を送信してユーザーエージェントに通知する必要があります。ターゲットリソースに現在の表現があり、その表現が囲まれた表現の状態に従って正常に変更された場合、オリジンサーバーは200（OK）または204（No Content）応答を送信して、正常に完了したことを示す必要があります。リクエスト。
An origin server SHOULD ignore unrecognized header fields received in a PUT request (i.e., do not save them as part of the resource state).
オリジンサーバーは、PUTリクエストで受信された認識されないヘッダーフィールドを無視する必要があります（つまり、リソース状態の一部として保存しないでください）。
An origin server SHOULD verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information related to the URI in order to set the values for representation metadata on GET responses. 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.
オリジンサーバーは、PUT表現が、PUTによって変更できない、または変更されないターゲットリソースに対するサーバーの制約と整合していることを確認する必要があります（SHOULD）。オリジンサーバーがURIに関連する内部構成情報を使用してGET応答の表現メタデータの値を設定する場合、これは特に重要です。 PUT表現がターゲットリソースと矛盾している場合、オリジンサーバーは、表現を変換するかリソース構成を変更してそれらを一貫させるか、表現が不適切である理由を説明する十分な情報を含む適切なエラーメッセージで応答する必要があります。 409（競合）または415（サポートされていないメディアタイプ）ステータスコードが推奨され、後者はContent-Type値の制約に固有のものです。
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:
たとえば、ターゲットリソースが常に "text / html"のContent-Typeを持つように構成され、PUTである表現が "image / jpeg"のContent-Typeを持つ場合、オリジンサーバーは次のいずれかを実行する必要があります。
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. 新しいリソース状態として保存する前に、PUT表現をリソースの形式と一致する形式に変換します。または、
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. ターゲットリソースが「text / html」に制限されていることを示す415（Unsupported Media Type）応答でリクエストを拒否します。おそらく、新しい表現の適切なターゲットとなる別のリソースへのリンクが含まれます。
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メソッドがオリジンサーバーの状態にどのように影響するかを、ユーザーエージェント要求の意図とオリジンサーバーの応答のセマンティクスを超えて正確に定義していません。 HTTPを介して提供されるインターフェースを超えて、その言葉の意味でのリソースが何であるかを定義するものではありません。リソースの状態が「格納」される方法や、リソースの状態の変化の結果としてそのようなストレージがどのように変化するかも定義されておらず、オリジンサーバーがリソースの状態を表現に変換する方法も定義されていません。一般的に言って、リソースインターフェースの背後にあるすべての実装の詳細は、サーバーによって意図的に隠されています。
An origin server MUST NOT send a validator header field (Section 7.2), 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 body (i.e., the resource's new representation data is identical to the representation data 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 body it has in memory remains current as a result of the PUT, thus not in need of being retrieved again from the origin server, and that the new validator(s) received in the response can be used for future conditional requests in order to prevent accidental overwrites (Section 5.2).
送信元サーバーは、PUTへの正常な応答として、本文に変換を適用せずにリクエストの表現データを保存しない限り、ETagやLast-Modifiedフィールドなどのバリデーターヘッダーフィールド（セクション7.2）を送信してはなりません（つまり、リソースの新しい表現データは、PUTリクエストで受け取った表現データと同じです）、バリデーターフィールドの値は新しい表現を反映します。この要件により、ユーザーエージェントは、PUTの結果としてメモリ内にあるリプレゼンテーションボディが最新のままであるため、オリジンサーバーから再度取得する必要がなく、新しいバリデータが応答で受信されたことを知ることができます。偶発的な上書きを防止するために、将来の条件付きリクエストに使用できます（セクション5.2）。
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.
POSTメソッドとPUTメソッドの基本的な違いは、囲まれた表現の異なる意図によって強調されています。 POSTリクエストのターゲットリソースは、リソース自体のセマンティクスに従って囲まれた表現を処理するためのものですが、PUTリクエストの囲まれた表現は、ターゲットリソースの状態を置き換えるものとして定義されます。したがって、正確な効果がオリジンサーバーによってのみ認識されている場合でも、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メソッドを使用して実装する必要があります（SHOULD）。オリジンサーバーが要求されたPUT状態をターゲットリソースに変更せず、代わりに、リソースが別のURIに移動された場合など、別のリソースに適用したい場合、オリジンサーバーは適切な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.
ターゲットリソースに適用されたPUTリクエストは、他のリソースに悪影響を与える可能性があります。たとえば、記事には、特定の各バージョンを識別するURI（ある時点で現在のバージョンのリソースと同じ状態を共有するさまざまなリソース）とは別の「現在のバージョン」（リソース）を識別するためのURIがある場合があります。したがって、「現在のバージョン」のURIでPUTリクエストが成功すると、ターゲットリソースの状態が変更されるだけでなく、新しいバージョンのリソースが作成され、関連するリソース間にリンクが追加される場合があります。
An origin server that allows PUT on a given target resource MUST send a 400 (Bad Request) response to a PUT request that contains a Content-Range header field (Section 4.2 of [RFC7233]), since the payload is likely to be partial content that has been mistakenly PUT as a full representation. Partial content updates are possible by targeting a separately identified resource with state that overlaps 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]).
特定のターゲットリソースでPUTを許可するオリジンサーバーは、ペイロードが部分的なコンテンツである可能性が高いため、Content-Rangeヘッダーフィールド（[RFC7233]のセクション4.2）を含むPUTリクエストに400（Bad Request）応答を送信する必要がありますこれは誤って完全な表現としてPUTされています。部分的なコンテンツの更新は、より大きなリソースの一部と重複する状態を持つ個別に識別されたリソースをターゲットにするか、部分的な更新用に特別に定義された別の方法（[RFC5789]で定義されたPATCHメソッドなど）を使用することで可能です。
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 effective request URI, those stored responses will be invalidated (see Section 4.4 of [RFC7234]).
PUTメソッドへの応答はキャッシュできません。成功したPUTリクエストが、有効なリクエストURIに対する1つ以上のレスポンスが保存されているキャッシュを通過すると、それらの保存されたレスポンスは無効になります（[RFC7234]のセクション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.
DELETEメソッドは、オリジンサーバーがターゲットリソースとその現在の機能の間の関連付けを削除することを要求します。実際、この方法はUNIXのrmコマンドに似ています。以前関連付けられていた情報が削除されることを期待するのではなく、オリジンサーバーの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つ以上の現在の表現がある場合、リソースの性質とオリジンサーバーによる実装に完全に依存して、それらはオリジンサーバーによって破棄される場合と破棄されない場合があり、関連するストレージが再利用される場合とされない場合があります（この仕様の範囲外です）。同様に、データベースやゲートウェイ接続など、DELETEの結果として、リソースの他の実装の側面を非アクティブ化またはアーカイブする必要がある場合があります。一般に、元のサーバーは、削除を実行するための所定のメカニズムを持つリソースに対してのみDELETEを許可すると想定されています。
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.
比較的少数のリソースでDELETEメソッドを使用できます。その主な用途は、ユーザーがその効果について何らかの指示を与えるリモートオーサリング環境です。たとえば、以前にPUTリクエストを使用して作成されたリソース、またはPOSTリクエストに対する201（Created）レスポンスの後にLocationヘッダーフィールドで識別されたリソースは、対応するDELETEリクエストでそれらのアクションを取り消すことができます。同様に、リモート操作にHTTPを使用するリビジョンコントロールクライアントなどのオーサリング機能を実装するカスタムユーザーエージェントの実装では、サーバーのURIスペースがバージョンリポジトリに対応するように作成されているという想定に基づいて、DELETEを使用する場合があります。
If a DELETE method is successfully applied, the origin server SHOULD send a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted, a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or a 200 (OK) status code if the action has been enacted and the response message includes a representation describing the status.
DELETEメソッドが正常に適用された場合、オリジンサーバーは、アクションが成功する可能性が高いがまだ制定されていない場合は202（Accepted）ステータスコードを送信し、アクションが制定されている場合は204（No Content）ステータスコードを送信する必要があります。情報が提供されます。アクションが実行され、応答メッセージにステータスを表す表現が含まれている場合は200（OK）ステータスコード。
A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.
DELETE要求メッセージ内のペイロードには、意味が定義されていません。 DELETEリクエストでペイロード本体を送信すると、一部の既存の実装がリクエストを拒否する可能性があります。
Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see Section 4.4 of [RFC7234]).
DELETEメソッドへの応答はキャッシュできません。 DELETEリクエストが、有効なリクエストURIに対する1つ以上のレスポンスが保存されているキャッシュを通過する場合、それらの保存されたレスポンスは無効になります（[RFC7234]のセクション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 packets, 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, [RFC5246]).
CONNECTメソッドは、受信者がrequest-targetで識別された宛先オリジンサーバーへのトンネルを確立することを要求し、成功した場合は、トンネルが閉じるまで、その動作を双方向のパケットのブラインド転送に制限します。トンネルは一般に、1つ以上のプロキシを介してエンドツーエンドの仮想接続を作成するために使用され、TLS（Transport Layer Security、[RFC5246]）を使用して保護できます。
CONNECT is intended only for use in requests to a proxy. An origin server that receives a CONNECT request for itself MAY respond with a 2xx (Successful) status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
CONNECTは、プロキシへのリクエストでの使用のみを目的としています。自身のCONNECT要求を受信したオリジンサーバーは、2xx（成功）ステータスコードで応答して、接続が確立されたことを示すことができます。ただし、ほとんどのオリジンサーバーはCONNECTを実装していません。
A client sending a CONNECT request MUST send the authority form of request-target (Section 5.3 of [RFC7230]); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. For example,
CONNECTリクエストを送信するクライアントは、request-targetの認証フォームを送信する必要があります（[RFC7230]のセクション5.3）。つまり、リクエストターゲットは、コロンで区切られたトンネル宛先のホスト名とポート番号のみで構成されます。例えば、
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another proxy, by forwarding the CONNECT request to the next inbound proxy. Any 2xx (Successful) response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the blank line that concludes the successful response's header section; data received after that blank line 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 and that the connection remains governed by HTTP.
受信側プロキシは、リクエストターゲットに直接接続するか、別のプロキシを使用するように構成されている場合は、CONNECTリクエストを次のインバウンドプロキシに転送することにより、トンネルを確立できます。 2xx（成功）応答は、送信者（およびすべての受信プロキシ）が、成功応答のヘッダーセクションを終了する空白行の直後にトンネルモードに切り替わることを示します。その空白行の後に受信したデータは、request-targetによって識別されたサーバーからのものです。成功した応答以外の応答は、トンネルがまだ形成されておらず、接続がHTTPによって管理されたままであることを示します。
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:80 HTTP/1.1
Host: server.example.com:80
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 a request-target of "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 whitelist of safe request targets.
特に宛先がWebトラフィック用ではない既知または予約済みのTCPポートである場合、任意のサーバーへのトンネルを確立することには大きなリスクがあります。たとえば、「example.com:25」のリクエストターゲットへのCONNECTは、プロキシがSMTPトラフィック用に予約されたポートに接続することを示唆します。許可されている場合、プロキシをだましてスパムメールをリレーさせる可能性があります。 CONNECTをサポートするプロキシは、その使用を既知のポートの限定されたセットまたは安全な要求ターゲットの構成可能なホワイトリストに制限する必要があります（SHOULD）。
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（成功）応答でTransfer-EncodingまたはContent-Lengthヘッダーフィールドを送信してはなりません（MUST NOT）。クライアントは、CONNECTへの正常な応答で受信したContent-LengthまたはTransfer-Encodingヘッダーフィールドを無視する必要があります。
A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause some existing implementations to reject the request.
CONNECTリクエストメッセージ内のペイロードには、意味が定義されていません。 CONNECTリクエストでペイロードボディを送信すると、一部の既存の実装がリクエストを拒否する可能性があります。
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メソッドは、発信元サーバーまたは仲介者のいずれかで、ターゲットリソースに使用可能な通信オプションに関する情報を要求します。このメソッドを使用すると、クライアントは、リソースアクションに関係なく、リソースに関連するオプションや要件、またはサーバーの機能を決定できます。
An OPTIONS request with an asterisk ("*") as the request-target (Section 5.3 of [RFC7230]) 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).
リクエストターゲットとしてアスタリスク（ "*"）が付いたOPTIONSリクエスト（[RFC7230]のセクション5.3）は、特定のリソースではなく、一般的にサーバーに適用されます。サーバーの通信オプションは通常リソースに依存するため、「*」リクエストは「ping」または「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.
request-targetがアスタリスクでない場合、OPTIONS要求は、ターゲットリソースとの通信時に使用可能なオプションに適用されます。
A server generating a successful response to OPTIONS SHOULD send any header fields 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 payload, 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. A server MUST generate a Content-Length field with a value of "0" if no payload body is to be sent in the response.
OPTIONSへの正常な応答を生成するサーバーは、サーバーによって実装され、この仕様で定義されていない可能性のある拡張機能を含む、ターゲットリソース（例：許可）に適用可能なオプション機能を示す可能性があるヘッダーフィールドを送信する必要があります。応答ペイロードは、存在する場合、通信オプションをマシンまたは人間が読める形式で記述します。そのような表現の標準形式はこの仕様では定義されていませんが、HTTPの将来の拡張によって定義される可能性があります。応答でペイロード本体が送信されない場合、サーバーは「0」の値でContent-Lengthフィールドを生成する必要があります。
A client MAY send a Max-Forwards header field in an OPTIONS request to target a specific recipient in the request chain (see Section 5.1.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.
クライアントは、OPTIONSリクエストでMax-Forwardsヘッダーフィールドを送信して、リクエストチェーン内の特定の受信者をターゲットにすることができます（セクション5.1.2を参照）。プロキシは、リクエストがMax-Forwardsフィールドで受信されない限り、リクエストの転送中にMax-Forwardsヘッダーフィールドを生成してはなりません（MUST NOT）。
A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing the representation media type. Although this specification does not define any use for such a payload, future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource.
ペイロード本体を含むOPTIONSリクエストを生成するクライアントは、表現メディアタイプを説明する有効なContent-Typeヘッダーフィールドを送信する必要があります。この仕様では、このようなペイロードの使用を定義していませんが、HTTPの将来の拡張では、OPTIONSボディを使用してターゲットリソースに関するより詳細なクエリを作成する可能性があります。
Responses to the OPTIONS method are not cacheable.
OPTIONSメソッドへの応答はキャッシュできません。
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 message body of a 200 (OK) response with a Content-Type of "message/http" (Section 8.3.1 of [RFC7230]). 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 5.1.2).
TRACEメソッドは、要求メッセージのリモートのアプリケーションレベルのループバックを要求します。リクエストの最後の受信者は、以下に説明するいくつかのフィールドを除いて、受信したメッセージをContent-Typeが「message / http」の200（OK）応答のメッセージ本文としてクライアントに反映する必要があります（セクション8.3.1の[RFC7230]）。最終受信者は、起点サーバーか、リクエストでMax-Forwards値ゼロ（0）を受信する最初のサーバーです（セクション5.1.2）。
A client MUST NOT generate header 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 [RFC7235] or cookies [RFC6265] in a TRACE request. The final recipient of the request SHOULD exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.
クライアントは、応答によって開示される可能性のある機密データを含むTRACE要求でヘッダーフィールドを生成してはなりません（MUST NOT）。たとえば、ユーザーエージェントがTRACEリクエストで保存されたユーザー資格情報[RFC7235]またはCookie [RFC6265]を送信するのはばかげたことです。リクエストの最後の受信者は、その受信者が応答本文を生成するときに機密データを含む可能性のあるリクエストヘッダーフィールドを除外する必要があります（SHOULD）。
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 5.7.1 of [RFC7230]) 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ヘッダーフィールド（[RFC7230]のセクション5.7.1）の値は、リクエストチェーンのトレースとして機能するため、特に重要です。 Max-Forwardsヘッダーフィールドを使用すると、クライアントはリクエストチェーンの長さを制限できます。これは、無限ループでメッセージを転送するプロキシのチェーンをテストするのに役立ちます。
A client MUST NOT send a message body in a TRACE request.
クライアントは、TRACEリクエストでメッセージ本文を送信してはいけません。
Responses to the TRACE method are not cacheable.
TRACEメソッドへの応答はキャッシュできません。
A client sends request header fields to provide more information about the request context, make the request conditional based on the target resource state, suggest preferred formats for the response, supply authentication credentials, or modify the expected request processing. These fields act as request modifiers, similar to the parameters on a programming language method invocation.
クライアントはリクエストヘッダーフィールドを送信して、リクエストコンテキストに関する詳細情報を提供し、ターゲットリソースの状態に基づいてリクエストを条件付きにし、レスポンスの優先フォーマットを提案し、認証資格情報を提供し、予期されるリクエスト処理を変更します。これらのフィールドは、プログラミング言語のメソッド呼び出しのパラメーターと同様に、要求修飾子として機能します。
Controls are request header fields that direct specific handling of the request.
コントロールは、リクエストの特定の処理を指示するリクエストヘッダーフィールドです。
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| Cache-Control | Section 5.2 of [RFC7234] |
| Expect | Section 5.1.1 |
| Host | Section 5.4 of [RFC7230] |
| Max-Forwards | Section 5.1.2 |
| Pragma | Section 5.4 of [RFC7234] |
| Range | Section 3.1 of [RFC7233] |
| TE | Section 4.3 of [RFC7230] |
+-------------------+--------------------------+
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. The only such expectation defined by this specification is 100-continue.
リクエストの「期待」ヘッダーフィールドは、このリクエストを適切に処理するためにサーバーでサポートする必要がある特定の一連の動作（期待）を示します。この仕様で定義されているそのような期待値は100-continueだけです。
Expect = "100-continue"
Expect = "100-continue"
The Expect field-value is case-insensitive.
Expectフィールド値は大文字と小文字を区別しません。
A server that receives an Expect field-value other than 100-continue MAY respond with a 417 (Expectation Failed) status code to indicate that the unexpected expectation cannot be met.
100-continue以外のExpectフィールド値を受信するサーバーは、予期しない期待に応えることができないことを示すために、417（Expectation Failed）ステータスコードで応答する場合があります。
A 100-continue expectation informs recipients that the client is about to send a (presumably large) message body in this request and wishes to receive a 100 (Continue) interim response if the request-line 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 message body before actually doing so, which can improve efficiency when the message body 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継続期待値は、クライアントがこのリクエストで（おそらく大きな）メッセージ本文を送信しようとしていることを受信者に通知し、リクエストラインとヘッダーフィールドが即時に発生するのに十分でない場合は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.
オリジンサーバーが401（無許可）や405（メソッドが許可されていない）などのエラーメッセージですぐに応答する前に、クライアントが不要なデータ転送でパイプを埋め始めます。
Requirements for clients:
クライアントの要件：
o A client MUST NOT generate a 100-continue expectation in a request that does not include a message body.
o クライアントは、メッセージ本文を含まないリクエストで100-continue期待値を生成してはなりません（MUST NOT）。
o A client that will wait for a 100 (Continue) response before sending the request message body MUST send an Expect header field containing a 100-continue expectation.
o リクエストメッセージ本文を送信する前に100（Continue）応答を待つクライアントは、100-continue期待値を含むExpectヘッダーフィールドを送信する必要があります。
o 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 message body 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 message body.
o 100継続期待値を送信するクライアントは、特定の時間待機する必要はありません。そのようなクライアントは、まだ応答を受け取っていなくても、メッセージ本文の送信を続行できます（MAY）。さらに、100（Continue）応答はHTTP / 1.0の中間手段を介して送信できないため、そのようなクライアントはメッセージ本文を送信する前に無期限に待機してはなりません（SHOULD NOT）。
o 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).
o 100継続期待値を含む要求に応答して417（期待値失敗）ステータスコードを受信するクライアントは、100継続期待値なしでその要求を繰り返す必要があります。417応答は、応答チェーンが期待値（たとえば、HTTP / 1.0サーバーを通過します）。
Requirements for servers:
サーバーの要件：
o A server that receives a 100-continue expectation in an HTTP/1.0 request MUST ignore that expectation.
o HTTP / 1.0リクエストで100-continue期待を受信するサーバーは、その期待を無視する必要があります。
o A server MAY omit sending a 100 (Continue) response if it has already received some or all of the message body for the corresponding request, or if the framing indicates that there is no message body.
o 対応する要求のメッセージ本文の一部またはすべてをすでに受信している場合、またはメッセージ本文がないことをフレーミングが示している場合、サーバーは100（Continue）応答の送信を省略できます。
o A server that sends a 100 (Continue) response MUST ultimately send a final status code, once the message body is received and processed, unless the connection is closed prematurely.
o 100（Continue）応答を送信するサーバーは、メッセージ本文が受信されて処理されると、接続が時期尚早に閉じられない限り、最終的に最終ステータスコードを送信する必要があります。
o A server that responds with a final status code before reading the entire message body SHOULD indicate in that response whether it intends to close the connection or continue reading and discarding the request message (see Section 6.6 of [RFC7230]).
o メッセージ本文全体を読み取る前に最終ステータスコードで応答するサーバーは、その応答で、接続を閉じるか、または要求メッセージの読み取りと破棄を続行するかどうかを示す必要があります（[RFC7230]のセクション6.6を参照）。
An origin server MUST, upon receiving an HTTP/1.1 (or later) request-line and a complete header section that contains a 100-continue expectation and indicates a request message body will follow, either send an immediate response with a final status code, if that status can be determined by examining just the request-line and header fields, or send an immediate 100 (Continue) response to encourage the client to send the request's message body. The origin server MUST NOT wait for the message body before sending the 100 (Continue) response.
オリジンサーバーは、HTTP / 1.1（またはそれ以降）のリクエストラインと、100-continue期待値を含み、リクエストメッセージ本文が続くことを示す完全なヘッダーセクションを受信すると、最終ステータスコードを含む即時応答を送信する必要があります。 request-lineフィールドとheaderフィールドだけを調べることでそのステータスを判別できる場合、またはクライアントにリクエストのメッセージ本文を送信するように促すために即時100（Continue）応答を送信する場合。オリジンサーバーは、100（Continue）応答を送信する前にメッセージ本文を待機してはなりません（MUST NOT）。
A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and a complete header section that contains a 100-continue expectation and indicates a request message body will follow, either send an immediate response with a final status code, if that status can be determined by examining just the request-line and header fields, or begin forwarding the request toward the origin server by sending a corresponding request-line and header section to the next inbound 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 message body.
プロキシは、HTTP / 1.1（またはそれ以降）の要求行と、100-continue期待値を含み、要求メッセージ本文が続くことを示す完全なヘッダーセクションを受信すると、最終ステータスコードを含む即時応答を送信する必要があります。そのステータスは、request-lineフィールドとheaderフィールドだけを調べるか、対応するrequest-lineセクションとheaderセクションを次のインバウンドサーバーに送信して、オリジンサーバーに向けて要求の転送を開始することで判断できます。プロキシが次の受信サーバーがHTTP / 1.0のみをサポートしていると（構成または過去の相互作用から）信じている場合、プロキシは即時100（Continue）応答を生成して、クライアントにメッセージ本文の送信を開始するように促してもよい（MAY）。
Note: The Expect header field was added after the original publication of HTTP/1.1 [RFC2068] as both the means to request an interim 100 (Continue) response and the general mechanism for indicating must-understand extensions. However, the extension mechanism has not been used by clients and the must-understand requirements have not been implemented by many servers, rendering the extension mechanism useless. This specification has removed the extension mechanism in order to simplify the definition and processing of 100-continue.
注：Expectヘッダーフィールドは、HTTP / 1.1 [RFC2068]の最初の公開後に追加され、暫定100（Continue）応答を要求する手段と、理解すべき拡張を示す一般的なメカニズムの両方として使用されました。ただし、拡張メカニズムはクライアントによって使用されておらず、理解しなければならない要件が多くのサーバーによって実装されていないため、拡張メカニズムは役に立たなくなります。この仕様では、100-continueの定義と処理を簡略化するために、拡張メカニズムが削除されています。
The "Max-Forwards" header field provides a mechanism with the TRACE (Section 4.3.8) and OPTIONS (Section 4.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"ヘッダーフィールドは、TRACE（セクション4.3.8）およびOPTIONS（セクション4.3.7）リクエストメソッドを備えたメカニズムを提供し、リクエストがプロキシによって転送される回数を制限します。これは、クライアントが失敗しているか、チェーンの途中でループしているように見える要求をトレースしようとしている場合に役立ちます。
Max-Forwards = 1*DIGIT
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値は、この要求メッセージを転送できる残りの回数を示す10進整数です。
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ヘッダーフィールドを含むTRACEまたはOPTIONSリクエストを受信する各仲介者は、リクエストを転送する前にその値をチェックして更新する必要があります。受信した値がゼロ（0）の場合、仲介者はリクエストを転送してはなりません（MUST NOT）。代わりに、仲介者は最終受信者として応答する必要があります。受信したMax-Forwards値が0より大きい場合、仲介者は、転送されたメッセージ内に、a）受信した値を1だけ減らした（1）またはb）より小さいフィールド値を使用して、更新されたMax-Forwardsフィールドを生成する必要があります。 Max-Forwardsに対する受信者の最大サポート値。
A recipient MAY ignore a Max-Forwards header field received with any other request methods.
受信者は、他の要求メソッドで受信されたMax-Forwardsヘッダーフィールドを無視してもよい（MAY）。
The HTTP conditional request header fields [RFC7232] allow a client to place a precondition on the state of the target resource, so that the action corresponding to the method semantics will not be applied if the precondition evaluates to false. Each precondition defined by this specification 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 7.2). 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 5 of [RFC7232].
HTTP条件付きリクエストヘッダーフィールド[RFC7232]を使用すると、クライアントはターゲットリソースの状態に前提条件を設定できるため、前提条件がfalseと評価された場合、メソッドのセマンティクスに対応するアクションは適用されません。この仕様で定義されている各前提条件は、ターゲットリソースの以前の表現から取得した一連のバリデータと、選択した表現の現在のバリデータの状態との比較で構成されています（セクション7.2）。したがって、これらの前提条件は、ターゲットリソースの状態がクライアントによって認識されている特定の状態以降に変更されたかどうかを評価します。このような評価の効果は、[RFC7232]のセクション5で定義されているように、メソッドのセマンティクスと条件の選択に依存します。
+---------------------+--------------------------+
| Header Field Name | Defined in... |
+---------------------+--------------------------+
| If-Match | Section 3.1 of [RFC7232] |
| If-None-Match | Section 3.2 of [RFC7232] |
| If-Modified-Since | Section 3.3 of [RFC7232] |
| If-Unmodified-Since | Section 3.4 of [RFC7232] |
| If-Range | Section 3.2 of [RFC7233] |
+---------------------+--------------------------+
The following request header fields are sent by a user agent to engage in proactive negotiation of the response content, as defined in Section 3.4.1. 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.
次のリクエストヘッダーフィールドは、ユーザーエージェントによって送信され、セクション3.4.1で定義されているように、応答コンテンツの積極的な交渉に従事します。これらのフィールドで送信される設定は、ターゲットリソースの表現、エラーまたは処理ステータスの表現、プロトコル内に表示される可能性のあるその他のテキスト文字列など、応答のコンテンツに適用されます。
+-------------------+---------------+
| Header Field Name | Defined in... |
+-------------------+---------------+
| Accept | Section 5.3.2 |
| Accept-Charset | Section 5.3.3 |
| Accept-Encoding | Section 5.3.4 |
| Accept-Language | Section 5.3.5 |
+-------------------+---------------+
Many of the request header fields for proactive negotiation 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桁以上を生成してはなりません（MUST NOT）。これらの値のユーザー構成も同じ方法で制限する必要があります。
The "Accept" header field can be used by user agents to specify response media types that are acceptable. 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」ヘッダーフィールドを使用して、許容可能な応答メディアタイプを指定できます。 Acceptヘッダーフィールドを使用して、インライン画像のリクエストの場合のように、リクエストが特定のタイプの小さなセットに限定されていることを示すことができます。
Accept = #( media-range [ accept-params ] )
media-range = ( "*/*"
/ ( type "/" "*" )
/ ( type "/" subtype )
) *( OWS ";" OWS parameter )
accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
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 zero or more applicable media type parameters (e.g., charset), an optional "q" parameter for indicating a relative weight (Section 5.3.1), and then zero or more extension parameters. The "q" parameter is necessary if any extensions (accept-ext) are present, since it acts as a separator between the two parameter sets.
各メディア範囲の後には、0個以上の適用可能なメディアタイプパラメーター（たとえば、文字セット）、相対重みを示すオプションの「q」パラメーター（セクション5.3.1）、その後に0個以上の拡張パラメーターが続く場合があります。 "q"パラメータは、2つのパラメータセット間のセパレータとして機能するため、拡張（accept-ext）が存在する場合に必要です。
Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters in Accept. Future media types are discouraged from registering any parameter named "q".
注：メディアタイプパラメーターをAccept拡張パラメーターから分離するために「q」パラメーター名を使用するのは、歴史的な慣習によるものです。これにより、「q」という名前のメディアタイプパラメータがメディア範囲で使用されなくなりますが、IANAメディアタイプレジストリに「q」パラメータが不足していること、およびメディアタイプがまれにしか使用されないことがこのようなイベントの原因となる可能性は低いと考えられます。 Acceptのパラメータ。将来のメディアタイプでは、「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 request without any Accept header field implies that the user agent will accept any media type in response. If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, 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.
Acceptヘッダーフィールドのないリクエストは、ユーザーエージェントが応答でメディアタイプを受け入れることを意味します。ヘッダーフィールドがリクエストに存在し、レスポンスの利用可能な表現のどれにも許容可能としてリストされているメディアタイプがない場合、オリジンサーバーは406（Not Acceptable）レスポンスを送信してヘッダーフィールドを受け入れるか、ヘッダーを無視できます。応答をコンテンツネゴシエーションの対象ではないかのように処理することにより、フィールド。
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 / xcは同等に優先されるメディアタイプですが、存在しない場合はtext / x-dvi表現を送信し、存在しない場合はtext /わかりやすい表現」。
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/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
would cause the following values to be associated:
次の値が関連付けられます。
+-------------------+---------------+
| Media Type | Quality Value |
+-------------------+---------------+
| text/html;level=1 | 1 |
| text/html | 0.7 |
| text/plain | 0.3 |
| image/jpeg | 0.5 |
| text/html;level=2 | 0.4 |
| text/html;level=3 | 0.7 |
+-------------------+---------------+
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 what charsets are acceptable in textual response content. 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」ヘッダーフィールドは、ユーザーエージェントが送信して、テキスト応答コンテンツでどの文字セットが許容されるかを示すことができます。このフィールドを使用すると、より包括的または特殊な文字セットを理解できるユーザーエージェントは、それらの文字セットで情報を表現できるオリジンサーバーにその機能を通知できます。
Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
Charset names are defined in Section 3.1.1.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 5.3.1. An example is
文字セット名はセクション3.1.1.2で定義されています。セクション5.3.1で定義されているように、ユーザーエージェントは各文字セットに品質値を関連付けて、その文字セットに対するユーザーの相対的な好みを示すことができます（MAY）。例は
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset field, matches every charset that is not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then any charsets not explicitly mentioned in the field are considered "not acceptable" to the client.
Accept-Charsetフィールドに存在する場合、特別な値 "*"は、Accept-Charsetフィールドのどこにも記載されていないすべての文字セットと一致します。 Accept-Charsetフィールドに「*」が存在しない場合、フィールドに明示的に記述されていない文字セットは、クライアントには「受け入れられない」と見なされます。
A request without any Accept-Charset header field implies that the user agent will accept any charset in response. Most general-purpose user agents do not send Accept-Charset, unless specifically configured to do so, because a detailed list of supported charsets makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (Section 9.7).
Accept-Charsetヘッダーフィールドのない要求は、ユーザーエージェントが応答として任意の文字セットを受け入れることを意味します。サポートされている文字セットの詳細なリストにより、サーバーはユーザーエージェントのリクエスト特性（セクション9.7）に基づいて個人を識別しやすくなるため、ほとんどの汎用ユーザーエージェントはAccept-Charsetを送信しません。
If an Accept-Charset header field is present in a request and none of the available representations for the response has a charset that is listed as acceptable, the origin server can either honor the header field, by sending a 406 (Not Acceptable) response, or disregard the header field by treating the resource as if it is not subject to content negotiation.
Accept-Charsetヘッダーフィールドがリクエストに存在し、レスポンスの利用可能な表現のいずれにも許容可能としてリストされている文字セットがない場合、オリジンサーバーは406（Not Acceptable）レスポンスを送信してヘッダーフィールドを受け入れることができます。または、リソースをコンテンツネゴシエーションの対象外として扱うことにより、ヘッダーフィールドを無視します。
The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (Section 3.1.2.1) are acceptable in the response. An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred.
"Accept-Encoding"ヘッダーフィールドをユーザーエージェントが使用して、どの応答コンテンツコーディング（セクション3.1.2.1）が応答で受け入れられるかを示すことができます。 「ID」トークンは、エンコーディングが優先されない場合に通信するために、「エンコーディングなし」の同義語として使用されます。
Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*"
Each codings value MAY be given an associated quality value representing the preference for that encoding, as defined in Section 5.3.1. The asterisk "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header field.
セクション5.3.1で定義されているように、各コーディング値には、そのエンコーディングの優先順位を表す関連する品質値を与えることができます。 Accept-Encodingフィールド内のアスタリスク "*"記号は、ヘッダーフィールドに明示的にリストされていない使用可能なコンテンツコーディングと一致します。
For example,
例えば、
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 request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings. Although this allows the server to use any content-coding in a response, it does not imply that the user agent will be able to correctly process all encodings.
Accept-Encodingヘッダーフィールドのないリクエストは、ユーザーエージェントがコンテンツコーディングに関する設定を持たないことを意味します。これにより、サーバーは応答でコンテンツコーディングを使用できますが、ユーザーエージェントがすべてのエンコーディングを正しく処理できることを意味するものではありません。
A server tests whether a content-coding for a given representation is acceptable using these rules:
サーバーは、次のルールを使用して、特定の表現のコンテンツコーディングが許容可能かどうかをテストします。
1. If no Accept-Encoding field is in the request, any content-coding is considered acceptable by the user agent.
1. Accept-Encodingフィールドがリクエストにない場合、コンテンツコーディングはユーザーエージェントによって受け入れ可能と見なされます。
2. If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity".
2. 表現にコンテンツコーディングがない場合、「identity」のより具体的なエントリなしで「identity; q = 0」または「*; q = 0」を示すAccept-Encodingフィールドによって明確に除外されない限り、デフォルトで許容されます。 。
3. If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable unless it is accompanied by a qvalue of 0. (As defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)
3. 表現のコンテンツコーディングがAccept-Encodingフィールドにリストされているコンテンツコーディングの1つである場合、qvalueが0でない限り許容されます（セクション5.3.1で定義されているように、qvalue 0は「受け付けできません"。）
4. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
4. 複数のコンテンツコーディングが許容できる場合、ゼロ以外のqvalueが最も高い許容可能なコンテンツコーディングが優先されます。
An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding in response. If an 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.
空のフィールド値を組み合わせたAccept-Encodingヘッダーフィールドは、ユーザーエージェントがコンテンツコーディングの応答を望まないことを意味します。 Accept-Encodingヘッダーフィールドがリクエストに存在し、レスポンスの利用可能な表現のどれにも許容可能としてリストされているコンテンツコーディングがない場合、オリジンサーバーはコンテンツコーディングなしでレスポンスを送信する必要があります（SHOULD）。
Note: Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues might not work and are not permitted with x-gzip or x-compress.
注：ほとんどのHTTP / 1.0アプリケーションは、コンテンツコーディングに関連付けられたqvalueを認識または従いません。つまり、qvalueは機能せず、x-gzipまたはx-compressでは許可されません。
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 3.1.3.1.
"Accept-Language"ヘッダーフィールドは、ユーザーエージェントが応答で優先される一連の自然言語を示すために使用できます。言語タグはセクション3.1.3.1で定義されています。
Accept-Language = 1#( 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 5.3.1. For example,
セクション5.3.1で定義されているように、各言語範囲には、その範囲で指定された言語に対するユーザーの好みの推定を表す関連する品質値を与えることができます。例えば、
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".
「私はデンマーク語が好きですが、イギリス英語と他のタイプの英語を受け入れます」を意味します。
A request without any Accept-Language header field implies that the user agent will accept any language in response. If the header field is present in a request and none of the available representations for the response have a matching language tag, the origin server can either disregard the header field by treating the response as if it is not subject to content negotiation or honor the header field by sending a 406 (Not Acceptable) response. However, the latter is not encouraged, as doing so can prevent users from accessing content that they might be able to use (with translation software, for example).
Accept-Languageヘッダーフィールドのないリクエストは、ユーザーエージェントが応答として任意の言語を受け入れることを意味します。ヘッダーフィールドがリクエストに存在し、応答の利用可能な表現のいずれにも一致する言語タグがない場合、オリジンサーバーは、コンテンツネゴシエーションの対象ではないかのように応答を処理することによってヘッダーフィールドを無視するか、ヘッダーを受け入れることができます。フィールドに406（Not Acceptable）応答を送信します。ただし、後者の場合、ユーザーが（たとえば、翻訳ソフトウェアを使用して）使用できるコンテンツにアクセスできなくなる可能性があるため、推奨されません。
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 9.7).
Accept-Languageヘッダーフィールドを、すべてのリクエストでユーザーの完全な言語設定で送信することは、ユーザーのプライバシーの期待に反する場合があります（セクション9.7）。
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.
了解度は個々のユーザーに大きく依存するため、ユーザーエージェントは言語プリファレンスをユーザーが制御できるようにする必要があります（ユーザーエージェント自体の設定またはデフォルトでユーザー制御可能なシステム設定による）。このような制御をユーザーに提供しないユーザーエージェントは、Accept-Languageヘッダーフィールドを送信してはなりません（MUST NOT）。
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.
注：ユーザーエージェントは、設定を行うときにユーザーにガイダンスを提供する必要があります。これは、ユーザーが上記の言語マッチングの詳細に精通していることはめったにないためです。たとえば、ユーザーが「en-gb」を選択すると、イギリス英語が利用できない場合は、あらゆる種類の英語のドキュメントが提供されると想定します。このような場合、ユーザーエージェントは、より一致する動作を実現するために、リストに「en」を追加することを提案する場合があります。
Two header fields are used for carrying authentication credentials, as defined in [RFC7235]. Note that various custom mechanisms for user authentication use the Cookie header field for this purpose, as defined in [RFC6265].
[RFC7235]で定義されているように、2つのヘッダーフィールドが認証資格情報の伝達に使用されます。 [RFC6265]で定義されているように、ユーザー認証のさまざまなカスタムメカニズムがこの目的でCookieヘッダーフィールドを使用することに注意してください。
+---------------------+--------------------------+
| Header Field Name | Defined in... |
+---------------------+--------------------------+
| Authorization | Section 4.2 of [RFC7235] |
| Proxy-Authorization | Section 4.4 of [RFC7235] |
+---------------------+--------------------------+
The following request header fields provide additional information about the request context, including information about the user, user agent, and resource behind the request.
次のリクエストヘッダーフィールドは、リクエストの背後にあるユーザー、ユーザーエージェント、リソースに関する情報など、リクエストコンテキストに関する追加情報を提供します。
+-------------------+---------------+
| Header Field Name | Defined in... |
+-------------------+---------------+
| From | Section 5.5.1 |
| Referer | Section 5.5.2 |
| User-Agent | Section 5.5.3 |
+-------------------+---------------+
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
From =メールボックス
mailbox = <mailbox, see [RFC5322], Section 3.4>
An example is:
例は次のとおりです。
From: webmaster@example.org
差出人：webmaster@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ヘッダーフィールドは、非ロボットユーザーエージェントによって送信されることはほとんどありません。ユーザーエージェントは、ユーザーの明示的な構成なしにFromヘッダーフィールドを送信しないでください。これは、ユーザーのプライバシー保護やサイトのセキュリティポリシーと競合する可能性があるためです。
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.
ロボットユーザーエージェントは有効なFromヘッダーフィールドを送信する必要があります（SHOULD）。ロボットが過剰な要求、望ましくない要求、または無効な要求を送信している場合など、サーバーで問題が発生した場合にロボットの実行責任者に連絡できるようにする必要があります。
A server SHOULD NOT use the From header field for access control or authentication, since most recipients will assume that the field value is public information.
ほとんどの受信者はフィールドの値が公開情報であると想定するため、サーバーはアクセス制御または認証にFromヘッダーフィールドを使用しないでください。
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 [RFC3986], if any, when generating the Referer field value.
「Referer」[sic]ヘッダーフィールドを使用すると、ユーザーエージェントは、ターゲットURIの取得元であるリソースのURI参照を指定できます（つまり、「referrer」ですが、フィールド名のスペルは間違っています）。ユーザーエージェントは、Refererフィールド値を生成するときに、URI参照[RFC3986]のフラグメントおよびuserinfoコンポーネントを含めてはなりません（MUST NOT）。
Referer = absolute-URI / partial-URI
リファラー=絶対URI /部分URI
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.
サーバーは、Refererヘッダーフィールドを使用して、単純な分析、ロギング、最適化されたキャッシュなどのために他のリソースへのバックリンクを生成できます。また、メンテナンスのために古いリンクや誤って入力されたリンクを見つけることもできます。一部のサーバーは、他のサイトからのリンクを拒否する手段（いわゆる「ディープリンク」）またはクロスサイトリクエストフォージェリ（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 field or send it with a value of "about:blank".
ターゲットURIが独自のURIを持たないソースから取得された場合（たとえば、ユーザーキーボードからの入力、またはユーザーのブックマーク/お気に入り内のエントリ）、ユーザーエージェントは、Refererフィールドを除外するか、Refererフィールドとともに送信する必要があります。 「about：blank」の値。
The Referer 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 MUST NOT send a Referer header field in an unsecured HTTP request if the referring page was received with a secure protocol. See Section 9.4 for additional security considerations.
Refererフィールドは、ユーザーのリクエストコンテキストまたは閲覧履歴に関する情報を公開する可能性があります。これは、参照リソースの識別子が個人情報（アカウント名など）または機密であると想定されるリソース（アカウント名など）を公開する場合のプライバシーの問題です。ファイアウォールの内側や保護されたサービスの内部など）。参照リソースがローカルの「ファイル」または「データ」URIの場合、ほとんどの汎用ユーザーエージェントは、Refererヘッダーフィールドを送信しません。安全なプロトコルで参照ページを受信した場合、ユーザーエージェントは、安全でないHTTPリクエストでRefererヘッダーフィールドを送信してはなりません（MUST NOT）。セキュリティに関するその他の考慮事項については、9.4項を参照してください。
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 request target.
一部の仲介者は、発信要求から無差別にリファラーヘッダーフィールドを削除することが知られています。これには、残念なことに、CSRF攻撃に対する保護を妨害するという副作用があります。これは、ユーザーにとってはるかに有害な場合があります。仲介者とユーザーエージェント拡張機能は、Refererでの情報開示を制限したい場合、内部ドメイン名を仮名に置き換えたり、クエリやパスコンポーネントを切り捨てたりするなど、変更を特定の編集に制限する必要があります。中間値は、フィールド値が要求ターゲットと同じスキームおよびホストを共有する場合、Refererヘッダーフィールドを変更または削除するべきではありません（SHOULD NOT）。
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 field in each request unless specifically configured not to do so.
「User-Agent」ヘッダーフィールドには、リクエストを発信したユーザーエージェントに関する情報が含まれます。これは、サーバーがレポートする相互運用性の問題の範囲の特定、特定のユーザーエージェントの制限を回避するための応答の回避または調整、分析のためによく使用されます。ブラウザまたはオペレーティングシステムの使用に関して。ユーザーエージェントは、特に設定しない限り、各リクエストでUser-Agentフィールドを送信する必要があります（SHOULD）。
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 3.2 of [RFC7230]), 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.
User-Agentフィールド値は、1つ以上の製品識別子で構成され、それぞれに0個以上のコメント（[RFC7230]のセクション3.2）が続きます。これらのコメントは、ユーザーエージェントソフトウェアとその重要なサブ製品をまとめて識別します。慣例により、製品識別子は、ユーザーエージェントソフトウェアを識別するための重要度の降順でリストされています。各製品IDは、名前とオプションのバージョンで構成されています。
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).
送信者は、生成された製品識別子を製品を識別するために必要なものに制限する必要があります（SHOULD）。送信者は、製品識別子内に広告またはその他の重要でない情報を生成してはいけません。送信者は、バージョン識別子ではない製品バージョンで情報を生成してはなりません（つまり、同じ製品名の連続するバージョンは、製品識別子の製品バージョン部分のみが異なるべきです）。
Example:
例：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
A user agent SHOULD NOT generate a User-Agent 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").
ユーザーエージェントは、不必要に細かい詳細を含むユーザーエージェントフィールドを生成してはならず（SHOULD NOT）、サードパーティによるサブプロダクトの追加を制限する必要があります（SHOULD）。過度に長く詳細なUser-Agentフィールド値は、リクエストのレイテンシを増加させ、ユーザーが希望に反して識別されるリスク（「フィンガープリント」）を引き起こします。
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 status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.
status-code要素は3桁の整数コードで、要求を理解して満足するための試行の結果を示します。
HTTP status codes are extensible. HTTP clients are 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, with the exception that a recipient MUST NOT cache a response with an unrecognized status code.
HTTPステータスコードは拡張可能です。 HTTPクライアントは、登録されているすべてのステータスコードの意味を理解する必要はありませんが、そのような理解が望ましいことは明らかです。ただし、クライアントは最初の桁で示されるように、ステータスコードのクラスを理解しなければならず、認識されないステータスコードは、そのクラスのx00ステータスコードと同等であるとして扱わなければなりません。認識されないステータスコード。
For example, if an unrecognized status code of 471 is received by a client, the client can assume 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（Bad Request）ステータスコードを受け取ったかのように応答を処理できます。通常、応答メッセージには、ステータスを説明する表現が含まれます。
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つの値があります。
o 1xx (Informational): The request was received, continuing process
o 1xx（情報）：リクエストを受け取り、プロセスを続行
o 2xx (Successful): The request was successfully received, understood, and accepted
o 2xx（成功）：リクエストは正常に受信され、理解され、受け入れられました
o 3xx (Redirection): Further action needs to be taken in order to complete the request
o 3xx（リダイレクト）：リクエストを完了するには、さらにアクションを実行する必要があります
o 4xx (Client Error): The request contains bad syntax or cannot be fulfilled
o 4xx（クライアントエラー）：リクエストに不正な構文が含まれている、または実行できない
o 5xx (Server Error): The server failed to fulfill an apparently valid request
o 5xx（サーバーエラー）：サーバーは明らかに有効な要求を実行できませんでした
The status codes listed below are defined in this specification, Section 4 of [RFC7232], Section 4 of [RFC7233], and Section 3 of [RFC7235]. The reason phrases listed here are only recommendations -- they can be replaced by local equivalents without affecting the protocol.
下記のステータスコードは、この仕様、[RFC7232]のセクション4、[RFC7233]のセクション4、[RFC7235]のセクション3で定義されています。ここに記載されている理由フレーズは推奨事項にすぎません。プロトコルに影響を与えることなく、ローカルの同等のものに置き換えることができます。
Responses with status codes that are defined as cacheable by default (e.g., 200, 203, 204, 206, 300, 301, 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 [RFC7234]; all other status codes are not cacheable by default.
デフォルトでキャッシュ可能として定義されているステータスコード（たとえば、この仕様では200、203、204、206、300、301、404、405、410、414、および501）を持つ応答は、ヒューリスティックな有効期限のあるキャッシュで再利用できます。それ以外の場合は、メソッド定義または明示的なキャッシュ制御によって示されます[RFC7234]。他のすべてのステータスコードは、デフォルトではキャッシュできません。
+------+-------------------------------+--------------------------+
| Code | Reason-Phrase | Defined in... |
+------+-------------------------------+--------------------------+
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | Section 4.1 of [RFC7233] |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | Section 4.1 of [RFC7232] |
| 305 | Use Proxy | Section 6.4.5 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | Section 3.1 of [RFC7235] |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | Section 3.2 of [RFC7235] |
| 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | Section 4.2 of [RFC7232] |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | Section 4.4 of [RFC7233] |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
+------+-------------------------------+--------------------------+ Note that this list is not exhaustive -- it does not include
extension status codes defined in other specifications. The complete
list of status codes is maintained by IANA. See Section 8.2 for
details.
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. 1xx responses are terminated by the first empty line after the status-line (the empty line signaling the end of the header section). 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（情報）クラスは、要求されたアクションを完了して最終応答を送信する前に、接続ステータスまたは要求の進行状況を通知するための暫定応答を示します。 1xx応答は、ステータス行の後の最初の空行で終了します（空行はヘッダーセクションの終わりを示します）。 HTTP / 1.0は1xxステータスコードを定義していないため、サーバーはHTTP / 1.0クライアントに1xx応答を送信してはなりません（MUST NOT）。
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応答を解析できなければなりません（MUST）。ユーザーエージェントは予期しない1xx応答を無視してもよい（MAY）。
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" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).
プロキシ自体が1xx応答の生成を要求しない限り、プロキシは1xx応答を転送する必要があります。たとえば、プロキシがリクエストを転送するときに「Expect：100-continue」フィールドを追加する場合、対応する100（Continue）応答を転送する必要はありません。
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 payload body, as described in Section 5.1.1. The client ought to continue sending the request and discard the 100 response.
リクエストに100-continue期待値を含むExpectヘッダーフィールドが含まれている場合、セクション5.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-continue期待値を含むExpectヘッダーフィールドが含まれていない場合、クライアントはこの暫定応答を単に破棄できます。
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 6.7 of [RFC7230]), 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 switched to immediately after the empty line that terminates the 101 response.
101（Switching Protocols）ステータスコードは、この接続で使用されているアプリケーションプロトコルの変更について、サーバーがクライアントの要求を理解し、Upgradeヘッダーフィールド（[RFC7230]のセクション6.7）を介してクライアントの要求に準拠する意思があることを示します。サーバーは、101応答を終了する空の行の直後にどのプロトコルに切り替えるかを示す応答にUpgradeヘッダーフィールドを生成する必要があります。
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 payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as:
200（OK）ステータスコードは、リクエストが成功したことを示します。 200応答で送信されるペイロードは、要求メソッドによって異なります。この仕様で定義されているメソッドの場合、ペイロードの意図する意味は次のように要約できます。
GET a representation of the target resource;
ターゲットリソースの表現を取得します。
HEAD the same representation as GET, but without the representation data;
HEADはGETと同じ表現ですが、表現データはありません。
POST a representation of the status of, or results obtained from, the action;
アクションのステータスまたはアクションから取得した結果の表現をPOSTします。
PUT, DELETE a representation of the status of the action;
アクションのステータスの表現をPUT、DELETE。
OPTIONS a representation of the communications options;
OPTIONSは、通信オプションの表現です。
TRACE a representation of the request message as received by the end server.
エンドサーバーが受信した要求メッセージの表現をトレースします。
Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. If no payload is desired, an origin server ought to send 204 (No Content) instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the 200 response header section.
CONNECTへの応答とは別に、200応答には常にペイロードがありますが、起点サーバーは長さゼロのペイロード本体を生成できます（MAY）。ペイロードが不要な場合、オリジンサーバーは代わりに204（コンテンツなし）を送信する必要があります。 CONNECTの場合、成功した結果は200応答ヘッダーセクションの直後から始まるトンネルであるため、ペイロードは許可されません。
A 200 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
200応答はデフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御で特に示されていない限り（[RFC7234]のセクション4.2.2を参照）。
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 field is received, by the effective request URI.
201（作成済み）ステータスコードは、要求が満たされ、1つ以上の新しいリソースが作成されたことを示します。リクエストによって作成されたプライマリリソースは、レスポンスのLocationヘッダーフィールドによって識別されます。Locationフィールドが受信されない場合は、有効なリクエストURIによって識別されます。
The 201 response payload typically describes and links to the resource(s) created. See Section 7.2 for a discussion of the meaning and purpose of validator header fields, such as ETag and Last-Modified, in a 201 response.
201応答ペイロードは通常、作成されたリソースを記述してリンクします。 201応答のETagやLast-Modifiedなどのバリデーターヘッダーフィールドの意味と目的については、セクション7.2を参照してください。
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（Accepted）ステータスコードは、要求が処理のために受け入れられたが、処理が完了していないことを示します。処理が実際に行われるときに許可されない場合があるため、要求は最終的に処理される場合と処理されない場合があります。 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 payload has been modified from that of the origin server's 200 (OK) response by a transforming proxy (Section 5.7.2 of [RFC7230]). 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（Non-Authoritative Information）ステータスコードは、リクエストは成功したが、囲まれたペイロードが、変換プロキシ（[RFC7230]のセクション5.7.2）によって、配信元サーバーの200（OK）応答のペイロードから変更されたことを示します。このステータスコードを使用すると、変換が適用されたときにプロキシが受信者に通知できるようになります。その知識は、コンテンツに関する後の決定に影響を与える可能性があるためです。たとえば、コンテンツの今後のキャッシュ検証リクエストは、同じリクエストパス（同じプロキシ経由）でのみ適用される可能性があります。
The 203 response is similar to the Warning code of 214 Transformation Applied (Section 5.5 of [RFC7234]), which has the advantage of being applicable to responses with any status code.
203応答は、214 Transformation Appliedの警告コード（[RFC7234]のセクション5.5）に似ています。これは、任意のステータスコードの応答に適用できるという利点があります。
A 203 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
203応答はデフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御で特に示されていない限り（[RFC7234]のセクション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 payload body. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.
204（No Content）ステータスコードは、サーバーがリクエストを正常に処理したこと、および応答ペイロードの本文で送信する追加のコンテンツがないことを示します。応答ヘッダーフィールドのメタデータは、要求されたアクションが適用された後のターゲットリソースとその選択された表現を参照します。
For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.
たとえば、PUTリクエストへの応答としてステータスコード204が受信され、そのレスポンスに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 first empty line after the header fields because it cannot contain a message body.
メッセージ本文を含めることができないため、204応答はヘッダーフィールドの後の最初の空行で終了します。
A 204 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
デフォルトでは、204応答はキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御で特に示されていない限り（[RFC7234]のセクション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 a payload in a 205 response. In other words, a server MUST do one of the following for a 205 response: a) indicate a zero-length body for the response by including a Content-Length header field with a value of 0; b) indicate a zero-length payload for the response by including a Transfer-Encoding header field with a value of chunked and a message body consisting of a single chunk of zero-length; or, c) close the connection immediately after sending the blank line terminating the header section.
205ステータスコードは追加のコンテンツが提供されないことを意味するため、サーバーは205応答でペイロードを生成してはなりません（MUST NOT）。言い換えると、サーバーは205応答に対して次のいずれかを実行する必要があります。a）値0のContent-Lengthヘッダーフィールドを含めることにより、応答の長さがゼロの本文を示します。 b）チャンクの値を持つTransfer-Encodingヘッダーフィールドと、長さがゼロの単一のチャンクで構成されるメッセージ本文を含めることにより、応答のゼロの長さのペイロードを示します。または、c）ヘッダーセクションを終了する空白行を送信した直後に接続を閉じます。
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. If a Location header field (Section 7.1.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 done with care for methods not known to be safe, as defined in Section 4.2.1, since the user might not wish to redirect an unsafe request.
ステータスコードの3xx（リダイレクト）クラスは、要求を満たすためにユーザーエージェントがさらにアクションを実行する必要があることを示します。 Locationヘッダーフィールド（セクション7.1.2）が提供されている場合、ユーザーエージェントは、特定のステータスコードが理解されていなくても、要求をLocationフィールド値によって参照されるURIに自動的にリダイレクトできます（MAY）。ユーザーが安全でない要求をリダイレクトしたくない場合があるため、自動リダイレクトは、セクション4.2.1で定義されているように、安全であることがわかっていないメソッドに注意して行う必要があります。
There are several types of redirects:
リダイレクトにはいくつかの種類があります。
1. Redirects that indicate the resource might be available at a different URI, as provided by the Location field, as in the status codes 301 (Moved Permanently), 302 (Found), and 307 (Temporary Redirect).
1. ステータスコード301（永久に移動）、302（見つかりました）、および307（一時的なリダイレクト）のように、[場所]フィールドで指定されているように、リソースが別のURIで使用できることを示すリダイレクト。
2. Redirection that offers a choice of matching resources, each capable of representing the original request target, as in the 300 (Multiple Choices) status code.
2. 300（Multiple Choices）ステータスコードのように、一致するリソースの選択肢を提供するリダイレクト。それぞれが元のリクエストターゲットを表すことができます。
3. Redirection to a different resource, identified by the Location field, that can represent an indirect response to the request, as in the 303 (See Other) status code.
3. 303（その他を参照）ステータスコードのように、要求への間接的な応答を表すことができる、Locationフィールドで識別される別のリソースへのリダイレクト。
4. Redirection to a previously cached result, as in the 304 (Not Modified) status code.
4. 304（Not Modified）ステータスコードのように、以前にキャッシュされた結果へのリダイレクト。
Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and 302 (Found) were defined for the first type of redirect ([RFC1945], Section 9.3). Early user agents split on whether the method applied to the redirect target would be the same as the original request or would be rewritten as GET. Although HTTP originally defined the former semantics for 301 and 302 (to match its original implementation at CERN), and defined 303 (See Other) to match the latter semantics, prevailing practice gradually converged on the latter semantics for 301 and 302 as well. The first revision of HTTP/1.1 added 307 (Temporary Redirect) to indicate the former semantics without being impacted by divergent practice. Over 10 years later, most user agents still do method rewriting for 301 and 302; therefore, this specification makes that behavior conformant when the original request is POST.
注：HTTP / 1.0では、ステータスコード301（永久に移動）および302（検出）は、最初のタイプのリダイレクト（[RFC1945]、セクション9.3）に対して定義されました。初期のユーザーエージェントは、リダイレクトターゲットに適用されるメソッドが元のリクエストと同じであるか、GETとして書き換えられるかで分かれていました。 HTTPは当初、301と302の前のセマンティクスを（CERNでの元の実装と一致するように）定義し、303（その他を参照）を後者のセマンティクスと一致するように定義しましたが、一般的な慣習は、301と302の後者のセマンティクスにも徐々に収束しました。 HTTP / 1.1の最初のリビジョンでは、307（一時的なリダイレクト）を追加して、異なる慣行の影響を受けずに以前のセマンティクスを示しました。 10年以上経った今でも、ほとんどのユーザーエージェントは、301と302のメソッドを書き換えています。したがって、この仕様では、元の要求がPOSTの場合にその動作を適合させます。
A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).
クライアントは、周期的なリダイレクト（つまり、「無限」のリダイレクトループ）を検出して介入する必要があります（SHOULD）。
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.
注：この仕様の以前のバージョンでは、最大5つのリダイレクトを推奨していました（[RFC2068]、セクション10.3）。コンテンツ開発者は、一部のクライアントがこのような固定された制限を実装する可能性があることを認識する必要があります。
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 3.4).
300（Multiple Choices）ステータスコードは、ターゲットリソースに複数の表現があり、それぞれに固有のより具体的な識別子があることを示します。ユーザー（またはユーザーエージェント）が優先表現を選択できるように、代替に関する情報が提供されています。リクエストをそれらの識別子の1つ以上にリダイレクトします。言い換えると、サーバーは、ユーザーエージェントがそのニーズに最適な表現を選択するために反応的な交渉を行うことを望んでいます（セクション3.4）。
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参照を含むLocationヘッダーフィールドを生成する必要があります（SHOULD）。ユーザーエージェントは、自動リダイレクトのためにLocationフィールド値を使用してもよい（MAY）。
For request methods other than HEAD, the server SHOULD generate a payload 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 payloads. 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.
HEAD以外のリクエストメソッドの場合、サーバーは、ユーザーまたはユーザーエージェントが最も好ましいものを選択できる表現メタデータとURI参照のリストを含む300応答でペイロードを生成する必要があります（SHOULD）。ユーザーエージェントは、提供されたメディアタイプを理解している場合、そのリストから自動的に選択してもよい（MAY）。 HTTPはペイロードの定義と直交関係を維持しようとするため、自動選択の特定の形式はこの仕様では定義されていません。実際には、表現は、共有設計またはコンテンツネゴシエーションによって決定される、ユーザーエージェントに受け入れられると考えられるいくつかの簡単に解析される形式、またはいくつかの一般的に受け入れられているハイパーテキスト形式で提供されます。
A 300 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
300応答はデフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御で特に示されていない限り（[RFC7234]のセクション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 using a set of Link header fields [RFC5988], each with a relationship of "alternate", though deployment is a chicken-and-egg problem.
注：300ステータスコードの最初の提案では、URIヘッダーフィールドを代替表現のリストを提供するものとして定義しました。これにより、200、300、および406応答で使用でき、HEADメソッドへの応答で転送されます。ただし、展開の欠如と構文の不一致により、URIと代替案（以降の提案）の両方がこの仕様から除外されました。リンクヘッダーフィールドのセット[RFC5988]を使用してリストを通信することは可能であり、それぞれが「代替」の関係にありますが、展開は鶏と卵の問題です。
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. Clients with link-editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible.
301（永久に移動）ステータスコードは、ターゲットリソースに新しい永続的なURIが割り当てられており、このリソースへの今後の参照では、囲まれたURIの1つを使用する必要があることを示します。リンク編集機能を備えたクライアントは、有効なリクエストURIへの参照を、可能な場合はサーバーから送信された1つ以上の新しい参照に自動的に再リンクする必要があります。
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 payload usually contains a short hypertext note with a hyperlink to the new URI(s).
サーバーは、新しい永続URIの優先URI参照を含む応答にLocationヘッダーフィールドを生成する必要があります（SHOULD）。ユーザーエージェントは、自動リダイレクトのためにLocationフィールド値を使用してもよい（MAY）。サーバーの応答ペイロードには、通常、新しい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.
注：歴史的な理由により、ユーザーエージェントは、後続のリクエストのリクエストメソッドをPOSTからGETに変更する場合があります。この動作が望ましくない場合は、代わりに307（一時リダイレクト）ステータスコードを使用できます。
A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
デフォルトでは、301応答はキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御で特に示されていない限り（[RFC7234]のセクション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 effective request URI for future requests.
302（Found）ステータスコードは、ターゲットリソースが一時的に別の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 payload usually contains a short hypertext note with a hyperlink to the different URI(s).
サーバーは、異なるURIのURI参照を含む応答にLocationヘッダーフィールドを生成する必要があります（SHOULD）。ユーザーエージェントは、自動リダイレクトのためにLocationフィールド値を使用してもよい（MAY）。サーバーの応答ペイロードには、通常、異なる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.
注：歴史的な理由により、ユーザーエージェントは、後続のリクエストのリクエストメソッドをPOSTからGETに変更する場合があります。この動作が望ましくない場合は、代わりに307（一時リダイレクト）ステータスコードを使用できます。
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 effective request URI.
303（その他を参照）ステータスコードは、サーバーがユーザーエージェントを別のリソースにリダイレクトしていることを示します。これは、元の要求に対する間接的な応答を提供するためのLocationヘッダーフィールドのURIによって示されます。ユーザーエージェントは、リダイレクトされる可能性があるそのURI（HTTPを使用している場合はGETまたはHEAD要求）を対象とする取得要求を実行し、最終的な結果を元の要求に対する応答として提示できます。 Locationヘッダーフィールドの新しい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 selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached, independent of the original request.
このステータスコードは、すべてのHTTPメソッドに適用できます。これは主に、POSTアクションの出力がユーザーエージェントを選択したリソースにリダイレクトできるようにするために使用されます。これにより、POST応答に対応する情報が、個別に識別、ブックマーク、およびキャッシュできる形式で提供されます。元の要求。
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応答は、オリジンサーバーが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.
HEAD要求への応答を除いて、303応答の表現には、Locationヘッダーフィールドで提供された同じURI参照へのハイパーリンクを持つ短いハイパーテキストノートが含まれている必要があります。
The 305 (Use Proxy) status code was defined in a previous version of this specification and is now deprecated (Appendix B).
305（プロキシの使用）ステータスコードは、この仕様の以前のバージョンで定義されており、現在は推奨されていません（付録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 effective request 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 payload usually contains a short hypertext note with a hyperlink to the different URI(s).
サーバーは、異なるURIのURI参照を含む応答にLocationヘッダーフィールドを生成する必要があります（SHOULD）。ユーザーエージェントは、自動リダイレクトのためにLocationフィールド値を使用してもよい（MAY）。サーバーの応答ペイロードには、通常、異なるURIへのハイパーリンクを含む短いハイパーテキストノートが含まれています。
Note: This status code is similar to 302 (Found), except that it does not allow changing the request method from POST to GET. This specification defines no equivalent counterpart for 301 (Moved Permanently) ([RFC7238], however, defines the status code 308 (Permanent Redirect) for this purpose).
注：このステータスコードは、リクエストメソッドをPOSTからGETに変更できないことを除いて、302（Found）に似ています。この仕様では、301（永久に移動）に相当するものは定義されていません（[RFC7238]は、この目的のためにステータスコード308（永久リダイレクト）を定義しています）。
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（クライアントエラー）クラスは、クライアントにエラーが発生したように見えることを示しています。 HEADリクエストに応答する場合を除いて、サーバーは、エラー状況の説明と、それが一時的な状態か永続的な状態かを含む表現を送信する必要があります（SHOULD）。これらのステータスコードは、どのリクエストメソッドにも適用できます。ユーザーエージェントは、含まれている表現をユーザーに表示する必要があります（SHOULD）。
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（Bad Request）ステータスコードは、クライアントエラーであると認識されている何か（不正なリクエスト構文、無効なリクエストメッセージのフレーミング、または不正なリクエストルーティングなど）が原因で、サーバーがリクエストを処理できない、または処理しないことを示します。
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 authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (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.
要求で認証資格情報が提供された場合、サーバーはそれらをアクセスを許可するには不十分であると見なします。クライアントは、同じ資格情報で要求を自動的に繰り返すべきではありません（SHOULD NOT）。クライアントは、新しいまたは異なる資格情報で要求を繰り返すことができます。ただし、認証情報とは無関係の理由でリクエストが禁止される場合があります。
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).
禁止されたターゲットリソースの現在の存在を「非表示」にするオリジンサーバーは、代わりにステータスコード404（Not Found）で応答する場合があります。
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（見つかりません）ステータスコードは、オリジンサーバーがターゲットリソースの現在の表現を見つけられなかったか、存在することを開示する意思がないことを示します。 404ステータスコードは、この表現の欠如が一時的なものか永続的なものかを示しません。おそらくいくつかの構成可能な手段を通じて、起点サーバーが状態が永続的である可能性が高いことを知っている場合、410（存在しない）状況コードは404よりも優先されます。
A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
404応答はデフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御で特に示されていない限り（[RFC7234]のセクション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（Method Not Allowed）ステータスコードは、request-lineで受信されたメソッドがオリジンサーバーによって認識されているが、ターゲットリソースによってサポートされていないことを示します。オリジンサーバーは、ターゲットリソースの現在サポートされているメソッドのリストを含む405応答にAllowヘッダーフィールドを生成する必要があります。
A 405 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
405応答はデフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御で特に示されていない限り（[RFC7234]のセクション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 5.3), and the server is unwilling to supply a default representation.
406（Not Acceptable）ステータスコードは、リクエスト（セクション5.3）で受信したプロアクティブネゴシエーションヘッダーフィールドに従って、ターゲットリソースがユーザーエージェントに受け入れられる現在の表現を持たず、サーバーがデフォルトの表現を指定します。
The server SHOULD generate a payload 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 6.4.1.
サーバーは、ユーザーまたはユーザーエージェントが最も適切なものを選択できる、利用可能な表現特性と対応するリソース識別子のリストを含むペイロードを生成する必要があります（SHOULD）。ユーザーエージェントは、そのリストから最も適切な選択肢を自動的に選択してもよい（MAY）。ただし、この仕様では、セクション6.4.1で説明されているように、そのような自動選択の標準を定義していません。
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. A server SHOULD send the "close" connection option (Section 6.1 of [RFC7230]) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client MAY repeat that request on a new connection.
408（リクエストタイムアウト）ステータスコードは、サーバーが待機する準備ができている時間内に完全なリクエストメッセージを受信しなかったことを示します。サーバーは、408がサーバーが待機を続けるのではなく接続を閉じることを決定したことを意味するため、応答で「閉じる」接続オプション（[RFC7230]のセクション6.1）を送信する必要があります。クライアントに転送中の未処理の要求がある場合、クライアントは新しい接続でその要求を繰り返すことができます（MAY）。
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 a payload that includes enough information for a user to recognize the source of the conflict.
409（競合）ステータスコードは、ターゲットリソースの現在の状態との競合が原因で要求を完了できなかったことを示します。このコードは、ユーザーが競合を解決してリクエストを再送信できる場合に使用されます。サーバーは、ユーザーが競合の原因を認識するのに十分な情報を含むペイロードを生成する必要があります（SHOULD）。
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リクエストへの応答で発生する可能性が最も高いです。たとえば、バージョニングが使用されていて、PUTである表現にリソースへの変更が含まれていて、以前の（サードパーティの）要求によって行われた変更と競合する場合、オリジンサーバーは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）ステータスコードは、ターゲットリソースへのアクセスがオリジンサーバーで利用できなくなったこと、およびこの状態が永続的である可能性が高いことを示しています。オリジンサーバーが状態が永続的であるかどうかを判断できない、または判断する機能がない場合は、代わりにステータスコード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メンテナンスのタスクを支援することを目的としています。このようなイベントは、期間限定のプロモーションサービスや、元のサーバーのサイトに関連付けられなくなった個人に属するリソースに共通です。永続的に利用できないリソースをすべて「存在しない」としてマークしたり、マークを任意の期間保持したりする必要はありません。これはサーバーの所有者の裁量に任されています。
A 410 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
410応答はデフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御で特に示されていない限り（[RFC7234]のセクション4.2.2を参照）。
The 411 (Length Required) status code indicates that the server refuses to accept the request without a defined Content-Length (Section 3.3.2 of [RFC7230]). The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request message.
411（Length Required）ステータスコードは、定義されたContent-Length（[RFC7230]のセクション3.3.2）がないと、サーバーがリクエストの受け入れを拒否することを示します。クライアントは、リクエストメッセージにメッセージ本文の長さを含む有効なContent-Lengthヘッダーフィールドを追加した場合、リクエストを繰り返すことができます。
The 413 (Payload Too Large) status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
413（Payload Too Large）ステータスコードは、リクエストのペイロードがサーバーの処理能力または処理能力を超えているため、サーバーがリクエストの処理を拒否していることを示します。サーバーは接続を閉じて、クライアントがリクエストを続行できないようにすることができます。
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.
条件が一時的なものである場合、サーバーはRetry-Afterヘッダーフィールドを生成して、それが一時的なものであること、およびクライアントが再試行する可能性のある時間を示す必要があります。
The 414 (URI Too Long) status code indicates that the server is refusing to service the request because the request-target (Section 5.3 of [RFC7230]) 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 a "black hole" 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が長すぎる）ステータスコードは、リクエストターゲット（[RFC7230]のセクション5.3）がサーバーが解釈するよりも長いため、サーバーがリクエストへのサービスを拒否していることを示します。このまれな状態が発生する可能性が高いのは、クライアントがPOSTリクエストを長いクエリ情報を含むGETリクエストに不適切に変換した場合、クライアントがリダイレクトの「ブラックホール」（たとえば、自身のサフィックス）、または潜在的なセキュリティホールを悪用しようとするクライアントによる攻撃を受けている場合。
A 414 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
414応答はデフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御で特に示されていない限り（[RFC7234]のセクション4.2.2を参照）。
The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the payload is in a format not supported by this method on the target resource. 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.
415（サポートされていないメディアタイプ）ステータスコードは、ペイロードがターゲットリソースのこのメソッドでサポートされていない形式であるため、配信元サーバーがリクエストへのサービスを拒否していることを示します。フォーマットの問題は、リクエストで示されたContent-TypeまたはContent-Encodingが原因であるか、データを直接検査した結果である可能性があります。
The 417 (Expectation Failed) status code indicates that the expectation given in the request's Expect header field (Section 5.1.1) could not be met by at least one of the inbound servers.
417（期待値失敗）ステータスコードは、要求のExpectヘッダーフィールド（セクション5.1.1）で指定された期待値が、少なくとも1つの受信サーバーで満たされなかったことを示します。
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 6.7 of [RFC7230]).
426（アップグレードが必要）ステータスコードは、サーバーが現在のプロトコルを使用して要求を実行することを拒否しているが、クライアントが別のプロトコルにアップグレードした後に実行する可能性があることを示します。サーバーは、426応答でUpgradeヘッダーフィールドを送信して、必要なプロトコルを示す必要があります（[RFC7230]のセクション6.7）。
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 response codes are applicable to any request method.
ステータスコードの5xx（サーバーエラー）クラスは、サーバーがエラーが発生したか、または要求されたメソッドを実行できないことをサーバーが認識していることを示します。 HEADリクエストに応答する場合を除いて、サーバーは、エラー状況の説明と、それが一時的な状態か永続的な状態かを含む表現を送信する必要があります（SHOULD）。ユーザーエージェントは、ユーザーに含まれる表現を表示する必要があります（SHOULD）。これらの応答コードは、すべての要求メソッドに適用できます。
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 cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
501応答はデフォルトでキャッシュ可能です。つまり、メソッド定義または明示的なキャッシュ制御で特に示されていない限り（[RFC7234]のセクション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 7.1.3) to suggest an appropriate amount of time for the client to wait before retrying the request.
503（Service Unavailable）ステータスコードは、一時的な過負荷または定期的なメンテナンスが原因で、サーバーが現在要求を処理できないことを示しています。サーバーはRetry-Afterヘッダーフィールド（セクション7.1.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.
注：503ステータスコードの存在は、サーバーが過負荷になったときにそれを使用する必要があることを意味しません。一部のサーバーは、接続を単に拒否する場合があります。
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.6 of [RFC7230], 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のメジャーバージョンをサポートしていないか、サポートを拒否していることを示します。サーバーは、[RFC7230]のセクション2.6で説明されているように、このエラーメッセージ以外では、クライアントと同じメジャーバージョンを使用してリクエストを完了できない、または望まないことを示しています。サーバーは、そのバージョンがサポートされていない理由とそのサーバーでサポートされている他のプロトコルを説明する505応答の表現を生成する必要があります（SHOULD）。
The response header fields allow the server to pass additional information about the response beyond what is placed in the status-line. These header fields give information about the server, about further access to the target resource, or about related resources.
サーバーは、応答ヘッダーフィールドを使用して、ステータス行に入力されたもの以外に、応答に関する追加情報を渡すことができます。これらのヘッダーフィールドは、サーバー、ターゲットリソースへの以降のアクセス、または関連リソースに関する情報を提供します。
Although each response header field has a defined meaning, in general, the precise semantics might be further refined by the semantics of the request method and/or response status code.
各レスポンスヘッダーフィールドには定義された意味がありますが、一般に、正確なセマンティクスは、リクエストメソッドやレスポンスステータスコードのセマンティクスによってさらに洗練される可能性があります。
Response header fields can supply control data that supplements the status code, directs caching, or instructs the client where to go next.
応答ヘッダーフィールドは、ステータスコードを補足する、キャッシングを指示する、またはクライアントに次に進む場所を指示する制御データを提供できます。
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| Age | Section 5.1 of [RFC7234] |
| Cache-Control | Section 5.2 of [RFC7234] |
| Expires | Section 5.3 of [RFC7234] |
| Date | Section 7.1.1.2 |
| Location | Section 7.1.2 |
| Retry-After | Section 7.1.3 |
| Vary | Section 7.1.4 |
| Warning | Section 5.5 of [RFC7234] |
+-------------------+--------------------------+
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
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 header field MUST accept all three HTTP-date formats. When a sender generates a header 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日付形式すべてを受け入れる必要があります。送信者が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. A sender that generates HTTP-date values from a local clock ought to use NTP ([RFC5905]) or some similar protocol to synchronize its clock to UTC.
HTTP日付値は、時刻を協定世界時（UTC）のインスタンスとして表します。最初の2つの形式は、UTC名の前身であるグリニッジ標準時（GMT）の3文字の略語でUTCを示します。 asctime形式の値はUTCであると見なされます。ローカルクロックからHTTP日付値を生成する送信者は、NTP（[RFC5905]）または同様のプロトコルを使用して、クロックをUTCに同期させる必要があります。
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 = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive
/ %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive
date1 = day SP month SP year ; e.g., 02 Jun 1982
date1 =日SP月SP年;例：1982年6月2日
day = 2DIGIT
month = %x4A.61.6E ; "Jan", case-sensitive
/ %x46.65.62 ; "Feb", case-sensitive
/ %x4D.61.72 ; "Mar", case-sensitive
/ %x41.70.72 ; "Apr", case-sensitive
/ %x4D.61.79 ; "May", case-sensitive
/ %x4A.75.6E ; "Jun", case-sensitive
/ %x4A.75.6C ; "Jul", case-sensitive
/ %x41.75.67 ; "Aug", case-sensitive
/ %x53.65.70 ; "Sep", case-sensitive
/ %x4F.63.74 ; "Oct", case-sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive
/ %x44.65.63 ; "Dec", case-sensitive
year = 4DIGIT
GMT = %x47.4D.54 ; "GMT", case-sensitive
time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (leap second)
hour = 2DIGIT minute = 2DIGIT second = 2DIGIT
時間= 2 DIGIT分= 2 DIGIT秒= DIGIT
Obsolete formats:
廃止されたフォーマット：
obs-date = rfc850-date / asctime-date
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 =日 "-"月 "-" 2DIGIT;例：82-Jun-82
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
asctime-date = day-name SP date3 SP time-of-day SP year date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) ; e.g., Jun 2
asctime-date =日名SP date3 SP time-of-day SP年date3 =月SP（2DIGIT /（SP 1DIGIT））;例：6月2日
HTTP-date is case sensitive. 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).
HTTP日付では大文字と小文字が区別されます。送信者は、文法にSPとして具体的に含まれているものを超えて、HTTP日付に追加の空白を生成してはなりません（MUST NOT）。 day-name、day、month、year、time-of-dayのセマンティクスは、対応する名前を持つインターネットメッセージフォーマット構成に定義されたものと同じです（[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年を超えると思われるタイムスタンプを、最後の2桁が同じである過去の最新の年を表すものとして解釈する必要があります。 。
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 the date/time stamp format apply only to their usage within the protocol stream. Implementations are not required to use these formats for user presentation, request logging, etc.
注：日付/タイムスタンプ形式のHTTP要件は、プロトコルストリーム内での使用にのみ適用されます。ユーザーの表示、要求のロギングなどにこれらの形式を使用するための実装は必要ありません。
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 7.1.1.1.
「日付」ヘッダーフィールドは、メッセージが発信された日時を表し、[RFC5322]のセクション3.6.1で定義されている発信日フィールド（orig-date）と同じセマンティクスを持っています。セクション7.1.1.1で定義されているように、フィールド値はHTTP日付です。
Date = HTTP-date
日付= HTTP日付
An example is
例は
Date: Tue, 15 Nov 1994 08:12:31 GMT
When a Date header field is generated, the sender 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 the payload is generated. In practice, the date can be generated at any time during message origination.
Dateヘッダーフィールドが生成されると、送信者はフィールド値をメッセージ生成の日付と時刻の最適な近似値として生成する必要があります（SHOULD）。理論的には、日付はペイロードが生成される直前を表す必要があります。実際には、日付はメッセージの発信中にいつでも生成できます。
An origin server MUST NOT send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instance in Coordinated Universal Time. An origin server MAY send a Date header field if the response is in the 1xx (Informational) or 5xx (Server Error) class of status codes. An origin server MUST send a Date header field in all other cases.
起点サーバーは、協定世界時での現在のインスタンスの適切な概算を提供できるクロックがない場合、日付ヘッダーフィールドを送信してはなりません（MUST NOT）。応答がステータスコードの1xx（情報）または5xx（サーバーエラー）クラスにある場合、オリジンサーバーは日付ヘッダーフィールドを送信できます（MAY）。オリジンサーバーは、他のすべての場合にDateヘッダーフィールドを送信する必要があります。
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.
Dateヘッダーフィールドのない応答メッセージを受信するクロックを持つ受信者は、受信された時間を記録し、対応するDateヘッダーフィールドがキャッシュされているか、ダウンストリームに転送されている場合は、メッセージのヘッダーセクションに追加する必要があります。
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 "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」ヘッダーフィールドは、応答に関連して特定のリソースを参照するために一部の応答で使用されます。関係のタイプは、リクエストメソッドとステータスコードのセマンティクスの組み合わせによって定義されます。
Location = URI-reference
場所= URI参照
The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5).
フィールド値は、単一のURI参照で構成されます。相対参照（[RFC3986]、セクション4.2）の形式の場合、最終的な値は、有効なリクエストURI（[RFC3986]、セクション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（Created）レスポンスの場合、Location値はリクエストによって作成されたプライマリリソースを指します。 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 request target (i.e., the redirection inherits the original reference's fragment, if any).
3xx（リダイレクト）応答で提供されるLocation値にフラグメントコンポーネントがない場合、ユーザーエージェントは、値がリクエストターゲットの生成に使用される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リクエストは、ヘッダーフィールドを含む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:
これは、ユーザーエージェントが「http://www.example.org/People.html#tim」にリダイレクトすることを示唆しています。同様に、URI参照「http://www.example.org/index.html#」に対して生成されたGETリクエスト「ラリー」は、ヘッダーフィールドを含む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.
Location値のフラグメント識別子が適切でない状況があります。たとえば、201（Created）応答のLocationヘッダーフィールドは、作成されたリソースに固有のURIを提供することになっています。
Note: Some recipients attempt to recover from Location 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.
注：一部の受信者は、有効なURI参照ではない場所フィールドからの回復を試みます。この仕様は、そのような処理を義務付けたり定義したりするものではありませんが、堅牢性のためにそれを許可しています。
Note: The Content-Location header field (Section 3.1.4.2) 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.
注：Content-Locationヘッダーフィールド（セクション3.1.4.2）は、Content-Locationが囲まれた表現に対応する最も具体的なリソースを参照するという点でLocationとは異なります。したがって、応答にLocationヘッダーフィールドとContent-Locationヘッダーフィールドの両方を含めることができます。
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（Service Unavailable）応答で送信された場合、Retry-Afterは、クライアントがサービスを利用できないと予想される期間を示します。 3xx（リダイレクト）応答とともに送信された場合、Retry-Afterは、リダイレクトされた要求を発行する前にユーザーエージェントが待機するように求められる最小時間を示します。
The value of this field can be either an HTTP-date or a number of seconds to delay after the response is received.
このフィールドの値は、HTTP日付または応答の受信後に遅延する秒数のいずれかです。
Retry-After = HTTP-date / delay-seconds
Retry-After = HTTP-date / delay-seconds
A delay-seconds value is a non-negative decimal integer, representing time in seconds.
delay-secondsの値は、負でない10進整数であり、秒単位で時間を表します。
delay-seconds = 1*DIGIT
遅延秒数= 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 "Vary" header field in a response describes what parts of a request message, aside from the method, Host header field, and request target, might influence the origin server's process for selecting and representing this response. The value consists of either a single asterisk ("*") or a list of header field names (case-insensitive).
応答の "Vary"ヘッダーフィールドは、メソッド、ホストヘッダーフィールド、および要求ターゲットを除いて、要求メッセージのどの部分が、この応答を選択して表すための起点サーバーのプロセスに影響を与える可能性があるかを示します。値は、単一のアスタリスク（ "*"）またはヘッダーフィールド名のリスト（大文字と小文字を区別しない）で構成されます。
Vary = "*" / 1#field-name
A Vary field value of "*" signals that anything about the request might play a role in selecting the response representation, possibly including elements 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 a Vary field with a "*" value.
「*」のVaryフィールド値は、リクエストに関するあらゆるものが、メッセージ構文の外部の要素（クライアントのネットワークアドレスなど）を含む可能性がある応答表現の選択に役割を果たす可能性があることを示します。受信者は、要求をオリジンサーバーに転送しないと、この応答が後の要求に適しているかどうかを判断できません。プロキシは、「*」値を持つVaryフィールドを生成してはなりません（MUST NOT）。
A Vary field value consisting of a comma-separated list of names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation. The potential selecting header fields are not limited to those defined by this specification.
名前のコンマ区切りリストで構成されるVaryフィールド値は、選択ヘッダーフィールドと呼ばれる名前付きリクエストヘッダーフィールドが、表現の選択に役割を果たす可能性があることを示します。潜在的な選択ヘッダーフィールドは、この仕様で定義されているフィールドに限定されません。
For example, a response that contains
たとえば、次を含む応答
Vary: accept-encoding, accept-language
変化：accept-encoding、accept-language
indicates that the origin server might have used the request's Accept-Encoding and Accept-Language fields (or lack thereof) as determining factors while choosing the content for this response.
オリジンサーバーがリクエストのAccept-EncodingフィールドとAccept-Languageフィールド（またはその欠如）を、この応答のコンテンツを選択する際の決定要因として使用した可能性があることを示します。
An origin server might send Vary with a list of fields for two purposes:
オリジンサーバーは、2つの目的でフィールドのリストを含むVaryを送信する場合があります。
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 fields as the original request (Section 4.1 of [RFC7234]). In other words, Vary expands the cache key required to match a new request to the stored cache entry.
1. キャッシュの受信者に、後のリクエストにリストされたフィールドの値が元のリクエストと同じでない限り（[RFC7234]のセクション4.1）、後のリクエストを満たすためにこの応答を使用してはならないことを通知するには、つまり、Varyは、新しい要求を格納されたキャッシュエントリに一致させるために必要なキャッシュキーを拡張します。
2. To inform user agent recipients that this response is subject to content negotiation (Section 5.3) and that a different representation might be sent in a subsequent request if additional parameters are provided in the listed header fields (proactive negotiation).
2. ユーザーエージェントの受信者に、この応答がコンテンツネゴシエーション（セクション5.3）の対象であること、およびリストされたヘッダーフィールドに追加のパラメーターが提供されている場合（プロアクティブネゴシエーション）、別の表現が後続の要求で送信される可能性があることを通知します。
An origin server SHOULD send a Vary header field when its algorithm for selecting a representation varies based on aspects of the request message other than the method and request target, unless the variance cannot be crossed or the origin server has been deliberately configured to prevent cache transparency. For example, there is no need to send the Authorization field name in Vary because reuse across users is constrained by the field definition (Section 4.2 of [RFC7235]). Likewise, an origin server might use Cache-Control directives (Section 5.2 of [RFC7234]) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching.
オリジンサーバーは、表現を選択するためのアルゴリズムがメソッドとリクエストターゲット以外のリクエストメッセージの側面に基づいて変化する場合、Varyヘッダーフィールドを送信する必要があります（バリアンスを越えることができないか、オリジンサーバーが意図的にキャッシュの透過性を防ぐように構成されていない場合） 。たとえば、ユーザー間での再利用はフィールド定義によって制限されるため（[RFC7235]のセクション4.2）、Varyで承認フィールド名を送信する必要はありません。同様に、配信サーバーがVaryのキャッシュへの影響のパフォーマンスコストよりも重要度が低いと見なす場合、オリジンサーバーは、Cache-Controlディレクティブ（[RFC7234]のセクション5.2）を使用して、Varyに取って代わることがあります。
Validator header fields convey metadata about the selected representation (Section 3). 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 status code semantics, the selected representation for a given response is not necessarily the same as the representation enclosed as response payload.
Validatorヘッダーフィールドは、選択された表現に関するメタデータを伝達します（セクション3）。安全な要求への応答では、バリデーターフィールドは、応答の処理中にオリジンサーバーによって選択された選択表現を記述します。ステータスコードのセマンティクスによっては、特定の応答に対して選択された表現が、応答ペイロードとして囲まれた表現と必ずしも同じではないことに注意してください。
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 header field in a 201 (Created) response communicates the entity-tag of the newly created resource's representation, so that it can be used in later conditional requests to prevent the "lost update" problem [RFC7232].
たとえば、201（Created）応答のETagヘッダーフィールドは、新しく作成されたリソースの表現のエンティティタグを伝達するため、「失われた更新」問題[RFC7232]を防ぐために、後の条件付き要求で使用できます。
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| ETag | Section 2.3 of [RFC7232] |
| Last-Modified | Section 2.2 of [RFC7232] |
+-------------------+--------------------------+
Authentication challenges indicate what mechanisms are available for the client to provide authentication credentials in future requests.
認証チャレンジは、クライアントが将来のリクエストで認証資格情報を提供するために使用できるメカニズムを示します。
+--------------------+--------------------------+
| Header Field Name | Defined in... |
+--------------------+--------------------------+
| WWW-Authenticate | Section 4.1 of [RFC7235] |
| Proxy-Authenticate | Section 4.3 of [RFC7235] |
+--------------------+--------------------------+
The remaining response header fields provide more information about the target resource for potential use in later requests.
残りの応答ヘッダーフィールドは、後のリクエストで潜在的に使用するためのターゲットリソースに関する詳細情報を提供します。
+-------------------+--------------------------+
| Header Field Name | Defined in... |
+-------------------+--------------------------+
| Accept-Ranges | Section 2.3 of [RFC7233] |
| Allow | Section 7.4.1 |
| Server | Section 7.4.2 |
+-------------------+--------------------------+
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」ヘッダーフィールドには、ターゲットリソースでサポートされているものとしてアドバタイズされる一連のメソッドが一覧表示されます。このフィールドの目的は、リソースに関連付けられている有効なリクエストメソッドを受信者に厳密に通知することです。
Allow = #method
Example of use:
使用例：
Allow: GET, HEAD, PUT
許可：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 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.
許可されたメソッドの実際のセットは、各リクエスト時に元のサーバーによって定義されます。オリジンサーバーは405（Method Not Allowed）応答でAllowフィールドを生成しなければならず（MUST）、他の応答ではそれを行うことができます（MAY）。空のAllowフィールド値は、リソースがメソッドを許可しないことを示します。これは、リソースが構成によって一時的に無効にされている場合、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.
プロキシは、Allowヘッダーフィールドを変更してはいけません-一般的なメッセージ処理ルールに従ってそれらを処理するために、示されたメソッドのすべてを理解する必要はありません。
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 field in its responses.
"Server"ヘッダーフィールドには、要求を処理するためにオリジンサーバーが使用するソフトウェアに関する情報が含まれています。これは、報告された相互運用性の問題の範囲を特定し、特定のサーバーの制限を回避するために要求を回避または調整するためにクライアントがよく使用します。サーバーまたはオペレーティングシステムの使用に関する分析用。オリジンサーバーはそのレスポンスでサーバーフィールドを生成するかもしれません。
Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers, each followed by zero or more comments (Section 3.2 of [RFC7230]), 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 5.5.3.
サーバーのフィールド値は、1つ以上の製品IDとそれに続く0個以上のコメント（[RFC7230]のセクション3.2）で構成されます。これらのコメントは、元のサーバーソフトウェアとその重要なサブ製品を一緒に識別します。慣例により、製品IDは、オリジンサーバーソフトウェアを識別するための重要度の降順でリストされています。各製品識別子は、セクション5.5.3で定義されているように、名前とオプションのバージョンで構成されます。
Example:
例：
Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server 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.
オリジンサーバーは、不必要に細かい詳細を含むサーバーフィールドを生成してはならず（SHOULD NOT）、サードパーティによるサブプロダクトの追加を制限する必要があります（SHOULD）。過度に長く詳細なサーバーフィールドの値は、応答の待ち時間を増やし、潜在的なセキュリティホールを攻撃者が見つけて悪用することを（わずかに）容易にする可能性のある内部実装の詳細を明らかにする可能性があります。
The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the namespace for the request method token (Section 4). The method registry has been created and is now maintained at <http://www.iana.org/assignments/http-methods>.
「ハイパーテキスト転送プロトコル（HTTP）メソッドレジストリ」は、リクエストメソッドトークンの名前空間を定義します（セクション4）。メソッドレジストリが作成され、<http://www.iana.org/assignments/http-methods>で維持されるようになりました。
HTTP method registrations MUST include the following fields:
HTTPメソッドの登録には、次のフィールドを含める必要があります。
o Method Name (see Section 4)
o メソッド名（セクション4を参照）
o Safe ("yes" or "no", see Section 4.2.1)
o 安全（「はい」または「いいえ」、セクション4.2.1を参照）
o Idempotent ("yes" or "no", see Section 4.2.2)
o べき等（ "yes"または "no"、セクション4.2.2を参照）
o Pointer to specification text
o 仕様テキストへのポインタ
Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).
この名前空間に追加される値には、IETFレビューが必要です（[RFC5226]、セクション4.1を参照）。
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 3.3 of [RFC7230]) 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 a message body on either the request or the response message. Definitions of new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a value of "0".
メッセージの解析（[RFC7230]のセクション3.3）は（HEADへの応答を除いて）メソッドのセマンティクスから独立している必要があるため、新しいメソッドの定義では、解析アルゴリズムを変更したり、要求または応答のいずれかにメッセージ本文を含めることを禁止したりできません。メッセージ。新しいメソッドの定義では、値が「0」のContent-Lengthヘッダーフィールドを要求することにより、長さゼロのメッセージ本文のみが許可されることを指定できます。
A new method definition needs to indicate whether it is safe (Section 4.2.1), idempotent (Section 4.2.2), cacheable (Section 4.2.3), what semantics are to be associated with the payload body if any is present in the request 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 5.2) 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 ([RFC7233]), it ought to document this, too.
新しいメソッド定義は、それが安全（セクション4.2.1）、べき等（セクション4.2.2）、キャッシュ可能（セクション4.2.3）であるかどうか、ペイロード本体に関連付けられているセマンティクスが存在する場合にそれを示す必要があります。リクエストと、メソッドがヘッダーフィールドまたはステータスコードのセマンティクスに対して行う調整。新しいメソッドがキャッシュ可能である場合、その定義は、キャッシュが応答を格納し、それを使用して後続の要求を満たすことができる方法と条件を記述する必要があります。新しいメソッドは、条件付きにすることができるかどうか（5.2節）、および条件付きにすることができる場合は、条件がfalseの場合のサーバーの応答を記述する必要があります。同様に、新しいメソッドがパーシャルレスポンスセマンティクス（[RFC7233]）を使用する可能性がある場合は、これも文書化する必要があります。
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].
注：「M-」で始まるメソッド名の定義は避けてください。その接頭辞は、[RFC2774]によってセマンティクスが割り当てられていると誤って解釈される可能性があるためです。
The "Hypertext Transfer Protocol (HTTP) Method Registry" has been populated with the registrations below:
「ハイパーテキスト転送プロトコル（HTTP）メソッドレジストリ」には、以下の登録が含まれています。
+---------+------+------------+---------------+
| Method | Safe | Idempotent | Reference |
+---------+------+------------+---------------+
| CONNECT | no | no | Section 4.3.6 |
| DELETE | no | yes | Section 4.3.5 |
| GET | yes | yes | Section 4.3.1 |
| HEAD | yes | yes | Section 4.3.2 |
| OPTIONS | yes | yes | Section 4.3.7 |
| POST | no | no | Section 4.3.3 |
| PUT | no | yes | Section 4.3.4 |
| TRACE | yes | yes | Section 4.3.8 |
+---------+------+------------+---------------+
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines the namespace for the response status-code token (Section 6). The status code registry is maintained at <http://www.iana.org/assignments/http-status-codes>.
「ハイパーテキスト転送プロトコル（HTTP）ステータスコードレジストリ」は、応答ステータスコードトークンの名前空間を定義します（セクション6）。ステータスコードレジストリは、<http://www.iana.org/assignments/http-status-codes>で管理されています。
This section replaces the registration procedure for HTTP Status Codes previously defined in Section 7.1 of [RFC2817].
このセクションは、[RFC2817]のセクション7.1で以前に定義されたHTTPステータスコードの登録手順を置き換えます。
A registration MUST include the following fields:
登録には次のフィールドを含める必要があります。
o Status Code (3 digits)
o ステータスコード（3桁）
o Short Description
o 簡単な説明
o Pointer to specification text
o 仕様テキストへのポインタ
Values to be added to the HTTP status code namespace require IETF Review (see [RFC5226], Section 4.1).
HTTPステータスコード名前空間に追加される値には、IETFレビューが必要です（[RFC5226]、セクション4.1を参照）。
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 6. To allow existing parsers to process the response message, new status codes cannot disallow a payload, although they can mandate a zero-length payload body.
新しいステータスコードは、セクション6で定義されたカテゴリのいずれかに該当する必要があります。既存のパーサーが応答メッセージを処理できるようにするために、新しいステータスコードは、長さゼロのペイロード本体を必須とすることはできますが、ペイロードを禁止することはできません。
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」、「3N9」などの表記を使用して、番号を早く消費することなく、提案されたステータスコードのクラスを示すことができます。
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 header field semantics are further refined when used with the new status code).
新しいステータスコードの定義は、そのステータスコード（リクエストヘッダーフィールドやメソッドの組み合わせなど）を含むレスポンスを引き起こすリクエスト条件と、レスポンスヘッダーフィールドへの依存関係（たとえば、フィールドは必須であり、どのフィールドがセマンティクスを変更できるか、およびどのヘッダーフィールドのセマンティクスが新しいステータスコードで使用されるとさらに洗練されますか）。
The definition of a new status code ought to specify whether or not it is cacheable. Note that all status codes can be cached if the response they occur in has explicit freshness information; however, status codes that are defined as being cacheable are allowed to be cached without explicit freshness information. Likewise, the definition of a status code can place constraints upon cache behavior. See [RFC7234] for more information.
新しいステータスコードの定義では、キャッシュ可能かどうかを指定する必要があります。それらが発生する応答に明示的な鮮度情報がある場合、すべてのステータスコードをキャッシュできることに注意してください。ただし、キャッシュ可能として定義されているステータスコードは、明示的な鮮度情報なしでキャッシュできます。同様に、ステータスコードの定義は、キャッシュの動作に制約を課す可能性があります。詳細については、[RFC7234]を参照してください。
Finally, the definition of a new status code ought to indicate whether the payload has any implied association with an identified resource (Section 3.1.4.1).
最後に、新しいステータスコードの定義は、ペイロードが識別されたリソースと暗黙的に関連付けられているかどうかを示す必要があります（セクション3.1.4.1）。
The status code registry has been updated with the registrations below:
ステータスコードレジストリは、以下の登録で更新されています。
+-------+-------------------------------+----------------+
| Value | Description | Reference |
+-------+-------------------------------+----------------+
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 305 | Use Proxy | Section 6.4.5 |
| 306 | (Unused) | Section 6.4.6 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
+-------+-------------------------------+----------------+
HTTP header fields are registered within the "Message Headers" registry located at <http://www.iana.org/assignments/message-headers>, as defined by [BCP90].
[BCP90]で定義されているように、HTTPヘッダーフィールドは、<http://www.iana.org/assignments/message-headers>にある「メッセージヘッダー」レジストリ内に登録されます。
Header fields are key:value pairs that can be used to communicate data about the message, its payload, the target resource, or the connection (i.e., control data). See Section 3.2 of [RFC7230] for a general definition of header field syntax in HTTP messages.
ヘッダーフィールドは、メッセージ、そのペイロード、ターゲットリソース、または接続に関するデータ（制御データなど）の通信に使用できるキーと値のペアです。 HTTPメッセージのヘッダーフィールド構文の一般的な定義については、[RFC7230]のセクション3.2をご覧ください。
The requirements for header field names are defined in [BCP90].
ヘッダーフィールド名の要件は、[BCP90]で定義されています。
Authors of specifications defining new fields are advised to keep the name as short as practical and not to prefix the name with "X-" unless the header field will never be used on the Internet. (The "X-" prefix idiom has been extensively misused in practice; it was intended to only be used as a mechanism for avoiding name collisions inside proprietary software or intranet processing, since the prefix would ensure that private names never collide with a newly registered Internet name; see [BCP178] for further information).
新しいフィールドを定義する仕様の作成者は、名前をできるだけ短くし、ヘッダーフィールドがインターネットで使用されない限り、名前の前に「X-」を付けないことをお勧めします。 （「X-」接頭辞のイディオムは、実際には広範囲にわたって誤用されています。これは、専用のソフトウェアまたはイントラネット処理内での名前の衝突を回避するメカニズムとしてのみ使用することを意図していました。インターネット名。詳細については、[BCP178]を参照してください）。
New header field values typically have their syntax defined using ABNF ([RFC5234]), using the extension defined in Section 7 of [RFC7230] as necessary, and are usually constrained to the range of US-ASCII characters. Header fields needing a greater range of characters can use an encoding such as the one defined in [RFC5987].
新しいヘッダーフィールドの値は通常、必要に応じて[RFC7230]のセクション7で定義された拡張子を使用して、ABNF（[RFC5234]）を使用して定義された構文を持ち、通常はUS-ASCII文字の範囲に制限されます。より広い範囲の文字を必要とするヘッダーフィールドは、[RFC5987]で定義されているようなエンコーディングを使用できます。
Leading and trailing whitespace in raw field values is removed upon field parsing (Section 3.2.4 of [RFC7230]). Field definitions where leading or trailing whitespace in values is significant will have to use a container syntax such as quoted-string (Section 3.2.6 of [RFC7230]).
生のフィールド値の先頭と末尾の空白は、フィールドの解析時に削除されます（[RFC7230]のセクション3.2.4）。値の先頭または末尾の空白が重要なフィールド定義では、引用文字列などのコンテナ構文を使用する必要があります（[RFC7230]のセクション3.2.6）。
Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed in the field-value. Typically, components that might contain a comma are protected with double-quotes using the quoted-string ABNF production.
コンマ（ "、"）はフィールド値間の一般的な区切り文字として使用されるため、フィールド値で許可されている場合は、慎重に扱う必要があります。通常、コンマを含む可能性のあるコンポーネントは、引用文字列ABNFプロダクションを使用して二重引用符で保護されます。
For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like these:
たとえば、テキストの日付とURI（どちらもコンマが含まれている可能性があります）は、次のようなフィールド値で安全に運ぶことができます。
Example-URI-Field: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside double-quotes will likely cause unnecessary confusion.
二重引用符の区切り文字は、ほとんど常に引用文字列の生成で使用されることに注意してください。二重引用符内で別の構文を使用すると、不要な混乱を引き起こす可能性があります。
Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in Section 3.1.1.5). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for it (for an example, see the notes on parameter handling for media types in Section 3.1.1.1).
多くのヘッダーフィールドは、（大文字と小文字を区別せずに）名前付きパラメーター（たとえば、セクション3.1.1.5で定義されているContent-Type）を含む形式を使用します。パラメータ値に引用符なし（トークン）と引用符付き（引用符付き文字列）の両方の構文を許可すると、受信者は既存のパーサーコンポーネントを使用できます。両方の形式を許可する場合、パラメーター値の意味は、使用される構文とは無関係である必要があります（例については、セクション3.1.1.1のメディアタイプのパラメーター処理に関する注記を参照してください）。
Authors of specifications defining new header fields are advised to consider documenting:
新しいヘッダーフィールドを定義する仕様の作成者は、文書化を検討することをお勧めします。
o Whether the field is a single value or whether it can be a list (delimited by commas; see Section 3.2 of [RFC7230]).
o フィールドが単一の値であるか、リストの可能性があるか（カンマで区切られます。[RFC7230]のセクション3.2を参照）。
If it does not use the list syntax, document how to treat messages where the field occurs multiple times (a sensible default would be to ignore the field, but this might not always be the right choice).
リスト構文を使用しない場合は、フィールドが複数回発生するメッセージの処理方法を文書化します（適切なデフォルトはフィールドを無視することですが、これが常に正しい選択であるとは限りません）。
Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the field's definition not allowing the list syntax. A robust format enables recipients to discover these situations (good example: "Content-Type", as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a URI).
フィールドの定義でリスト構文が許可されていなくても、仲介者とソフトウェアライブラリは複数のヘッダーフィールドインスタンスを1つのインスタンスに結合する場合があることに注意してください。堅牢な形式により、受信者はこれらの状況を発見できます（コンマは引用符で囲まれた文字列内にのみ出現できるため、「Content-Type」、URI内ではコンマが発生する可能性があるため、「Location」など）。
o Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses to a particular request method, etc.
o ヘッダーフィールドを使用できる条件。たとえば、応答または要求のみ、すべてのメッセージ、特定の要求メソッドへの応答のみなど。
o Whether the field should be stored by origin servers that understand it upon a PUT request.
o PUTリクエストでフィールドを理解するオリジンサーバーがフィールドを保存するかどうか。
o Whether the field semantics are further refined by the context, such as by existing request methods or status codes.
o フィールドのセマンティクスが、既存のリクエストメソッドやステータスコードなどのコンテキストによってさらに絞り込まれるかどうか。
o Whether it is appropriate to list the field-name in the Connection header field (i.e., if the header field is to be hop-by-hop; see Section 6.1 of [RFC7230]).
o Connectionヘッダーフィールドにフィールド名をリストすることが適切かどうか（つまり、ヘッダーフィールドがホップバイホップである場合。[RFC7230]のセクション6.1を参照）。
o Under what conditions intermediaries are allowed to insert, delete, or modify the field's value.
o 仲介者がフィールドの値を挿入、削除、または変更できるのは、どのような状況下ですか。
o Whether 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 7.1.4).
o Varyレスポンスヘッダーフィールドにフィールド名をリストすることが適切かどうか（たとえば、リクエストヘッダーフィールドがオリジンサーバーのコンテンツ選択アルゴリズムによって使用される場合。セクション7.1.4を参照）。
o Whether the header field is useful or allowable in trailers (see Section 4.1 of [RFC7230]).
o ヘッダーフィールドが有用であるか、トレーラーで許可されているか（[RFC7230]のセクション4.1を参照）。
o Whether the header field ought to be preserved across redirects.
o ヘッダーフィールドをリダイレクト間で保持する必要があるかどうか。
o Whether it introduces any additional security considerations, such as disclosure of privacy-related data.
o プライバシー関連データの開示など、セキュリティに関する追加の考慮事項が導入されているかどうか。
The "Message Headers" registry has been updated with the following permanent registrations:
「メッセージヘッダー」レジストリは、次の永続的な登録で更新されています。
+-------------------+----------+----------+-----------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------------+
| Accept | http | standard | Section 5.3.2 |
| Accept-Charset | http | standard | Section 5.3.3 |
| Accept-Encoding | http | standard | Section 5.3.4 |
| Accept-Language | http | standard | Section 5.3.5 |
| Allow | http | standard | Section 7.4.1 |
| Content-Encoding | http | standard | Section 3.1.2.2 |
| Content-Language | http | standard | Section 3.1.3.2 |
| Content-Location | http | standard | Section 3.1.4.2 |
| Content-Type | http | standard | Section 3.1.1.5 |
| Date | http | standard | Section 7.1.1.2 |
| Expect | http | standard | Section 5.1.1 |
| From | http | standard | Section 5.5.1 |
| Location | http | standard | Section 7.1.2 |
| Max-Forwards | http | standard | Section 5.1.2 |
| MIME-Version | http | standard | Appendix A.1 |
| Referer | http | standard | Section 5.5.2 |
| Retry-After | http | standard | Section 7.1.3 |
| Server | http | standard | Section 7.4.2 |
| User-Agent | http | standard | Section 5.5.3 |
| Vary | http | standard | Section 7.1.4 |
+-------------------+----------+----------+-----------------+
The change controller for the above registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
上記の登録の変更コントローラは、「IETF（iesg@ietf.org）-Internet Engineering Task Force」です。
The "HTTP Content Coding Registry" defines the namespace for content coding names (Section 4.2 of [RFC7230]). The content coding registry is maintained at <http://www.iana.org/assignments/http-parameters>.
「HTTPコンテンツコーディングレジストリ」は、コンテンツコーディング名の名前空間を定義します（[RFC7230]のセクション4.2）。コンテンツコーディングレジストリは、<http://www.iana.org/assignments/http-parameters>で管理されています。
Content coding registrations MUST include the following fields:
コンテンツコーディング登録には、次のフィールドを含める必要があります。
o Name
o 名前
o Description
o 説明
o Pointer to specification text
o 仕様テキストへのポインタ
Names of content codings MUST NOT overlap with names of transfer codings (Section 4 of [RFC7230]), unless the encoding transformation is identical (as is the case for the compression codings defined in Section 4.2 of [RFC7230]).
コンテンツコーディングの名前は、（[RFC7230]のセクション4.2で定義されている圧縮コーディングの場合のように）エンコード変換が同一でない限り、転送コーディング（[RFC7230]のセクション4）の名前と重複してはなりません。
Values to be added to this namespace require IETF Review (see Section 4.1 of [RFC5226]) and MUST conform to the purpose of content coding defined in this section.
この名前空間に追加される値は、IETFレビュー（[RFC5226]のセクション4.1を参照）を必要とし、このセクションで定義されたコンテンツコーディングの目的に準拠する必要があります。
The "HTTP Content Coding Registry" has been updated with the registrations below:
「HTTPコンテンツコーディングレジストリ」は、以下の登録で更新されています。
+----------+----------------------------------------+---------------+
| Name | Description | Reference |
+----------+----------------------------------------+---------------+
| identity | Reserved (synonym for "no encoding" in | Section 5.3.4 |
| | Accept-Encoding) | |
+----------+----------------------------------------+---------------+
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 message syntax, parsing, and routing are discussed in Section 9 of [RFC7230].
このセクションは、開発者、情報プロバイダー、およびユーザーに、HTTPセマンティクスに関連する既知のセキュリティ問題と、インターネット経由で情報を転送するためのその使用法を通知することを目的としています。メッセージの構文、解析、ルーティングに関する考慮事項は、[RFC7230]のセクション9で説明されています。
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 payloads received via HTTP, or secure use of the Internet in general, rather than security of the protocol. Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]).
以下の考慮事項のリストは完全ではありません。 HTTPセマンティクスに関連するほとんどのセキュリティ問題は、サーバー側アプリケーション（HTTPインターフェースの背後にあるコード）の保護、HTTP経由で受信したペイロードのユーザーエージェント処理の保護、またはプロトコルのセキュリティではなく、インターネットの一般的な使用の保護に関するものです。さまざまな組織が、トピック情報と、Webアプリケーションのセキュリティに関する現在の研究（[OWASP]など）へのリンクを維持しています。
Origin servers frequently make use of their local file system to manage the mapping from effective request 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 request target to files, folders, or directories.
オリジンサーバーはローカルファイルシステムを頻繁に利用して、有効なリクエストURIからリソース表現へのマッピングを管理します。ほとんどのファイルシステムは、悪意のあるファイルまたはパス名から保護するように設計されていません。したがって、オリジンサーバーは、リクエストターゲットをファイル、フォルダー、またはディレクトリにマッピングするときに、システムにとって特別な意味を持つ名前にアクセスしないようにする必要があります。
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、およびその他のオペレーティングシステムは、現在の1つ上のディレクトリレベルを示すパスコンポーネントとして「..」を使用し、特別に名前を付けたパスまたはファイル名を使用してシステムデバイスにデータを送信します。同様の命名規則が他のタイプのストレージシステム内に存在する場合があります。同様に、ローカルストレージシステムは、無効または予期しない文字の処理、分解された文字の再構成、大文字と小文字を区別しない名前の大文字と小文字の正規化を行う場合、セキュリティよりもユーザーフレンドリーを優先するという厄介な傾向があります。
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, request-target, header fields, or body) to contain data that might be misinterpreted as a command, code, or query when passed through a command invocation, language interpreter, or database interface.
オリジンサーバーは多くの場合、システムサービスの識別、データベースエントリの選択、またはデータソースの選択の手段として、URI内のパラメーターを使用します。ただし、リクエストで受信したデータは信頼できません。攻撃者は、任意の要求データ要素（メソッド、要求ターゲット、ヘッダーフィールド、または本文）を作成して、コマンド呼び出し、言語インタープリター、またはデータベースを介して渡されたときに、コマンド、コード、またはクエリとして誤って解釈される可能性があるデータを含める可能性があります。インターフェース。
For example, SQL injection is a common attack wherein additional query language is inserted within some part of the request-target 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インジェクションは一般的な攻撃であり、追加のクエリ言語がリクエストターゲットまたはヘッダーフィールドの一部に挿入されます（例：ホスト、リファラーなど）。受信したデータが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.
ログファイルや監視ツール内など、保存して後で処理するとき、または埋め込みスクリプトを許可するデータ形式に含めるときに、同様の考慮事項が要求データに適用されます。
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.
クライアントは、リソースとやり取りするためにユーザーが提供する情報（ユーザーの名前、場所、メールアドレス、パスワード、暗号化キーなど）とユーザーの閲覧アクティビティに関する情報の両方を含む、大量の個人情報を知っていることがよくあります。時間（履歴、ブックマークなど）。実装では、個人情報の意図しない開示を防ぐ必要があります。
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. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose.
URIは、セキュリティで保護されたリソースを識別した場合でも、共有ではなく保護されることを目的としています。 URIは多くの場合、ディスプレイに表示され、ページの印刷時にテンプレートに追加され、保護されていないさまざまなブックマークリストに保存されます。したがって、機密性の高い、個人を特定できる、または開示するリスクがあるURI内に情報を含めることは賢明ではありません。
Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. Such services ought to use POST-based form submission instead.
サービスの作成者は、機密データの送信のためにGETベースのフォームを回避する必要があります。これは、そのデータが要求ターゲットに配置されるためです。多くの既存のサーバー、プロキシ、およびユーザーエージェントは、リクエストターゲットを第三者が見ることができる場所に記録または表示します。そのようなサービスでは、代わりにPOSTベースのフォーム送信を使用する必要があります。
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 5.5.2 to address some of its security considerations.
Refererヘッダーフィールドは、リクエストの原因となったコンテキストについてターゲットサイトに通知するため、ユーザーの即時の閲覧履歴に関する情報や、参照リソースのURIにある個人情報を明らかにする可能性があります。セキュリティに関する考慮事項の一部に対処するために、Refererヘッダーフィールドの制限については、セクション5.5.2で説明しています。
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 7.1.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参照内で使用されるフラグメント識別子はリクエストで送信されませんが、実装者は、それらがユーザーエージェントと、応答の結果として実行されている拡張機能またはスクリプトから見えることに注意する必要があります。特に、リダイレクトが発生し、元のリクエストのフラグメント識別子がLocation（セクション7.1.2）の新しい参照によって継承されると、あるサイトのフラグメントが別のサイトに開示される可能性があります。最初のサイトが個人情報をフラグメントで使用する場合、その継承をブロックするために、他のサイトへのリダイレクトに（おそらく空の）フラグメントコンポーネントが含まれていることを確認する必要があります。
The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [RFC7230]), and Server (Section 7.4.2) 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.
User-Agent（セクション5.5.3）、Via（[RFC7230]のセクション5.7.1）、およびServer（セクション7.4.2）ヘッダーフィールドは、それぞれの送信者のソフトウェアシステムに関する情報を明らかにします。理論的には、これにより攻撃者は既知のセキュリティホールを簡単に悪用することができます。実際には、攻撃者は使用されているソフトウェアのバージョンに関係なく、すべての潜在的なホールを試す傾向があります。
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ヘッダーフィールドを使用すると、仲介者が機密のマシン名を仮名に置き換えることができます。
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 its TCP behavior, 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 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.
ブラウザのフィンガープリントは、その固有の一連の特性を通じて特定のユーザーエージェントを経時的に識別するための一連の手法です。これらの特性には、TCPの動作、機能、スクリプト環境に関連する情報が含まれる場合がありますが、特に興味深いのは、HTTPを介して通信される可能性のある一連の固有の特性です。フィンガープリントは、ユーザーが他の形式のデータ収集（Cookieなど）に対して持つ可能性のある対応する制御なしに、ユーザーエージェントの動作を経時的に追跡できるため、プライバシーの問題と見なされます。多くの汎用ユーザーエージェント（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ヘッダーフィールドは最も明白ですが、Fromはユーザーが自己識別を希望する場合にのみ送信されることが予想されます。同様に、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 5.3), including the Accept, Accept-Charset, Accept-Encoding, and Accept-Language header fields.
User-Agentヘッダーフィールドには、特定のデバイスを一意に識別するのに十分な情報が含まれている可能性があります。通常、他の特性と組み合わせると、特にユーザーエージェントがユーザーのシステムや拡張機能に関する過度の詳細を送信する場合にそうです。ただし、ユーザーが最も予期しない一意の情報のソースは、Accept、Accept-Charset、Accept-Encoding、およびAccept-Languageヘッダーフィールドを含むプロアクティブネゴシエーション（セクション5.3）です。
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 whitelisted, perhaps via interaction after detecting a Vary header field that indicates language negotiation might be useful.
フィンガープリントの問題に加えて、Accept-Languageヘッダーフィールドを詳細に使用すると、ユーザーが私的な性質のものであると考える可能性のある情報を明らかにすることができます。たとえば、特定の言語セットを理解することは、特定の民族グループのメンバーシップと強く相関している場合があります。このようなプライバシーの喪失を制限するアプローチは、おそらく言語ネゴシエーションが有用であることを示すVaryヘッダーフィールドを検出した後の相互作用を介して、ホワイトリストに登録されたサイトを除いて、ユーザーエージェントがAccept-Languageの送信を省略することです。
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.
プロキシを使用してプライバシーを強化する環境では、ユーザーエージェントはプロアクティブなネゴシエーションヘッダーフィールドを送信する際に慎重でなければなりません。高度なヘッダーフィールドの構成機能を提供する汎用ユーザーエージェントは、詳細が多すぎる場合に発生する可能性があるプライバシーの喪失についてユーザーに通知する必要があります。極端なプライバシー対策として、プロキシはリレーされたリクエストのプロアクティブネゴシエーションヘッダーフィールドをフィルタリングできます。
See Section 10 of [RFC7230].
[RFC7230]のセクション10をご覧ください。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
[RFC4647]フィリップス、A。、エド。 M.デイビス編、「言語タグのマッチング」、BCP 47、RFC 4647、2006年9月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]フィリップス、A。、エド。 M.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011.
[RFC6365] Hoffman、P。およびJ. Klensin、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、2011年9月。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、2014年6月。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、2014年6月。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.
[RFC7233] Fielding、R。、編、Lafon、Y。、編、およびJ. Reschke、編、「Hypertext Transfer Protocol（HTTP / 1.1）：Range Requests」、RFC 7233、2014年6月。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、June 2014。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、2014年6月。
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[BCP13] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、2013年1月。
[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月。
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[BCP90] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web Applications and Web Services", The Open Web Application Security Project (OWASP) 2.0.1, July 2005, <https://www.owasp.org/>.
[OWASP] van der Stock、A。、編、「セキュリティで保護されたWebアプリケーションとWebサービスの構築ガイド」、Open Web Application Security Project（OWASP）2.0.1、2005年7月、<https：//www.owasp .org />。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Doctoral Dissertation, University of California, Irvine, September 2000, <http://roy.gbiv.com/pubs/dissertation/top.htm>.
[REST] Fielding、R。、「Architectural Styles and the Design of Network-based Software Architectures」、博士論文、カリフォルニア大学アーバイン校、2000年9月、<http://roy.gbiv.com/pubs/dissertation/top .htm>。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945] Berners-Lee、T.、Fielding、R。、およびH. Nielsen、「Hypertext Transfer Protocol-HTTP / 1.0」、RFC 1945、1996年5月。
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC2049] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Five：Conformance Criteria and Examples」、RFC 2049、1996年11月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068] Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、1997年1月。
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.
[RFC2295] Holtman、K。およびA. Mutz、「HTTPでの透過的なコンテンツネゴシエーション」、RFC 2295、1998年3月。
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, August 1998.
[RFC2388] Masinter、L。、「Returning Values from Forms：multipart / form-data」、RFC 2388、1998年8月。
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[RFC2557] Palme、F.、Hopmann、A.、Shelness、N。、およびE. Stefferud、「MIME Encapsulation of Aggregate Documents such as HTML（MHTML）」、RFC 2557、1999年3月。
[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, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP Extension Framework", RFC 2774, February 2000.
[RFC2774] Frystyk、H.、Leach、P。、およびS. Lawrence、「An HTTP Extension Framework」、RFC 2774、2000年2月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817] Khare、R。およびS. Lawrence、「HTTP / 1.1内のTLSへのアップグレード」、RFC 2817、2000年5月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978] Freed、N。およびJ. Postel、「IANA Charset Registration Procedures」、BCP 19、RFC 2978、2000年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, March 2010.
[RFC5789] Dusseault、L.およびJ. Snell、「PATCH Method for HTTP」、RFC 5789、2010年3月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, August 2010.
[RFC5987] Reschke、J。、「ハイパーテキスト転送プロトコル（HTTP）ヘッダーフィールドパラメーターの文字セットと言語エンコード」、RFC 5987、2010年8月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]ノッティンガム、M。、「Webリンク」、RFC 5988、2010年10月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]バース、A。、「HTTP状態管理メカニズム」、RFC 6265、2011年4月。
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)", RFC 6266, June 2011.
[RFC6266] Reschke、J。、「ハイパーテキスト転送プロトコル（HTTP）でのContent-Dispositionヘッダーフィールドの使用」、RFC 6266、2011年6月。
[RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)", RFC 7238, June 2014.
[RFC7238] Reschke、J。、「Hypertext Transfer Protocol（HTTP）Status Code 308（Permanent Redirect）」、RFC 7238、2014年6月。
HTTP/1.1 uses many of the constructs defined for the Internet Message Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] to allow a message body to be transmitted in an open variety of representations and with extensible header fields. However, RFC 2045 is focused only on email; applications of HTTP have many characteristics that differ from email; hence, HTTP has features that differ from MIME. These differences were carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
HTTP / 1.1は、インターネットメッセージフォーマット[RFC5322]および多目的インターネットメール拡張（MIME）[RFC2045]に定義されている多くの構成要素を使用して、メッセージ本文をさまざまな表現で、拡張可能なヘッダーフィールドで送信できるようにします。ただし、RFC 2045は電子メールにのみ焦点を当てています。 HTTPのアプリケーションには、電子メールとは異なる多くの特性があります。したがって、HTTPにはMIMEとは異なる機能があります。これらの違いは、バイナリ接続でのパフォーマンスを最適化し、新しいメディアタイプをより自由に使用できるようにし、日付の比較を容易にし、一部の初期のHTTPサーバーとクライアントの動作を認めるために慎重に選択されました。
This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to and from strict MIME environments need to be aware of these differences and provide the appropriate conversions where necessary.
この付録では、HTTPがMIMEと異なる特定の領域について説明します。厳密なMIME環境との間のプロキシおよびゲートウェイは、これらの違いを認識し、必要に応じて適切な変換を提供する必要があります。
HTTP is not a MIME-compliant protocol. However, messages can include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message. Use of the MIME-Version header field indicates that the message is in full conformance with the MIME protocol (as defined in [RFC2045]). Senders are responsible for ensuring full conformance (where possible) when exporting HTTP messages to strict MIME environments.
HTTPはMIME準拠のプロトコルではありません。ただし、メッセージには単一のMIME-Versionヘッダーフィールドを含めて、メッセージの作成に使用されたMIMEプロトコルのバージョンを示すことができます。 MIME-Versionヘッダーフィールドの使用は、メッセージがMIMEプロトコルに完全に準拠していることを示します（[RFC2045]で定義）。送信者は、HTTPメッセージを厳密なMIME環境にエクスポートするときに、（可能な場合）完全な準拠を保証する責任があります。
MIME requires that an Internet mail body part be converted to canonical form prior to being transferred, as described in Section 4 of [RFC2049]. Section 3.1.1.3 of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. [RFC2046] requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content.
[RFC2049]のセクション4で説明されているように、MIMEでは、転送する前にインターネットメールの本文部分を正規の形式に変換する必要があります。このドキュメントのセクション3.1.1.3は、HTTP経由で送信されるときに「テキスト」メディアタイプのサブタイプに許可されるフォームについて説明しています。 [RFC2046]は、タイプが「テキスト」のコンテンツが改行をCRLFとして表すことを要求し、改行シーケンスの外でのCRまたはLFの使用を禁止します。 HTTPでは、CRLF、ベアCR、およびベアLFでテキストコンテンツ内の改行を示すことができます。
A proxy or gateway from HTTP to a strict MIME environment ought to translate all line breaks within the text media types described in Section 3.1.1.3 of this document to the RFC 2049 canonical form of CRLF. Note, however, this might be complicated by the presence of a Content-Encoding and by the fact that HTTP allows the use of some charsets that do not use octets 13 and 10 to represent CR and LF, respectively.
HTTPから厳密なMIME環境へのプロキシまたはゲートウェイは、このドキュメントのセクション3.1.1.3で説明されているテキストメディアタイプ内のすべての改行をRFC 2049正規形式のCRLFに変換する必要があります。ただし、これは、Content-Encodingが存在すること、およびHTTPではオクテット13と10をそれぞれ使用しない一部の文字セットを使用してCRとLFを表すことができるため、複雑になる可能性があることに注意してください。
Conversion will break any cryptographic checksums applied to the original content unless the original content is already in canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP.
元のコンテンツが既に正規形式でない限り、変換によって元のコンテンツに適用されている暗号化チェックサムは無効になります。したがって、HTTPでこのようなチェックサムを使用するコンテンツには、正規形式が推奨されます。
HTTP/1.1 uses a restricted set of date formats (Section 7.1.1.1) to simplify the process of date comparison. Proxies and gateways from other protocols ought to ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
HTTP / 1.1は、日付比較のプロセスを簡素化するために、制限された日付形式のセット（7.1.1.1節）を使用します。他のプロトコルのプロキシとゲートウェイは、メッセージに存在する日付ヘッダーフィールドがHTTP / 1.1形式のいずれかに準拠していることを確認し、必要に応じて日付を書き換える必要があります。
MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols ought to either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards).
MIMEには、HTTP / 1.1のContent-Encodingヘッダーフィールドに相当する概念は含まれていません。これはメディアタイプの修飾子として機能するため、HTTPからMIME準拠のプロトコルへのプロキシとゲートウェイは、メッセージを転送する前にContent-Typeヘッダーフィールドの値を変更するか、表現をデコードする必要があります。 （インターネットメールのContent-Typeの一部の実験的アプリケーションでは、 "; conversions = <content-coding>"のメディアタイプパラメーターを使用して、Content-Encodingと同等の機能を実行しています。ただし、このパラメーターはMIME標準の一部ではありません。 ）。
HTTP does not use the Content-Transfer-Encoding field of MIME. Proxies and gateways from MIME-compliant protocols to HTTP need to remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
HTTPはMIMEのContent-Transfer-Encodingフィールドを使用しません。 MIME準拠プロトコルからHTTPへのプロキシとゲートウェイは、HTTPクライアントに応答メッセージを配信する前に、Content-Transfer-Encodingを削除する必要があります。
Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol being used. Such a proxy or gateway ought to transform and label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol.
HTTPからMIME準拠のプロトコルへのプロキシとゲートウェイは、メッセージが正しいフォーマットとそのプロトコルでの安全なトランスポートのエンコーディングであることを保証する責任があります。「安全なトランスポート」は、使用されるプロトコルの制限によって定義されます。このようなプロキシまたはゲートウェイは、適切なContent-Transfer-Encodingを使用してデータを変換およびラベル付けする必要があります。これにより、宛先プロトコルを介した安全な転送の可能性が向上します。
HTTP implementations that share code with MHTML [RFC2557] implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations and folding, canonicalization, etc., since HTTP transfers message-bodies as payload and, aside from the "multipart/byteranges" type (Appendix A of [RFC7233]), does not interpret the content or any MIME header lines that might be contained therein.
MHTML [RFC2557]実装とコードを共有するHTTP実装は、MIME行の長さの制限に注意する必要があります。 HTTPにはこの制限がないため、HTTPは長い行を折り返しません。 HTTPによって転送されるMHTMLメッセージは、行の長さの制限や折りたたみ、正規化など、MHTMLのすべての規則に従います。これは、HTTPがメッセージ本体をペイロードとして転送するため、「multipart / byteranges」タイプは別として（[RFC7233]の付録A） ）、コンテンツまたはそこに含まれている可能性のあるMIMEヘッダー行を解釈しません。
The primary changes in this revision have been editorial in nature: extracting the messaging syntax and partitioning HTTP semantics into separate documents for the core features, conditional requests, partial requests, caching, and authentication. The conformance language has been revised to clearly target requirements and the terminology has been improved to distinguish payload from representations and representations from resources.
このリビジョンの主な変更は本質的に編集であり、メッセージング構文を抽出し、HTTPセマンティクスをコア機能、条件付きリクエスト、部分リクエスト、キャッシング、および認証用の個別のドキュメントに分割しました。要件を明確に対象とするように準拠言語が改訂され、表現とペイロード、およびリソースと表現を区別するために用語が改善されました。
A new requirement has been added that semantics embedded in a URI be disabled when those semantics are inconsistent with the request method, since this is a common cause of interoperability failure. (Section 2)
これは相互運用性の障害の一般的な原因であるため、URIに埋め込まれたセマンティクスがリクエストメソッドと一致しない場合は無効にするという新しい要件が追加されました。 （第2節）
An algorithm has been added for determining if a payload is associated with a specific identifier. (Section 3.1.4.1)
ペイロードが特定の識別子に関連付けられているかどうかを判断するアルゴリズムが追加されました。 （セクション3.1.4.1）
The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition says. Likewise, special treatment of ISO-8859-1 has been removed from the Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3)
テキストメディアタイプのISO-8859-1のデフォルトの文字セットは削除されました。デフォルトは、メディアタイプの定義にあるとおりです。同様に、ISO-8859-1の特別な扱いがAccept-Charsetヘッダーフィールドから削除されました。 （セクション3.1.1.3およびセクション5.3.3）
The definition of Content-Location has been changed to no longer affect the base URI for resolving relative URI references, due to poor implementation support and the undesirable effect of potentially breaking relative links in content-negotiated resources. (Section 3.1.4.2)
Content-Locationの定義が変更され、相対的なURI参照を解決するためのベースURIに影響を与えなくなりました。これは、実装のサポートが不十分であり、コンテンツネゴシエーションされたリソースの相対リンクが壊れる可能性があるという望ましくない影響があるためです。 （セクション3.1.4.2）
To be consistent with the method-neutral parsing algorithm of [RFC7230], the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (Section 4.3.1)
[RFC7230]のメソッド中立構文解析アルゴリズムと一貫性を持たせるため、GETの定義は緩和され、本文にGETの意味がない場合でも、リクエストに本文を含めることができるようになりました。 （セクション4.3.1）
Servers are no longer required to handle all Content-* header fields and use of Content-Range has been explicitly banned in PUT requests. (Section 4.3.4)
サーバーはすべてのContent- *ヘッダーフィールドを処理する必要がなくなり、PUTリクエストでContent-Rangeの使用が明示的に禁止されました。 （セクション4.3.4）
Definition of the CONNECT method has been moved from [RFC2817] to this specification. (Section 4.3.6)
CONNECTメソッドの定義は[RFC2817]からこの仕様に移動されました。 （セクション4.3.6）
The OPTIONS and TRACE request methods have been defined as being safe. (Section 4.3.7 and Section 4.3.8)
OPTIONSおよびTRACE要求メソッドは安全であると定義されています。 （セクション4.3.7およびセクション4.3.8）
The Expect header field's extension mechanism has been removed due to widely-deployed broken implementations. (Section 5.1.1)
Expectヘッダーフィールドの拡張メカニズムは、広く展開されている壊れた実装のために削除されました。 （セクション5.1.1）
The Max-Forwards header field has been restricted to the OPTIONS and TRACE methods; previously, extension methods could have used it as well. (Section 5.1.2)
Max-Forwardsヘッダーフィールドは、OPTIONSおよびTRACEメソッドに制限されています。以前は、拡張メソッドもそれを使用できました。 （セクション5.1.2）
The "about:blank" URI has been suggested as a value for the Referer header field when no referring URI is applicable, which distinguishes that case from others where the Referer field is not sent or has been removed. (Section 5.5.2)
「about：blank」URIは、参照URIが適用されない場合のRefererヘッダーフィールドの値として提案されており、Refererフィールドが送信されないか削除された他の場合と区別されます。 （セクション5.5.2）
The following status codes are now cacheable (that is, they can be stored and reused by a cache without explicit freshness information present): 204, 404, 405, 414, 501. (Section 6)
次のステータスコードがキャッシュ可能になりました（つまり、明示的な鮮度情報がなくても、キャッシュに保存して再利用できます）：204、404、405、414、501。（セクション6）
The 201 (Created) status description has been changed to allow for the possibility that more than one resource has been created. (Section 6.3.2)
201（作成済み）ステータスの説明が変更され、複数のリソースが作成された可能性が考慮されました。 （セクション6.3.2）
The definition of 203 (Non-Authoritative Information) has been broadened to include cases of payload transformations as well. (Section 6.3.4)
203（非権威情報）の定義は、ペイロード変換のケースも含むように拡大されました。 （セクション6.3.4）
The set of request methods that are safe to automatically redirect is no longer closed; user agents are able to make that determination based upon the request method semantics. The redirect status codes 301, 302, and 307 no longer have normative requirements on response payloads and user interaction. (Section 6.4)
自動的にリダイレクトしても安全な一連のリクエストメソッドは閉じていません。ユーザーエージェントは、リクエストメソッドのセマンティクスに基づいてその決定を行うことができます。リダイレクトステータスコード301、302、および307には、応答ペイロードとユーザーインタラクションに関する規範的な要件がなくなりました。 （6.4節）
The status codes 301 and 302 have been changed to allow user agents to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3)
ステータスコード301および302が変更され、ユーザーエージェントがメソッドをPOSTからGETに書き換えることができるようになりました。 （セクション6.4.2および6.4.3）
The description of the 303 (See Other) status code has been changed to allow it to be cached if explicit freshness information is given, and a specific definition has been added for a 303 response to GET. (Section 6.4.4)
303（その他を参照）ステータスコードの説明が変更され、明示的な鮮度情報が提供された場合にキャッシュできるようになり、GETへの303応答に特定の定義が追加されました。 （セクション6.4.4）
The 305 (Use Proxy) status code has been deprecated due to security concerns regarding in-band configuration of a proxy. (Section 6.4.5)
305（プロキシの使用）ステータスコードは、プロキシのインバンド構成に関するセキュリティ上の懸念により廃止されました。 （セクション6.4.5）
The 400 (Bad Request) status code has been relaxed so that it isn't limited to syntax errors. (Section 6.5.1)
400（Bad Request）ステータスコードは緩和されており、構文エラーに限定されません。 （セクション6.5.1）
The 426 (Upgrade Required) status code has been incorporated from [RFC2817]. (Section 6.5.15)
426（アップグレードが必要）ステータスコードは[RFC2817]から組み込まれました。 （セクション6.5.15）
The target of requirements on HTTP-date and the Date header field have been reduced to those systems generating the date, rather than all systems sending a date. (Section 7.1.1)
HTTP-dateおよびDateヘッダーフィールドの要件のターゲットは、日付を送信するすべてのシステムではなく、日付を生成するシステムに削減されました。 （セクション7.1.1）
The syntax of the Location header field has been changed to allow all URI references, including relative references and fragments, along with some clarifications as to when use of fragments would not be appropriate. (Section 7.1.2)
Locationヘッダーフィールドの構文が変更され、相対参照やフラグメントを含むすべてのURI参照が許可されるようになり、フラグメントの使用が適切でない場合の明確化も行われました。 （セクション7.1.2）
Allow has been reclassified as a response header field, removing the option to specify it in a PUT request. Requirements relating to the content of Allow have been relaxed; correspondingly, clients are not required to always trust its value. (Section 7.4.1)
Allowが応答ヘッダーフィールドとして再分類され、PUTリクエストで指定するオプションが削除されました。許可の内容に関する要件が緩和されました。これに対応して、クライアントは常にその値を信頼する必要はありません。 （セクション7.4.1）
A Method Registry has been defined. (Section 8.1)
メソッドレジストリが定義されました。 （セクション8.1）
The Status Code Registry has been redefined by this specification; previously, it was defined in Section 7.1 of [RFC2817]. (Section 8.2)
ステータスコードレジストリは、この仕様によって再定義されました。以前は、[RFC2817]のセクション7.1で定義されていました。 （セクション8.2）
Registration of content codings has been changed to require IETF Review. (Section 8.4)
コンテンツコーディングの登録が変更され、IETFレビューが必要になりました。 （8.4節）
The Content-Disposition header field has been removed since it is now defined by [RFC6266].
Content-Dispositionヘッダーフィールドは、[RFC6266]で定義されているため、削除されました。
The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.
Content-MD5ヘッダーフィールドは、部分的な応答に関して一貫して実装されていなかったため、削除されました。
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で定義されている次のコアルールが参照として含まれています：ALPHA（文字）、CR（キャリッジリターン）、CRLF（CR LF）、CTL（コントロール）、DIGIT（10進数の9） 、DQUOTE（二重引用符）、HEXDIG（16進数の0-9 / AF / af）、HTAB（水平タブ）、LF（ラインフィード）、OCTET（データの任意の8ビットシーケンス）、SP（スペース）、およびVCHAR（目に見えるUS-ASCII文字）。
The rules below are defined in [RFC7230]:
以下のルールは[RFC7230]で定義されています：
BWS = <BWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3>
RWS = <RWS, see [RFC7230], Section 3.2.3>
URI-reference = <URI-reference, see [RFC7230], Section 2.7>
absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
comment = <comment, see [RFC7230], Section 3.2.6>
field-name = <comment, see [RFC7230], Section 3.2>
partial-URI = <partial-URI, see [RFC7230], Section 2.7>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
In the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230].
以下の収集されたABNFでは、リストルールが[RFC7230]のセクション1.2に従って拡張されています。
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] )
Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
BWS = <BWS, see [RFC7230], Section 3.2.3>
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
content-coding ] )
Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
language-tag ] )
Content-Location = absolute-URI / partial-URI
Content-Type = media-type
Date = HTTP-date
日付= HTTP日付
Expect = "100-continue"
Expect = "100-continue"
From = mailbox
From =メールボックス
GMT = %x47.4D.54 ; GMT
HTTP-date = IMF-fixdate / obs-date
HTTP-date = IMF-fixdate / obs-date
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
IMF-fixdate = day-name "、" SP日付1 SP時刻SP GMT
Location = URI-reference
場所= URI参照
Max-Forwards = 1*DIGIT
Max-Forwards = 1 * DIGIT
OWS = <OWS, see [RFC7230], Section 3.2.3>
RWS = <RWS, see [RFC7230], Section 3.2.3>
Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-seconds Server = product *( RWS ( product / comment ) )
URI-reference = <URI-reference, see [RFC7230], Section 2.7>
User-Agent = product *( RWS ( product / comment ) )
Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
) )
absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
accept-params = weight *accept-ext
asctime-date = day-name SP date3 SP time-of-day SP year
charset = token
codings = content-coding / "identity" / "*"
comment = <comment, see [RFC7230], Section 3.2.6>
content-coding = token
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
field-name = <comment, see [RFC7230], Section 3.2>
hour = 2DIGIT
時間= 2DIGIT
language-range = <language-range, see [RFC4647], Section 2.1>
language-tag = <Language-Tag, see [RFC5646], Section 2.1>
mailbox = <mailbox, see [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" OWS parameter )
media-type = type "/" subtype *( OWS ";" OWS parameter )
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-date = rfc850-date / asctime-date
parameter = token "=" ( token / quoted-string )
partial-URI = <partial-URI, see [RFC7230], Section 2.7>
product = token [ "/" product-version ]
product-version = token
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
rfc850-date = day-name-l "、" SP日付2 SP時刻SP GMT
second = 2DIGIT subtype = token
2番目= 2DIGITサブタイプ=トークン
time-of-day = hour ":" minute ":" second
token = <token, see [RFC7230], Section 3.2.6>
type = token
weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT
年= 4DIGIT
Index
索引
1 1xx Informational (status code class) 50
1 1xx情報（ステータスコードクラス）50
2 2xx Successful (status code class) 51
2 2xx成功（ステータスコードクラス）51
3 3xx Redirection (status code class) 54
3 3xxリダイレクト（ステータスコードクラス）54
4 4xx Client Error (status code class) 58
4 4xxクライアントエラー（ステータスコードクラス）58
5 5xx Server Error (status code class) 62
5 5xxサーバーエラー（ステータスコードクラス）62
1 100 Continue (status code) 50 100-continue (expect value) 34 101 Switching Protocols (status code) 50
1 100継続（ステータスコード）50100継続（期待値）34101スイッチングプロトコル（ステータスコード）50
2 200 OK (status code) 51 201 Created (status code) 52 202 Accepted (status code) 52 203 Non-Authoritative Information (status code) 52 204 No Content (status code) 53 205 Reset Content (status code) 53
2200 OK（ステータスコード）51201作成済み（ステータスコード）52202承認済み（ステータスコード）52203非信頼情報（ステータスコード）52204コンテンツなし（ステータスコード）53205コンテンツのリセット（ステータスコード）53
3 300 Multiple Choices (status code) 55 301 Moved Permanently (status code) 56 302 Found (status code) 56 303 See Other (status code) 57 305 Use Proxy (status code) 58 306 (Unused) (status code) 58 307 Temporary Redirect (status code) 58
3300複数の選択肢（ステータスコード）55301永久に移動（ステータスコード）56302見つかった（ステータスコード）56303その他を参照（ステータスコード）57305プロキシの使用（ステータスコード）58306（未使用）（ステータスコード）58307一時的なリダイレクト（ステータスコード）58
4 400 Bad Request (status code) 58 402 Payment Required (status code) 59 403 Forbidden (status code) 59 404 Not Found (status code) 59 405 Method Not Allowed (status code) 59 406 Not Acceptable (status code) 59 408 Request Timeout (status code) 60 409 Conflict (status code) 60 410 Gone (status code) 60 411 Length Required (status code) 61 413 Payload Too Large (status code) 61 414 URI Too Long (status code) 61 415 Unsupported Media Type (status code) 62 417 Expectation Failed (status code) 62 426 Upgrade Required (status code) 62
4 400不正なリクエスト（ステータスコード）58402支払いが必要（ステータスコード）59403禁止（ステータスコード）59404見つかりません（ステータスコード）59405許可されていないメソッド（ステータスコード）59406受け入れられない（ステータスコード）59408リクエストタイムアウト（ステータスコード）60409競合（ステータスコード）60410存在しない（ステータスコード）60411必要な長さ（ステータスコード）61413ペイロードが大きすぎます（ステータスコード）61414 URIが長すぎます（ステータスコード）61415サポートされていないメディアタイプ（ステータスコード）62417期待される失敗（ステータスコード）62426アップグレードが必要（ステータスコード）62
5 500 Internal Server Error (status code) 63 501 Not Implemented (status code) 63 502 Bad Gateway (status code) 63 503 Service Unavailable (status code) 63 504 Gateway Timeout (status code) 63 505 HTTP Version Not Supported (status code) 64
5 500内部サーバーエラー（ステータスコード）63 501未実装（ステータスコード）63 502不正なゲートウェイ（ステータスコード）63 503サービスを利用できません（ステータスコード）63 504ゲートウェイのタイムアウト（ステータスコード）63 505サポートされていないHTTPバージョン（ステータスコード）64
A Accept header field 38 Accept-Charset header field 40 Accept-Encoding header field 41 Accept-Language header field 42 Allow header field 72
Acceptヘッダーフィールド38 Accept-Charsetヘッダーフィールド40 Accept-Encodingヘッダーフィールド41 Accept-Languageヘッダーフィールド42 Allowヘッダーフィールド72
C cacheable 24 compress (content coding) 11 conditional request 36 CONNECT method 30 content coding 11 content negotiation 6 Content-Encoding header field 12 Content-Language header field 13 Content-Location header field 15 Content-Transfer-Encoding header field 89 Content-Type header field 10
Cキャッシュ可能24圧縮（コンテンツコーディング）11条件付き要求36 CONNECTメソッド30コンテンツコーディング11コンテンツネゴシエーション6 Content-Encodingヘッダーフィールド12 Content-Languageヘッダーフィールド13 Content-Locationヘッダーフィールド15 Content-Transfer-Encodingヘッダーフィールド89 Content-Typeヘッダーフィールド10
D Date header field 67 deflate (content coding) 11 DELETE method 29
D日付ヘッダーフィールド67 deflate（コンテンツコーディング）11 DELETEメソッド29
E Expect header field 34
Eヘッダーフィールドを期待34
F From header field 44
F Fromヘッダーフィールド44
G GET method 24 Grammar Accept 38 Accept-Charset 40 Accept-Encoding 41 accept-ext 38 Accept-Language 42 accept-params 38 Allow 72 asctime-date 66 charset 9 codings 41 content-coding 11 Content-Encoding 12 Content-Language 13 Content-Location 15 Content-Type 10 Date 67 date1 65 day 65 day-name 65 day-name-l 65 delay-seconds 69 Expect 34 From 44 GMT 65 hour 65 HTTP-date 65 IMF-fixdate 65 language-range 42 language-tag 13 Location 68 Max-Forwards 36 media-range 38 media-type 8 method 21 minute 65 month 65 obs-date 66 parameter 8 product 46 product-version 46 qvalue 38 Referer 45 Retry-After 69 rfc850-date 66 second 65 Server 73 subtype 8 time-of-day 65 type 8 User-Agent 46 Vary 70 weight 38 year 65 gzip (content coding) 11
G GETメソッド24文法Accept 38 Accept-Charset 40 Accept-Encoding 41 accept-ext 38 Accept-Language 42 Accept-params 38 Allow 72 asctime-date 66 charset 9コーディング41 content-coding 11 Content-Encoding 12 Content-Language 13 Content -Location 15 Content-Type 10 Date 67 date1 65 day 65 day-name 65 day-name-l 65 delay-seconds 69 Expect 34 From 44 GMT 65 hour 65 HTTP-date 65 IMF-fixdate 65 language-range 42 language-tag 13場所68最大転送36メディア範囲38メディアタイプ8メソッド21分65月65 obs-date 66パラメータ8 product 46 product-version 46 qvalue 38リファラー45 Retry-After 69 rfc850-date 66秒65サーバー73サブタイプ8時刻65タイプ8ユーザーエージェント46変動70重量38年65 gzip（コンテンツコーディング）11
H HEAD method 25
H HEADメソッド25
I idempotent 23
私はべき等23
L Location header field 68
Lロケーションヘッダーフィールド68
M Max-Forwards header field 36 MIME-Version header field 89
M Max-Forwardsヘッダーフィールド36 MIME-Versionヘッダーフィールド89
O OPTIONS method 31
O OPTIONSメソッド31
P payload 17 POST method 25 PUT method 26
Pペイロード17 POSTメソッド25 PUTメソッド26
R Referer header field 45 representation 7 Retry-After header field 69
Rリファラーヘッダーフィールド45の表現7 Retry-Afterヘッダーフィールド69
S safe 22 selected representation 7, 71 Server header field 73 Status Codes Classes 1xx Informational 50 2xx Successful 51 3xx Redirection 54 4xx Client Error 58 5xx Server Error 62
Sセーフ22選択表現7、71サーバーヘッダーフィールド73ステータスコードクラス1xx情報50 2xx成功51 3xxリダイレクション54 4xxクライアントエラー58 5xxサーバーエラー62
T TRACE method 32
T TRACEメソッド32
U User-Agent header field 46
U User-Agentヘッダーフィールド46
V Vary header field 70
V Varyヘッダーフィールド70
X x-compress (content coding) 11 x-gzip (content coding) 11
X x-compress（コンテンツコーディング）11 x-gzip（コンテンツコーディング）11
Authors' Addresses
著者のアドレス
Roy T. Fielding (editor) Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
ロイT.フィールディング（編集者）Adobe Systems Incorporated 345 Park Ave San Jose、CA 95110 USA
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F. Reschke（編集者）greenbytes GmbH Hafenweg 16 Muenster、NW 48155ドイツ
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/