[要約] RFC 2616はHTTP/1.1の仕様を定義しており、インターネット上での情報の転送を可能にするためのプロトコルです。このRFCの目的は、クライアントとサーバー間の通信を効率的かつ信頼性の高いものにすることです。
Network Working Group R. Fielding
Request for Comments: 2616 UC Irvine
Obsoletes: 2068 J. Gettys
Category: Standards Track Compaq/W3C
J. Mogul
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June 1999
Hypertext Transfer Protocol -- HTTP/1.1
ハイパーテキスト転送プロトコル-HTTP / 1.1
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
Abstract
概要
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
ハイパーテキスト転送プロトコル（HTTP）は、分散型の協調型ハイパーメディア情報システム用のアプリケーションレベルのプロトコルです。これは、要求メソッド、エラーコード、およびヘッダーの拡張を通じて、ネームサーバーや分散オブジェクト管理システムなど、ハイパーテキストの使用を超えた多くのタスクに使用できる汎用のステートレスプロトコルです[47]。 HTTPの機能は、データ表現のタイプとネゴシエーションであり、転送されるデータとは独立してシステムを構築できます。
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
HTTPは、1990年以来、World-Wide Webグローバル情報イニシアチブによって使用されてきました。この仕様は、「HTTP / 1.1」と呼ばれるプロトコルを定義し、RFC 2068 [33]の更新版です。
Table of Contents
目次
1 Introduction ...................................................7
1.1 Purpose......................................................7
1.2 Requirements .................................................8
1.3 Terminology ..................................................8
1.4 Overall Operation ...........................................12
2 Notational Conventions and Generic Grammar ....................14
2.1 Augmented BNF ...............................................14
2.2 Basic Rules .................................................15
3 Protocol Parameters ...........................................17
3.1 HTTP Version ................................................17
3.2 Uniform Resource Identifiers ................................18
3.2.1 General Syntax ...........................................19
3.2.2 http URL .................................................19
3.2.3 URI Comparison ...........................................20
3.3 Date/Time Formats ...........................................20
3.3.1 Full Date ................................................20
3.3.2 Delta Seconds ............................................21
3.4 Character Sets ..............................................21
3.4.1 Missing Charset ..........................................22
3.5 Content Codings .............................................23
3.6 Transfer Codings ............................................24
3.6.1 Chunked Transfer Coding ..................................25
3.7 Media Types .................................................26
3.7.1 Canonicalization and Text Defaults .......................27
3.7.2 Multipart Types ..........................................27
3.8 Product Tokens ..............................................28
3.9 Quality Values ..............................................29
3.10 Language Tags ...............................................29
3.11 Entity Tags .................................................30
3.12 Range Units .................................................30
4 HTTP Message ..................................................31
4.1 Message Types ...............................................31
4.2 Message Headers .............................................31
4.3 Message Body ................................................32
4.4 Message Length ..............................................33
4.5 General Header Fields .......................................34
5 Request .......................................................35
5.1 Request-Line ................................................35
5.1.1 Method ...................................................36
5.1.2 Request-URI ..............................................36
5.2 The Resource Identified by a Request ........................38
5.3 Request Header Fields .......................................38
6 Response ......................................................39
6.1 Status-Line .................................................39
6.1.1 Status Code and Reason Phrase ............................39
6.2 Response Header Fields ......................................41
7 Entity ........................................................42
7.1 Entity Header Fields ........................................42
7.2 Entity Body .................................................43
7.2.1 Type .....................................................43
7.2.2 Entity Length ............................................43
8 Connections ...................................................44
8.1 Persistent Connections ......................................44
8.1.1 Purpose ..................................................44
8.1.2 Overall Operation ........................................45
8.1.3 Proxy Servers ............................................46
8.1.4 Practical Considerations .................................46
8.2 Message Transmission Requirements ...........................47
8.2.1 Persistent Connections and Flow Control ..................47
8.2.2 Monitoring Connections for Error Status Messages .........48
8.2.3 Use of the 100 (Continue) Status .........................48
8.2.4 Client Behavior if Server Prematurely Closes Connection ..50
9 Method Definitions ............................................51
9.1 Safe and Idempotent Methods .................................51
9.1.1 Safe Methods .............................................51
9.1.2 Idempotent Methods .......................................51
9.2 OPTIONS .....................................................52
9.3 GET .........................................................53
9.4 HEAD ........................................................54
9.5 POST ........................................................54
9.6 PUT .........................................................55
9.7 DELETE ......................................................56
9.8 TRACE .......................................................56
9.9 CONNECT .....................................................57
10 Status Code Definitions ......................................57
10.1 Informational 1xx ...........................................57
10.1.1 100 Continue .............................................58
10.1.2 101 Switching Protocols ..................................58
10.2 Successful 2xx ..............................................58
10.2.1 200 OK ...................................................58
10.2.2 201 Created ..............................................59
10.2.3 202 Accepted .............................................59
10.2.4 203 Non-Authoritative Information ........................59
10.2.5 204 No Content ...........................................60
10.2.6 205 Reset Content ........................................60
10.2.7 206 Partial Content ......................................60
10.3 Redirection 3xx .............................................61
10.3.1 300 Multiple Choices .....................................61
10.3.2 301 Moved Permanently ....................................62
10.3.3 302 Found ................................................62
10.3.4 303 See Other ............................................63
10.3.5 304 Not Modified .........................................63
10.3.6 305 Use Proxy ............................................64
10.3.7 306 (Unused) .............................................64
10.3.8 307 Temporary Redirect ...................................65
10.4 Client Error 4xx ............................................65
10.4.1 400 Bad Request .........................................65
10.4.2 401 Unauthorized ........................................66
10.4.3 402 Payment Required ....................................66
10.4.4 403 Forbidden ...........................................66
10.4.5 404 Not Found ...........................................66
10.4.6 405 Method Not Allowed ..................................66
10.4.7 406 Not Acceptable ......................................67
10.4.8 407 Proxy Authentication Required .......................67
10.4.9 408 Request Timeout .....................................67
10.4.10 409 Conflict ............................................67
10.4.11 410 Gone ................................................68
10.4.12 411 Length Required .....................................68
10.4.13 412 Precondition Failed .................................68
10.4.14 413 Request Entity Too Large ............................69
10.4.15 414 Request-URI Too Long ................................69
10.4.16 415 Unsupported Media Type ..............................69
10.4.17 416 Requested Range Not Satisfiable .....................69
10.4.18 417 Expectation Failed ..................................70
10.5 Server Error 5xx ............................................70
10.5.1 500 Internal Server Error ................................70
10.5.2 501 Not Implemented ......................................70
10.5.3 502 Bad Gateway ..........................................70
10.5.4 503 Service Unavailable ..................................70
10.5.5 504 Gateway Timeout ......................................71
10.5.6 505 HTTP Version Not Supported ...........................71
11 Access Authentication ........................................71
12 Content Negotiation ..........................................71
12.1 Server-driven Negotiation ...................................72
12.2 Agent-driven Negotiation ....................................73
12.3 Transparent Negotiation .....................................74
13 Caching in HTTP ..............................................74
13.1.1 Cache Correctness ........................................75
13.1.2 Warnings .................................................76
13.1.3 Cache-control Mechanisms .................................77
13.1.4 Explicit User Agent Warnings .............................78
13.1.5 Exceptions to the Rules and Warnings .....................78
13.1.6 Client-controlled Behavior ...............................79
13.2 Expiration Model ............................................79
13.2.1 Server-Specified Expiration ..............................79
13.2.2 Heuristic Expiration .....................................80
13.2.3 Age Calculations .........................................80
13.2.4 Expiration Calculations ..................................83
13.2.5 Disambiguating Expiration Values .........................84
13.2.6 Disambiguating Multiple Responses ........................84
13.3 Validation Model ............................................85
13.3.1 Last-Modified Dates ......................................86
13.3.2 Entity Tag Cache Validators ..............................86
13.3.3 Weak and Strong Validators ...............................86
13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89
13.3.5 Non-validating Conditionals ..............................90
13.4 Response Cacheability .......................................91
13.5 Constructing Responses From Caches ..........................92
13.5.1 End-to-end and Hop-by-hop Headers ........................92
13.5.2 Non-modifiable Headers ...................................92
13.5.3 Combining Headers ........................................94
13.5.4 Combining Byte Ranges ....................................95
13.6 Caching Negotiated Responses ................................95
13.7 Shared and Non-Shared Caches ................................96
13.8 Errors or Incomplete Response Cache Behavior ................97
13.9 Side Effects of GET and HEAD ................................97
13.10 Invalidation After Updates or Deletions ...................97
13.11 Write-Through Mandatory ...................................98
13.12 Cache Replacement .........................................99
13.13 History Lists .............................................99
14 Header Field Definitions ....................................100
14.1 Accept .....................................................100
14.2 Accept-Charset .............................................102
14.3 Accept-Encoding ............................................102
14.4 Accept-Language ............................................104
14.5 Accept-Ranges ..............................................105
14.6 Age ........................................................106
14.7 Allow ......................................................106
14.8 Authorization ..............................................107
14.9 Cache-Control ..............................................108
14.9.1 What is Cacheable .......................................109
14.9.2 What May be Stored by Caches ............................110
14.9.3 Modifications of the Basic Expiration Mechanism .........111
14.9.4 Cache Revalidation and Reload Controls ..................113
14.9.5 No-Transform Directive ..................................115
14.9.6 Cache Control Extensions ................................116
14.10 Connection ...............................................117
14.11 Content-Encoding .........................................118
14.12 Content-Language .........................................118
14.13 Content-Length ...........................................119
14.14 Content-Location .........................................120
14.15 Content-MD5 ..............................................121
14.16 Content-Range ............................................122
14.17 Content-Type .............................................124
14.18 Date .....................................................124
14.18.1 Clockless Origin Server Operation ......................125
14.19 ETag .....................................................126
14.20 Expect ...................................................126
14.21 Expires ..................................................127
14.22 From .....................................................128
14.23 Host .....................................................128
14.24 If-Match .................................................129
14.25 If-Modified-Since ........................................130
14.26 If-None-Match ............................................132
14.27 If-Range .................................................133
14.28 If-Unmodified-Since ......................................134
14.29 Last-Modified ............................................134
14.30 Location .................................................135
14.31 Max-Forwards .............................................136
14.32 Pragma ...................................................136
14.33 Proxy-Authenticate .......................................137
14.34 Proxy-Authorization ......................................137
14.35 Range ....................................................138
14.35.1 Byte Ranges ...........................................138
14.35.2 Range Retrieval Requests ..............................139
14.36 Referer ..................................................140
14.37 Retry-After ..............................................141
14.38 Server ...................................................141
14.39 TE .......................................................142
14.40 Trailer ..................................................143
14.41 Transfer-Encoding..........................................143
14.42 Upgrade ..................................................144
14.43 User-Agent ...............................................145
14.44 Vary .....................................................145
14.45 Via ......................................................146
14.46 Warning ..................................................148
14.47 WWW-Authenticate .........................................150
15 Security Considerations .......................................150
15.1 Personal Information....................................151
15.1.1 Abuse of Server Log Information .........................151
15.1.2 Transfer of Sensitive Information .......................151
15.1.3 Encoding Sensitive Information in URI's .................152
15.1.4 Privacy Issues Connected to Accept Headers ..............152
15.2 Attacks Based On File and Path Names .......................153
15.3 DNS Spoofing ...............................................154
15.4 Location Headers and Spoofing ..............................154
15.5 Content-Disposition Issues .................................154
15.6 Authentication Credentials and Idle Clients ................155
15.7 Proxies and Caching ........................................155
15.7.1 Denial of Service Attacks on Proxies....................156
16 Acknowledgments .............................................156
17 References ..................................................158
18 Authors' Addresses ..........................................162
19 Appendices ..................................................164
19.1 Internet Media Type message/http and application/http ......164
19.2 Internet Media Type multipart/byteranges ...................165
19.3 Tolerant Applications ......................................166
19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167
19.4.1 MIME-Version ............................................167
19.4.2 Conversion to Canonical Form ............................167
19.4.3 Conversion of Date Formats ..............................168
19.4.4 Introduction of Content-Encoding ........................168
19.4.5 No Content-Transfer-Encoding ............................168
19.4.6 Introduction of Transfer-Encoding .......................169
19.4.7 MHTML and Line Length Limitations .......................169
19.5 Additional Features ........................................169
19.5.1 Content-Disposition .....................................170
19.6 Compatibility with Previous Versions .......................170
19.6.1 Changes from HTTP/1.0 ...................................171
19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172
19.6.3 Changes from RFC 2068 ...................................172
20 Index .......................................................175
21 Full Copyright Statement ....................................176
1 Introduction
1はじめに
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" has necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities.
ハイパーテキスト転送プロトコル（HTTP）は、分散型の協調型ハイパーメディア情報システム用のアプリケーションレベルのプロトコルです。 HTTPは、1990年以降、World-Wide Webグローバル情報イニシアチブで使用されています。HTTP/ 0.9と呼ばれるHTTPの最初のバージョンは、インターネットを介した生データ転送用のシンプルなプロトコルでした。 RFC 1945 [6]で定義されているHTTP / 1.0は、メッセージをMIMEのようなメッセージの形式にし、転送されたデータに関するメタ情報と要求/応答セマンティクスの修飾子を含めることで、プロトコルを改善しました。ただし、HTTP / 1.0では、階層プロキシ、キャッシュ、永続的な接続の必要性、または仮想ホストの影響を十分に考慮していません。さらに、「HTTP / 1.0」と呼ばれる不完全に実装されたアプリケーションの急増により、2つの通信アプリケーションが互いの真の機能を判別するために、プロトコルバージョンの変更が必要になりました。
This specification defines the protocol referred to as "HTTP/1.1". This protocol includes more stringent requirements than HTTP/1.0 in order to ensure reliable implementation of its features.
この仕様は、「HTTP / 1.1」と呼ばれるプロトコルを定義しています。このプロトコルには、機能の信頼できる実装を保証するために、HTTP / 1.0よりも厳しい要件が含まれています。
Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods and headers that indicate the purpose of a request [47]. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) [3], as a location (URL) [4] or name (URN) [20], for indicating the resource to which a
実用的な情報システムには、検索、フロントエンドの更新、注釈など、単純な検索よりも多くの機能が必要です。 HTTPは、リクエストの目的を示すメソッドとヘッダーの制限のないセットを許可します[47]。これは、Uniform Resource Identifier（URI）[3]によって提供される参照の規律に基づいて、場所（URL）[4]または名前（URN）[20]として構築され、
method is to be applied. Messages are passed in a format similar to that used by Internet mail [9] as defined by the Multipurpose Internet Mail Extensions (MIME) [7].
メソッドが適用されます。メッセージは、多目的インターネットメール拡張機能（MIME）[7]で定義されているインターネットメール[9]で使用されるものと同様の形式で渡されます。
HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems, including those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], and WAIS [10] protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.
HTTPは、SMTP [16]、NNTP [13]、FTP [18]、Gopher [2]、およびWAIS [でサポートされているものを含む、他のインターネットシステムへのユーザーエージェントとプロキシ/ゲートウェイ間の通信の汎用プロトコルとしても使用されます。 10]プロトコル。このように、HTTPは、さまざまなアプリケーションから利用可能なリソースへの基本的なハイパーメディアアクセスを許可します。
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 RFC 2119 [34].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [34]で説明されているように解釈されます。
An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."
実装するプロトコルの1つ以上の必須または必須レベルの要件を満たさない場合、実装は準拠していません。プロトコルのすべてのMUSTまたはREQUIREDレベルおよびすべてのSHOULDレベルの要件を満たす実装は、「無条件に準拠」していると言われています。プロトコルのすべてのMUSTレベルの要件を満たしているが、そのプロトコルのすべてのSHOULDレベルの要件を満たしていないものは、「条件付きで準拠している」と言われます。
This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication.
この仕様では、いくつかの用語を使用して、HTTP通信の参加者とHTTP通信のオブジェクトが果たす役割を指します。
connection A transport layer virtual circuit established between two programs for the purpose of communication.
接続通信を目的として2つのプログラム間に確立されたトランスポート層仮想回線。
message The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in section 4 and transmitted via the connection.
メッセージHTTP通信の基本単位。セクション4で定義された構文に一致し、接続を介して送信されるオクテットの構造化されたシーケンスで構成されます。
request An HTTP request message, as defined in section 5.
requestセクション5で定義されているHTTPリクエストメッセージ。
response An HTTP response message, as defined in section 6.
セクション6で定義されているHTTP応答メッセージ。
resource A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways.
リソース3.2で定義されているように、URIで識別できるネットワークデータオブジェクトまたはサービス。リソースは、複数の表現（複数の言語、データ形式、サイズ、解像度など）で利用できる場合と、他の方法で異なる場合があります。
entity The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in section 7.
エンティティリクエストまたはレスポンスのペイロードとして転送される情報。エンティティは、セクション7で説明されているように、エンティティヘッダーフィールドの形式のメタ情報とエンティティ本体の形式のコンテンツで構成されます。
representation An entity included with a response that is subject to content negotiation, as described in section 12. There may exist multiple representations associated with a particular response status.
表現セクション12で説明されているように、コンテンツネゴシエーションの対象となる応答に含まれるエンティティ。特定の応答ステータスに関連付けられた複数の表現が存在する場合があります。
content negotiation The mechanism for selecting the appropriate representation when servicing a request, as described in section 12. The representation of entities in any response can be negotiated (including error responses).
コンテンツネゴシエーションセクション12で説明するように、要求を処理するときに適切な表現を選択するためのメカニズム。応答内のエンティティの表現は、ネゴシエートできます（エラー応答を含む）。
variant A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.
バリアントAリソースには、任意の瞬間に1つまたは複数の表現が関連付けられている場合があります。これらの表現のそれぞれを「バリアント」と呼びます。 「バリアント」という用語の使用は、リソースがコンテンツネゴシエーションの対象であることを必ずしも意味しません。
client A program that establishes connections for the purpose of sending requests.
クライアントリクエストを送信する目的で接続を確立するプログラム。
user agent The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.
ユーザーエージェントリクエストを開始するクライアント。これらは、多くの場合、ブラウザー、エディター、スパイダー（Webトラバースロボット）、またはその他のエンドユーザーツールです。
server An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.
サーバー応答を送り返すことによって要求を処理するために接続を受け入れるアプリケーションプログラム。特定のプログラムは、クライアントとサーバーの両方になることができます。これらの用語の使用は、プログラムの一般的な機能ではなく、特定の接続に対してプログラムによって実行される役割のみを指します。同様に、どのサーバーも、オリジンサーバー、プロキシ、ゲートウェイ、またはトンネルとして機能し、各リクエストの性質に基づいて動作を切り替えます。
origin server The server on which a given resource resides or is to be created.
起点サーバー特定のリソースが存在するサーバー、または作成されるサーバー。
proxy An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.
プロキシ他のクライアントに代わってリクエストを行う目的でサーバーとクライアントの両方として機能する中間プログラム。リクエストは内部的に処理されるか、他のサーバーに変換される可能性があります。プロキシは、この仕様のクライアントとサーバーの両方の要件を実装する必要があります。 「透過プロキシ」は、プロキシの認証と識別に必要なものを超えて要求または応答を変更しないプロキシです。 「非透過プロキシ」は、グループアノテーションサービス、メディアタイプの変換、プロトコルの削減、匿名フィルタリングなどの追加サービスをユーザーエージェントに提供するために、要求または応答を変更するプロキシです。透過的または非透過的な動作が明示的に記述されている場合を除き、HTTPプロキシ要件は両方のタイプのプロキシに適用されます。
gateway A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway.
ゲートウェイ他のサーバーの仲介として機能するサーバー。プロキシとは異なり、ゲートウェイはリクエストされたリソースのオリジンサーバーであるかのようにリクエストを受信します。要求元のクライアントは、ゲートウェイと通信していることを認識していない場合があります。
tunnel An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed.
トンネル2つの接続間のブラインドリレーとして機能する中間プログラム。いったんアクティブになると、トンネルはHTTP通信の当事者とは見なされませんが、トンネルはHTTP要求によって開始された可能性があります。リレーされた接続の両端が閉じられると、トンネルは存在しなくなります。
cache A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.
キャッシュプログラムの応答メッセージのローカルストアと、メッセージの保存、取得、削除を制御するサブシステム。キャッシュは、将来の同等の要求での応答時間とネットワーク帯域幅の消費を削減するために、キャッシュ可能な応答を格納します。トンネルとして機能しているサーバーはキャッシュを使用できませんが、クライアントまたはサーバーにはキャッシュを含めることができます。
cacheable A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request.
cacheableキャッシュは、後続の要求への応答に使用するために応答メッセージのコピーを格納することが許可されている場合、キャッシュ可能です。 HTTP応答のキャッシュ可能性を決定するためのルールは、セクション13で定義されています。リソースがキャッシュ可能である場合でも、キャッシュが特定の要求に対してキャッシュされたコピーを使用できるかどうかに追加の制約がある場合があります。
first-hand A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more proxies. A response is also first-hand if its validity has just been checked directly with the origin server.
first-handおそらく、1つ以上のプロキシを介して、オリジンサーバーから直接、不必要な遅延なしに応答が返される場合、応答は直接的なものです。オリジンサーバーで直接有効性を確認したばかりの場合も、レスポンスは直接的なものです。
explicit expiration time The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.
明示的な有効期限元のサーバーが、エンティティをさらに検証しないとキャッシュから返されないようにする予定の時間。
heuristic expiration time An expiration time assigned by a cache when no explicit expiration time is available.
ヒューリスティック有効期限明示的な有効期限がない場合にキャッシュによって割り当てられる有効期限。
age The age of a response is the time since it was sent by, or successfully validated with, the origin server.
age応答の経過時間は、元のサーバーによって送信されてから、または正常に検証されてからの時間です。
freshness lifetime The length of time between the generation of a response and its expiration time.
フレッシュネスライフタイム応答の生成とその有効期限の間の時間の長さ。
fresh A response is fresh if its age has not yet exceeded its freshness lifetime.
フレッシュ年齢がフレッシュネスライフタイムを超えていない場合、レスポンスはフレッシュです。
stale A response is stale if its age has passed its freshness lifetime.
古くなった存続期間が経過すると、応答は古くなります。
semantically transparent A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither the requesting client nor the origin server, except to improve performance. When a cache is semantically transparent, the client receives exactly the same response (except for hop-by-hop headers) that it would have received had its request been handled directly by the origin server.
意味的に透過的キャッシュは、パフォーマンスの向上を除いて、その使用が要求側クライアントにもオリジンサーバーにも影響を与えない場合、特定の応答に関して「意味的に透過的」な方法で動作します。キャッシュが意味的に透過的である場合、クライアントは、要求がオリジンサーバーによって直接処理された場合とまったく同じ応答（ホップバイホップヘッダーを除く）を受け取ります。
validator A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent copy of an entity.
バリデーターキャッシュエントリがエンティティの同等のコピーであるかどうかを確認するために使用されるプロトコル要素（エンティティタグやLast-Modified時間など）。
upstream/downstream Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.
アップストリーム/ダウンストリームアップストリームとダウンストリームは、メッセージのフローを示します。すべてのメッセージは、アップストリームからダウンストリームに流れます。
inbound/outbound Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent"
インバウンド/アウトバウンドインバウンドおよびアウトバウンドは、メッセージの要求および応答パスを指します。「インバウンド」は「オリジンサーバーに向かう」を意味し、「アウトバウンド」は「ユーザーエージェントに向かう」を意味します
The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content. The relationship between HTTP and MIME is described in appendix 19.4.
HTTPプロトコルは、要求/応答プロトコルです。クライアントは、リクエストメソッド、URI、プロトコルバージョンの形式でサーバーにリクエストを送信し、その後、サーバーとの接続を介して、リクエスト修飾子、クライアント情報、および可能なボディコンテンツを含むMIMEのようなメッセージを送信します。サーバーは、メッセージのプロトコルバージョンと成功またはエラーコードを含むステータス行で応答し、その後にサーバー情報、エンティティメタ情報、および可能性のあるエンティティ本体コンテンツを含むMIMEのようなメッセージが続きます。 HTTPとMIMEの関係については、付録19.4で説明しています。
Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin server (O).
ほとんどのHTTP通信はユーザーエージェントによって開始され、いくつかのオリジンサーバー上のリソースに適用される要求で構成されます。最も単純なケースでは、これは、ユーザーエージェント（UA）とオリジンサーバー（O）の間の単一の接続（v）を介して実行できます。
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three common forms of intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, receiving requests for a URI in its absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by the URI. A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests to the underlying server's protocol. A tunnel acts as a relay point between two connections without changing the messages; tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary cannot understand the contents of the messages.
1つ以上の仲介者が要求/応答チェーンに存在する場合、より複雑な状況が発生します。仲介には、プロキシ、ゲートウェイ、トンネルの3つの一般的な形式があります。プロキシは転送エージェントであり、絶対形式でURIの要求を受け取り、メッセージのすべてまたは一部を書き換え、URIで識別されるサーバーに向けて再フォーマットされた要求を転送します。ゲートウェイは受信エージェントであり、他のサーバーの上位層として機能し、必要に応じて、要求を基になるサーバーのプロトコルに変換します。トンネルは、メッセージを変更せずに2つの接続間の中継点として機能します。トンネルは、仲介者がメッセージの内容を理解できない場合でも、通信が仲介者（ファイアウォールなど）を通過する必要がある場合に使用されます。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response message that travels the whole chain will pass through four separate connections. This distinction is important because some HTTP communication options may apply only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along the chain. Although the diagram is linear, each participant may be engaged in multiple, simultaneous communications. For example, B may be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, at the same time that it is handling A's request.
上の図は、ユーザーエージェントと配信元サーバーの間の3つの仲介者（A、B、C）を示しています。チェーン全体を移動する要求または応答メッセージは、4つの個別の接続を通過します。一部のHTTP通信オプションは、最も近いトンネル以外のネイバーとの接続、チェーンのエンドポイント、またはチェーンに沿ったすべての接続にのみ適用される場合があるため、この区別は重要です。図は直線的ですが、各参加者は複数の同時通信に従事する場合があります。たとえば、Bは、A以外の多くのクライアントからの要求を受信したり、C以外のサーバーに要求を転送したりすると同時に、Aの要求を処理している場合があります。
Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from O (via C) for a request which has not been cached by UA or A.
トンネルとして機能していない通信の当事者は、要求を処理するために内部キャッシュを使用できます。キャッシュの効果は、チェーン上の参加者の1人がそのリクエストに適用可能なキャッシュされたレスポンスを持っている場合、リクエスト/レスポンスチェーンが短縮されることです。以下は、UAまたはAによってキャッシュされていないリクエストに対して、BがOからの（Cを介した）以前の応答のキャッシュされたコピーを持っている場合の結果のチェーンを示しています。
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache behavior. HTTP requirements for cache behavior and cacheable responses are defined in section 13.
すべての応答が有効にキャッシュできるわけではなく、一部の要求には、キャッシュの動作に特別な要件を課す修飾子が含まれる場合があります。キャッシュ動作とキャッシュ可能な応答のHTTP要件は、セクション13で定義されています。
In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with or deployed across the World Wide Web. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems that broadcast or multicast cache entries, organizations that distribute subsets of cached data via CD-ROM, and so on. HTTP systems are used in corporate intranets over high-bandwidth links, and for access via PDAs with low-power radio links and intermittent connectivity. The goal of HTTP/1.1 is to support the wide diversity of configurations already deployed while introducing protocol constructs that meet the needs of those who build web applications that require high reliability and, failing that, at least reliable indications of failure.
実際、キャッシュとプロキシのさまざまなアーキテクチャと構成があり、現在World Wide Webで実験または展開されています。これらのシステムには、大洋横断の帯域幅を節約するプロキシキャッシュの全国階層、キャッシュエントリをブロードキャストまたはマルチキャストするシステム、CD-ROMを介してキャッシュデータのサブセットを配布する組織などが含まれます。 HTTPシステムは、広帯域イントラネット上の企業イントラネットで使用され、低電力の無線リンクと断続的な接続を備えたPDA経由のアクセスに使用されます。 HTTP / 1.1の目標は、高い信頼性を必要とするWebアプリケーションを構築する人のニーズを満たすプロトコルコンストラクトを導入しながら、すでに導入された幅広い構成をサポートし、少なくとも信頼性の高い障害表示を失敗させることです。
HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.
HTTP通信は通常、TCP / IP接続を介して行われます。デフォルトのポートはTCP 80 [19]ですが、他のポートを使用することもできます。これは、HTTPがインターネットまたは他のネットワーク上の他のプロトコルの上に実装されることを排除するものではありません。 HTTPは信頼できるトランスポートのみを前提としています。そのような保証を提供する任意のプロトコルを使用できます。問題のプロトコルのトランスポートデータユニットへのHTTP / 1.1要求および応答構造のマッピングは、この仕様の範囲外です。
In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see section 8.1).
HTTP / 1.0では、ほとんどの実装で、要求/応答交換ごとに新しい接続が使用されていました。 HTTP / 1.1では、接続は1つ以上の要求/応答交換に使用できますが、接続はさまざまな理由でクローズされる場合があります（8.1節を参照）。
2 Notational Conventions and Generic Grammar
2表記規則と一般文法
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 [9]. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs:
このドキュメントで指定されているすべてのメカニズムは、RFC 822 [9]で使用されているものと同様に、散文と拡張バッカスナウアフォーム（BNF）の両方で説明されています。この仕様を理解するには、実装者は表記法に精通している必要があります。拡張BNFには、次の構成が含まれます。
name = definition The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.
name = definitionルールの名前は単に名前自体（ "<"や ">"で囲まれていない）であり、等号の "="文字によってその定義から分離されています。空白は、継続行のインデントが複数行にわたるルール定義を示すために使用されるという点でのみ重要です。 SP、LWS、HT、CRLF、DIGIT、ALPHAなどの特定の基本ルールは大文字です。山括弧は、ルール名の使用を識別しやすくするために、定義内で使用されます。
"literal" Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.
"literal"引用符はリテラルテキストを囲みます。特に明記しない限り、テキストでは大文字と小文字が区別されません。
rule1 | rule2 Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.
ルール1 | rule2棒（ "|"）で区切られた要素は代替です。たとえば、 "yes | no"はyesまたはnoを受け入れます。
(rule1 rule2) Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem".
（rule1 rule2）括弧で囲まれた要素は単一の要素として扱われます。したがって、「（elem（foo | bar）elem）」では、トークンシーケンス「elem foo elem」と「elem bar elem」が許可されます。
*rule The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two.
* rule要素の前の文字「*」は繰り返しを示します。完全な形式は "<n> * <m> element"であり、要素の少なくとも<n>および最大で<m>個の出現を示します。デフォルト値は0と無限大なので、「*（要素）」はゼロを含む任意の数を許可します。 「1 *要素」には少なくとも1つ必要です。 "1 * 2element"は1つまたは2つを許可します。
[rule] Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".
[ルール]角括弧はオプションの要素を囲みます。 「[foo bar]」は「* 1（foo bar）」と同等です。
N rule Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
Nルール特定の繰り返し：「<n>（要素）」は「<n> * <n>（要素）」と同等です。つまり、（要素）が正確に<n>回出現します。したがって、2DIGITは2桁の数字で、3ALPHAは3つのアルファベット文字の文字列です。
#rule A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by one or more commas (",") and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as ( *LWS element *( *LWS "," *LWS element )) can be shown as 1#element Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.
#rule要素のリストを定義するために、「*」と同様に「＃」という構成が定義されています。完全な形式は "<n>＃<m> element"であり、それぞれが1つ以上のコンマ（ "、"）およびオプションの線形空白（LWS）で区切られた、少なくとも<n>および多くとも<m>の要素を示します。これにより、通常のリスト形式が非常に簡単になります。 （* LWS element *（* LWS "、" * LWS element））などのルールは、1＃elementとして表示できます。この構成が使用される場合は、null要素が許可されますが、存在する要素の数には影響しません。つまり、「（要素）、、（要素）」は許可されますが、2つの要素としてのみカウントされます。したがって、少なくとも1つの要素が必要な場合、少なくとも1つのnull以外の要素が存在する必要があります。デフォルト値は0と無限大なので、「＃element」はゼロを含む任意の数を許可します。 「1＃element」には少なくとも1つ必要です。 「1＃2element」は1つまたは2つを許可します。
; comment A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications.
;コメントセミコロンは、ルールテキストの右側に少し離れており、コメントを開始して行の終わりまで続きます。これは、仕様と並行して役立つメモを含める簡単な方法です。
implied *LWS The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or
暗黙の* LWSこの仕様で記述されている文法は単語ベースです。特に明記されていない限り、フィールドの解釈を変更せずに、隣接する2つの単語（トークンまたは引用符付き文字列）の間、および隣接する単語と区切り文字の間に線形空白（LWS）を含めることができます。少なくとも1つの区切り文字（LWSおよび/または
separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.
セパレータ）は、2つのトークンの間に存在する必要があります（以下の「トークン」の定義の場合）。これらのトークンは、単一のトークンとして解釈されるためです。
The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986 [21].
この仕様全体で、次のルールを使用して、基本的な構文解析構文を説明しています。 US-ASCIIコード化文字セットは、ANSI X3.4-1986 [21]で定義されています。
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7.
HTTP / 1.1は、エンティティ本体を除くすべてのプロトコル要素の行末マーカーとしてシーケンスCR LFを定義しています（耐性のあるアプリケーションについては、付録19.3を参照してください）。エンティティ本体内の行末マーカーは、セクション3.7で説明するように、関連するメディアタイプによって定義されます。
CRLF = CR LF
CRLF = CR LF
HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.
継続行がスペースまたは水平タブで始まる場合、HTTP / 1.1ヘッダーフィールド値は複数行に折りたたむことができます。折りたたみを含むすべての線形空白は、SPと同じセマンティクスを持っています。受信者は、フィールド値を解釈したり、メッセージをダウンストリームに転送したりする前に、線形空白を単一のSPで置き換えてもよい（MAY）。
LWS = [CRLF] 1*( SP | HT )
The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 [22] only when encoded according to the rules of RFC 2047 [14].
TEXTルールは、メッセージパーサーによる解釈を目的としない説明的なフィールドの内容と値にのみ使用されます。 * TEXTの単語には、RFC 2047 [14]の規則に従ってエンコードされている場合にのみ、ISO-8859-1 [22]以外の文字セットの文字を含めることができます。
TEXT = <any OCTET except CTLs, but including LWS>
TEXT = <CTLを除く任意のOCTET、ただしLWSを含む>
A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value.
CRLFは、ヘッダーフィールドの継続の一部としてのみ、TEXTの定義で許可されます。 TEXT値を解釈する前に、フォールディングLWSが単一のSPに置き換えられることが期待されています。
Hexadecimal numeric characters are used in several protocol elements.
16進数の数字は、いくつかのプロトコル要素で使用されます。
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value (as defined in section 3.6).
多くのHTTP / 1.1ヘッダーフィールド値は、LWSまたは特殊文字で区切られた単語で構成されています。これらの特殊文字は、パラメータ値（セクション3.6で定義）内で使用される引用符付き文字列に含まれている必要があります。
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
コメントは、コメントテキストを括弧で囲むことにより、一部のHTTPヘッダーフィールドに含めることができます。コメントは、フィールド値の定義の一部として「コメント」を含むフィールドでのみ許可されます。他のすべてのフィールドでは、括弧はフィールド値の一部と見なされます。
comment = "(" *( ctext | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
A string of text is parsed as a single word if it is quoted using double-quote marks.
テキストの文字列は、二重引用符で囲まれている場合、1つの単語として解析されます。
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>
The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs.
バックスラッシュ文字（ "\"）は、引用文字列およびコメント構造内でのみ、単一文字の引用メカニズムとして使用できます。
quoted-pair = "\" CHAR
quoted-pair = "\" CHAR
3 Protocol Parameters
3プロトコルパラメータ
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed. See RFC 2145 [36] for a fuller explanation.
HTTPは "<major>。<minor>"番号付けスキームを使用して、プロトコルのバージョンを示します。プロトコルのバージョン管理ポリシーは、送信者がメッセージの形式と、その通信を介して取得される機能ではなく、HTTP通信をさらに理解するための容量を示すことを目的としています。通信動作に影響を与えない、または拡張可能なフィールド値のみを追加するメッセージコンポーネントを追加しても、バージョン番号は変更されません。 <マイナー>番号は、プロトコルに加えられた変更により、一般的なメッセージ解析アルゴリズムを変更しない機能が追加されますが、メッセージセマンティクスに追加され、送信者の追加機能を意味する場合に増加します。 <major>番号は、プロトコル内のメッセージのフォーマットが変更されると増加します。詳細については、RFC 2145 [36]を参照してください。
The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message.
HTTPメッセージのバージョンは、メッセージの最初の行のHTTP-Versionフィールドで示されます。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Note that the major and minor numbers MUST be treated as separate integers and that each MAY be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT be sent.
メジャー番号とマイナー番号は別々の整数として扱われる必要があり、それぞれが1桁より大きくなる場合があることに注意してください。したがって、HTTP / 2.4はHTTP / 2.13よりも低いバージョンであり、HTTP / 2.13はHTTP / 12.3よりも低いバージョンです。先頭のゼロは受信者によって無視されなければならず、送信されてはなりません。
An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this specification SHOULD use an HTTP-Version of "HTTP/1.1" in their messages, and MUST do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, see RFC 2145 [36].
「HTTP / 1.1」のHTTPバージョンを含む要求または応答メッセージを送信するアプリケーションは、少なくともこの条件に条件付きで準拠している必要があります。この仕様に少なくとも条件付きで準拠しているアプリケーションは、メッセージ内で「HTTP / 1.1」のHTTP-Versionを使用する必要があり（SHOULD）、HTTP / 1.0と互換性のないメッセージに対しては必ず使用する必要があります。特定のHTTP-Version値を送信するタイミングの詳細については、RFC 2145 [36]を参照してください。
The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.
アプリケーションのHTTPバージョンは、アプリケーションが少なくとも条件付きで準拠している最も高いHTTPバージョンです。
Proxy and gateway applications need to be careful when forwarding messages in protocol versions different from that of the application. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway MUST NOT send a message with a version indicator which is greater than its actual version. If a higher version request is received, the proxy/gateway MUST either downgrade the request version, or respond with an error, or switch to tunnel behavior.
プロキシおよびゲートウェイアプリケーションは、アプリケーションとは異なるプロトコルバージョンでメッセージを転送する場合は注意が必要です。プロトコルバージョンは送信者のプロトコル機能を示すため、プロキシ/ゲートウェイは、実際のバージョンよりも大きいバージョンインジケータを含むメッセージを送信してはなりません（MUST NOT）。より高いバージョンのリクエストを受信した場合、プロキシ/ゲートウェイは、リクエストのバージョンをダウングレードするか、エラーで応答するか、トンネルの動作に切り替える必要があります。
Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068[33], caching proxies MUST, gateways MAY, and tunnels MUST NOT upgrade the request to the highest version they support. The proxy/gateway's response to that request MUST be in the same major version as the request.
RFC 2068 [33]の公開以降に発見されたHTTP / 1.0プロキシとの相互運用性の問題により、キャッシングプロキシは、MAY、ゲートウェイが可能であり、トンネルは、サポートする最高バージョンにリクエストをアップグレードしてはなりません（MUST NOT）。そのリクエストに対するプロキシ/ゲートウェイの応答は、リクエストと同じメジャーバージョンである必要があります。
Note: Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.
注：HTTPのバージョン間の変換には、関連するバージョンで必要または禁止されているヘッダーフィールドの変更が含まれる場合があります。
URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers [3], and finally the combination of Uniform Resource Locators (URL) [4] and Names (URN) [20]. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location, or any other characteristic--a resource.
URIは、WWWアドレス、Universal Document Identifiers、Universal Resource Identifiers [3]、そして最後にUniform Resource Locator（URL）[4]とNames（URN）[20]の多くの名前で知られています。 HTTPに関する限り、Uniform Resource Identifierは、名前、場所、またはその他の特性を介してリソースを識別する、単純にフォーマットされた文字列です。
URIs in HTTP can be represented in absolute form or relative to some known base URI [11], depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", and "authority" from that specification.
HTTPのURIは、その使用状況に応じて、絶対形式または既知のベースURI [11]を基準にして表すことができます。 2つの形式は、絶対URIが常にスキーム名で始まり、その後にコロンが続くという事実によって区別されます。 URLの構文とセマンティクスの詳細については、「Uniform Resource Identifiers（URI）：Generic Syntax and Semantics」、RFC 2396 [42]（RFC 1738 [4]およびRFC 1808 [11]に代わるもの）を参照してください。この仕様は、「URI参照」、「絶対URI」、「相対URI」、「ポート」、「ホスト」、「abs_path」、「rel_path」、および「権限」の定義をその仕様から採用しています。
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).
HTTPプロトコルでは、URIの長さに事前の制限はありません。サーバーは、サービスを提供するすべてのリソースのURIを処理できなければならず（MUST）、そのようなURIを生成できるGETベースのフォームを提供する場合は、無制限の長さのURIを処理できる必要があります（SHOULD）。 URIがサーバーが処理できる長さより長い場合、サーバーは414（Request-URI Too Long）ステータスを返す必要があります（セクション10.4.15を参照）。
Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
注：サーバーは、255バイトを超えるURIの長さに依存することに注意する必要があります。これは、一部の古いクライアントまたはプロキシの実装がこれらの長さを適切にサポートしていない場合があるためです。
The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs.
「http」スキームは、HTTPプロトコルを介してネットワークリソースを見つけるために使用されます。このセクションでは、http URLのスキーマ固有の構文とセマンティクスを定義します。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (section 5.1.2). The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2). If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy MUST NOT change the host name.
ポートが空または指定されていない場合は、ポート80が想定されます。意味は、識別されたリソースがそのホストのそのポートでTCP接続をリッスンしているサーバーにあり、リソースのRequest-URIがabs_path（セクション5.1.2）であることです。 URLでのIPアドレスの使用は、可能な限り避けてください（RFC 1900 [24]を参照）。 abs_pathがURLに存在しない場合、リソースのRequest-URIとして使用する場合は「/」として指定する必要があります（セクション5.1.2）。プロキシが完全修飾ドメイン名ではないホスト名を受け取った場合、受け取ったホスト名にそのドメインを追加してもよい（MAY）。プロキシが完全修飾ドメイン名を受け取った場合、プロキシはホスト名を変更してはなりません（MUST NOT）。
When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
2つのURIを比較して一致するかどうかを判断する場合、クライアントはURI全体の大文字と小文字を区別するオクテットごとの比較を使用する必要があります（以下を除く）。
- A port that is empty or not given is equivalent to the default port for that URI-reference;
- 空または指定されていないポートは、そのURI参照のデフォルトポートと同等です。
- Comparisons of host names MUST be case-insensitive;
- ホスト名の比較では、大文字と小文字を区別しないでください。
- Comparisons of scheme names MUST be case-insensitive;
- スキーム名の比較では大文字と小文字を区別する必要があります。
- An empty abs_path is equivalent to an abs_path of "/".
- 空のabs_pathは、「/」のabs_pathと同等です。
Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
「予約済み」および「安全でない」セット（RFC 2396 [42]を参照）以外の文字は、「 "％" HEX HEX」エンコーディングと同等です。
For example, the following three URIs are equivalent:
たとえば、次の3つのURIは同等です。
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
HTTP applications have historically allowed three different formats for the representation of date/time stamps:
HTTPアプリケーションはこれまで、日付/時刻スタンプの表現に3つの異なる形式を許可してきました。
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 [8] (an update to RFC 822 [9]). The second format is in common use, but is based on the obsolete RFC 850 [12] date format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value MUST accept all three formats (for compatibility with HTTP/1.0), though they MUST only generate the RFC 1123 format for representing HTTP-date values in header fields. See section 19.3 for further information.
最初の形式はインターネット標準として推奨され、RFC 1123 [8]（RFC 822 [9]の更新版）で定義されたものの固定長サブセットを表します。 2番目の形式は一般的に使用されていますが、廃止されたRFC 850 [12]日付形式に基づいており、4桁の年がありません。日付値を解析するHTTP / 1.1クライアントとサーバーは、HTTP / 1.0との互換性のために3つの形式すべてを受け入れる必要がありますが、ヘッダーフィールドでHTTP日付値を表すためのRFC 1123形式のみを生成する必要があります。詳細については、セクション19.3を参照してください。
Note: Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications, as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.
注：日付値の受信者は、プロキシ/ゲートウェイ経由でSMTPまたはNNTPにメッセージを取得または投稿する場合によくあるように、HTTP以外のアプリケーションから送信された可能性のある日付値を受け入れることを強く推奨されます。
All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for time zone, and MUST be assumed when reading the asctime format. HTTP-date is case sensitive and MUST NOT include additional LWS beyond that specifically included as SP in the grammar.
すべてのHTTP日付/タイムスタンプは、例外なく、グリニッジ標準時（GMT）で表現する必要があります。 HTTPの目的では、GMTはUTC（協定世界時）とまったく同じです。これは、タイムゾーンの3文字の省略形として「GMT」を含めることによって最初の2つの形式で示され、asctime形式を読み取るときに想定する必要があります。 HTTP-dateは大文字と小文字を区別し、文法にSPとして具体的に含まれているものを超える追加のLWSを含めてはなりません。
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
Note: HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers are not required to use these formats for user presentation, request logging, etc.
注：日付/タイムスタンプ形式のHTTP要件は、プロトコルストリーム内での使用にのみ適用されます。クライアントおよびサーバーは、ユーザーの表示、要求のロギングなどにこれらの形式を使用する必要はありません。
Some HTTP header fields allow a time value to be specified as an integer number of seconds, represented in decimal, after the time that the message was received.
一部のHTTPヘッダーフィールドでは、メッセージが受信された時刻から10進数で表される秒数の整数として時刻値を指定できます。
delta-seconds = 1*DIGIT
デルタ秒= 1 * DIGIT
HTTP uses the same definition of the term "character set" as that described for MIME: The term "character set" is used in this document to refer to a method used with one or more tables to convert a sequence of octets into a sequence of characters. Note that unconditional conversion in the other direction is not required, in that not all characters may be available in a given character set and a character set may provide more than one sequence of octets to represent a particular character. This definition is intended to allow various kinds of character encoding, from simple single-table mappings such as US-ASCII to complex table switching methods such as those that use ISO-2022's techniques. However, the definition associated with a MIME character set name MUST fully specify the mapping to be performed from octets to characters. In particular, use of external profiling information to determine the exact mapping is not permitted.
HTTPは、MIMEについて説明したものと同じ「文字セット」という用語の定義を使用します。このドキュメントでは、「文字セット」という用語は、1つまたは複数のテーブルで使用され、オクテットのシーケンスをシーケンスに変換する方法を指します。文字。特定の文字セットですべての文字を使用できるわけではなく、文字セットが特定の文字を表すオクテットの複数のシーケンスを提供する場合があるため、逆方向の無条件変換は必要ありません。この定義は、US-ASCIIなどの単純な単一テーブルマッピングからISO-2022の手法を使用するような複雑なテーブルスイッチング方法まで、さまざまな種類の文字エンコーディングを可能にすることを目的としています。ただし、MIME文字セット名に関連付けられた定義では、オクテットから文字へのマッピングを完全に指定する必要があります。特に、正確なマッピングを判別するための外部プロファイリング情報の使用は許可されていません。
Note: This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME share the same registry, it is important that the terminology also be shared.
注：この「文字セット」という用語の使用法は、より一般的には「文字エンコーディング」と呼ばれています。ただし、HTTPとMIMEは同じレジストリを共有するため、用語も共有することが重要です。
HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character Set registry [19].
HTTP文字セットは、大文字と小文字を区別しないトークンによって識別されます。トークンの完全なセットは、IANA文字セットレジストリ[19]によって定義されています。
charset = token
文字セット=トークン
Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA Character Set registry [19] MUST represent the character set defined by that registry. Applications SHOULD limit their use of character sets to those defined by the IANA registry.
HTTPでは任意のトークンを文字セット値として使用できますが、IANA文字セットレジストリ[19]内に事前定義された値を持つトークンは、そのレジストリで定義された文字セットを表す必要があります。アプリケーションは、文字セットの使用をIANAレジストリで定義されているものに制限する必要があります（SHOULD）。
Implementors should be aware of IETF character set requirements [38] [41].
実装者は、IETF文字セット要件[38] [41]に注意する必要があります。
Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should guess." Senders wishing to defeat this behavior MAY include a charset parameter even when the charset is ISO-8859-1 and SHOULD do so when it is known that it will not confuse the recipient.
一部のHTTP / 1.0ソフトウェアは、charsetパラメータのないContent-Typeヘッダーを誤って解釈し、「受信者が推測する必要がある」ことを意味しています。この動作を無効にしたい送信者は、文字セットがISO-8859-1の場合でも文字セットパラメータを含めることができ（MAY）、受信者を混乱させないことがわかっている場合は含める必要があります（SHOULD）。
Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients MUST respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset MUST use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially displaying a document. See section 3.7.1.
残念ながら、一部の古いHTTP / 1.0クライアントは明示的な文字セットパラメータを適切に処理しませんでした。 HTTP / 1.1受信者は、送信者から提供された文字セットラベルを尊重する必要があります。また、文字セットを「推測」する機能を持つユーザーエージェントは、ドキュメントを最初に表示するときに、受信者の設定ではなく、その文字セットをサポートしている場合は、コンテンツタイプフィールドの文字セットを使用する必要があります。セクション3.7.1を参照してください。
Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only decoded by the recipient.
コンテンツコーディング値は、エンティティに適用された、またはエンティティに適用できるエンコード変換を示します。コンテンツコーディングは主に、基になるメディアタイプのIDを失うことなく、また情報を失うことなく、ドキュメントを圧縮またはその他の方法で有効に変換できるようにするために使用されます。多くの場合、エンティティはコード化された形式で保存され、直接送信され、受信者のみがデコードします。
content-coding = token
content-coding =トークン
All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (section 14.3) and Content-Encoding (section 14.11) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding mechanism will be required to remove the encoding.
content-codingの値はすべて大文字と小文字が区別されません。 HTTP / 1.1は、Accept-Encoding（セクション14.3）およびContent-Encoding（セクション14.11）ヘッダーフィールドでcontent-coding値を使用します。値はコンテンツコーディングを示しますが、より重要なのは、エンコーディングを削除するために必要なデコードメカニズムを示すことです。
The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry contains the following tokens:
Internet Assigned Numbers Authority（IANA）は、コンテンツコーディング値トークンのレジストリとして機能します。最初、レジストリには次のトークンが含まれています。
gzip An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
gzip RFC 1952 [25]で説明されているように、ファイル圧縮プログラム "gzip"（GNU zip）によって生成されるエンコード形式。このフォーマットは、32ビットCRCを備えたLempel-Zivコーディング（LZ77）です。
compress The encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch coding (LZW).
一般的なUNIXファイル圧縮プログラム「compress」によって生成されるエンコード形式。このフォーマットは、適応型Lempel-Ziv-Welchコーディング（LZW）です。
Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. Their use here is representative of historical practice, not good design. For compatibility with previous implementations of HTTP, applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
エンコーディング形式の識別にプログラム名を使用することは望ましくないため、将来のエンコーディングでは推奨されません。ここでのそれらの使用は歴史的な慣行の代表であり、良いデザインではありません。 HTTPの以前の実装との互換性のために、アプリケーションは「x-gzip」および「x-compress」をそれぞれ「gzip」および「compress」と同等であると見なすべきです。
deflate The "zlib" format defined in RFC 1950 [31] in combination with the "deflate" compression mechanism described in RFC 1951 [29].
deflate RFC 1951 [29]で説明されている「deflate」圧縮メカニズムと組み合わせて、RFC 1950 [31]で定義された「zlib」フォーマット。
identity The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding header, and SHOULD NOT be used in the Content-Encoding header.
identityデフォルト（アイデンティティ）エンコーディング。まったく変換を使用しません。このcontent-codingはAccept-Encodingヘッダーでのみ使用され、Content-Encodingヘッダーでは使用しないでください。
New content-coding value tokens SHOULD be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed to implement a new value SHOULD be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in this section.
新しいcontent-coding値トークンを登録する必要があります。クライアントとサーバー間の相互運用性を可能にするために、新しい値を実装するために必要なコンテンツコーディングアルゴリズムの仕様は公に利用可能であり、独立した実装に適切である必要があり、このセクションで定義されたコンテンツコーディングの目的に適合します。
Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding is a property of the message, not of the original entity.
transfer-coding値は、ネットワークを介した「安全なトランスポート」を確実にするために、エンティティ本体に適用されている、適用できる、または適用する必要があるエンコーディング変換を示すために使用されます。これは、転送コーディングが元のエンティティではなくメッセージのプロパティであるという点で、コンテンツコーディングとは異なります。
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )
Parameters are in the form of attribute/value pairs.
パラメータは、属性/値のペアの形式です。
parameter = attribute "=" value attribute = token value = token | quoted-string
パラメータ=属性 "="値属性=トークン値=トークン|引用文字列
All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (section 14.39) and in the Transfer-Encoding header field (section 14.41).
すべてのtransfer-coding値は大文字と小文字を区別しません。 HTTP / 1.1は、TEヘッダーフィールド（セクション14.39）およびTransfer-Encodingヘッダーフィールド（セクション14.41）でtransfer-coding値を使用します。
Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer-coding is used, it MUST be the last transfer-coding applied to the message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message (section 4.4).
転送コーディングがメッセージ本文に適用される場合は常に、接続を閉じることによってメッセージが終了しない限り、転送コーディングのセットに「チャンク」が含まれている必要があります。 「チャンクされた」転送コーディングが使用される場合、それはメッセージ本文に適用される最後の転送コーディングでなければなりません。 「チャンクされた」転送コーディングは、メッセージ本文に複数回適用してはなりません（MUST NOT）。これらのルールにより、受信者はメッセージの転送長を決定できます（セクション4.4）。
Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME [7], which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty in determining the exact body length (section 7.2.2), or the desire to encrypt data over a shared transport.
転送コーディングは、MIME [7]のContent-Transfer-Encoding値に類似しており、7ビットのトランスポートサービスを介してバイナリデータを安全にトランスポートできるように設計されています。ただし、安全な転送では、8ビットのクリーンな転送プロトコルに対して別の焦点があります。 HTTPでは、メッセージ本文の安全でない唯一の特徴は、正確な本文の長さ（セクション7.2.2）を決定するのが難しいこと、または共有トランスポートを介してデータを暗号化することです。
The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).
Internet Assigned Numbers Authority（IANA）は、転送コーディング値トークンのレジストリとして機能します。最初、レジストリには次のトークンが含まれています：「チャンク」（セクション3.6.1）、「アイデンティティ」（セクション3.6.2）、「gzip」（セクション3.5）、「圧縮」（セクション3.5）、および「収縮」（セクション3.5）。
New transfer-coding value tokens SHOULD be registered in the same way as new content-coding value tokens (section 3.5).
新しいtransfer-coding値トークンは、新しいcontent-coding値トークンと同じ方法で登録する必要があります（セクション3.5）。
A server which receives an entity-body with a transfer-coding it does not understand SHOULD return 501 (Unimplemented), and close the connection. A server MUST NOT send transfer-codings to an HTTP/1.0 client.
理解できないtransfer-codingのエンティティ本体を受信するサーバーは、501（実装されていない）を返し、接続を閉じます。サーバーはHTTP / 1.0クライアントに転送コーディングを送信してはいけません（MUST NOT）。
The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer containing entity-header fields. This allows dynamically produced content to be transferred along with the information necessary for the recipient to verify that it has received the full message.
チャンクエンコーディングでは、メッセージの本文を変更して、それぞれに独自のサイズインジケーターが付いた一連のチャンクとして転送し、その後にエンティティヘッダーフィールドを含むオプションのトレーラーを追加します。これにより、動的に作成されたコンテンツを、受信者が完全なメッセージを受信したことを確認するために必要な情報とともに転送できます。
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk = chunk-size [chunk-extension] CRLF chunk-data CRLF chunk-size = 1 * HEX last-chunk = 1 *（ "0"）[chunk-extension] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
The chunk-size field is a string of hex digits indicating the size of the chunk. The chunked encoding is ended by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
チャンクサイズフィールドは、チャンクのサイズを示す16進数の文字列です。チャンクエンコーディングは、サイズがゼロのチャンクで終了し、その後にトレーラーが続き、空の行で終了します。
The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field can be used to indicate which header fields are included in a trailer (see section 14.40).
トレーラーにより、送信者はメッセージの最後に追加のHTTPヘッダーフィールドを含めることができます。 Trailerヘッダーフィールドは、どのヘッダーフィールドがトレーラーに含まれるかを示すために使用できます（セクション14.40を参照）。
A server using chunked transfer-coding in a response MUST NOT use the trailer for any header fields unless at least one of the following is true:
応答でチャンク転送コーディングを使用するサーバーは、次の少なくとも1つが当てはまらない限り、ヘッダーフィールドのトレーラーを使用してはなりません（MUST NOT）。
a)the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as described in section 14.39; or,
a）セクション14.39で説明されているように、「トレーラー」が応答の転送コーディングで受け入れられることを示すTEヘッダーフィールドが含まれている要求。または、
b)the server is the origin server for the response, the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable to the origin server) without receiving this metadata. In other words, the origin server is willing to accept the possibility that the trailer fields might be silently discarded along the path to the client.
b）サーバーは応答の元のサーバーであり、トレーラーフィールドはすべてオプションのメタデータで構成され、受信者はこのメタデータを受信せずにメッセージを（元のサーバーに受け入れられる方法で）使用できます。言い換えれば、オリジンサーバーは、トレーラーフィールドがクライアントへのパスに沿って静かに破棄される可能性を受け入れる用意があります。
This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly infinite buffer on the proxy.
この要件により、メッセージがHTTP / 1.1（またはそれ以降）のプロキシによって受信され、HTTP / 1.0受信者に転送されるときの相互運用性の障害が防止されます。これにより、プロトコルに準拠するためにプロキシ上に無限のバッファが必要になる状況が回避されます。
An example process for decoding a Chunked-Body is presented in appendix 19.4.6.
チャンクボディをデコードするプロセスの例を付録19.4.6に示します。
All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding, and MUST ignore chunk-extension extensions they do not understand.
すべてのHTTP / 1.1アプリケーションは、「チャンクされた」転送コーディングを受信してデコードできなければならず、理解できないチャンク拡張拡張を無視しなければなりません（MUST）。
HTTP uses Internet Media Types [17] in the Content-Type (section 14.17) and Accept (section 14.1) header fields in order to provide open and extensible data typing and type negotiation.
HTTPは、Content-Type（セクション14.17）およびAccept（セクション14.1）ヘッダーフィールドでインターネットメディアタイプ[17]を使用して、オープンで拡張可能なデータタイプとタイプネゴシエーションを提供します。
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
Parameters MAY follow the type/subtype in the form of attribute/value pairs (as defined in section 3.6).
パラメータは、（セクション3.6で定義されているように）属性/値のペアの形式でタイプ/サブタイプに従うことができます（MAY）。
The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. Linear white space (LWS) MUST NOT be used between the type and subtype, nor between an attribute and its value. 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.
タイプ、サブタイプ、およびパラメーターの属性名では、大文字と小文字が区別されません。パラメータ名のセマンティクスに応じて、パラメータ値は大文字と小文字を区別する場合としない場合があります。タイプとサブタイプの間、または属性とその値の間では線形空白（LWS）を使用してはなりません（MUST NOT）。メディアタイプレジストリ内の定義によっては、パラメータの有無がメディアタイプの処理にとって重要になる場合があります。
Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications, implementations SHOULD only use media type parameters when they are required by that type/subtype definition.
一部の古いHTTPアプリケーションはメディアタイプパラメータを認識しないことに注意してください。古いHTTPアプリケーションにデータを送信する場合、実装は、そのタイプ/サブタイプの定義で必要な場合にのみメディアタイプパラメータを使用する必要があります（SHOULD）。
Media-type values are registered with the Internet Assigned Number Authority (IANA [19]). The media type registration process is outlined in RFC 1590 [17]. Use of non-registered media types is discouraged.
メディアタイプの値は、Internet Assigned Number Authority（IANA [19]）に登録されています。メディアタイプ登録プロセスは、RFC 1590 [17]で概説されています。登録されていないメディアタイプの使用はお勧めしません。
Internet media types are registered with a canonical form. An entity-body transferred via HTTP messages MUST be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph.
インターネットメディアタイプは、正規の形式で登録されます。 HTTPメッセージを介して転送されるエンティティ本体は、次の段落で定義されているように、「テキスト」タイプを除いて、その送信前に適切な正規形式で表現する必要があります。
When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if the text is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body; a bare CR or LF MUST NOT be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
正規形式の場合、「テキスト」タイプのメディアサブタイプはCRLFをテキストの改行として使用します。 HTTPはこの要件を緩和し、エンティティボディ全体に対して一貫して行われる場合、改行を表すプレーンなCRまたはLFのみのテキストメディアの転送を許可します。 HTTPアプリケーションは、HTTP経由で受信したテキストメディアの改行を表すものとして、CRLF、ベアCR、およびベアLFを受け入れる必要があります。さらに、いくつかのマルチバイト文字セットの場合のように、テキストがCRとLFにそれぞれオクテット13と10を使用しない文字セットで表されている場合、HTTPは、それによって定義されるオクテットシーケンスの使用を許可します。改行のCRおよびLFに相当する文字セット。改行に関するこの柔軟性は、エンティティ本体のテキストメディアにのみ適用されます。すべてのHTTP制御構造（ヘッダーフィールドやマルチパート境界など）内のCRLFをベアCRまたはLFで置き換えてはなりません（MUST NOT）。
If an entity-body is encoded with a content-coding, the underlying data MUST be in a form defined above prior to being encoded.
entity-bodyがcontent-codingでエンコードされている場合、基礎となるデータは、エンコードされる前に上で定義された形式でなければなりません。
The "charset" parameter is used with some media types to define the character set (section 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value. See section 3.4.1 for compatibility problems.
「charset」パラメータは、一部のメディアタイプでデータの文字セット（セクション3.4）を定義するために使用されます。送信者から明示的な文字セットパラメータが提供されない場合、「テキスト」タイプのメディアサブタイプは、HTTP経由で受信したときに「ISO-8859-1」のデフォルト文字セット値を持つように定義されます。 「ISO-8859-1」またはそのサブセット以外の文字セットのデータは、適切な文字セット値でラベル付けする必要があります。互換性の問題については、セクション3.4.1を参照してください。
MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All multipart types share a common syntax, as defined in section 5.1.1 of RFC 2046
MIMEは、多数の「マルチパート」タイプを提供します-1つのメッセージ本文内の1つ以上のエンティティのカプセル化。 RFC 2046のセクション5.1.1で定義されているように、すべてのマルチパートタイプは共通の構文を共有します
[40], and MUST include a boundary parameter as part of the media type value. The message body is itself a protocol element and MUST therefore use only CRLF to represent line breaks between body-parts. Unlike in RFC 2046, the epilogue of any multipart message MUST be empty; HTTP applications MUST NOT transmit the epilogue (even if the original multipart contains an epilogue). These restrictions exist in order to preserve the self-delimiting nature of a multipart message-body, wherein the "end" of the message-body is indicated by the ending multipart boundary.
[40]、およびメディアタイプ値の一部として境界パラメーターを含める必要があります。メッセージ本文自体はプロトコル要素であるため、CRLFのみを使用して、本文部分間の改行を表す必要があります。 RFC 2046とは異なり、マルチパートメッセージのエピローグは空である必要があります。 HTTPアプリケーションは、エピローグを送信してはなりません（元のマルチパートにエピローグが含まれている場合でも）。これらの制限は、マルチパートメッセージボディの自己区切りの性質を維持するために存在します。メッセージボディの「終了」は、マルチパート境界の終了によって示されます。
In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception is the "multipart/byteranges" type (appendix 19.2) when it appears in a 206 (Partial Content) response, which will be interpreted by some HTTP caching mechanisms as described in sections 13.5.4 and 14.16. In all other cases, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics.
一般に、HTTPはマルチパートメッセージ本文を他のメディアタイプとまったく同じように、厳密にはペイロードとして扱います。 1つの例外は、「multipart / byteranges」タイプ（付録19.2）であり、206（Partial Content）応答に表示される場合、セクション13.5.4および14.16で説明されているように、一部のHTTPキャッシュメカニズムによって解釈されます。他のすべてのケースでは、HTTPユーザーエージェントは、マルチパートタイプを受信したときのMIMEユーザーエージェントと同じまたは同様の動作に従う必要があります（SHOULD）。マルチパートメッセージボディの各ボディパート内のMIMEヘッダーフィールドは、MIMEセマンティクスで定義されているものを超えて、HTTPに対して重要ではありません。
In general, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. If an application receives an unrecognized multipart subtype, the application MUST treat it as being equivalent to "multipart/mixed".
一般に、HTTPユーザーエージェントは、MIMEユーザーエージェントがマルチパートタイプを受信したときと同じまたは同様の動作に従う必要があります（SHOULD）。アプリケーションが認識されないマルチパートサブタイプを受信した場合、アプリケーションはそれを「マルチパート/混合」と同等のものとして扱う必要があります。
Note: The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request method, as described in RFC 1867 [15].
注：「multipart / form-data」タイプは、RFC 1867 [15]で説明されているように、POSTリクエストメソッドによる処理に適したフォームデータを伝送するために明確に定義されています。
Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields using product tokens also allow sub-products which form a significant part of the application to be listed, separated by white space. By convention, the products are listed in order of their significance for identifying the application.
製品トークンを使用して、通信アプリケーションがソフトウェア名とバージョンによって自分自身を識別できるようにします。製品トークンを使用するほとんどのフィールドでは、アプリケーションの重要な部分を形成するサブ製品を空白で区切ってリストすることもできます。慣例により、製品はアプリケーションを識別するために重要度の高い順にリストされています。
product = token ["/" product-version] product-version = token
製品=トークン["/"製品バージョン]製品バージョン=トークン
Examples:
例：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Product tokens SHOULD be short and to the point. They MUST NOT be used for advertising or other non-essential information. Although any token character MAY appear in a product-version, this token SHOULD only be used for a version identifier (i.e., successive versions of the same product SHOULD only differ in the product-version portion of the product value).
製品トークンは短く、要点があります。広告やその他の重要でない情報に使用することはできません。トークン文字は製品バージョンに表示される場合がありますが、このトークンはバージョン識別子にのみ使用する必要があります（つまり、同じ製品の連続するバージョンは、製品値の製品バージョン部分のみが異なる必要があります。）
HTTP content negotiation (section 12) uses short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has a quality value of 0, then content with this parameter is `not acceptable' for the client. HTTP/1.1 applications MUST NOT generate more than three digits after the decimal point. User configuration of these values SHOULD also be limited in this fashion.
HTTPコンテンツネゴシエーション（セクション12）では、短い「浮動小数点」数を使用して、さまざまなネゴシエート可能なパラメーターの相対的な重要度（「重み」）を示します。重みは0から1の範囲の実数に正規化されます。0は最小値で、1は最大値です。パラメータの品質値が0の場合、このパラメータのコンテンツはクライアントには「受け入れられません」。 HTTP / 1.1アプリケーションは、小数点以下4桁を生成してはなりません。これらの値のユーザー構成も、この方法で制限する必要があります。
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
"Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.
「品質値」は、望ましい品質の相対的な低下を表すに過ぎないため、誤称です。
A language tag 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. HTTP uses language tags within the Accept-Language and Content-Language fields.
言語タグは、他の人間と情報をやり取りするために人間が話したり、書いたり、その他の方法で伝えたりする自然言語を識別します。コンピュータ言語は明示的に除外されています。 HTTPはAccept-LanguageおよびContent-Languageフィールド内の言語タグを使用します。
The syntax and registry of HTTP language tags is the same as that defined by RFC 1766 [1]. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags:
HTTP言語タグの構文とレジストリは、RFC 1766 [1]で定義されているものと同じです。要約すると、言語タグは1つ以上の部分で構成されています。主言語タグと、場合によっては空の一連のサブタグ：
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
White space is not allowed within the tag and all tags are case-insensitive. The name space of language tags is administered by the IANA. Example tags include:
タグ内での空白の使用は許可されておらず、すべてのタグで大文字と小文字が区別されません。言語タグの名前空間は、IANAによって管理されます。タグの例は次のとおりです。
en, en-US, en-cockney, i-cherokee, x-pig-latin
en、en-US、en-cockney、i-cherokee、x-pig-latin
where any two-letter primary-tag is an ISO-639 language abbreviation and any two-letter initial subtag is an ISO-3166 country code. (The last three tags above are not registered tags; all but the last are examples of tags which could be registered in future.)
ここで、2文字のプライマリタグはISO-639言語の省略形で、2文字の最初のサブタグはISO-3166国コードです。 （上記の最後の3つのタグは登録されたタグではありません。最後のタグを除くすべては、将来登録される可能性のあるタグの例です。）
Entity tags are used for comparing two or more entities from the same requested resource. HTTP/1.1 uses entity tags in the ETag (section 14.19), If-Match (section 14.24), If-None-Match (section 14.26), and If-Range (section 14.27) header fields. The definition of how they are used and compared as cache validators is in section 13.3.3. An entity tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
エンティティタグは、同じリクエストされたリソースからの2つ以上のエンティティを比較するために使用されます。 HTTP / 1.1は、ETag（セクション14.19）、If-Match（セクション14.24）、If-None-Match（セクション14.26）、およびIf-Range（セクション14.27）ヘッダーフィールドでエンティティタグを使用します。キャッシュバリデーターとして使用および比較する方法の定義は、セクション13.3.3にあります。エンティティタグは、不透明の引用符付き文字列で構成され、弱点インジケータが前に付いている可能性があります。
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
A "strong entity tag" MAY be shared by two entities of a resource only if they are equivalent by octet equality.
「強力なエンティティタグ」は、オクテットの同等性によって同等である場合にのみ、リソースの2つのエンティティによって共有される場合があります。
A "weak entity tag," indicated by the "W/" prefix, MAY be shared by two entities of a resource only if the entities are equivalent and could be substituted for each other with no significant change in semantics. A weak entity tag can only be used for weak comparison.
接頭辞「W /」で示される「弱いエンティティタグ」は、エンティティが同等で、セマンティクスを大幅に変更することなく相互に置き換えることができる場合にのみ、リソースの2つのエンティティで共有できます。弱いエンティティタグは、弱い比較にのみ使用できます。
An entity tag MUST be unique across all versions of all entities associated with a particular resource. A given entity tag value MAY be used for entities obtained by requests on different URIs. The use of the same entity tag value in conjunction with entities obtained by requests on different URIs does not imply the equivalence of those entities.
エンティティタグは、特定のリソースに関連付けられているすべてのエンティティのすべてのバージョンで一意である必要があります。特定のエンティティタグの値は、さまざまなURIでのリクエストによって取得されたエンティティに使用される場合があります。異なるURIでのリクエストによって取得されたエンティティと同じエンティティタグ値を使用しても、それらのエンティティが同等であるとは限りません。
HTTP/1.1 allows a client to request that only part (a range of) the response entity be included within the response. HTTP/1.1 uses range units in the Range (section 14.35) and Content-Range (section 14.16) header fields. An entity can be broken down into subranges according to various structural units.
HTTP / 1.1を使用すると、クライアントは応答エンティティの一部（範囲）のみを応答に含めるように要求できます。 HTTP / 1.1は、範囲（セクション14.35）およびコンテンツ範囲（セクション14.16）ヘッダーフィールドで範囲単位を使用します。エンティティは、さまざまな構造単位に従ってサブ範囲に分割できます。
range-unit = bytes-unit | other-range-unit bytes-unit = "bytes" other-range-unit = token
範囲単位=バイト単位| other-range-unit bytes-unit = "bytes" other-range-unit = token
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units.
HTTP / 1.1で定義されている唯一の範囲単位は「バイト」です。 HTTP / 1.1実装は、他の単位を使用して指定された範囲を無視してもよい（MAY）。
HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges.
HTTP / 1.1は、範囲の知識に依存しないアプリケーションの実装を可能にするように設計されています。
4 HTTP Message
4 HTTPメッセージ
HTTP messages consist of requests from client to server and responses from server to client.
HTTPメッセージは、クライアントからサーバーへの要求とサーバーからクライアントへの応答で構成されます。
HTTP-message = Request | Response ; HTTP/1.1 messages
Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body.
要求（セクション5）および応答（セクション6）メッセージは、エンティティ（メッセージのペイロード）の転送にRFC 822 [9]の一般的なメッセージ形式を使用します。どちらのタイプのメッセージも、開始行、0個以上のヘッダーフィールド（「ヘッダー」とも呼ばれる）、ヘッダーフィールドの終わりを示す空行（CRLFの前に何もない行）、および場合によってはメッセージ本文。
generic-message = start-line *(message-header CRLF) CRLF [ message-body ] start-line = Request-Line | Status-Line
generic-message = start-line *（message-header CRLF）CRLF [message-body] start-line = Request-Line |ステータスライン
In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.
堅牢性のために、サーバーは、リクエストラインが期待される場所で受信された空のラインを無視する必要があります。つまり、サーバーがメッセージの先頭でプロトコルストリームを読み取り、最初にCRLFを受信した場合、CRLFを無視する必要があります。
Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF.
特定のバグのあるHTTP / 1.0クライアント実装は、POST要求の後に追加のCRLFを生成します。 BNFによって明示的に禁止されていることを述べるために、HTTP / 1.1クライアントは、追加のCRLFを使用してリクエストの前に置いたり、それに続くことはできません。
HTTP header fields, which include general-header (section 4.5), request-header (section 5.3), response-header (section 6.2), and entity-header (section 7.1) fields, follow the same generic format as that given in Section 3.1 of RFC 822 [9]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HT. Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms.
general-header（セクション4.5）、request-header（セクション5.3）、response-header（セクション6.2）、およびentity-header（セクション7.1）フィールドを含むHTTPヘッダーフィールドは、セクションで指定されたものと同じ一般的な形式に従いますRFC 822 [9]の3.1。各ヘッダーフィールドは、名前とそれに続くコロン（ "："）およびフィールド値で構成されます。フィールド名は大文字と小文字を区別しません。単一のSPが推奨されますが、フィールド値の前に任意の量のLWSを付けることができます。ヘッダーフィールドは、追加の各行の前に少なくとも1つのSPまたはHTを付けることにより、複数行に拡張できます。 HTTP構造を生成するとき、アプリケーションは「共通形式」に従う必要があります。これは、共通形式以外のものが受け入れられない実装が存在する可能性があるためです。
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS MAY be removed without changing the semantics of the field value. Any LWS that occurs between field-content MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream.
フィールドコンテンツには、先頭または末尾のLWSは含まれません。フィールド値の最初の非空白文字の前、またはフィールド値の最後の非空白文字の後に発生する線形空白。このような先頭または末尾のLWSは、フィールド値のセマンティクスを変更せずに削除できます。フィールドコンテンツ間で発生するすべてのLWSは、フィールド値を解釈したり、メッセージをダウンストリームに転送したりする前に、単一のSPで置き換えることができます。
The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header fields.
異なるフィールド名を持つヘッダーフィールドが受信される順序は重要ではありません。ただし、最初に一般ヘッダーフィールドを送信し、次にリクエストヘッダーフィールドまたは応答ヘッダーフィールドを送信して、エンティティヘッダーフィールドで終了することをお勧めします。
Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.
同じフィールド名を持つ複数のメッセージヘッダーフィールドは、そのヘッダーフィールドのフィールド値全体がコンマ区切りのリストとして定義されている場合（つまり、＃（values））にのみ存在します。メッセージのセマンティクスを変更せずに、複数のヘッダーフィールドを1つの「フィールド名：フィールド値」ペアに結合することが可能でなければなりません。後続の各フィールド値を最初のフィールド値にカンマで区切って追加します。したがって、同じフィールド名を持つヘッダーフィールドが受信される順序は、結合されたフィールド値の解釈にとって重要です。したがって、プロキシは、メッセージが転送されるときにこれらのフィールド値の順序を変更してはなりません。
The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding header field (section 14.41).
HTTPメッセージのメッセージ本文（存在する場合）は、要求または応答に関連付けられたエンティティ本体を運ぶために使用されます。 Transfer-Encodingヘッダーフィールド（セクション14.41）で示されているように、転送コーディングが適用されている場合にのみ、message-bodyがentity-bodyと異なります。
message-body = entity-body | <entity-body encoded as per Transfer-Encoding>
メッセージ本体=エンティティ本体| <Transfer-Encodingに従ってエンコードされたエンティティボディ>
Transfer-Encoding MUST be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding is a property of the message, not of the entity, and thus MAY be added or removed by any application along the request/response chain. (However, section 3.6 places restrictions on when certain transfer-codings may be used.)
Transfer-Encodingは、メッセージの安全で適切な転送を保証するためにアプリケーションによって適用される転送コーディングを示すために使用する必要があります。 Transfer-Encodingは、エンティティではなくメッセージのプロパティであるため、要求/応答チェーンに沿ってアプリケーションによって追加または削除される場合があります。 （ただし、セクション3.6では、特定の転送コーディングを使用できる場合に制限を設けています。）
The rules for when a message-body is allowed in a message differ for requests and responses.
メッセージでメッセージ本文を許可する場合のルールは、要求と応答で異なります。
The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
要求内のメッセージ本文の存在は、要求のメッセージヘッダーにContent-LengthまたはTransfer-Encodingヘッダーフィールドを含めることによって通知されます。リクエストメソッドの仕様（セクション5.1.1）がリクエストでのエンティティボディの送信を許可しない場合、メッセージボディをリクエストに含めることはできません。サーバーはどんなリクエストでもメッセージ本文を読んで転送すべきです。リクエストメソッドにエンティティボディの定義されたセマンティクスが含まれていない場合、リクエストを処理するときにメッセージボディを無視する必要があります（SHOULD）。
For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code (section 6.1.1). All responses to the HEAD request method MUST NOT include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it MAY be of zero length.
応答メッセージの場合、メッセージ本文がメッセージに含まれるかどうかは、要求メソッドと応答ステータスコードの両方に依存します（セクション6.1.1）。エンティティヘッダーフィールドが存在すると信じることができる場合でも、HEADリクエストメソッドへのすべての応答にメッセージ本文を含めることはできません。すべての1xx（情報）、204（コンテンツなし）、および304（変更されていない）応答には、メッセージ本文を含めることはできません。他のすべての応答にはメッセージ本文が含まれますが、長さはゼロになる場合があります。
The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):
メッセージのtransfer-lengthは、メッセージに表示されるメッセージ本体の長さです。つまり、転送コーディングが適用された後です。メッセージ本文がメッセージに含まれている場合、その本文の転送長は、次のいずれかによって決定されます（優先順位順）。
1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message.
1.「MUST NOT」にメッセージ本文が含まれるすべての応答メッセージ（1xx、204、304応答やHEAD要求への応答など）は、ヘッダーフィールドの後の最初の空行で常に終了します。メッセージに存在するエンティティヘッダーフィールド。
2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.
2. Transfer-Encodingヘッダーフィールド（セクション14.41）が存在し、 "identity"以外の値がある場合、メッセージが転送されない限り、 "チャンクされた" transfer-coding（セクション3.6）を使用してtransfer-lengthが定義されます。接続を閉じると終了します。
3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
3. Content-Lengthヘッダーフィールド（セクション14.13）が存在する場合、OCTETの10進数値はエンティティ長と転送長の両方を表します。これら2つの長さが異なる場合（つまり、Transfer-Encodingヘッダーフィールドが存在する場合）、Content-Lengthヘッダーフィールドを送信してはなりません（MUST NOT）。 Transfer-EncodingヘッダーフィールドとContent-Lengthヘッダーフィールドの両方を含むメッセージを受信した場合、後者は無視する必要があります。
4.If the message uses the media type "multipart/byteranges", and the ransfer-length is not otherwise specified, then this self-elimiting media type defines the transfer-length. This media type UST NOT be used unless the sender knows that the recipient can arse it; the presence in a request of a Range header with ultiple byte-range specifiers from a 1.1 client implies that the lient can parse multipart/byteranges responses.
4.メッセージがメディアタイプ「multipart / byteranges」を使用し、転送長が特に指定されていない場合、この自己制限メディアタイプが転送長を定義します。このメディアタイプは、送信者が受信者が付与できることを知らない限り、使用しないでください。 1.1クライアントからの複数のバイト範囲指定子を持つRangeヘッダーの要求に存在することは、クライアントがmultipart / byteranges応答を解析できることを意味します。
A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server MUST delimit the message using methods defined in items 1,3 or 5 of this section.
範囲ヘッダーは、マルチパート/バイト範囲を認識しない1.0プロキシによって転送される可能性があります。この場合、サーバーは、このセクションの項目1、3、または5で定義されたメソッドを使用してメッセージを区切る必要があります。
5.By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.)
5.サーバーが接続を閉じる。 （接続を閉じることは、サーバーが応答を送り返す可能性を残さないため、要求本文の終わりを示すために使用することはできません。）
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length.
HTTP / 1.0アプリケーションとの互換性のために、サーバーがHTTP / 1.1準拠であることがわかっている場合を除き、メッセージボディを含むHTTP / 1.1リクエストには有効なContent-Lengthヘッダーフィールドを含める必要があります。リクエストにメッセージ本文が含まれていてContent-Lengthが指定されていない場合、サーバーは、メッセージの長さを判断できない場合は400（不正なリクエスト）で応答するか、要求したい場合は411（必要な長さ）で応答する必要があります。有効なContent-Lengthを受け取ります。
All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.
エンティティを受信するすべてのHTTP / 1.1アプリケーションは、「チャンク」転送コーディング（セクション3.6）を受け入れる必要があるため、メッセージの長さが事前に決定できない場合に、このメカニズムをメッセージに使用できます。
Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored.
メッセージには、Content-Lengthヘッダーフィールドと非ID転送コーディングの両方を含めることはできません。メッセージに非ID転送コーディングが含まれている場合、Content-Lengthは無視する必要があります。
When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.
メッセージ本文が許可されているメッセージでContent-Lengthを指定する場合、そのフィールド値はメッセージ本文のOCTETの数と正確に一致する必要があります。 HTTP / 1.1ユーザーエージェントは、無効な長さが受信および検出されたときにユーザーに通知する必要があります。
There are a few header fields which have general applicability for both request and response messages, but which do not apply to the entity being transferred. These header fields apply only to the message being transmitted.
要求メッセージと応答メッセージの両方に一般的に適用できるヘッダーフィールドがいくつかありますが、転送されるエンティティには適用されません。これらのヘッダーフィールドは、送信されるメッセージにのみ適用されます。
general-header = Cache-Control ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.18
| Pragma ; Section 14.32
| Trailer ; Section 14.40
| Transfer-Encoding ; Section 14.41
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46
General-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize them to be general-header fields. Unrecognized header fields are treated as entity-header fields.
汎用ヘッダーフィールド名は、プロトコルバージョンの変更と組み合わせた場合にのみ確実に拡張できます。ただし、通信のすべての関係者が一般ヘッダーフィールドであると認識した場合、新しいヘッダーフィールドまたは実験的なヘッダーフィールドに一般ヘッダーフィールドのセマンティクスが与えられることがあります。認識されないヘッダーフィールドは、エンティティヘッダーフィールドとして扱われます。
5 Request
5リクエスト
A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.
クライアントからサーバーへの要求メッセージには、そのメッセージの最初の行に、リソースに適用されるメソッド、リソースの識別子、および使用中のプロトコルバージョンが含まれています。
Request = Request-Line ; Section 5.1
*(( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 4.3
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
Request-Lineはメソッドトークンで始まり、Request-URIとプロトコルバージョンが続き、CRLFで終わります。要素はSP文字で区切られます。最後のCRLFシーケンスを除いて、CRまたはLFは許可されません。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
Request-Line =メソッドSP Request-URI SP HTTP-Version CRLF
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.
Methodトークンは、Request-URIで識別されるリソースで実行されるメソッドを示します。このメソッドでは大文字と小文字が区別されます。
Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token
The list of methods allowed by a resource can be specified in an Allow header field (section 14.7). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the set of allowed methods can change dynamically. An origin server SHOULD return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD MUST be supported by all general-purpose servers. All other methods are OPTIONAL; however, if the above methods are implemented, they MUST be implemented with the same semantics as those specified in section 9.
リソースによって許可されるメソッドのリストは、Allowヘッダーフィールド（セクション14.7）で指定できます。許可されたメソッドのセットは動的に変更できるため、リソースのメソッドが現在許可されているかどうか、応答の戻りコードは常にクライアントに通知します。オリジンサーバーは、メソッドがオリジンサーバーによって認識されているが要求されたリソースに対して許可されていない場合はステータスコード405（メソッドは許可されていません）を返し、メソッドがオリジンサーバーによって認識されていないか実装されていない場合は501（実装されていません）を返す必要があります。メソッドGETおよびHEADは、すべての汎用サーバーでサポートされている必要があります。他のすべての方法はオプションです。ただし、上記のメソッドが実装されている場合は、セクション9で指定されているものと同じセマンティクスで実装する必要があります。
The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon which to apply the request.
Request-URIはUniform Resource Identifier（セクション3.2）であり、要求を適用するリソースを識別します。
Request-URI = "*" | absoluteURI | abs_path | authority
Request-URI = "*" |絶対URI | abs_path |権限
The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. One example would be
Request-URIの4つのオプションは、要求の性質によって異なります。アスタリスク「*」は、リクエストが特定のリソースではなくサーバー自体に適用されることを意味し、使用されるメソッドが必ずしもリソースに適用されない場合にのみ許可されます。一例は
OPTIONS * HTTP/1.1
オプション* HTTP / 1.1
The absoluteURI form is REQUIRED when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be:
リクエストがプロキシに対して行われている場合、absoluteURI形式が必要です。プロキシは、リクエストを転送するか、有効なキャッシュからサービスを提供し、レスポンスを返すようにリクエストされます。プロキシは、リクエストを別のプロキシに転送するか、absoluteURIで指定されたサーバーに直接転送する場合があります。要求ループを回避するために、プロキシは、エイリアス、ローカルバリエーション、および数値IPアドレスを含む、サーバーのすべての名前を認識できる必要があります。 Request-Lineの例は次のようになります。
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
HTTPの将来のバージョンでは、すべてのリクエストで絶対URIに移行できるようにするため、HTTP / 1.1クライアントはプロキシへのリクエストでのみ生成する場合でも、すべてのHTTP / 1.1サーバーはリクエストで絶対URIフォームを受け入れる必要があります。
The authority form is only used by the CONNECT method (section 9.9).
権限フォームは、CONNECTメソッドでのみ使用されます（セクション9.9）。
The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:
Request-URIの最も一般的な形式は、オリジンサーバーまたはゲートウェイ上のリソースを識別するために使用される形式です。この場合、URIの絶対パスをリクエストURIとして送信し（セクション3.2.1、abs_pathを参照）、URIのネットワークロケーション（権限）をホストヘッダーフィールドで送信する必要があります。たとえば、上記のリソースをオリジンサーバーから直接取得したいクライアントは、ホスト「www.w3.org」のポート80へのTCP接続を作成し、次の行を送信します。
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original URI, it MUST be given as "/" (the server root).
リクエストの残りが続きます。絶対パスを空にすることはできません。元のURIに何も存在しない場合は、 "/"（サーバールート）として指定する必要があります。
The Request-URI is transmitted in the format specified in section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding [42], the origin server MUST decode the Request-URI in order to properly interpret the request. Servers SHOULD respond to invalid Request-URIs with an appropriate status code.
Request-URIは、セクション3.2.1で指定された形式で送信されます。 Request-URIが「％HEX HEX」エンコーディング[42]を使用してエンコードされている場合、オリジンサーバーはリクエストを適切に解釈するためにRequest-URIをデコードする必要があります。サーバーは、無効なリクエストURIに適切なステータスコードで応答する必要があります（SHOULD）。
A transparent proxy MUST NOT rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above to replace a null abs_path with "/".
透過プロキシは、次の受信サーバーに転送するときに、受信したRequest-URIの「abs_path」部分を書き換えてはなりません（ただし、上記のnull abs_pathを「/」に置き換える場合を除く）。
Note: The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been known to rewrite the Request-URI.
注：「リライトなし」ルールは、オリジンサーバーが予約された目的で予約されていないURI文字を不適切に使用している場合に、プロキシがリクエストの意味を変更しないようにします。実装者は、HTTP / 1.1より前のプロキシの一部がRequest-URIを書き換えることがわかっていることを認識しておく必要があります。
The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.
インターネット要求によって識別される正確なリソースは、Request-URIとHostヘッダーフィールドの両方を調べることによって決定されます。
An origin server that does not allow resources to differ by the requested host MAY ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
リクエストされたホストによるリソースの違いを許可しないオリジンサーバーは、HTTP / 1.1リクエストで識別されたリソースを決定するときに、Hostヘッダーフィールドの値を無視してもよい（MAY）。 （ただし、HTTP / 1.1でのホストサポートに関するその他の要件については、セクション19.6.1.1を参照してください。）
An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) MUST use the following rules for determining the requested resource on an HTTP/1.1 request:
要求されたホスト（仮想ホストまたはバニティホスト名と呼ばれることもある）に基づいてリソースを区別するオリジンサーバーは、HTTP / 1.1要求で要求されたリソースを決定するために次のルールを使用する必要があります。
1. If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored.
1. Request-URIがabsoluteURIの場合、ホストはRequest-URIの一部です。リクエスト内のホストヘッダーフィールド値はすべて無視する必要があります。
2. If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host header field value.
2. Request-URIが絶対URIではなく、リクエストにHostヘッダーフィールドが含まれている場合、ホストはHostヘッダーフィールドの値によって決定されます。
3. If the host as determined by rule 1 or 2 is not a valid host on the server, the response MUST be a 400 (Bad Request) error message.
3. ルール1または2で決定されたホストがサーバー上の有効なホストでない場合、応答は400（Bad Request）エラーメッセージでなければなりません。
Recipients of an HTTP/1.0 request that lacks a Host header field MAY attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine what exact resource is being requested.
HostヘッダーフィールドのないHTTP / 1.0リクエストの受信者は、どの正確なリソースがリクエストされているかを判断するために、ヒューリスティック（特定のホストに固有の何かのURIパスの検査など）を使用しようとする場合があります。
The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language method invocation.
リクエストヘッダーフィールドを使用すると、クライアントはリクエストとクライアント自体に関する追加情報をサーバーに渡すことができます。これらのフィールドは要求修飾子として機能し、セマンティクスはプログラミング言語のメソッド呼び出しのパラメーターと同等です。
request-header = Accept ; Section 14.1
| Accept-Charset ; Section 14.2
| Accept-Encoding ; Section 14.3
| Accept-Language ; Section 14.4
| Authorization ; Section 14.8
| Expect ; Section 14.20
| From ; Section 14.22
| Host ; Section 14.23
| If-Match ; Section 14.24
| If-Modified-Since ; Section 14.25
| If-None-Match ; Section 14.26
| If-Range ; Section 14.27
| If-Unmodified-Since ; Section 14.28
| Max-Forwards ; Section 14.31
| Proxy-Authorization ; Section 14.34
| Range ; Section 14.35
| Referer ; Section 14.36
| TE ; Section 14.39
| User-Agent ; Section 14.43
Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields. Unrecognized header fields are treated as entity-header fields.
要求ヘッダーフィールド名は、プロトコルバージョンの変更と組み合わせた場合にのみ確実に拡張できます。ただし、通信のすべての関係者がそれらをリクエストヘッダーフィールドであると認識する場合、新しいヘッダーフィールドまたは実験的なヘッダーフィールドにリクエストヘッダーフィールドのセマンティクスを与えることができます。認識されないヘッダーフィールドは、エンティティヘッダーフィールドとして扱われます。
6 Response
6応答
After receiving and interpreting a request message, a server responds with an HTTP response message.
要求メッセージを受信して解釈した後、サーバーはHTTP応答メッセージで応答します。
Response = Status-Line ; Section 6.1
*(( general-header ; Section 4.5
| response-header ; Section 6.2
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2
The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
応答メッセージの最初の行はStatus-Lineであり、プロトコルバージョンと、それに続く数値のステータスコードとそれに関連するテキストフレーズで構成され、各要素はSP文字で区切られています。最後のCRLFシーケンスを除いて、CRまたはLFは許可されません。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in section 10. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.
Status-Code要素は、要求を理解して満足する試みの3桁の整数の結果コードです。これらのコードはセクション10で完全に定義されています。Reason-Phraseは、Status-Codeの短いテキスト記述を提供することを目的としています。 Status-Codeはオートマトンによる使用を意図しており、Reason-Phraseは人間のユーザーを対象としています。クライアントは、Reason-Phraseを調べたり表示したりする必要はありません。
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:
ステータスコードの最初の桁は、応答のクラスを定義します。下2桁には、分類の役割はありません。最初の桁には5つの値があります。
- 1xx: Informational - Request received, continuing process
- 1xx：情報-リクエストを受け取り、プロセスを続行
- 2xx: Success - The action was successfully received, understood, and accepted
- 2xx：成功-アクションは正常に受信され、理解され、受け入れられました
- 3xx: Redirection - Further action must be taken in order to complete the request
- 3xx：リダイレクト-リクエストを完了するには、さらにアクションを実行する必要があります
- 4xx: Client Error - The request contains bad syntax or cannot be fulfilled
- 4xx：クライアントエラー-リクエストに不正な構文が含まれている、または実行できない
- 5xx: Server Error - The server failed to fulfill an apparently valid request
- 5xx：サーバーエラー-サーバーは明らかに有効なリクエストを実行できませんでした
The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol.
HTTP / 1.1に定義された数値ステータスコードの個々の値と、対応する理由フレーズのサンプルセットを以下に示します。ここに記載されている理由フレーズは推奨事項にすぎません。プロトコルに影響を与えることなく、ローカルの同等のものに置き換えることができます。
Status-Code =
"100" ; Section 10.1.1: Continue
| "101" ; Section 10.1.2: Switching Protocols
| "200" ; Section 10.2.1: OK
| "201" ; Section 10.2.2: Created
| "202" ; Section 10.2.3: Accepted
| "203" ; Section 10.2.4: Non-Authoritative Information
| "204" ; Section 10.2.5: No Content
| "205" ; Section 10.2.6: Reset Content
| "206" ; Section 10.2.7: Partial Content
| "300" ; Section 10.3.1: Multiple Choices
| "301" ; Section 10.3.2: Moved Permanently
| "302" ; Section 10.3.3: Found
| "303" ; Section 10.3.4: See Other
| "304" ; Section 10.3.5: Not Modified
| "305" ; Section 10.3.6: Use Proxy
| "307" ; Section 10.3.8: Temporary Redirect
| "400" ; Section 10.4.1: Bad Request
| "401" ; Section 10.4.2: Unauthorized
| "402" ; Section 10.4.3: Payment Required
| "403" ; Section 10.4.4: Forbidden
| "404" ; Section 10.4.5: Not Found
| "405" ; Section 10.4.6: Method Not Allowed
| "406" ; Section 10.4.7: Not Acceptable
| "407" ; Section 10.4.8: Proxy Authentication Required
| "408" ; Section 10.4.9: Request Time-out
| "409" ; Section 10.4.10: Conflict
| "410" ; Section 10.4.11: Gone
| "411" ; Section 10.4.12: Length Required
| "412" ; Section 10.4.13: Precondition Failed
| "413" ; Section 10.4.14: Request Entity Too Large
| "414" ; Section 10.4.15: Request-URI Too Large
| "415" ; Section 10.4.16: Unsupported Media Type
| "416" ; Section 10.4.17: Requested range not satisfiable
| "417" ; Section 10.4.18: Expectation Failed
| "500" ; Section 10.5.1: Internal Server Error
| "501" ; Section 10.5.2: Not Implemented
| "502" ; Section 10.5.3: Bad Gateway
| "503" ; Section 10.5.4: Service Unavailable
| "504" ; Section 10.5.5: Gateway Time-out
| "505" ; Section 10.5.6: HTTP Version not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human-readable information which will explain the unusual status.
HTTPステータスコードは拡張可能です。 HTTPアプリケーションは、登録されているすべてのステータスコードの意味を理解する必要はありませんが、そのような理解が明らかに望ましいです。ただし、アプリケーションは最初の桁で示されるように、ステータスコードのクラスを理解しなければならず、認識されない応答はキャッシュされてはならないという例外を除いて、そのクラスのx00ステータスコードと同等のものとして扱います。たとえば、クライアントが認識できないステータスコード431を受信した場合、リクエストに問題があると想定し、400ステータスコードを受信したかのように応答を処理できます。そのような場合、そのエンティティは異常な状態を説明する人間が読める情報を含む可能性が高いので、ユーザーエージェントはユーザーに応答で返されたエンティティを提示する必要があります。
The response-header fields allow the server to pass additional information about the response which cannot be placed in the Status-Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.
応答ヘッダーフィールドを使用すると、サーバーはステータス行に配置できない応答に関する追加情報を渡すことができます。これらのヘッダーフィールドは、サーバーに関する情報と、Request-URIで識別されるリソースへの以降のアクセスに関する情報を提供します。
response-header = Accept-Ranges ; Section 14.5
| Age ; Section 14.6
| ETag ; Section 14.19
| Location ; Section 14.30
| Proxy-Authenticate ; Section 14.33
| Retry-After ; Section 14.37
| Server ; Section 14.38
| Vary ; Section 14.44
| WWW-Authenticate ; Section 14.47
Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of response-header fields if all parties in the communication recognize them to be response-header fields. Unrecognized header fields are treated as entity-header fields.
応答ヘッダーフィールド名は、プロトコルバージョンの変更と組み合わせた場合にのみ確実に拡張できます。ただし、通信のすべての関係者がそれらを応答ヘッダーフィールドであると認識する場合、新しいヘッダーフィールドまたは実験的なヘッダーフィールドに応答ヘッダーフィールドのセマンティクスを与えることができます。認識されないヘッダーフィールドは、エンティティヘッダーフィールドとして扱われます。
7 Entity
7エンティティ
Request and Response messages MAY transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers.
要求および応答メッセージは、要求メソッドまたは応答ステータスコードによって制限されていない限り、エンティティを転送する場合があります。エンティティはエンティティヘッダーフィールドとエンティティボディで構成されますが、一部の応答にはエンティティヘッダーのみが含まれます。
In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.
このセクションでは、送信者と受信者の両方が、エンティティの送信者と受信者に応じて、クライアントまたはサーバーを指します。
Entity-header fields define metainformation about the entity-body or, if no body is present, about the resource identified by the request. Some of this metainformation is OPTIONAL; some might be REQUIRED by portions of this specification.
エンティティヘッダーフィールドは、エンティティボディに関するメタ情報を定義します。ボディが存在しない場合は、リクエストによって識別されるリソースに関するメタ情報を定義します。このメタ情報の一部はオプションです。この仕様の一部では一部が必要になる場合があります。
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
extension-header = message-header
The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields SHOULD be ignored by the recipient and MUST be forwarded by transparent proxies.
拡張ヘッダーメカニズムでは、プロトコルを変更せずに追加のエンティティヘッダーフィールドを定義できますが、これらのフィールドを受信者が認識できると想定することはできません。認識されないヘッダーフィールドは受信者によって無視されるべきで（SHOULD）、透過的なプロキシによって転送されなければなりません（MUST）。
The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.
HTTPリクエストまたはHTTP応答で送信されたエンティティ本体（存在する場合）は、エンティティヘッダーフィールドで定義された形式とエンコーディングです。
entity-body = *OCTET
An entity-body is only present in a message when a message-body is present, as described in section 4.3. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure safe and proper transfer of the message.
エンティティー本体は、セクション4.3で説明されているように、メッセージ本体が存在する場合にのみメッセージに存在します。 entity-bodyは、メッセージの安全で適切な転送を保証するために適用された可能性のあるTransfer-Encodingをデコードすることにより、message-bodyから取得されます。
When an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type and Content-Encoding. These define a two-layer, ordered encoding model:
エンティティボディがメッセージに含まれている場合、そのボディのデータタイプは、ヘッダーフィールドContent-TypeおよびContent-Encodingを介して決定されます。これらは、2層の順序付きエンコーディングモデルを定義します。
entity-body := Content-Encoding( Content-Type( data ) )
Content-Type specifies the media type of the underlying data. Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that are a property of the requested resource. There is no default encoding.
Content-Typeは、基になるデータのメディアタイプを指定します。 Content-Encodingは、通常はデータ圧縮の目的で、要求されたリソースのプロパティである、データに適用される追加のコンテンツコーディングを示すために使用できます。デフォルトのエンコーディングはありません。
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
エンティティボディを含むHTTP / 1.1メッセージには、そのボディのメディアタイプを定義するContent-Typeヘッダーフィールドを含める必要があります（SHOULD）。メディアタイプがContent-Typeフィールドで指定されていない場合に限り、受信者はコンテンツの検査やリソースの識別に使用されるURIの名前拡張子、またはその両方を介してメディアタイプを推測しようとする場合があります。メディアタイプが不明のままである場合、受信者はそれをタイプ「application / octet-stream」として扱う必要があります。
The entity-length of a message is the length of the message-body before any transfer-codings have been applied. Section 4.4 defines how the transfer-length of a message-body is determined.
メッセージのエンティティ長は、転送コーディングが適用される前のメッセージ本文の長さです。セクション4.4では、メッセージ本文の転送長を決定する方法を定義しています。
8 Connections
8接続
Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP servers and causing congestion on the Internet. The use of inline images and other associated data often require a client to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a prototype implementation are available [26] [30]. Implementation experience and measurements of actual HTTP/1.1 (RFC 2068) implementations show good results [39]. Alternatives have also been explored, for example, T/TCP [27].
永続的な接続の前は、各URLを取得するために個別のTCP接続が確立されていたため、HTTPサーバーの負荷が増加し、インターネットで輻輳が発生していました。多くの場合、インライン画像やその他の関連データを使用するには、クライアントが同じサーバーに対して複数のリクエストを短時間で行う必要があります。これらのパフォーマンス問題の分析とプロトタイプ実装の結果が利用可能です[26] [30]。実際のHTTP / 1.1（RFC 2068）実装の実装経験と測定は、良い結果を示しています[39]。 T / TCPなどの代替手段も検討されています[27]。
Persistent HTTP connections have a number of advantages:
永続的なHTTP接続には、いくつかの利点があります。
- By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
- 開いたり閉じたりするTCP接続を減らすことで、CPU時間はルーターとホスト（クライアント、サーバー、プロキシ、ゲートウェイ、トンネル、またはキャッシュ）で節約され、TCPプロトコル制御ブロックに使用されるメモリはホストで節約できます。
- HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.
- HTTP要求と応答は、接続でパイプライン処理できます。パイプライン処理により、クライアントは各応答を待たずに複数の要求を行うことができ、単一のTCP接続をはるかに短い時間でより効率的に使用できます。
- Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network.
- TCPオープンによって引き起こされるパケットの数を減らし、TCPがネットワークの輻輳状態を判別するのに十分な時間を与えることにより、ネットワークの輻輳が軽減されます。
- Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.
- TCPの接続開始ハンドシェイクに時間が費やされないため、後続の要求の待ち時間が短縮されます。
- HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old semantics after an error is reported.
- エラーはTCP接続を閉じるペナルティなしで報告できるため、HTTPはより適切に進化できます。 HTTPの将来のバージョンを使用するクライアントは新機能を楽観的に試す可能性がありますが、古いサーバーと通信する場合は、エラーが報告された後、古いセマンティクスで再試行してください。
HTTP implementations SHOULD implement persistent connections.
HTTP実装は永続的な接続を実装する必要があります（SHOULD）。
A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server.
HTTP / 1.1と以前のバージョンのHTTPの大きな違いは、永続的な接続がすべてのHTTP接続のデフォルトの動作であることです。つまり、特に明記されていない限り、クライアントは、サーバーからのエラー応答の後でも、サーバーが永続的な接続を維持すると想定する必要があります（SHOULD）。
Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling takes place using the Connection header field (section 14.10). Once a close has been signaled, the client MUST NOT send any more requests on that connection.
永続的な接続は、クライアントとサーバーがTCP接続の終了を通知できるメカニズムを提供します。このシグナリングは、接続ヘッダーフィールド（セクション14.10）を使用して行われます。クローズが通知されると、クライアントはその接続でこれ以上リクエストを送信してはなりません（MUST NOT）。
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it SHOULD send a Connection header including the connection-token close.
HTTP / 1.1サーバーは、接続トークンの "close"を含むConnectionヘッダーがリクエストで送信されない限り、HTTP / 1.1クライアントが永続的な接続を維持するつもりであると想定する場合があります。サーバーが応答を送信した直後に接続を閉じることを選択した場合は、接続トークンの閉じを含む接続ヘッダーを送信する必要があります（SHOULD）。
An HTTP/1.1 client MAY expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains a Connection header with the connection-token close. In case the client does not want to maintain a connection for more than that request, it SHOULD send a Connection header including the connection-token close.
HTTP / 1.1クライアントは、接続が開いたままであることを期待できますが、サーバーからの応答に、接続トークンが閉じる接続ヘッダーが含まれているかどうかに基づいて、接続を開いたままにすることを決定します。クライアントがそのリクエスト以上の接続を維持したくない場合は、接続トークンのクローズを含む接続ヘッダーを送信する必要があります（SHOULD）。
If either the client or the server sends the close token in the Connection header, that request becomes the last one for the connection.
クライアントまたはサーバーのいずれかが接続ヘッダーでクローズトークンを送信すると、その要求は接続の最後の要求になります。
Clients and servers SHOULD NOT assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See section 19.6.2 for more information on backward compatibility with HTTP/1.0 clients.
クライアントとサーバーは、明示的に通知されない限り、永続的な接続が1.1より前のバージョンのHTTPで維持されていると想定すべきではありません。 HTTP / 1.0クライアントとの下位互換性の詳細については、セクション19.6.2を参照してください。
In order to remain persistent, all messages on the connection MUST have a self-defined message length (i.e., one not defined by closure of the connection), as described in section 4.4.
セクション4.4で説明されているように、永続性を維持するために、接続上のすべてのメッセージは、自己定義のメッセージ長（つまり、接続のクローズによって定義されていないもの）を持つ必要があります。
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.
永続的な接続をサポートするクライアントは、そのリクエストを「パイプライン化」することができます（つまり、各応答を待たずに複数のリクエストを送信できます）。サーバーは、それらの要求に対する応答を、要求が受信されたのと同じ順序で送信する必要があります。
Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
接続の確立直後に永続的な接続とパイプラインを想定するクライアントは、最初のパイプライン化の試行が失敗した場合に接続を再試行する準備をする必要があります。クライアントがそのような再試行を行う場合、接続が永続的であると認識する前にパイプラインを実行してはなりません（MUST NOT）。対応するすべての応答を送信する前にサーバーが接続を閉じた場合、クライアントは要求を再送信する準備もしなければなりません。
Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request.
クライアントは、非べき等メソッドまたは非べき等メソッドシーケンスを使用してリクエストをパイプライン処理するべきではありません（セクション9.1.2を参照）。そうしないと、トランスポート接続が途中で終了すると、結果が不確定になる可能性があります。べき等でない要求を送信したいクライアントは、前の要求の応答ステータスを受信するまで、その要求の送信を待機する必要があります（SHOULD）。
It is especially important that proxies correctly implement the properties of the Connection header field as specified in section 14.10.
セクション10.10で指定されているように、プロキシがConnectionヘッダーフィールドのプロパティを正しく実装することが特に重要です。
The proxy server MUST signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects to. Each persistent connection applies to only one transport link.
プロキシサーバーは、クライアントと、接続先のオリジンサーバー（または他のプロキシサーバー）との永続的な接続を個別に通知する必要があります。各永続的接続は、1つのトランスポートリンクにのみ適用されます。
A proxy server MUST NOT establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068 [33] for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
プロキシサーバーは、HTTP / 1.0クライアントとのHTTP / 1.1永続的接続を確立してはなりません（ただし、多くのHTTP / 1.0クライアントによって実装されたKeep-Aliveヘッダーの問題と詳細については、RFC 2068 [33]を参照してください）。
Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server. The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client or the server.
サーバーには通常、タイムアウト値があり、それを超えると非アクティブな接続を維持できなくなります。クライアントが同じサーバーを介してより多くの接続を行う可能性が高いため、プロキシサーバーはこれをより高い値にする場合があります。永続的な接続を使用しても、クライアントまたはサーバーのいずれかで、このタイムアウトの長さ（または存在）に要件はありません。
When a client or server wishes to time-out it SHOULD issue a graceful close on the transport connection. Clients and servers SHOULD both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does not detect the other side's close promptly it could cause unnecessary resource drain on the network.
クライアントまたはサーバーがタイムアウトしたい場合は、トランスポート接続で適切なクローズを発行する必要があります。クライアントとサーバーは両方とも、トランスポートの反対側が閉じるのを常に監視し、必要に応じてそれに応答する必要があります。クライアントまたはサーバーが相手側のクローズを迅速に検出しない場合、ネットワーク上で不要なリソースが消費される可能性があります。
A client, server, or proxy MAY close the transport connection at any time. For example, a client might have started to send a new request at the same time that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed while it was idle, but from the client's point of view, a request is in progress.
クライアント、サーバー、またはプロキシは、いつでもトランスポート接続を閉じることができます。たとえば、サーバーが「アイドル」接続を閉じることを決定したと同時に、クライアントが新しい要求の送信を開始した可能性があります。サーバーの観点からは、接続はアイドル状態のときに閉じられていますが、クライアントの観点からは、要求が進行中です。
This means that clients, servers, and proxies MUST be able to recover from asynchronous close events. Client software SHOULD reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request sequence is idempotent (see section 9.1.2). Non-idempotent methods or sequences MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding of the application MAY substitute for user confirmation. The automatic retry SHOULD NOT be repeated if the second sequence of requests fails.
これは、クライアント、サーバー、およびプロキシが非同期のクローズイベントから回復できる必要があることを意味します。クライアントソフトウェアは、リクエストシーケンスがべき等である限り（セクション9.1.2を参照）、トランスポート接続を再度開き、ユーザーの操作なしに中止されたリクエストシーケンスを再送信する必要があります（SHOULD）。べき等ではないメソッドまたはシーケンスは、自動的に再試行してはなりません（MUST）。ただし、ユーザーエージェントは、人間のオペレーターにリクエストを再試行する選択肢を提供できます（MAY）。アプリケーションのセマンティックな理解を持つユーザーエージェントソフトウェアによる確認は、ユーザー確認の代わりになる場合があります。要求の2番目のシーケンスが失敗した場合、自動再試行は繰り返されるべきではない（SHOULD NOT）。
Servers SHOULD always respond to at least one request per connection, if at all possible. Servers SHOULD NOT close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
サーバーは、可能な場合は常に、接続ごとに少なくとも1つの要求に応答する必要があります（SHOULD）。ネットワークまたはクライアントの障害が疑われる場合を除いて、サーバーは応答の送信中に接続を閉じないでください。
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
永続的な接続を使用するクライアントは、特定のサーバーに対して維持する同時接続の数を制限する必要があります（SHOULD）。シングルユーザークライアントは、サーバーまたはプロキシとの接続を3つ以上維持すべきではありません。プロキシは、別のサーバーまたはプロキシへの最大2 * N接続を使用する必要があります（Nは同時にアクティブなユーザーの数です）。これらのガイドラインは、HTTP応答時間を改善し、輻輳を回避することを目的としています。
HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating connections with the expectation that clients will retry. The latter technique can exacerbate network congestion.
HTTP / 1.1サーバーは、クライアントが再試行することを期待して接続を終了するのではなく、永続的な接続を維持し、TCPのフロー制御メカニズムを使用して一時的な過負荷を解決する必要があります。後者の手法は、ネットワークの輻輳を悪化させる可能性があります。
An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (section 3.6), a zero length chunk and empty trailer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection.
メッセージボディを送信するHTTP / 1.1（またはそれ以降）クライアントは、リクエストを送信している間、ネットワーク接続のエラーステータスを監視する必要があります（SHOULD）。クライアントがエラーステータスを確認した場合は、本文の送信を直ちに中止する必要があります（SHOULD）。本文が「チャンク」エンコーディング（セクション3.6）を使用して送信されている場合は、長さがゼロのチャンクと空のトレーラーを使用して、メッセージの終わりを時期尚早にマークすることができます。本文の前にContent-Lengthヘッダーがある場合、クライアントは接続を閉じる必要があります。
The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.
100（続行）ステータス（セクション10.1.1を参照）の目的は、要求本文を含む要求メッセージを送信しているクライアントが、元のサーバーが要求を受け入れる用意があるかどうかを（要求ヘッダーに基づいて）判断できるようにすることです。クライアントがリクエスト本文を送信する前。場合によっては、サーバーが本文を見ずにメッセージを拒否する場合、クライアントが本文を送信することが不適切または非効率的である可能性があります。
Requirements for HTTP/1.1 clients:
HTTP / 1.1クライアントの要件：
- If a client will wait for a 100 (Continue) response before sending the request body, it MUST send an Expect request-header field (section 14.20) with the "100-continue" expectation.
- クライアントがリクエスト本文を送信する前に100（Continue）応答を待つ場合、クライアントはExpectリクエストヘッダーフィールド（セクション14.20）に「100-continue」の期待値を送信する必要があります。
- A client MUST NOT send an Expect request-header field (section 14.20) with the "100-continue" expectation if it does not intend to send a request body.
- クライアントは、リクエスト本文を送信するつもりがない場合は、「100-continue」の期待値でExpectリクエストヘッダーフィールド（セクション14.20）を送信してはなりません（MUST NOT）。
Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect: 100- continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client SHOULD NOT wait for an indefinite period before sending the request body.
古い実装が存在するため、このプロトコルは、クライアントが417（期待失敗）ステータスまたは100（続行）ステータスを受信せずに "期待：100-続行"を送信する可能性があるあいまいな状況を許可します。したがって、クライアントがこのヘッダーフィールドを（おそらくプロキシ経由で）オリジンサーバーに送信すると、100（Continue）ステータスを一度も確認したことがない場合、クライアントはリクエスト本文を送信する前に無期限に待機してはなりません（SHOULD NOT）。
Requirements for HTTP/1.1 origin servers:
HTTP / 1.1オリジンサーバーの要件：
- Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server MUST either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code. The origin server MUST NOT wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it MAY close the transport connection or it MAY continue to read and discard the rest of the request. It MUST NOT perform the requested method if it returns a final status code.
- "100-continue"期待のExpectリクエストヘッダーフィールドを含むリクエストを受信すると、オリジンサーバーは100（Continue）ステータスで応答し、入力ストリームからの読み取りを続けるか、または最終ステータスコードで応答する必要があります。オリジンサーバーは、100（Continue）応答を送信する前にリクエストボディを待機してはなりません（MUST NOT）。最終ステータスコードで応答する場合、トランスポート接続を閉じるか、残りのリクエストを読み取り、破棄し続ける場合があります。最終ステータスコードを返す場合は、要求されたメソッドを実行してはなりません。
- An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation, and MUST NOT send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility with RFC 2068, a server MAY send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header field with the "100- continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value.
- オリジンサーバーは、リクエストメッセージに「100-continue」の期待値を持つExpectリクエストヘッダーフィールドが含まれていない場合は100（Continue）応答を送信すべきではなく、そのようなリクエストが発信された場合は100（Continue）応答を送信してはならない（MUST NOT） HTTP / 1.0（またはそれ以前）のクライアント。このルールには例外があります。RFC2068との互換性のために、サーバーは、HTTP / 1.1 PUTまたはPOSTリクエストに応答して100（Continue）ステータスを送信できます。このリクエストには、「100-続ける」期待。この例外は、宣言されていない100（続行）ステータスの待機に関連するクライアント処理遅延を最小限に抑えることを目的としており、HTTP / 1.1リクエストにのみ適用され、他のHTTPバージョン値を持つリクエストには適用されません。
- An origin server MAY omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request.
- オリジンサーバーは、対応するリクエストのリクエストボディの一部またはすべてをすでに受け取っている場合、100（Continue）レスポンスを省略してもよい（MAY）。
- An origin server that sends a 100 (Continue) response MUST ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection prematurely.
- 100（Continue）応答を送信するオリジンサーバーは、トランスポート接続が途中で終了しない限り、リクエストボディが受信されて処理されると、最終的に最終ステータスコードを送信する必要があります。
- If an origin server receives a request that does not include an Expect request-header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final status code before reading the entire request body from the transport connection, then the server SHOULD NOT close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, the client might not reliably receive the response message. However, this requirement is not be construed as preventing a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
- オリジンサーバーが「100-continue」の期待値を持つExpectリクエストヘッダーフィールドを含まないリクエストを受信した場合、リクエストにはリクエストボディが含まれ、サーバーはリクエストボディ全体を読み取る前に最終ステータスコードで応答します。トランスポート接続の場合、サーバーは、リクエスト全体を読み取るか、クライアントが接続を閉じるまで、トランスポート接続を閉じないでください。そうしないと、クライアントが応答メッセージを確実に受信できない可能性があります。ただし、この要件は、サーバーがサービス拒否攻撃からサーバーを防御したり、ひどく壊れたクライアント実装からサーバーを防御したりすることを妨げるものではありません。
Requirements for HTTP/1.1 proxies:
HTTP / 1.1プロキシの要件：
- If a proxy receives a request that includes an Expect request-header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop server, it MUST forward the request, including the Expect header field.
- プロキシがExpectリクエストヘッダーフィールドに「100-continue」の期待値を含むリクエストを受信した場合、プロキシは、ネクストホップサーバーがHTTP / 1.1以降に準拠していることを知っているか、HTTPバージョンを知らないネクストホップサーバーの場合は、Expectヘッダーフィールドを含め、リクエストを転送する必要があります。
- If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST respond with a 417 (Expectation Failed) status.
- プロキシがネクストホップサーバーのバージョンがHTTP / 1.0以下であることを知っている場合、プロキシは要求を転送してはならず（MUST）、417（期待値失敗）ステータスで応答する必要があります。
- Proxies SHOULD maintain a cache recording the HTTP version numbers received from recently-referenced next-hop servers.
- プロキシは、最近参照されたネクストホップサーバーから受信したHTTPバージョン番号を記録するキャッシュを維持する必要があります（SHOULD）。
- A proxy MUST NOT forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 1xx responses (see section 10.1).
- リクエストメッセージがHTTP / 1.0（またはそれ以前）のクライアントから受信され、「100-continue」の期待値を持つExpectリクエストヘッダーフィールドが含まれていない場合、プロキシは100（Continue）応答を転送してはなりません（MUST NOT）。この要件は、1xx応答の転送に関する一般的なルールを上書きします（セクション10.1を参照）。
If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the client sees the connection close before receiving any status from the server, the client SHOULD retry the request. If the client does retry this request, it MAY use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:
HTTP / 1.1クライアントが、リクエスト本文を含むが「100-continue」の期待値を持つExpectリクエストヘッダーフィールドを含まないリクエストを送信する場合、およびクライアントがHTTP / 1.1オリジンサーバーに直接接続されていない場合、そしてサーバーからステータスを受信する前にクライアントが接続のクローズを確認した場合、クライアントはリクエストを再試行する必要があります（SHOULD）。クライアントがこのリクエストを再試行する場合、信頼できる応答を確実に取得するために、次の「バイナリ指数バックオフ」アルゴリズムを使用する場合があります。
1. Initiate a new connection to the server
1. サーバーへの新しい接続を開始する
2. Transmit the request-headers
2. リクエストヘッダーを送信する
3. Initialize a variable R to the estimated round-trip time to the server (e.g., based on the time it took to establish the connection), or to a constant value of 5 seconds if the round-trip time is not available.
3. 変数Rをサーバーへの推定往復時間（たとえば、接続の確立にかかった時間に基づく）に初期化するか、往復時間が利用できない場合は5秒の定数値に初期化します。
4. Compute T = R * (2**N), where N is the number of previous retries of this request.
4. T = R *（2 ** N）を計算します。ここで、Nはこの要求の以前の再試行の数です。
5. Wait either for an error response from the server, or for T seconds (whichever comes first)
5. サーバーからのエラー応答またはT秒（いずれか早い方）を待つ
6. If no error response is received, after T seconds transmit the body of the request.
6. エラー応答が受信されない場合は、T秒後に要求の本文を送信します。
7. If client sees that the connection is closed prematurely, repeat from step 1 until the request is accepted, an error response is received, or the user becomes impatient and terminates the retry process.
7. 接続が途中で閉じられたことをクライアントが確認した場合は、要求が受け入れられるか、エラー応答が受信されるか、ユーザーが待ち焦がれて再試行プロセスを終了するまで、手順1から繰り返します。
If at any point an error status is received, the client
いずれかの時点でエラーステータスが受信された場合、クライアント
- SHOULD NOT continue and
- 続行しないでください
- SHOULD close the connection if it has not completed sending the request message.
- 要求メッセージの送信が完了していない場合は、接続を閉じる必要があります（SHOULD）。
9 Method Definitions
9メソッドの定義
The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers.
HTTP / 1.1の一般的なメソッドのセットを以下に定義します。このセットは拡張できますが、個別に拡張されたクライアントとサーバーで同じセマンティクスを共有する追加のメソッドを想定することはできません。
The Host request-header field (section 14.23) MUST accompany all HTTP/1.1 requests.
Hostリクエストヘッダーフィールド（セクション14.23）は、すべてのHTTP / 1.1リクエストに伴う必要があります。
Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.
実装者は、ソフトウェアがインターネット上のやり取りでユーザーを表すことを認識し、自分や他の人にとって予期しない重要性を持っている可能性があるアクションをユーザーが認識できるように注意する必要があります。
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
特に、GETメソッドとHEADメソッドが取得以外のアクションを実行することの重要性を持たないことが規約に定められています。これらの方法は「安全」であると考えられるべきです。これにより、ユーザーエージェントはPOST、PUT、DELETEなどの他のメソッドを特別な方法で表すことができるため、ユーザーは安全でない可能性のあるアクションが要求されているという事実を知ることができます。
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
当然、GET要求を実行した結果としてサーバーが副作用を生成しないようにすることはできません。実際、一部の動的リソースはその機能を考慮しています。ここでの重要な違いは、ユーザーが副作用を要求しなかったため、それらに対して責任を負うことができないことです。
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.
メソッドは、（エラーまたは期限切れの問題は別として）N> 0の同一リクエストの副作用が単一リクエストの場合と同じであるという点で、「べき等」のプロパティを持つこともできます。メソッドGET、HEAD、PUT、DELETEはこのプロパティを共有します。また、メソッドOPTIONSとTRACEには副作用がないため、本質的にべき等です。
However, it is possible that a sequence of several requests is non-idempotent, even if all of the methods executed in that sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence.
ただし、そのシーケンスで実行されるすべてのメソッドがべき等であっても、複数のリクエストのシーケンスがべき等ではない可能性があります。 （シーケンス全体の単一の実行が常にそのシーケンスのすべてまたは一部の再実行によって変更されない結果をもたらす場合、シーケンスはべき等です。）たとえば、結果がに依存している場合、シーケンスは非べき等ではありません。後で同じシーケンスで変更される値。
A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed on the same set of resources).
副作用がない決してシーケンスはべき等です（同じリソースのセットで並行操作が実行されていない場合）。
The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
OPTIONSメソッドは、Request-URIで識別される要求/応答チェーンで使用可能な通信オプションに関する情報の要求を表します。このメソッドを使用すると、クライアントは、リソースアクションを示唆したり、リソースの取得を開始したりすることなく、リソースに関連付けられたオプションや要件、またはサーバーの機能を決定できます。
Responses to this method are not cacheable.
このメソッドへの応答はキャッシュできません。
If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body.
OPTIONSリクエストにエンティティボディが含まれている場合（Content-LengthまたはTransfer-Encodingの存在によって示される）、メディアタイプはContent-Typeフィールドで示される必要があります。この仕様では、このような本文の使用を定義していませんが、HTTPの将来の拡張では、OPTIONS本文を使用してサーバーでより詳細なクエリを作成する可能性があります。そのような拡張をサポートしないサーバーは、リクエストボディを破棄するかもしれません。
If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply 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 compliance (or lack thereof).
Request-URIがアスタリスク（ "*"）の場合、OPTIONS要求は、特定のリソースではなくサーバー全体に適用されることを意図しています。サーバーの通信オプションは通常リソースに依存するため、「*」リクエストは「ping」または「no-op」タイプのメソッドとしてのみ役立ちます。クライアントがサーバーの機能をテストできるようにするだけです。たとえば、これは、HTTP / 1.1コンプライアンス（またはその欠如）のプロキシをテストするために使用できます。
If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource.
Request-URIがアスタリスクでない場合、OPTIONS要求は、そのリソースとの通信時に使用可能なオプションにのみ適用されます。
A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0".
200レスポンスには、サーバーによって実装され、そのリソースに適用可能なオプション機能（許可など）を示すヘッダーフィールドが含まれる必要があります（SHOULD）。応答本文には、もしあれば、通信オプションに関する情報も含まれる必要があります（SHOULD）。そのような本文の形式はこの仕様では定義されていませんが、HTTPの将来の拡張によって定義される可能性があります。コンテンツネゴシエーションは、適切な応答フォーマットを選択するために使用される場合があります。応答本文が含まれていない場合、応答にはフィールド値「0」のContent-Lengthフィールドを含める必要があります。
The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.
Max-Forwardsリクエストヘッダーフィールドを使用して、リクエストチェーン内の特定のプロキシをターゲットにすることができます。プロキシが、リクエストの転送が許可されているabsoluteURIでOPTIONSリクエストを受信した場合、プロキシはMax-Forwardsフィールドを確認する必要があります。 Max-Forwardsフィールド値がゼロ（ "0"）の場合、プロキシはメッセージを転送してはならない（MUST NOT）。代わりに、プロキシは独自の通信オプションで応答する必要があります（SHOULD）。 Max-Forwardsフィールド値がゼロより大きい整数の場合、プロキシはリクエストを転送するときにフィールド値をデクリメントする必要があります。リクエストにMax-Forwardsフィールドが存在しない場合、転送されるリクエストにはMax-Forwardsフィールドを含めてはなりません（MUST NOT）。
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.
GETメソッドは、Request-URIで識別される情報（エンティティーの形式）を取得します。 Request-URIがデータ生成プロセスを参照する場合、そのテキストがたまたまプロセスの出力でない限り、プロセスのソーステキストではなく、応答のエンティティとして返されるのは生成されたデータです。
The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.
リクエストメッセージにIf-Modified-Since、If-Unmodified-Since、If-Match、If-None-Match、またはIf-Rangeヘッダーフィールドが含まれている場合、GETメソッドのセマンティクスは「条件付きGET」に変わります。条件付きGETメソッドは、条件付きヘッダーフィールドで記述された状況でのみエンティティを転送するよう要求します。条件付きGETメソッドは、複数のリクエストを要求したり、クライアントがすでに保持しているデータを転送したりせずに、キャッシュされたエンティティを更新できるようにすることで、不要なネットワーク使用量を減らすことを目的としています。
The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred, as described in section 14.35. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client.
リクエストメッセージにRangeヘッダーフィールドが含まれている場合、GETメソッドのセマンティクスは「部分的なGET」に変わります。部分的なGETは、セクション14.35で説明されているように、エンティティの一部のみを転送することを要求します。部分的なGETメソッドは、クライアントが既に保持しているデータを転送せずに部分的に取得されたエンティティを完了できるようにすることで、不要なネットワーク使用量を減らすことを目的としています。
The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13.
GET要求への応答は、セクション13で説明されているHTTPキャッシングの要件を満たしている場合にのみキャッシュ可能です。
See section 15.1.3 for security considerations when used for forms.
フォームに使用する場合のセキュリティに関する考慮事項については、セクション15.1.3を参照してください。
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.
HEADメソッドは、サーバーが応答でメッセージ本文を返してはならないことを除いて、GETと同じです。 HEADリクエストへの応答でHTTPヘッダーに含まれるメタ情報は、GETリクエストへの応答で送信される情報と同一である必要があります（SHOULD）。このメソッドは、エンティティ本体自体を転送せずに、要求によって暗示されるエンティティに関するメタ情報を取得するために使用できます。この方法は、ハイパーテキストリンクの有効性、アクセシビリティ、および最近の変更をテストするためによく使用されます。
The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.
HEAD要求への応答は、応答に含まれている情報がそのリソースから以前にキャッシュされたエンティティを更新するために使用される場合があるという意味でキャッシュ可能である場合があります。新しいフィールド値が、キャッシュされたエンティティが現在のエンティティと異なることを示す場合（Content-Length、Content-MD5、ETag、またはLast-Modifiedの変更によって示される）、キャッシュはキャッシュエントリを古いものとして扱う必要があります。
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:
POSTメソッドは、要求に含まれるエンティティを、オリジンサーバーがRequest-LineのRequest-URIで識別されるリソースの新しい下位として受け入れることを要求するために使用されます。 POSTは、以下の機能をカバーする統一された方法を可能にするように設計されています。
- Annotation of existing resources;
- 既存のリソースの注釈。
- Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
- 掲示板、ニュースグループ、メーリングリスト、または同様の記事グループにメッセージを投稿する。
- Providing a block of data, such as the result of submitting a form, to a data-handling process;
- フォームの送信結果などのデータブロックをデータ処理プロセスに提供する。
- Extending a database through an append operation.
- 追加操作によるデータベースの拡張。
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.
POSTメソッドによって実行される実際の機能はサーバーによって決定され、通常はRequest-URIに依存します。投稿されたエンティティは、ファイルがそれを含むディレクトリに従属している、ニュース記事が投稿先のニュースグループに従属している、またはレコードがデータベースに従属しているのと同じように、そのURIに従属しています。
The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.
POSTメソッドによって実行されるアクションは、URIで識別できるリソースにならない場合があります。この場合、応答に結果を説明するエンティティが含まれているかどうかに応じて、200（OK）または204（コンテンツなし）が適切な応答ステータスです。
If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).
オリジンサーバーでリソースが作成されている場合、レスポンスは201（作成済み）である必要があり、リクエストのステータスを記述し、新しいリソースを参照するエンティティとロケーションヘッダーを含む必要があります（セクション14.30を参照）。
Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.
このメソッドへの応答は、応答に適切なCache-ControlまたはExpiresヘッダーフィールドが含まれていない限り、キャッシュできません。ただし、303（その他を参照）応答を使用して、ユーザーエージェントにキャッシュ可能なリソースを取得するように指示できます。
POST requests MUST obey the message transmission requirements set out in section 8.2.
POSTリクエストは、セクション8.2に記載されているメッセージ送信要件に従う必要があります。
See section 15.1.3 for security considerations.
セキュリティに関する考慮事項については、セクション15.1.3を参照してください。
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.
PUTメソッドは、囲まれたエンティティが指定されたRequest-URIの下に格納されることを要求します。 Request-URIが既存のリソースを参照している場合、囲まれたエンティティは、起点サーバーに存在するエンティティの変更バージョンと見なされるべきです（SHOULD）。 Request-URIが既存のリソースを指さず、そのURIが要求元のユーザーエージェントによって新しいリソースとして定義できる場合、オリジンサーバーはそのURIでリソースを作成できます。新しいリソースが作成された場合、オリジンサーバーは201（Created）応答を介してユーザーエージェントに通知する必要があります。既存のリソースが変更された場合、200（OK）または204（No Content）応答コードのいずれかを送信して、リクエストが正常に完了したことを示す必要があります。リソースをRequest-URIで作成または変更できなかった場合、問題の性質を反映した適切なエラー応答を提供する必要があります（SHOULD）。エンティティの受信者は、理解または実装していないContent- *（Content-Rangeなど）ヘッダーを無視してはならず（MUST）、そのような場合は501（Not Implemented）応答を返さなければなりません（MUST）。
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
リクエストがキャッシュを通過し、Request-URIが現在キャッシュされている1つ以上のエンティティを識別する場合、それらのエントリは古いものとして扱われる必要があります（SHOULD）。このメソッドへの応答はキャッシュできません。
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.
POST要求とPUT要求の基本的な違いは、Request-URIの異なる意味に反映されています。 POSTリクエストのURIは、囲まれたエンティティを処理するリソースを識別します。そのリソースは、データを受け入れるプロセス、他のプロトコルへのゲートウェイ、または注釈を受け入れる個別のエンティティである可能性があります。対照的に、PUTリクエストのURIは、リクエストに含まれるエンティティを識別します。ユーザーエージェントは、意図するURIを認識しており、サーバーはリクエストを他のリソースに適用してはいけません。サーバーがリクエストを別のURIに適用することを希望する場合、サーバーは301（永久に移動）応答を送信する必要があります。次に、ユーザーエージェントは、リクエストをリダイレクトするかどうかに関して独自の決定を行うことができます。
A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.
単一のリソースは、多くの異なるURIによって識別される場合があります。たとえば、記事には、特定の各バージョンを識別するURIとは別の「現在のバージョン」を識別するためのURIがある場合があります。この場合、一般的なURIに対するPUTリクエストにより、他のいくつかのURIがオリジンサーバーによって定義される可能性があります。
HTTP/1.1 does not define how a PUT method affects the state of an origin server.
HTTP / 1.1は、PUTメソッドがオリジンサーバーの状態にどのように影響するかを定義していません。
PUT requests MUST obey the message transmission requirements set out in section 8.2.
PUTリクエストは、セクション8.2に記載されているメッセージ送信要件に従う必要があります。
Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.
特定のエンティティヘッダーに特に指定されていない限り、PUTリクエストのエンティティヘッダーは、PUTによって作成または変更されたリソースに適用する必要があります（SHOULD）。
The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.
DELETEメソッドは、起点サーバーがRequest-URIで識別されるリソースを削除することを要求します。このメソッドは、オリジンサーバーでの人間の介入（または他の手段）によってオーバーライドされる場合があります。オリジンサーバーから返されたステータスコードがアクションが正常に完了したことを示している場合でも、クライアントは操作が実行されたことを保証できません。ただし、サーバーは、応答が与えられたときに、リソースを削除するか、アクセスできない場所に移動することを意図していない限り、成功を示すべきではありません（SHOULD NOT）。
A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.
成功した応答は、応答にステータスを説明するエンティティが含まれている場合は200（OK）、アクションがまだ実行されていない場合は202（承認済み）、アクションが実行されているが応答に含まれていない場合は204（コンテンツなし）であるべきです（SHOULD）。エンティティ。
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
リクエストがキャッシュを通過し、Request-URIが現在キャッシュされている1つ以上のエンティティを識別する場合、それらのエントリは古いものとして扱われる必要があります（SHOULD）。このメソッドへの応答はキャッシュできません。
The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.
TRACEメソッドは、要求メッセージのリモートのアプリケーション層ループバックを呼び出すために使用されます。リクエストの最後の受信者は、クライアントに返されたメッセージを200（OK）応答のエンティティ本体として反映する必要があります（SHOULD）。最終的な受信者は、元のサーバーか、要求でゼロ（0）のMax-Forwards値を受信する最初のプロキシまたはゲートウェイです（セクション14.31を参照）。 TRACEリクエストにエンティティを含めることはできません。
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 14.45) 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ヘッダーフィールド（セクション14.45）の値は、リクエストチェーンのトレースとして機能するため、特に重要です。 Max-Forwardsヘッダーフィールドを使用すると、クライアントはリクエストチェーンの長さを制限できます。これは、無限ループでメッセージを転送するプロキシのチェーンをテストするのに役立ちます。
If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method MUST NOT be cached.
リクエストが有効である場合、レスポンスはエンティティボディにリクエストメッセージ全体を含み、Content-Typeは「message / http」になります。このメソッドへの応答はキャッシュしてはなりません（MUST NOT）。
This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).
この仕様では、動的にトンネルに切り替えることができるプロキシ（SSLトンネリング[44]など）で使用するために、メソッド名CONNECTが予約されています。
10 Status Code Definitions
10ステータスコードの定義
Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response.
各ステータスコードは、それが従うことができるメソッドの説明と応答で必要なメタ情報を含めて、以下で説明されています。
This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.
このクラスのステータスコードは、Status-Lineとオプションのヘッダーのみで構成される暫定応答を示し、空の行で終了します。このクラスのステータスコードに必要なヘッダーはありません。 HTTP / 1.0は1xxステータスコードを定義しなかったので、サーバーは実験的な状況を除いて、HTTP / 1.0クライアントに1xx応答を送信してはなりません（MUST NOT）。
A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent.
クライアントが100（Continue）ステータスメッセージを期待していない場合でも、クライアントは、通常の応答の前に1つ以上の1xxステータス応答を受け入れる準備をしている必要があります。予期しない1xxステータス応答は、ユーザーエージェントによって無視される場合があります。
Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response. (For example, if a proxy adds a "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 client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code.
クライアントはリクエストを続行する必要があります。この暫定応答は、要求の最初の部分が受信され、サーバーによってまだ拒否されていないことをクライアントに通知するために使用されます。クライアントは、残りのリクエストを送信して続行する必要があります（SHOULD）。リクエストがすでに完了している場合は、このレスポンスを無視してください。サーバーは、要求が完了した後に最終応答を送信する必要があります。このステータスコードの使用と処理の詳細については、セクション8.2.3を参照してください。
The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
サーバーは、この接続で使用されているアプリケーションプロトコルの変更について、Upgradeメッセージヘッダーフィールド（セクション14.42）を介してクライアントの要求を理解し、これに応じます。サーバーは、101応答を終了する空の行の直後に、プロトコルを応答のUpgradeヘッダーフィールドで定義されたプロトコルに切り替えます。
The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.
プロトコルは、そうすることが有利な場合にのみ切り替えるべきです（SHOULD）。たとえば、HTTPの新しいバージョンへの切り替えは古いバージョンよりも有利であり、リアルタイムの同期プロトコルへの切り替えは、そのような機能を使用するリソースを配信するときに有利になる場合があります。
This class of status code indicates that the client's request was successfully received, understood, and accepted.
このクラスのステータスコードは、クライアントのリクエストが正常に受信され、理解され、受け入れられたことを示します。
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
リクエストは成功しました。応答で返される情報は、要求で使用されたメソッドによって異なります。次に例を示します。
GET an entity corresponding to the requested resource is sent in the response;
GET要求されたリソースに対応するエンティティが応答で送信されます。
HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
HEAD要求されたリソースに対応するエンティティヘッダーフィールドは、メッセージ本文なしで応答で送信されます。
POST an entity describing or containing the result of the action;
アクションの結果を説明または含むエンティティをPOSTします。
TRACE an entity containing the request message as received by the end server.
エンドサーバーが受信した要求メッセージを含むエンティティを追跡します。
The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.
リクエストが満たされ、新しいリソースが作成されました。新しく作成されたリソースは、応答のエンティティで返されるURIで参照できます。リソースの最も具体的なURIは、Locationヘッダーフィールドで指定されます。応答には、ユーザーまたはユーザーエージェントが最も適切なものを選択できるリソースの特性と場所のリストを含むエンティティを含める必要があります（SHOULD）。エンティティ形式は、Content-Typeヘッダーフィールドで指定されたメディアタイプによって指定されます。オリジンサーバーは、201ステータスコードを返す前にリソースを作成する必要があります。アクションをすぐに実行できない場合、サーバーは代わりに202（Accepted）応答で応答する必要があります（SHOULD）。
A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.
201応答には、作成されたばかりの要求されたバリアントのエンティティタグの現在の値を示すETag応答ヘッダーフィールドが含まれる場合があります（セクション14.19を参照）。
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 for re-sending a status code from an asynchronous operation such as this.
リクエストは処理のために受け入れられましたが、処理は完了していません。処理が実際に行われるときに許可されない場合があるため、要求は最終的に処理される場合と処理されない場合があります。このような非同期操作からステータスコードを再送信する機能はありません。
The 202 response is intentionally non-committal. 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 entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
202の応答は、意図的にコミットメントされていません。その目的は、サーバーがユーザーエージェントのサーバーへの接続をプロセスが完了するまで維持することを必要とせずに、サーバーが他のプロセス（おそらく1日に1回だけ実行されるバッチ指向のプロセス）の要求を受け入れることを許可することです。このレスポンスで返されるエンティティには、リクエストの現在のステータスの表示と、ステータスモニターへのポインターまたはユーザーがリクエストが実行されると予想できる時期の推定値のいずれかが含まれている必要があります。
The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).
エンティティヘッダーで返されるメタ情報は、オリジンサーバーから入手できる決定的なセットではなく、ローカルまたはサードパーティのコピーから収集されます。提示されたセットは、元のバージョンのサブセットまたはスーパーセットである場合があります。たとえば、リソースに関するローカルの注釈情報を含めると、配信元サーバーで認識されるメタ情報のスーパーセットが生成される場合があります。この応答コードの使用は必須ではなく、応答が200（OK）である場合にのみ適切です。
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.
サーバーは要求を満たしていますが、エンティティ本体を返す必要はなく、更新されたメタ情報を返したい場合があります。応答には、エンティティヘッダーの形式で新しいメタ情報または更新されたメタ情報を含めることができます。
If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.
クライアントがユーザーエージェントである場合、リクエストの送信を引き起こしたものからドキュメントビューを変更するべきではありません（SHOULD NOT）。この応答は主に、ユーザーエージェントのアクティブなドキュメントビューに変更を加えずにアクションの入力を可能にすることを目的としていますが、新しいまたは更新されたメタ情報は、現在ユーザーエージェントのアクティブなビューにあるドキュメントに適用する必要があります。
The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
204応答にはメッセージ本文を含めてはならないため、常にヘッダーフィールドの後の最初の空行で終了します。
The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.
サーバーは要求を満たし、ユーザーエージェントは、要求が送信される原因となったドキュメントビューをリセットする必要があります（SHOULD）。この応答は主に、ユーザー入力を介してアクションの入力を許可し、続いてユーザーが別の入力アクションを簡単に開始できるように、入力が行われたフォームをクリアできるようにすることを目的としています。応答にエンティティを含めることはできません。
The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional.
サーバーはリソースの部分的なGETリクエストを実行しました。リクエストには、希望する範囲を示すRangeヘッダーフィールド（セクション14.35）を含める必要があり、リクエストを条件付きにするためにIf-Rangeヘッダーフィールド（セクション14.27）を含めることができます（MAY）。
The response MUST include the following header fields:
応答には、次のヘッダーフィールドを含める必要があります。
- Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body.
- この応答に含まれる範囲を示すContent-Rangeヘッダーフィールド（セクション14.16）、または各パートのContent-Rangeフィールドを含むmultipart / byteranges Content-Typeのいずれか。 Content-Lengthヘッダーフィールドが応答に存在する場合、その値は、メッセージ本文で送信される実際のOCTETの数と一致する必要があります。
- Date
- 日付
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- ETagおよび/またはContent-Location（ヘッダーが同じリクエストに対する200応答で送信された場合）
- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
- Expires、Cache-Control、および/またはVary（同じバリアントの以前の応答で送信されたものとフィールド値が異なる場合）
If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
206応答が、強力なキャッシュバリデーター（セクション13.3.3を参照）を使用したIf-Rangeリクエストの結果である場合、応答には他のエンティティヘッダーを含めないでください。応答が弱いバリデーターを使用したIf-Rangeリクエストの結果である場合、応答には他のエンティティヘッダーを含めることはできません。これにより、キャッシュされたエンティティー本体と更新されたヘッダーの間の不整合が防止されます。それ以外の場合、応答には、同じ要求に対する200（OK）応答で返されるすべてのエンティティヘッダーを含める必要があります。
A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4.
ETagまたはLast-Modifiedヘッダーが正確に一致しない場合、キャッシュは206応答を以前にキャッシュされた他のコンテンツと組み合わせてはなりません（MUST）。13.5.4を参照してください。
A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.
RangeおよびContent-Rangeヘッダーをサポートしないキャッシュは、206（部分）応答をキャッシュしてはなりません（MUST NOT）。
This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.
このクラスのステータスコードは、要求を満たすためにユーザーエージェントがさらにアクションを実行する必要があることを示します。 2番目のリクエストで使用されるメソッドがGETまたはHEADの場合に限り、必要なアクションはユーザーとの対話なしにユーザーエージェントによって実行される場合があります。このようなループはリダイレクトごとにネットワークトラフィックを生成するため、クライアントは無限のリダイレクトループを検出する必要があります（SHOULD）。
Note: previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation.
注：この仕様の以前のバージョンでは、最大5つのリダイレクトを推奨していました。コンテンツ開発者は、このような固定された制限を実装するクライアントが存在する可能性があることを認識する必要があります。
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.
要求されたリソースは、それぞれ独自の特定の場所を持つ一連の表現のいずれかに対応し、ユーザー（またはユーザーエージェント）が優先表現を選択してリダイレクトできるように、エージェント駆動の交渉情報（セクション12）が提供されますその場所へのリクエスト。
Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.
HEADリクエストでない限り、レスポンスには、ユーザーまたはユーザーエージェントが最も適切なものを選択できるリソースの特性と場所のリストを含むエンティティが含まれる必要があります（SHOULD）。エンティティ形式は、Content-Typeヘッダーフィールドで指定されたメディアタイプによって指定されます。ユーザーエージェントの形式と機能に応じて、最も適切な選択肢の選択が自動的に実行される場合があります。ただし、この仕様では、このような自動選択の標準を定義していません。
If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.
サーバーが適切な表現の選択肢を持っている場合、その表現に固有のURIをLocationフィールドに含める必要があります。ユーザーエージェントは、自動リダイレクトにLocationフィールド値を使用できます。特に指定のない限り、この応答はキャッシュ可能です。
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
リクエストされたリソースには新しい永続的なURIが割り当てられており、このリソースへの今後の参照では、返されたURIの1つを使用する必要があります。リンク編集機能を持つクライアントは、Request-URIへの参照を、可能であればサーバーから返される1つ以上の新しい参照に自動的に再リンクする必要があります。特に指定のない限り、この応答はキャッシュ可能です。
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
新しい永続URIは、応答のLocationフィールドで指定する必要があります（SHOULD）。リクエストメソッドがHEADでない限り、レスポンスのエンティティには、新しいURIへのハイパーリンクを含む短いハイパーテキストノートを含める必要があります（SHOULD）。
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
GETまたはHEAD以外のリクエストへの応答として301ステータスコードを受信した場合、ユーザーエージェントは、リクエストが発行された条件を変更する可能性があるため、ユーザーが確認できない限り、リクエストを自動的にリダイレクトしてはなりません。
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
注：POSTリクエストを301ステータスコードを受け取った後で自動的にリダイレクトすると、一部の既存のHTTP / 1.0ユーザーエージェントが誤ってそれをGETリクエストに変更します。
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
リクエストされたリソースは一時的に別のURIに存在します。リダイレクトは時々変更される可能性があるため、クライアントは今後のリクエストに引き続きRequest-URIを使用する必要があります（SHOULD）。この応答は、Cache-ControlまたはExpiresヘッダーフィールドで示されている場合にのみキャッシュ可能です。
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
一時URIは、応答のLocationフィールドで指定する必要があります（SHOULD）。リクエストメソッドがHEADでない限り、レスポンスのエンティティには、新しいURIへのハイパーリンクを含む短いハイパーテキストノートを含める必要があります（SHOULD）。
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
GETまたはHEAD以外のリクエストに応答して302ステータスコードを受信した場合、ユーザーエージェントは、ユーザーが確認できない限り、リクエストを自動的にリダイレクトしてはなりません。これにより、リクエストが発行された条件が変わる可能性があります。
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
注：RFC 1945およびRFC 2068では、クライアントがリダイレクトされた要求のメソッドを変更できないように指定されています。ただし、既存のほとんどのユーザーエージェント実装では、302を303応答のように扱い、元のリクエストメソッドに関係なく、Locationフィールドの値に対してGETを実行します。ステータスコード303と307は、クライアントにどのような反応が期待されるかを明確にしたいサーバー用に追加されました。
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
リクエストへの応答は別のURIで見つけることができ、そのリソースでGETメソッドを使用して取得する必要があります。このメソッドは主に、POSTでアクティブ化されたスクリプトの出力がユーザーエージェントを選択したリソースにリダイレクトできるようにするために存在します。新しいURIは、最初に要求されたリソースの代替参照ではありません。 303応答はキャッシュしてはなりません（MUST NOT）が、2番目の（リダイレクトされた）要求への応答はキャッシュ可能である可能性があります。
The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
異なるURIは、応答のLocationフィールドで指定する必要があります（SHOULD）。リクエストメソッドがHEADでない限り、レスポンスのエンティティには、新しいURIへのハイパーリンクを含む短いハイパーテキストノートを含める必要があります（SHOULD）。
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
注：HTTP / 1.1より前のユーザーエージェントの多くは、303ステータスを理解していません。このようなクライアントとの相互運用性が懸念される場合は、ほとんどのユーザーエージェントがここで303について説明するように302応答に反応するため、代わりに302ステータスコードを使用できます。
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.
クライアントが条件付きGETリクエストを実行し、アクセスは許可されているが、ドキュメントが変更されていない場合、サーバーはこのステータスコードで応答する必要があります（SHOULD）。 304応答にはメッセージ本文を含めてはならないため、常にヘッダーフィールドの後の最初の空行で終了します。
The response MUST include the following header fields:
応答には、次のヘッダーフィールドを含める必要があります。
- Date, unless its omission is required by section 14.18.1
- 日付、セクション14.18.1で省略が必要な場合を除く
If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.
クロックレスオリジンサーバーがこれらのルールに従い、プロキシとクライアントが応答なしで受信した応答に独自の日付を追加する場合（[RFC 2068]のセクション14.19ですでに指定されているように）、キャッシュは正しく動作します。
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- ETagおよび/またはContent-Location（ヘッダーが同じリクエストに対する200応答で送信された場合）
- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
- Expires、Cache-Control、および/またはVary（同じバリアントの以前の応答で送信されたものとフィールド値が異なる場合）
If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
条件付きGETが強力なキャッシュバリデーターを使用した場合（セクション13.3.3を参照）、応答には他のエンティティヘッダーを含めないでください。それ以外の場合（つまり、条件付きGETが弱いバリデーターを使用した場合）、応答に他のエンティティヘッダーを含めることはできません。これにより、キャッシュされたエンティティー本体と更新されたヘッダーの間の不整合が防止されます。
If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.
304応答が、現在キャッシュされていないエンティティを示している場合、キャッシュは応答を無視し、条件なしで要求を繰り返す必要があります。
If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.
キャッシュが受信した304応答を使用してキャッシュエントリを更新する場合、キャッシュは応答で指定された新しいフィールド値を反映するようにエントリを更新する必要があります。
The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.
要求されたリソースは、Locationフィールドで指定されたプロキシを介してアクセスする必要があります。 LocationフィールドはプロキシのURIを示します。受信者は、プロキシ経由でこの単一の要求を繰り返すことが期待されています。 305応答は、オリジンサーバーによってのみ生成される必要があります。
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences.
注：RFC 2068は、305が単一の要求をリダイレクトすること、およびオリジンサーバーによってのみ生成されることを目的としていたことを明確にしていませんでした。これらの制限を守らないと、セキュリティに重大な影響があります。
The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.
306ステータスコードは、以前のバージョンの仕様で使用されていたもので、現在は使用されていません。コードは予約されています。
The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
リクエストされたリソースは一時的に別のURIに存在します。リダイレクションは時々変更される可能性があるため、クライアントは今後のリクエストに引き続きRequest-URIを使用する必要があります（SHOULD）。この応答は、Cache-ControlまたはExpiresヘッダーフィールドで示されている場合にのみキャッシュ可能です。
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.
一時URIは、応答のLocationフィールドで指定する必要があります（SHOULD）。リクエストメソッドがHEADでない限り、多くのHTTP / 1.1より前のユーザーエージェントは307ステータスを理解できないため、レスポンスのエンティティには、新しいURIへのハイパーリンクを含む短いハイパーテキストノートを含める必要があります。したがって、メモには、ユーザーが新しいURIで元の要求を繰り返すために必要な情報が含まれている必要があります（SHOULD）。
If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
GETまたはHEAD以外のリクエストへの応答として307ステータスコードを受け取った場合、ユーザーエージェントは、ユーザーが確認できない限り、リクエストを自動的にリダイレクトしてはなりません。これは、リクエストが発行された条件を変更する可能性があるためです。
The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity 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 entity to the user.
ステータスコードの4xxクラスは、クライアントにエラーが発生したと思われる場合を対象としています。 HEADリクエストに応答する場合を除いて、サーバーは、エラー状況の説明を含むエンティティ、およびそれが一時的な状態か永続的な状態かを含めるべきです（SHOULD）。これらのステータスコードは、どのリクエストメソッドにも適用できます。ユーザーエージェントは、含まれるエンティティをユーザーに表示する必要があります（SHOULD）。
If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application.
クライアントがデータを送信している場合、サーバーが入力接続を閉じる前に、TCPを使用するサーバー実装は、クライアントが応答を含むパケットの受信を確認するように注意する必要があります。クライアントが閉じた後もサーバーにデータを送信し続ける場合、サーバーのTCPスタックはリセットパケットをクライアントに送信します。これにより、クライアントの未確認の入力バッファーがHTTPアプリケーションによって読み取られ解釈される前に消去される場合があります。
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
不正な構文のため、サーバーはリクエストを理解できませんでした。クライアントは変更せずにリクエストを繰り返すべきではありません。
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].
リクエストにはユーザー認証が必要です。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールド（セクション14.47）を含める必要があります。クライアントは適切なAuthorizationヘッダーフィールド（セクション14.8）を使用してリクエストを繰り返すことができます（MAY）。要求にすでに認証資格情報が含まれている場合、401応答は、それらの資格情報の認証が拒否されたことを示します。 401応答に前の応答と同じチャレンジが含まれていて、ユーザーエージェントが少なくとも1回は認証を試みている場合、エンティティには関連する診断情報が含まれている可能性があるため、ユーザーは応答で指定されたエンティティを提示する必要があります（SHOULD）。 HTTPアクセス認証については、「HTTP認証：基本およびダイジェストアクセス認証」[43]で説明しています。
This code is reserved for future use.
このコードは将来の使用のために予約されています。
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。リクエストメソッドがHEADではなく、サーバーがリクエストが実行されなかった理由を公開したい場合は、エンティティで拒否の理由を説明する必要があります。サーバーがこの情報をクライアントに提供したくない場合は、代わりにステータスコード404（見つかりません）を使用できます。
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
サーバーは、Request-URIに一致するものを検出しませんでした。状態が一時的であるか永続的であるかは示されません。 410（Gone）ステータスコードは、サーバーが内部的に構成可能なメカニズムを介して、古いリソースが永続的に利用できず、転送アドレスがないことを知っている場合に使用する必要があります（SHOULD）。このステータスコードは、サーバーがリクエストが拒否された理由を正確に明らかにしたくない場合、または他の応答が該当しない場合に一般的に使用されます。
The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.
Request-Lineで指定されたメソッドは、Request-URIで識別されるリソースには許可されていません。応答には、要求されたリソースの有効なメソッドのリストを含むAllowヘッダーを含める必要があります。
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.
リクエストで識別されたリソースは、リクエストで送信されたAcceptヘッダーに応じて許容できないコンテンツ特性を持つレスポンスエンティティのみを生成できます。
Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.
HEADリクエストでない限り、レスポンスには、ユーザーまたはユーザーエージェントが最も適切なものを選択できる、利用可能なエンティティの特性と場所のリストを含むエンティティが含まれる必要があります（SHOULD）。エンティティ形式は、Content-Typeヘッダーフィールドで指定されたメディアタイプによって指定されます。ユーザーエージェントの形式と機能に応じて、最も適切な選択肢の選択が自動的に実行される場合があります。ただし、この仕様では、このような自動選択の標準を定義していません。
Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.
注：HTTP / 1.1サーバーは、リクエストで送信されたAcceptヘッダーに応じて受け入れられない応答を返すことができます。場合によっては、これは406応答を送信するよりも望ましいことがあります。ユーザーエージェントは、受信応答のヘッダーを検査して、それが受け入れ可能かどうかを判断することをお勧めします。
If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.
応答が受け入れられない可能性がある場合、ユーザーエージェントは、追加のデータの受信を一時的に停止し、ユーザーにクエリを実行して、その後のアクションの決定を求めます。
This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].
このコードは401（Unauthorized）に似ていますが、クライアントが最初にプロキシで自身を認証する必要があることを示しています。プロキシは、要求されたリソースのプロキシに適用可能なチャレンジを含むProxy-Authenticateヘッダーフィールド（セクション14.33）を返す必要があります。クライアントは適切なProxy-Authorizationヘッダーフィールド（セクション14.34）を使用してリクエストを繰り返すことができます（MAY）。 HTTPアクセス認証については、「HTTP認証：基本およびダイジェストアクセス認証」[43]で説明しています。
The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
サーバーが待機する準備ができている時間内に、クライアントが要求を生成しませんでした。クライアントは、いつでも変更なしでリクエストを繰り返すことができます。
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
リソースの現在の状態と競合しているため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。レスポンスボディには、ユーザーが競合の原因を認識するのに十分な情報を含める必要があります（SHOULD）。理想的には、応答エンティティには、ユーザーまたはユーザーエージェントが問題を修正するのに十分な情報が含まれます。ただし、それは不可能であり、必須ではありません。
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
競合は、PUTリクエストへの応答で発生する可能性が最も高いです。たとえば、バージョニングが使用されていて、PUTされるエンティティにリソースへの変更が含まれており、それが以前の（サードパーティ）リクエストによる変更と競合する場合、サーバーは409レスポンスを使用してリクエストを完了できないことを示す場合があります。 。この場合、応答エンティティには、応答のContent-Typeで定義された形式で2つのバージョンの違いのリストが含まれている可能性があります。
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.
要求されたリソースはサーバーで使用できなくなり、転送先アドレスが不明です。この状態は永続的であると考えられています。リンク編集機能を持つクライアントは、ユーザーの承認後にRequest-URIへの参照を削除する必要があります（SHOULD）。サーバーが状態が永続的であるかどうかを判断できない、または判断する機能がない場合は、代わりにステータスコード404（見つかりません）を使用する必要があります（SHOULD）。特に指定のない限り、この応答はキャッシュ可能です。
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 working at the 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メンテナンスのタスクを支援することを目的としています。このようなイベントは、期間限定のプロモーションサービスや、サーバーのサイトで働いていない個人が所有するリソースに共通です。永続的に利用できないリソースをすべて「存在しない」としてマークしたり、マークを任意の期間保持したりする必要はありません。これはサーバーの所有者の裁量に任されています。
The server refuses to accept the request without a defined Content-Length. 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.
サーバーは、定義されたContent-Lengthなしで要求を受け入れることを拒否します。クライアントは、リクエストメッセージにメッセージ本文の長さを含む有効なContent-Lengthヘッダーフィールドを追加した場合、リクエストを繰り返すことができます。
The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.
サーバーでテストされたときに、1つ以上のリクエストヘッダーフィールドに指定された前提条件がfalseと評価されました。この応答コードにより、クライアントは現在のリソースのメタ情報（ヘッダーフィールドデータ）に前提条件を設定できるため、要求されたメソッドが意図したもの以外のリソースに適用されるのを防ぐことができます。
The server is refusing to process a request because the request entity 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.
要求エンティティーがサーバーが処理できるか、処理できるよりも大きいため、サーバーは要求の処理を拒否しています。サーバーは接続を閉じて、クライアントがリクエストを続行できないようにすることができます。
If the condition is temporary, the server SHOULD include a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.
条件が一時的なものである場合、サーバーはRetry-Afterヘッダーフィールドを含めて、それが一時的なものであること、およびクライアントが再試行する可能性のある時間を示す必要があります。
The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "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 security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI.
Request-URIがサーバーが解釈するよりも長いため、サーバーは要求の処理を拒否しています。このまれな状態が発生する可能性が高いのは、クライアントがPOSTリクエストを長いクエリ情報を含むGETリクエストに不適切に変換した場合、クライアントがリダイレクトのURI「ブラックホール」（たとえば、それ自体のサフィックス）、または要求URIの読み取りまたは操作に固定長バッファーを使用して一部のサーバーに存在するセキュリティホールを悪用しようとするクライアントによる攻撃を受けている場合。
The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.
リクエストのエンティティがリクエストされたメソッドのリクエストされたリソースでサポートされていない形式であるため、サーバーはリクエストの処理を拒否しています。
A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)
リクエストにRangeリクエストヘッダーフィールド（セクション14.35）が含まれ、このフィールドのどの範囲指定子値も選択されたリソースの現在の範囲と重複せず、リクエストが失敗した場合、サーバーはこのステータスコードで応答を返す必要があります（SHOULD）。 If-Rangeリクエストヘッダーフィールドを含めます。 （バイト範囲の場合、これは、すべてのバイト範囲指定値の最初のバイト位置が、選択したリソースの現在の長さよりも大きかったことを意味します。）
When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content-type.
このステータスコードがバイト範囲リクエストに対して返される場合、レスポンスには、選択されたリソースの現在の長さを指定するContent-Rangeエンティティヘッダーフィールドが含まれる必要があります（セクション14.16を参照）。この応答はmultipart / byteranges content-typeを使用してはなりません（MUST NOT）。
The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.
Expectリクエストヘッダーフィールド（セクション14.20を参照）で指定された期待値がこのサーバーで満たされなかったか、サーバーがプロキシの場合、次のホップのサーバーで要求が満たされなかったという明確な証拠がサーバーにあります。
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method.
数字「5」で始まる応答ステータスコードは、サーバーがエラーを検出したか、要求を実行できないことをサーバーが認識している場合を示します。 HEADリクエストに応答する場合を除いて、サーバーは、エラー状況の説明を含むエンティティ、およびそれが一時的な状態か永続的な状態かを含めるべきです（SHOULD）。ユーザーエージェントは、含まれるエンティティをユーザーに表示する必要があります（SHOULD）。これらの応答コードは、すべての要求メソッドに適用できます。
The server encountered an unexpected condition which prevented it from fulfilling the request.
サーバーで予期しない状態が発生したため、要求を実行できませんでした。
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.
サーバーは、要求を満たすために必要な機能をサポートしていません。これは、サーバーが要求メソッドを認識せず、どのリソースに対してもそれをサポートできない場合の適切な応答です。
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
サーバーは、ゲートウェイまたはプロキシとして機能しているときに、要求を満たすためにアクセスした上流サーバーから無効な応答を受け取りました。
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
サーバーの一時的な過負荷またはメンテナンスのため、サーバーは現在リクエストを処理できません。これは、これが一時的な状態であり、少し遅れて緩和されることを意味します。既知の場合、遅延の長さはRetry-Afterヘッダーで示される場合があります。 Retry-Afterが指定されていない場合、クライアントは500応答の場合と同様に応答を処理する必要があります（SHOULD）。
Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.
注：503ステータスコードの存在は、サーバーが過負荷になったときにそれを使用する必要があることを意味しません。一部のサーバーは、単に接続を拒否したい場合があります。
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
サーバーは、ゲートウェイまたはプロキシとして機能しているときに、URIで指定された上流サーバー（HTTP、FTP、LDAPなど）またはその他の補助サーバー（DNSなど）からタイムリーな応答を受信しませんでした。リクエスト。
Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.
注：実装者への注意：一部のデプロイ済みプロキシは、DNSルックアップがタイムアウトすると400または500を返すことがわかっています。
The server does not support, or refuses to support, the HTTP protocol version 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 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.
サーバーは、要求メッセージで使用されたHTTPプロトコルバージョンをサポートしていないか、サポートを拒否します。サーバーは、セクション3.1で説明されているように、クライアントと同じメジャーバージョンを使用して、このエラーメッセージ以外の要求を完了できないか、または実行する意思がないことを示しています。応答には、そのバージョンがサポートされていない理由と、そのサーバーでサポートされている他のプロトコルを説明するエンティティが含まれている必要があります（SHOULD）。
11 Access Authentication
11アクセス認証
HTTP provides several OPTIONAL challenge-response authentication mechanisms which can be used by a server to challenge a client request and by a client to provide authentication information. The general framework for access authentication, and the specification of "basic" and "digest" authentication, are specified in "HTTP Authentication: Basic and Digest Access Authentication" [43]. This specification adopts the definitions of "challenge" and "credentials" from that specification.
HTTPは、サーバーがクライアント要求にチャレンジするために使用したり、クライアントが認証情報を提供したりするために使用できるいくつかのオプションのチャレンジ/レスポンス認証メカニズムを提供します。アクセス認証の一般的なフレームワーク、および「基本」および「ダイジェスト」認証の仕様は、「HTTP認証：基本およびダイジェストアクセス認証」[43]で指定されています。この仕様では、その仕様からの「チャレンジ」と「クレデンシャル」の定義を採用しています。
12 Content Negotiation
12コンテンツ交渉
Most HTTP responses include an entity which contains information for interpretation by a human user. Naturally, it is desirable to supply the user with the "best available" entity corresponding to the request. Unfortunately for servers and caches, not all users have the same preferences for what is "best," and not all user agents are equally capable of rendering all entity types. For that reason, HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the best representation for a given response when there are multiple representations available.
ほとんどのHTTP応答には、人間のユーザーが解釈するための情報を含むエンティティが含まれています。当然のことながら、リクエストに対応する「最適な」エンティティをユーザーに提供することが望ましいです。残念ながら、サーバーとキャッシュについては、すべてのユーザーが「最良」のものについて同じ設定を持っているわけではなく、すべてのユーザーエージェントがすべてのエンティティタイプを同等にレンダリングできるわけではありません。そのため、HTTPには、「コンテンツネゴシエーション」のメカニズムがいくつか用意されています。これは、複数の表現が利用可能な場合に、特定の応答に最適な表現を選択するプロセスです。
Note: This is not called "format negotiation" because the alternate representations may be of the same media type, but use different capabilities of that type, be in different languages, etc.
注：代替表現は同じメディアタイプであっても、そのタイプの異なる機能を使用したり、異なる言語で使用したりするため、これは「フォーマットネゴシエーション」と呼ばれません。
Any response containing an entity-body MAY be subject to negotiation, including error responses.
エンティティ本体を含む応答は、エラー応答を含め、交渉の対象となる場合があります。
There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two kinds of negotiation are orthogonal and thus may be used separately or in combination. One method of combination, referred to as transparent negotiation, occurs when a cache uses the agent-driven negotiation information provided by the origin server in order to provide server-driven negotiation for subsequent requests.
HTTPで可能なコンテンツネゴシエーションには、サーバー駆動型とエージェント駆動型の2種類があります。これらの2種類のネゴシエーションは直交しているため、個別にまたは組み合わせて使用できます。透過的ネゴシエーションと呼ばれる1つの組み合わせ方法は、後続の要求にサーバー主導のネゴシエーションを提供するために、キャッシュがオリジンサーバーによって提供されたエージェント主導のネゴシエーション情報を使用するときに発生します。
If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g. language, content-coding, etc.) and the contents of particular header fields in the request message or on other information pertaining to the request (such as the network address of the client).
応答の最適な表現の選択がサーバーにあるアルゴリズムによって行われる場合、それはサーバー駆動のネゴシエーションと呼ばれます。選択は、応答の利用可能な表現（変化する可能性のある次元、たとえば言語、コンテンツコーディングなど）と、要求メッセージ内の特定のヘッダーフィールドの内容、または要求に関連するその他の情報（たとえば、クライアントのネットワークアドレスとして）。
Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult to describe to the user agent, or when the server desires to send its "best guess" to the client 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, the user agent MAY include request header fields (Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response.
サーバー主導のネゴシエーションは、利用可能な表現から選択するアルゴリズムがユーザーエージェントに説明するのが難しい場合、またはサーバーが最初の応答と一緒にその「最良の推測」をクライアントに送信することを望む場合に有利です（回避するため） 「最良の推測」がユーザーにとって十分である場合、後続のリクエストの往復遅延）。サーバーの推測を改善するために、ユーザーエージェントは、そのような応答の設定を記述する要求ヘッダーフィールド（Accept、Accept-Language、Accept-Encodingなど）を含めることができます（MAY）。
Server-driven negotiation has disadvantages:
サーバー主導のネゴシエーションには欠点があります。
1. 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?).
1. ユーザーエージェントの機能と応答の使用目的の両方について完全な知識が必要となるため（たとえば、ユーザーが表示したい場合など）、サーバーが特定のユーザーにとって「最適」なものを正確に決定することは不可能です。画面に表示するか、紙に印刷しますか？）。
2. 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 violation of the user's privacy.
2. ユーザーエージェントにすべてのリクエストでその機能を説明させることは非常に非効率的であり（応答のごく一部のみが複数の表現を持つ場合）、ユーザーのプライバシーの潜在的な違反となる可能性があります。
3. It complicates the implementation of an origin server and the algorithms for generating responses to a request.
3. オリジンサーバーの実装と、リクエストへの応答を生成するためのアルゴリズムが複雑になります。
4. It may limit a public cache's ability to use the same response for multiple user's requests.
4. 複数のユーザーの要求に対して同じ応答を使用するパブリックキャッシュの機能が制限される場合があります。
HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent capabilities and user preferences: Accept (section 14.1), Accept-Charset (section 14.2), Accept-Encoding (section 14.3), Accept-Language (section 14.4), and User-Agent (section 14.43). However, an origin server is not limited to these dimensions and MAY vary the response based on any aspect of the request, including information outside the request-header fields or within extension header fields not defined by this specification.
HTTP / 1.1には、ユーザーエージェント機能とユーザー設定の説明を通じてサーバー主導のネゴシエーションを有効にするための次のリクエストヘッダーフィールドが含まれています：Accept（セクション14.1）、Accept-Charset（セクション14.2）、Accept-Encoding（セクション14.3）、Accept-言語（セクション14.4）、およびユーザーエージェント（セクション14.43）。ただし、オリジンサーバーはこれらのディメンションに限定されず、リクエストヘッダーフィールドの外側またはこの仕様で定義されていない拡張ヘッダーフィールド内の情報を含め、リクエストのあらゆる側面に基づいて応答を変更する場合があります。
The Vary header field can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation. See section 13.6 for use of the Vary header field by caches and section 14.44 for use of the Vary header field by servers.
Varyヘッダーフィールドは、サーバー主導のネゴシエーションの対象となる表現を選択するためにサーバーが使用するパラメーターを表すために使用できます。キャッシュによるVaryヘッダーフィールドの使用についてはセクション13.6を、サーバーによるVaryヘッダーフィールドの使用についてはセクション14.44を参照してください。
With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving an initial response from the origin server. Selection is based on a list of the available representations of the response included within the header fields or entity-body of the initial response, with each representation identified by its own URI. Selection from among the representations may be performed automatically (if the user agent is capable of doing so) or manually by the user selecting from a generated (possibly hypertext) menu.
エージェント駆動のネゴシエーションでは、応答の最適な表現の選択は、オリジンサーバーから初期応答を受け取った後にユーザーエージェントによって実行されます。選択は、最初の応答のヘッダーフィールドまたはエンティティ本体に含まれる応答の利用可能な表現のリストに基づいており、各表現は独自のURIで識別されます。表現の中からの選択は、自動的に（ユーザーエージェントがそうすることができる場合）、または生成された（おそらくハイパーテキストの）メニューからユーザーが選択することによって手動で実行できます。
Agent-driven 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.
エージェント主導のネゴシエーションは、一般的に使用される次元（タイプ、言語、エンコーディングなど）で応答が異なる場合、元のサーバーがリクエストの検査からユーザーエージェントの機能を判別できない場合、および一般にパブリックキャッシュがサーバーの負荷を分散し、ネットワークの使用量を減らすために使用されます。
Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation. This second request is only efficient when caching is used. In addition, this specification does not define any mechanism for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension and used within HTTP/1.1.
エージェント主導のネゴシエーションは、最適な代替表現を取得するために2番目の要求が必要になるという欠点があります。この2番目のリクエストは、キャッシングが使用されている場合にのみ効率的です。さらに、この仕様では、自動選択をサポートするメカニズムは定義されていませんが、そのようなメカニズムが拡張機能として開発されてHTTP / 1.1内で使用されることを妨げるものではありません。
HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using server-driven negotiation.
HTTP / 1.1は、サーバー主導のネゴシエーションを使用してさまざまな応答を提供したくない、または提供できない場合にエージェント主導のネゴシエーションを有効にするための300（Multiple Choices）および406（Not Acceptable）ステータスコードを定義します。
Transparent negotiation is a combination of both server-driven and agent-driven negotiation. When a cache is supplied with a form of the list of available representations of the response (as in agent-driven negotiation) and the dimensions of variance are completely understood by the cache, then the cache becomes capable of performing server-driven negotiation on behalf of the origin server for subsequent requests on that resource.
透過的なネゴシエーションは、サーバー主導とエージェント主導の両方のネゴシエーションの組み合わせです。 （エージェント主導のネゴシエーションのように）応答の利用可能な表現のリストの形式でキャッシュが提供され、分散の次元がキャッシュによって完全に理解されると、キャッシュはサーバー主導のネゴシエーションを実行できるようになります。そのリソースに対する後続のリクエストのためのオリジンサーバーの。
Transparent negotiation has the advantage of distributing the negotiation work that would otherwise be required of the origin server and also removing the second request delay of agent-driven negotiation when the cache is able to correctly guess the right response.
透過的なネゴシエーションには、本来であればオリジンサーバーに必要となるネゴシエーション作業を分散し、キャッシュが正しい応答を正しく推測できる場合にエージェント主導のネゴシエーションの2番目の要求遅延を取り除くという利点があります。
This specification does not define any mechanism for transparent negotiation, though it also does not prevent any such mechanism from being developed as an extension that could be used within HTTP/1.1.
この仕様は、透過的なネゴシエーションのメカニズムを定義していませんが、HTTP / 1.1内で使用できる拡張機能としてのそのようなメカニズムの開発を妨げていません。
13 Caching in HTTP
13 HTTPでのキャッシュ
HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible. Because these elements are inextricable from other aspects of the protocol, and because they interact with each other, it is useful to describe the basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc.
HTTPは通常、応答キャッシュを使用することでパフォーマンスを向上できる分散情報システムに使用されます。 HTTP / 1.1プロトコルには、キャッシングを可能な限り機能させることを目的とした多数の要素が含まれています。これらの要素はプロトコルの他の側面から切り離せないため、また相互に作用するため、メソッド、ヘッダー、応答コードなどの詳細な説明とは別に、HTTPの基本的なキャッシングデザインを説明するのに役立ちます。
Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose (see section 13.2). The latter reduces network bandwidth requirements; we use a "validation" mechanism for this purpose (see section 13.3).
パフォーマンスが大幅に改善されない場合、キャッシュは役に立ちません。 HTTP / 1.1でのキャッシングの目的は、多くの場合に要求を送信する必要をなくし、他の多くの場合に完全な応答を送信する必要をなくすことです。前者は、多くの操作に必要なネットワークラウンドトリップの数を減らします。この目的のために「有効期限」メカニズムを使用します（セクション13.2を参照）。後者はネットワーク帯域幅の要件を軽減します。この目的のために「検証」メカニズムを使用します（セクション13.3を参照）。
Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and might be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed
パフォーマンス、可用性、非接続操作の要件により、セマンティックの透明性の目標を緩和できる必要があります。 HTTP / 1.1プロトコルにより、オリジンサーバー、キャッシュ、およびクライアントは、必要に応じて透過性を明示的に減らすことができます。ただし、非透過的な操作は、専門家でないユーザーを混乱させ、特定のサーバーアプリケーション（商品の注文など）と互換性がない場合があるため、プロトコルでは透過性を緩和する必要があります。
- only by an explicit protocol-level request when relaxed by client or origin server
- クライアントまたはオリジンサーバーによって緩和されたときに、明示的なプロトコルレベルの要求によってのみ
- only with an explicit warning to the end user when relaxed by cache or client
- キャッシュまたはクライアントによって緩和されたときにエンドユーザーに明示的な警告を表示する場合のみ
Therefore, the HTTP/1.1 protocol provides these important elements:
したがって、HTTP / 1.1プロトコルは次の重要な要素を提供します。
1. Protocol features that provide full semantic transparency when this is required by all parties.
1. すべての関係者が必要とする場合に、完全なセマンティックの透過性を提供するプロトコル機能。
2. Protocol features that allow an origin server or user agent to explicitly request and control non-transparent operation.
2. オリジンサーバーまたはユーザーエージェントが非透過的な操作を明示的に要求および制御できるようにするプロトコル機能。
3. Protocol features that allow a cache to attach warnings to responses that do not preserve the requested approximation of semantic transparency.
3. 要求されたセマンティック透明度の近似を維持しない応答にキャッシュが警告を添付できるようにするプロトコル機能。
A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency.
基本的な原則は、クライアントが意味の透明性の潜在的な緩和を検出することが可能でなければならないということです。
Note: The server, cache, or client implementor might be faced with design decisions not explicitly discussed in this specification. If a decision might affect semantic transparency, the implementor ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency.
注：サーバー、キャッシュ、またはクライアントの実装者は、この仕様で明示的に説明されていない設計上の決定に直面する可能性があります。決定が意味の透明性に影響を与える可能性がある場合、慎重かつ完全な分析が透明性の破壊に大きな利点を示さない限り、実装者は透明性を維持する側で誤りを犯すべきです。
A correct cache MUST respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see sections 13.2.5, 13.2.6, and 13.12) which meets one of the following conditions:
正しいキャッシュは、次の条件のいずれかを満たす、リクエストに適切なキャッシュが保持する最新の応答（セクション13.2.5、13.2.6、および13.12を参照）でリクエストに応答する必要があります。
1. It has been checked for equivalence with what the origin server would have returned by revalidating the response with the origin server (section 13.3);
1. オリジンサーバーとの応答を再検証することにより、オリジンサーバーが返すものと同等かどうかがチェックされています（セクション13.3）。
2. It is "fresh enough" (see section 13.2). In the default case, this means it meets the least restrictive freshness requirement of the client, origin server, and cache (see section 14.9); if the origin server so specifies, it is the freshness requirement of the origin server alone.
2. 「十分に新鮮」です（セクション13.2を参照）。デフォルトの場合、これは、クライアント、オリジンサーバー、およびキャッシュの最も制限の少ない鮮度要件を満たしていることを意味します（セクション14.9を参照）。オリジンサーバーがそのように指定する場合、それはオリジンサーバーのみの鮮度要件です。
If a stored response is not "fresh enough" by the most restrictive freshness requirement of both the client and the origin server, in carefully considered circumstances the cache MAY still return the response with the appropriate Warning header (see section 13.1.5 and 14.46), unless such a response is prohibited (e.g., by a "no-store" cache-directive, or by a "no-cache" cache-request-directive; see section 14.9).
格納された応答がクライアントとオリジンサーバーの両方の最も制限的な鮮度要件によって「十分に新鮮」でない場合でも、慎重に検討された状況では、キャッシュは適切な警告ヘッダー（13.1.5と14.46を参照）で応答を返します（MAY）。 、そのような応答が禁止されていない限り（たとえば、「ストアなし」のキャッシュディレクティブまたは「キャッシュなし」のキャッシュリクエストディレクティブによる。セクション14.9を参照）。
3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or error (4xx or 5xx) response message.
3. これは、適切な304（変更されていない）、305（プロキシリダイレクト）、またはエラー（4xxまたは5xx）の応答メッセージです。
If the cache can not communicate with the origin server, then a correct cache SHOULD respond as above if the response can be correctly served from the cache; if not it MUST return an error or warning indicating that there was a communication failure.
キャッシュがオリジンサーバーと通信できない場合、応答がキャッシュから正しく提供される場合、正しいキャッシュは上記のように応答する必要があります（SHOULD）。そうでない場合は、通信障害があったことを示すエラーまたは警告を返さなければなりません。
If a cache receives a response (either an entire response, or a 304 (Not Modified) response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache SHOULD forward it to the requesting client without adding a new Warning (but without removing any existing Warning headers). A cache SHOULD NOT attempt to revalidate a response simply because that response became stale in transit; this might lead to an infinite loop. A user agent that receives a stale response without a Warning MAY display a warning indication to the user.
キャッシュが通常は要求側クライアントに転送するであろう応答（応答全体または304（Not Modified）応答のいずれか）を受信し、受信された応答がもはやフレッシュではない場合、キャッシュはそれなしで要求側クライアントに転送する必要があります（SHOULD）。新しい警告を追加する（ただし、既存の警告ヘッダーを削除しない）。キャッシュは、応答が転送中に古くなったという理由だけで応答の再検証を試みるべきではありません（SHOULD NOT）。これにより、無限ループが発生する可能性があります。警告なしで古い応答を受信するユーザーエージェントは、ユーザーに警告を表示する場合があります。
Whenever a cache returns a response that is neither first-hand nor "fresh enough" (in the sense of condition 2 in section 13.1.1), it MUST attach a warning to that effect, using a Warning general-header. The Warning header and the currently defined warnings are described in section 14.46. The warning allows clients to take appropriate action.
（セクション13.1.1の条件2の意味で）キャッシュが直接でも「十分に新鮮」でもない応答を返すときは常に、Warning汎用ヘッダーを使用して、その影響に警告を添付する必要があります。警告ヘッダーと現在定義されている警告については、セクション14.46で説明しています。警告により、クライアントは適切なアクションを実行できます。
Warnings MAY be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguish these responses from true failures.
警告は、キャッシュ関連とそれ以外の両方の目的で使用される場合があります。エラーステータスコードではなく警告を使用することで、これらの応答を実際の障害と区別します。
Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning MUST or MUST NOT be deleted from a stored cache entry after a successful revalidation: 1xx Warnings that describe the freshness or revalidation status of the response, and so MUST be deleted after a successful revalidation. 1XX warn-codes MAY be generated by a cache only when validating a cached entry. It MUST NOT be generated by clients.
警告には3桁の警告コードが割り当てられています。 1桁目は、再検証が成功した後、保存されているキャッシュエントリから警告を削除する必要があるかどうかを示します。1xx応答は、応答の新しさまたは再検証ステータスを示すため、再検証が成功した後に削除する必要があります。 1XX warn-codesは、キャッシュされたエントリを検証するときにのみ、キャッシュによって生成される場合があります。クライアントが生成してはいけません。
2xx Warnings that describe some aspect of the entity body or entity headers that is not rectified by a revalidation (for example, a lossy compression of the entity bodies) and which MUST NOT be deleted after a successful revalidation.
再検証によって修正されないエンティティボディまたはエンティティヘッダーの一部の側面を説明する2xx警告（たとえば、エンティティボディの非可逆圧縮）であり、再検証が成功した後に削除してはなりません。
See section 14.46 for the definitions of the codes themselves.
コード自体の定義については、セクション14.46を参照してください。
HTTP/1.0 caches will cache all Warnings in responses, without deleting the ones in the first category. Warnings in responses that are passed to HTTP/1.0 caches carry an extra warning-date field, which prevents a future HTTP/1.1 recipient from believing an erroneously cached Warning.
HTTP / 1.0キャッシュは、最初のカテゴリの警告を削除せずに、応答のすべての警告をキャッシュします。 HTTP / 1.0キャッシュに渡される応答の警告には、追加のwarning-dateフィールドが含まれ、将来のHTTP / 1.1受信者が誤ってキャッシュされた警告を信じることを防ぎます。
Warnings also carry a warning text. The text MAY be in any appropriate natural language (perhaps based on the client's Accept headers), and include an OPTIONAL indication of what character set is used.
警告には警告テキストも含まれます。テキストは、適切な自然言語（おそらくクライアントのAcceptヘッダーに基づく）であり、使用される文字セットのオプションの指示を含めることができます（MAY）。
Multiple warnings MAY be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number. For example, a server might provide the same warning with texts in both English and Basque.
同じコード番号の複数の警告を含む、複数の警告が（オリジンサーバーまたはキャッシュのいずれかによって）応答に添付される場合があります。たとえば、サーバーが英語とバスク語の両方のテキストで同じ警告を表示する場合があります。
When multiple warnings are attached to a response, it might not be practical or reasonable to display all of them to the user. This version of HTTP does not specify strict priority rules for deciding which warnings to display and in what order, but does suggest some heuristics.
応答に複数の警告が添付されている場合、それらすべてをユーザーに表示することは実用的または合理的ではない場合があります。このバージョンのHTTPは、表示する警告とその順序を決定するための厳密な優先順位ルールを指定していませんが、いくつかのヒューリスティックを提案しています。
The basic cache mechanisms in HTTP/1.1 (server-specified expiration times and validators) are implicit directives to caches. In some cases, a server or client might need to provide explicit directives to the HTTP caches. We use the Cache-Control header for this purpose.
HTTP / 1.1の基本的なキャッシュメカニズム（サーバー指定の有効期限とバリデーター）は、キャッシュへの暗黙のディレクティブです。場合によっては、サーバーまたはクライアントがHTTPキャッシュに明示的なディレクティブを提供する必要があります。この目的のために、Cache-Controlヘッダーを使用します。
The Cache-Control header allows a client or server to transmit a variety of directives in either requests or responses. These directives typically override the default caching algorithms. As a general rule, if there is any apparent conflict between header values, the most restrictive interpretation is applied (that is, the one that is most likely to preserve semantic transparency). However, in some cases, cache-control directives are explicitly specified as weakening the approximation of semantic transparency (for example, "max-stale" or "public").
Cache-Controlヘッダーを使用すると、クライアントまたはサーバーは、要求または応答でさまざまなディレクティブを送信できます。これらのディレクティブは通常、デフォルトのキャッシュアルゴリズムをオーバーライドします。原則として、ヘッダー値の間に明らかな矛盾がある場合は、最も制限的な解釈が適用されます（つまり、セマンティックの透明性を維持する可能性が最も高い解釈）。ただし、場合によっては、キャッシュ制御ディレクティブがセマンティックの透過性の近似を弱めるものとして明示的に指定されています（たとえば、「max-stale」または「public」）。
The cache-control directives are described in detail in section 14.9.
キャッシュ制御ディレクティブについては、セクション14.9で詳しく説明しています。
Many user agents make it possible for users to override the basic caching mechanisms. For example, the user agent might allow the user to specify that cached entities (even explicitly stale ones) are never validated. Or the user agent might habitually add "Cache-Control: max-stale=3600" to every request. The user agent SHOULD NOT default to either non-transparent behavior, or behavior that results in abnormally ineffective caching, but MAY be explicitly configured to do so by an explicit action of the user.
多くのユーザーエージェントは、ユーザーが基本的なキャッシュメカニズムをオーバーライドできるようにします。たとえば、ユーザーエージェントを使用すると、キャッシュされたエンティティ（明示的に古いエンティティであっても）を検証しないように指定できます。または、ユーザーエージェントは、すべてのリクエストに「Cache-Control：max-stale = 3600」を習慣的に追加する場合があります。ユーザーエージェントは、デフォルトでは、非透過的な動作、または異常に効果のないキャッシュが発生する動作に設定するべきではありません（SHOULD NOT）が、ユーザーの明示的なアクションによって明示的に設定できます（MAY）。
If the user has overridden the basic caching mechanisms, the user agent SHOULD explicitly indicate to the user whenever this results in the display of information that might not meet the server's transparency requirements (in particular, if the displayed entity is known to be stale). Since the protocol normally allows the user agent to determine if responses are stale or not, this indication need only be displayed when this actually happens. The indication need not be a dialog box; it could be an icon (for example, a picture of a rotting fish) or some other indicator.
ユーザーが基本的なキャッシュメカニズムをオーバーライドした場合、ユーザーエージェントは、これによりサーバーの透過性要件を満たさない可能性のある情報が表示される場合（特に、表示されたエンティティが古くなっていることがわかっている場合）に、ユーザーに明示的に示す必要があります（SHOULD）。このプロトコルでは通常、ユーザーエージェントは応答が失効しているかどうかを判断できるため、この表示は実際に発生した場合にのみ表示する必要があります。表示はダイアログボックスである必要はありません。アイコン（たとえば、腐った魚の写真）やその他のインジケーターである可能性があります。
If the user has overridden the caching mechanisms in a way that would abnormally reduce the effectiveness of caches, the user agent SHOULD continually indicate this state to the user (for example, by a display of a picture of currency in flames) so that the user does not inadvertently consume excess resources or suffer from excessive latency.
ユーザーがキャッシュの有効性を異常に低下させるような方法でキャッシュメカニズムをオーバーライドした場合、ユーザーエージェントは、ユーザーにこの状態を継続的にユーザーに示す必要があります（たとえば、炎の中の通貨の画像を表示することにより）。誤って過剰なリソースを消費したり、過度の遅延に悩まされたりすることはありません。
In some cases, the operator of a cache MAY choose to configure it to return stale responses even when not requested by clients. This decision ought not be made lightly, but may be necessary for reasons of availability or performance, especially when the cache is poorly connected to the origin server. Whenever a cache returns a stale response, it MUST mark it as such (using a Warning header) enabling the client software to alert the user that there might be a potential problem.
場合によっては、キャッシュのオペレーターは、クライアントから要求されていない場合でも、古い応答を返すように構成することを選択できます（MAY）。この決定は軽く行うべきではありませんが、特にキャッシュがオリジンサーバーに十分に接続されていない場合、可用性やパフォーマンスの理由で必要になることがあります。キャッシュが古くなった応答を返すときはいつでも、（Warningヘッダーを使用して）そのようにキャッシュにマークを付け、クライアントソフトウェアがユーザーに潜在的な問題の可能性があることを警告できるようにする必要があります。
It also allows the user agent to take steps to obtain a first-hand or fresh response. For this reason, a cache SHOULD NOT return a stale response if the client explicitly requests a first-hand or fresh one, unless it is impossible to comply for technical or policy reasons.
また、ユーザーエージェントは、直接または新鮮な応答を取得するための手順を実行できます。このため、技術的またはポリシー上の理由で準拠できない場合を除き、クライアントが直接または新しいものを明示的に要求した場合、キャッシュは古い応答を返さないでください（SHOULD NOT）。
While the origin server (and to a lesser extent, intermediate caches, by their contribution to the age of a response) are the primary source of expiration information, in some cases the client might need to control a cache's decision about whether to return a cached response without validating it. Clients do this using several directives of the Cache-Control header.
起点サーバー（そして、より少ない程度で、応答の経過時間への寄与によって中間キャッシュ）が有効期限情報の主要なソースですが、場合によっては、クライアントは、キャッシュされたキャッシュを返すかどうかに関するキャッシュの決定を制御する必要があります検証せずに応答します。クライアントは、Cache-Controlヘッダーのいくつかのディレクティブを使用してこれを行います。
A client's request MAY specify the maximum age it is willing to accept of an unvalidated response; specifying a value of zero forces the cache(s) to revalidate all responses. A client MAY also specify the minimum time remaining before a response expires. Both of these options increase constraints on the behavior of caches, and so cannot further relax the cache's approximation of semantic transparency.
クライアントのリクエストは、検証されていない応答を受け入れる用意がある最大年齢を指定してもよい（MAY）。ゼロの値を指定すると、キャッシュがすべての応答を再検証します。クライアントは、応答が期限切れになるまでの残りの最小時間も指定できます（MAY）。これらのオプションはどちらもキャッシュの動作に対する制約を増やすため、セマンティック透明度のキャッシュの近似をさらに緩和することはできません。
A client MAY also specify that it will accept stale responses, up to some maximum amount of staleness. This loosens the constraints on the caches, and so might violate the origin server's specified constraints on semantic transparency, but might be necessary to support disconnected operation, or high availability in the face of poor connectivity.
クライアントはまた、古い応答の最大量まで、古い応答を受け入れることを指定してもよい（MAY）。これにより、キャッシュの制約が緩和されるため、セマンティックの透過性に関するオリジンサーバーの指定された制約に違反する可能性がありますが、切断された操作、または接続性が悪い場合の高可用性をサポートするために必要になる場合があります。
HTTP caching works best when caches can entirely avoid making requests to the origin server. The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future, indicating that a response MAY be used to satisfy subsequent requests. In other words, a cache can return a fresh response without first contacting the server.
HTTPキャッシングは、キャッシュが元のサーバーへのリクエストを完全に回避できる場合に最適に機能します。リクエストを回避するための主要なメカニズムは、オリジンサーバーが将来の明示的な有効期限を提供することです。これは、後続のリクエストを満たすためにレスポンスが使用される可能性があることを示します。つまり、キャッシュは最初にサーバーに接続しなくても、新しい応答を返すことができます。
Our expectation is that servers will assign future explicit expiration times to responses in the belief that the entity is not likely to change, in a semantically significant way, before the expiration time is reached. This normally preserves semantic transparency, as long as the server's expiration times are carefully chosen.
サーバーは、エンティティが有効期限に達する前に意味的に重要な方法で変更される可能性は低いと考えて、サーバーが将来の明示的な有効期限を応答に割り当てることを期待しています。サーバーの有効期限が注意深く選択されている限り、これは通常、意味の透明性を保持します。
The expiration mechanism applies only to responses taken from a cache and not to first-hand responses forwarded immediately to the requesting client.
有効期限メカニズムは、キャッシュから取得された応答にのみ適用され、要求元のクライアントに直ちに転送される直接的な応答には適用されません。
If an origin server wishes to force a semantically transparent cache to validate every request, it MAY assign an explicit expiration time in the past. This means that the response is always stale, and so the cache SHOULD validate it before using it for subsequent requests. See section 14.9.4 for a more restrictive way to force revalidation.
オリジンサーバーがすべてのリクエストを検証するために意味的に透過的なキャッシュを強制したい場合、過去の有効期限を明示的に割り当てるかもしれません。これは、応答が常に古くなっていることを意味します。したがって、キャッシュは、後続の要求に使用する前にそれを検証する必要があります（SHOULD）。再検証を強制するより制限的な方法については、セクション14.9.4を参照してください。
If an origin server wishes to force any HTTP/1.1 cache, no matter how it is configured, to validate every request, it SHOULD use the "must-revalidate" cache-control directive (see section 14.9).
オリジンサーバーがどのように設定されていても、HTTP / 1.1キャッシュを強制してすべてのリクエストを検証したい場合は、「must-revalidate」キャッシュ制御ディレクティブを使用する必要があります（セクション14.9を参照）。
Servers specify explicit expiration times using either the Expires header, or the max-age directive of the Cache-Control header.
サーバーは、ExpiresヘッダーまたはCache-Controlヘッダーのmax-ageディレクティブを使用して、有効期限を明示的に指定します。
An expiration time cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource is initiated. See section 13.13 for an explanation of the difference between caches and history mechanisms.
有効期限を使用して、ユーザーエージェントに表示の更新やリソースの再読み込みを強制することはできません。そのセマンティクスはキャッシングメカニズムにのみ適用され、そのようなメカニズムは、そのリソースに対する新しいリクエストが開始されたときに、リソースの有効期限ステータスをチェックするだけで済みます。キャッシュと履歴メカニズムの違いについては、セクション13.13を参照してください。
Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on their results. Since heuristic expiration times might compromise semantic transparency, they ought to used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible.
オリジンサーバーは常に有効期限を明示的に提供するわけではないため、HTTPキャッシュは通常、ヒューリスティックな有効期限を割り当て、他のヘッダー値（Last-Modified時間など）を使用して妥当な有効期限を推定するアルゴリズムを採用します。 HTTP / 1.1仕様は特定のアルゴリズムを提供していませんが、結果に最悪の場合の制約を課しています。ヒューリスティックな有効期限は意味の透明性を損なう可能性があるため、慎重に使用する必要があり、オリジンサーバーは可能な限り明示的な有効期限を提供することをお勧めします。
In order to know if a cached entry is fresh, a cache needs to know if its age exceeds its freshness lifetime. We discuss how to calculate the latter in section 13.2.4; this section describes how to calculate the age of a response or cache entry.
キャッシュされたエントリが新しいかどうかを知るために、キャッシュはその存続期間が経過したかどうかを知る必要があります。後者の計算方法については、セクション13.2.4で説明します。このセクションでは、応答またはキャッシュエントリの経過時間を計算する方法について説明します。
In this discussion, we use the term "now" to mean "the current value of the clock at the host performing the calculation." Hosts that use HTTP, but especially hosts running origin servers and caches, SHOULD use NTP [28] or some similar protocol to synchronize their clocks to a globally accurate time standard.
この説明では、「現在」という用語を使用して、「計算を実行しているホストでのクロックの現在の値」を意味します。 HTTPを使用するホスト、特にオリジンサーバーとキャッシュを実行するホストは、NTP [28]または同様のプロトコルを使用して、クロックをグローバルに正確な時間標準に同期する必要があります（SHOULD）。
HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response was generated (see section 14.18). We use the term "date_value" to denote the value of the Date header, in a form appropriate for arithmetic operations.
HTTP / 1.1は、可能であれば、すべての応答と共に日付ヘッダーを送信するようにオリジンサーバーに要求し、応答が生成された時刻を提供します（セクション14.18を参照）。 「date_value」という用語は、算術演算に適した形式で、Dateヘッダーの値を示すために使用します。
HTTP/1.1 uses the Age response-header to convey the estimated age of the response message when obtained from a cache. The Age field value is the cache's estimate of the amount of time since the response was generated or revalidated by the origin server.
HTTP / 1.1は、Age応答ヘッダーを使用して、キャッシュから取得した応答メッセージの推定経過時間を伝えます。 Ageフィールドの値は、応答がオリジンサーバーによって生成または再検証されてからのキャッシュの推定時間です。
In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus the amount of time it has been in transit along network paths.
本質的に、Age値は、応答が起点サーバーからのパスに沿って各キャッシュに常駐していた時間と、ネットワークパスに沿って転送されていた時間の合計です。
We use the term "age_value" to denote the value of the Age header, in a form appropriate for arithmetic operations.
「age_value」という用語を使用して、算術演算に適した形式でAgeヘッダーの値を示します。
A response's age can be calculated in two entirely independent ways:
応答の年齢は、2つの完全に独立した方法で計算できます。
1. now minus date_value, if the local clock is reasonably well synchronized to the origin server's clock. If the result is negative, the result is replaced by zero.
1. ローカルクロックが元のサーバーのクロックに適切に同期されている場合は、マイナスdate_valueになります。結果が負の場合、結果はゼロに置き換えられます。
2. age_value, if all of the caches along the response path implement HTTP/1.1.
2. age_value（応答パス上のすべてのキャッシュがHTTP / 1.1を実装する場合）。
Given that we have two independent ways to compute the age of a response when it is received, we can combine these as
応答が受信されたときの経過時間を計算する2つの独立した方法があるとすると、これらを次のように組み合わせることができます。
corrected_received_age = max(now - date_value, age_value)
and as long as we have either nearly synchronized clocks or all-HTTP/1.1 paths, one gets a reliable (conservative) result.
ほぼ同期したクロックまたはすべてHTTP / 1.1のパスがある限り、信頼できる（保守的な）結果が得られます。
Because of network-imposed delays, some significant interval might pass between the time that a server generates a response and the time it is received at the next outbound cache or client. If uncorrected, this delay could result in improperly low ages.
ネットワークによる遅延のため、サーバーが応答を生成してから次のアウトバウンドキャッシュまたはクライアントで受信されるまでの間に、かなりの間隔が経過する場合があります。修正されていない場合、この遅延により年齢が不適切に低くなる可能性があります。
Because the request that resulted in the returned Age value must have been initiated prior to that Age value's generation, we can correct for delays imposed by the network by recording the time at which the request was initiated. Then, when an Age value is received, it MUST be interpreted relative to the time the request was initiated, not the time that the response was received. This algorithm results in conservative behavior no matter how much delay is experienced. So, we compute:
返されるAge値の原因となった要求は、そのAge値の生成前に開始されている必要があるため、要求が開始された時間を記録することにより、ネットワークによって課された遅延を修正できます。次に、Age値が受信されると、応答が受信された時間ではなく、要求が開始された時間に関連して解釈される必要があります。このアルゴリズムは、どの程度の遅延が発生しても、保守的な動作になります。したがって、次を計算します。
corrected_initial_age = corrected_received_age + (now - request_time)
corrected_initial_age = corrected_received_age +（now-request_time）
where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.
「request_time」は、この応答を引き出した要求が送信された時刻（ローカルクロックによる）です。
Summary of age calculation algorithm, when a cache receives a response:
キャッシュが応答を受け取ったときの年齢計算アルゴリズムの要約：
/*
* age_value
* is the value of Age: header received by the cache with
* this response.
* date_value
* is the value of the origin server's Date: header
* request_time
* is the (local) time when the cache made the request
* that resulted in this cached response
* response_time
* is the (local) time when the cache received the
* response
* now
* is the current (local) time
*/
apparent_age = max(0, response_time - date_value);
corrected_received_age = max(apparent_age, age_value);
response_delay = response_time - request_time;
corrected_initial_age = corrected_received_age + response_delay;
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;
The current_age of a cache entry is calculated by adding the amount of time (in seconds) since the cache entry was last validated by the origin server to the corrected_initial_age. When a response is generated from a cache entry, the cache MUST include a single Age header field in the response with a value equal to the cache entry's current_age.
キャッシュエントリのcurrent_ageは、キャッシュエントリがオリジンサーバーによって最後に検証されてからの時間（秒単位）をcorrected_initial_ageに追加することによって計算されます。キャッシュエントリから応答が生成されるとき、キャッシュは、キャッシュエントリのcurrent_ageと等しい値を持つ単一のAgeヘッダーフィールドを応答に含める必要があります。
The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not true, since the lack of an Age header field in a response does not imply that the response is first-hand unless all caches along the request path are compliant with HTTP/1.1 (i.e., older HTTP caches did not implement the Age header field).
応答にAgeヘッダーフィールドが存在することは、応答が直接ではないことを意味します。ただし、応答にAgeヘッダーフィールドがないことは、要求パスに沿ったすべてのキャッシュがHTTP / 1.1に準拠していない限り、応答が直接であることを意味しないため（つまり、古いHTTPキャッシュがAgeヘッダーフィールドを実装します）。
In order to decide whether a response is fresh or stale, we need to compare its freshness lifetime to its age. The age is calculated as described in section 13.2.3; this section describes how to calculate the freshness lifetime, and to determine if a response has expired. In the discussion below, the values can be represented in any form appropriate for arithmetic operations.
応答が新鮮であるか古くなっているのかを判断するには、新鮮さの存続期間をその年齢と比較する必要があります。年齢はセクション13.2.3で説明されているように計算されます。このセクションでは、鮮度の有効期間を計算する方法と、応答の有効期限が切れているかどうかを判断する方法について説明します。以下の説明では、値は算術演算に適した任意の形式で表すことができます。
We use the term "expires_value" to denote the value of the Expires header. We use the term "max_age_value" to denote an appropriate value of the number of seconds carried by the "max-age" directive of the Cache-Control header in a response (see section 14.9.3).
Expiresヘッダーの値を示すために「expires_value」という用語を使用します。 「max_age_value」という用語を使用して、応答のCache-Controlヘッダーの「max-age」ディレクティブによって運ばれる秒数の適切な値を示します（セクション14.9.3を参照）。
The max-age directive takes priority over Expires, so if max-age is present in a response, the calculation is simply:
max-ageディレクティブはExpiresよりも優先されるため、応答にmax-ageが存在する場合、計算は次のようになります。
freshness_lifetime = max_age_value
freshness_lifetime = max_age_value
Otherwise, if Expires is present in the response, the calculation is:
それ以外の場合、応答にExpiresが存在すると、計算は次のようになります。
freshness_lifetime = expires_value - date_value
freshness_lifetime = expires_value-date_value
Note that neither of these calculations is vulnerable to clock skew, since all of the information comes from the origin server.
すべての情報はオリジンサーバーから取得されるため、これらの計算はいずれもクロックスキューに対して脆弱ではないことに注意してください。
If none of Expires, Cache-Control: max-age, or Cache-Control: s-maxage (see section 14.9.3) appears in the response, and the response does not include other restrictions on caching, the cache MAY compute a freshness lifetime using a heuristic. The cache MUST attach Warning 113 to any response whose age is more than 24 hours if such warning has not already been added.
Expires、Cache-Control：max-age、またはCache-Control：s-maxage（セクション14.9.3を参照）が応答に表示されず、応答にキャッシングに関する他の制限が含まれていない場合、キャッシュは鮮度を計算できます（MAY）ヒューリスティックを使用した寿命。そのような警告がまだ追加されていない場合、キャッシュは、経過時間が24時間を超える応答に警告113を添付する必要があります。
Also, if the response does have a Last-Modified time, the heuristic expiration value SHOULD be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
また、応答にLast-Modified時間がある場合、ヒューリスティックな有効期限の値は、その時間以降の間隔の一部にすぎない必要があります（SHOULD）。この割合の一般的な設定は10％です。
The calculation to determine if a response has expired is quite simple:
応答の有効期限が切れているかどうかを判断する計算は非常に簡単です。
response_is_fresh = (freshness_lifetime > current_age)
Because expiration values are assigned optimistically, it is possible for two caches to contain fresh values for the same resource that are different.
有効期限の値は楽観的に割り当てられるため、2つのキャッシュに、同じリソースの異なる新しい値が含まれる可能性があります。
If a client performing a retrieval receives a non-first-hand response for a request that was already fresh in its own cache, and the Date header in its existing cache entry is newer than the Date on the new response, then the client MAY ignore the response. If so, it MAY retry the request with a "Cache-Control: max-age=0" directive (see section 14.9), to force a check with the origin server.
取得を実行しているクライアントが、自身のキャッシュで既に新鮮なリクエストに対する非直接応答を受信し、既存のキャッシュエントリのDateヘッダーが新しい応答のDateよりも新しい場合、クライアントは無視してもよい（MAY）応答。その場合、「Cache-Control：max-age = 0」ディレクティブ（セクション14.9を参照）を使用して要求を再試行し、オリジンサーバーでのチェックを強制することができます（MAY）。
If a cache has two fresh responses for the same representation with different validators, it MUST use the one with the more recent Date header. This situation might arise because the cache is pooling responses from other caches, or because a client has asked for a reload or a revalidation of an apparently fresh cache entry.
キャッシュに、同じバリデーターを使用した同じ表現に対する2つの新しい応答がある場合、最新のDateヘッダーを持つものを使用する必要があります。この状況は、キャッシュが他のキャッシュからの応答をプールしているため、またはクライアントが明らかに新しいキャッシュエントリのリロードまたは再検証を要求したために発生する可能性があります。
Because a client might be receiving responses via multiple paths, so that some responses flow through one set of caches and other responses flow through a different set of caches, a client might receive responses in an order different from that in which the origin server sent them. We would like the client to use the most recently generated response, even if older responses are still apparently fresh.
クライアントは複数のパスを介して応答を受信する可能性があるため、一部の応答は1つのキャッシュセットを通過し、他の応答は異なるキャッシュセットを通過するため、クライアントは、オリジンサーバーが送信した順序とは異なる順序で応答を受信する可能性があります。 。古い応答が明らかに新鮮である場合でも、クライアントは最新の応答を使用してください。
Neither the entity tag nor the expiration value can impose an ordering on responses, since it is possible that a later response intentionally carries an earlier expiration time. The Date values are ordered to a granularity of one second.
エンティティタグも有効期限値も、応答に順序を付けることはできません。これは、後の応答が意図的に早い有効期限を伝える可能性があるためです。日付の値は、1秒単位で並べられます。
When a client tries to revalidate a cache entry, and the response it receives contains a Date header that appears to be older than the one for the existing entry, then the client SHOULD repeat the request unconditionally, and include
クライアントがキャッシュエントリの再検証を試み、クライアントが受け取った応答に既存のエントリのものより古いと思われるDateヘッダーが含まれている場合、クライアントは無条件に要求を繰り返し、含める必要があります。
Cache-Control: max-age=0
キャッシュ制御：max-age = 0
to force any intermediate caches to validate their copies directly with the origin server, or
中間キャッシュに強制的にコピーをオリジンサーバーで直接検証させる、または
Cache-Control: no-cache
キャッシュ制御：キャッシュなし
to force any intermediate caches to obtain a new copy from the origin server.
中間キャッシュに強制的に元のサーバーから新しいコピーを取得させる。
If the Date values are equal, then the client MAY use either response (or MAY, if it is being extremely prudent, request a new response). Servers MUST NOT depend on clients being able to choose deterministically between responses generated during the same second, if their expiration times overlap.
日付の値が等しい場合、クライアントはいずれかの応答を使用できます（非常に慎重な場合は、新しい応答を要求できます）。サーバーは、有効期限が重複している場合、クライアントが同じ秒の間に生成された応答間で決定論的に選択できることに依存してはなりません（MUST NOT）。
When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, the HTTP/1.1 protocol supports the use of conditional methods.
キャッシュにクライアントの要求への応答として使用したい古いエントリがある場合、最初にオリジンサーバー（またはおそらく新しい応答を持つ中間キャッシュ）をチェックして、キャッシュされたエントリがまだ使用可能かどうかを確認する必要があります。これをキャッシュエントリの「検証」と呼びます。キャッシュされたエントリが適切である場合、完全な応答を再送信するオーバーヘッドを支払う必要がないので、キャッシュされたエントリが無効な場合、余分なラウンドトリップのオーバーヘッドを支払う必要がないため、HTTP / 1.1プロトコルは、条件付きメソッドの使用。
The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server generates a full response, it attaches some sort of validator to it, which is kept with the cache entry. When a client (user agent or proxy cache) makes a conditional request for a resource for which it has a cache entry, it includes the associated validator in the request.
条件付きメソッドをサポートするための主要なプロトコル機能は、「キャッシュバリデーター」に関係するものです。オリジンサーバーが完全な応答を生成するとき、それはある種のバリデーターをそれに接続します。それはキャッシュエントリーと共に保持されます。クライアント（ユーザーエージェントまたはプロキシキャッシュ）がキャッシュエントリを持つリソースに対して条件付き要求を行うと、関連するバリデーターが要求に含まれます。
The server then checks that validator against the current validator for the entity, and, if they match (see section 13.3.3), it responds with a special status code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it returns a full response (including entity-body). Thus, we avoid transmitting the full response if the validator matches, and we avoid an extra round trip if it does not match.
次に、サーバーはエンティティの現在のバリデータに対してそのバリデータをチェックし、それらが一致する場合（セクション13.3.3を参照）、エンティティ本体なしの特別なステータスコード（通常は304（未変更））で応答します。それ以外の場合は、完全な応答（エンティティー本体を含む）を返します。したがって、バリデーターが一致する場合は完全な応答の送信を回避し、一致しない場合は余分な往復を回避します。
In HTTP/1.1, a conditional request looks exactly the same as a normal request for the same resource, except that it carries a special header (which includes the validator) that implicitly turns the method (usually, GET) into a conditional.
HTTP / 1.1では、条件付きリクエストは、メソッド（通常はGET）を条件付きに暗黙的に変換する特別なヘッダー（バリデーターを含む）を運ぶことを除いて、同じリソースに対する通常のリクエストとまったく同じに見えます。
The protocol includes both positive and negative senses of cache-validating conditions. That is, it is possible to request either that a method be performed if and only if a validator matches or if and only if no validators match.
このプロトコルには、キャッシュ検証条件の肯定的な意味と否定的な意味の両方が含まれています。つまり、バリデーターが一致する場合にのみ、またはバリデーターが一致しない場合にのみメソッドを実行するよう要求できます。
Note: a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited by a cache-control directive. However, a cache cannot do a conditional retrieval if it does not have a validator for the entity, which means it will not be refreshable after it expires.
注：バリデーターがない応答は、キャッシュ制御ディレクティブで明示的に禁止されていない限り、キャッシュされ、期限が切れるまでキャッシュから提供されます。ただし、エンティティのバリデーターがない場合、キャッシュは条件付き取得を実行できません。つまり、有効期限が切れた後はキャッシュを更新できません。
The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered to be valid if the entity has not been modified since the Last-Modified value.
Last-Modifiedエンティティヘッダーフィールドの値は、キャッシュバリデーターとしてよく使用されます。簡単に言うと、Last-Modified値以降にエンティティが変更されていない場合、キャッシュエントリは有効であると見なされます。
The ETag response-header field value, an entity tag, provides for an "opaque" cache validator. This might allow more reliable validation in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates.
ETag応答ヘッダーフィールドの値であるエンティティタグは、「不透明な」キャッシュバリデーターを提供します。これにより、HTTP日付値の1秒の解決では不十分な場合、または元のサーバーが変更日付の使用から生じる可能性がある特定のパラドックスを回避したい場合に、変更日付を保存するのが不便な状況で、より信頼できる検証が可能になる場合があります。 。
Entity Tags are described in section 3.11. The headers used with entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
エンティティタグについては、セクション3.11で説明しています。エンティティタグで使用されるヘッダーについては、セクション14.19、14.24、14.26、および14.44で説明します。
Since both origin servers and caches will compare two validators to decide if they represent the same or different entities, one normally would expect that if the entity (the entity-body or any entity-headers) changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong validator."
オリジンサーバーとキャッシュの両方が2つのバリデーターを比較して、それらが同じまたは異なるエンティティを表すかどうかを判断するため、通常、エンティティー（エンティティーボディまたはエンティティーヘッダー）が何らかの形で変更された場合、関連付けられているバリデーターは同様に変更します。これがtrueの場合、このバリデーターを「強力なバリデーター」と呼びます。
However, there might be cases when a server prefers to change the validator only on semantically significant changes, and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator."
ただし、サーバーがエンティティの重要ではない変更ではなく、意味的に重要な変更でのみバリデーターを変更することを好む場合があります。リソースが変更されても常に変更されるわけではないバリデーターは「弱いバリデーター」です。
Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.
エンティティタグは通常「強力なバリデータ」ですが、プロトコルはエンティティタグに「弱い」タグを付けるメカニズムを提供します。強いバリデーターは、エンティティのビットが変化するたびに変化するバリデーターと考えることができますが、弱い値は、エンティティーの意味が変化するたびに変化します。あるいは、強いバリデーターを特定のエンティティーの識別子の一部として考えることができますが、弱いバリデーターは、意味的に等価なエンティティのセットの識別子の一部です。
Note: One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.
注：強力なバリデーターの一例は、エンティティが変更されるたびに安定したストレージで増分される整数です。
An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible that the resource might be modified twice during a single second.
エンティティの変更時間が1秒の解像度で表されている場合、リソースが1秒間に2回変更される可能性があるため、弱いバリデータである可能性があります。
Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects; for example, a hit counter on a site is probably good enough if it is updated every few days or weeks, and any value during that period is likely "good enough" to be equivalent.
弱いバリデーターのサポートはオプションです。ただし、弱いバリデーターを使用すると、同等のオブジェクトをより効率的にキャッシュできます。たとえば、サイトのヒットカウンタは、数日または数週間ごとに更新される場合はおそらく十分であり、その期間中の値は同等であると「十分に良好」である可能性があります。
A "use" of a validator is either when a client generates a request and includes the validator in a validating header field, or when a server compares two validators.
バリデーターの「使用」は、クライアントがリクエストを生成し、検証ヘッダーフィールドにバリデーターを含める場合、またはサーバーが2つのバリデーターを比較する場合のいずれかです。
Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality of an entity. For example, either kind is usable for a conditional GET of a full entity. However, only a strong validator is usable for a sub-range retrieval, since otherwise the client might end up with an internally inconsistent entity.
強力なバリデーターはどのような状況でも使用できます。弱いバリデーターは、エンティティの正確な等価性に依存しないコンテキストでのみ使用できます。たとえば、どちらの種類も完全なエンティティの条件付きGETに使用できます。ただし、強力なバリデーターのみがサブ範囲の取得に使用できます。それ以外の場合、クライアントは内部的に一貫性のないエンティティになる可能性があるためです。
Clients MAY issue simple (non-subrange) GET requests with either weak validators or strong validators. Clients MUST NOT use weak validators in other forms of request.
クライアントは、弱いバリデーターまたは強いバリデーターのいずれかを使用して、単純な（サブレンジではない）GETリクエストを発行できます（MAY）。クライアントは、他の形式のリクエストで弱いバリデーターを使用してはなりません。
The only function that the HTTP/1.1 protocol defines on validators is comparison. There are two validator comparison functions, depending on whether the comparison context allows the use of weak validators or not:
HTTP / 1.1プロトコルがバリデーターで定義する唯一の関数は比較です。比較コンテキストが弱いバリデーターの使用を許可するかどうかに応じて、2つのバリデーター比較関数があります。
- The strong comparison function: in order to be considered equal, both validators MUST be identical in every way, and both MUST NOT be weak.
- 強力な比較関数：等しいと見なされるためには、両方のバリデーターがあらゆる点で同一である必要があり、両方が弱いことはありません。
- The weak comparison function: in order to be considered equal, both validators MUST be identical in every way, but either or both of them MAY be tagged as "weak" without affecting the result.
- 弱い比較関数：等しいと見なされるためには、両方のバリデーターはあらゆる点で同一である必要がありますが、結果に影響を与えることなく、どちらかまたは両方に「弱い」というタグを付けることができます。
An entity tag is strong unless it is explicitly tagged as weak. Section 3.11 gives the syntax for entity tags.
エンティティタグは、明示的に弱いタグが付けられていない限り、強力です。セクション3.11は、エンティティタグの構文を示しています。
A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules:
Last-Modified時間は、リクエストでバリデータとして使用された場合、次のルールを使用して、それが強いと推定できない限り、暗黙的に弱いです。
- The validator is being compared by an origin server to the actual current validator for the entity and,
- バリデーターは、起点サーバーによってエンティティーの実際の現在のバリデーターと比較され、
- That origin server reliably knows that the associated entity did not change twice during the second covered by the presented validator.
- その起点サーバーは、関連付けられたエンティティーが、提示されたバリデーターによってカバーされる2番目の間に2回変更されなかったことを確実に認識しています。
or
または
- The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header, because the client has a cache entry for the associated entity, and
- クライアントに関連付けられたエンティティのキャッシュエントリがあるため、バリデーターはクライアントがIf-Modified-SinceまたはIf-Unmodified-Sinceヘッダーで使用しようとしています。
- That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
- そのキャッシュエントリには、元のサーバーが元の応答を送信した時刻を示す日付値が含まれています。
- The presented Last-Modified time is at least 60 seconds before the Date value.
- 提示されるLast-Modified時間は、Date値の少なくとも60秒前です。
or
または
- The validator is being compared by an intermediate cache to the validator stored in its cache entry for the entity, and
- バリデータは、中間キャッシュによって、エンティティのキャッシュエントリに格納されているバリデータと比較されます。
- That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
- そのキャッシュエントリには、元のサーバーが元の応答を送信した時刻を示す日付値が含まれています。
- The presented Last-Modified time is at least 60 seconds before the Date value.
- 提示されるLast-Modified時間は、Date値の少なくとも60秒前です。
This method relies on the fact that if two different responses were sent by the origin server during the same second, but both had the same Last-Modified time, then at least one of those responses would have a Date value equal to its Last-Modified time. The arbitrary 60- second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks, or at somewhat different times during the preparation of the response. An implementation MAY use a value larger than 60 seconds, if it is believed that 60 seconds is too short.
この方法は、同じ秒の間に2つの異なる応答が起点サーバーによって送信されたが、両方のLast-Modified時間が同じであった場合、それらの応答の少なくとも1つは、Last-Modifiedと等しい日付値を持っているという事実に依存します。時間。任意の60秒の制限により、DateとLast-Modifiedの値が異なるクロックから、または応答の準備中に多少異なる時刻に生成される可能性を防ぎます。 60秒が短すぎると考えられる場合、実装は60秒より大きい値を使用してもよい（MAY）。
If a client wishes to perform a sub-range retrieval on a value for which it has only a Last-Modified time and no opaque validator, it MAY do this only if the Last-Modified time is strong in the sense described here.
クライアントがLast-Modified時刻のみを持ち、不透明なバリデーターがない値に対してサブレンジ検索を実行したい場合、Last-Modified時刻がここで説明する意味で強い場合にのみ、これを実行できます。
A cache or origin server receiving a conditional request, other than a full-body GET request, MUST use the strong comparison function to evaluate the condition.
全身GETリクエスト以外の条件付きリクエストを受信するキャッシュまたはオリジンサーバーは、強力な比較関数を使用して条件を評価する必要があります。
These rules allow HTTP/1.1 caches and clients to safely perform sub-range retrievals on values that have been obtained from HTTP/1.0 servers.
これらのルールにより、HTTP / 1.1キャッシュとクライアントは、HTTP / 1.0サーバーから取得された値に対してサブレンジ検索を安全に実行できます。
We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types ought to be used, and for what purposes.
さまざまなバリデータータイプをいつ使用するか、およびその目的に関して、オリジンサーバー、クライアント、およびキャッシュに一連のルールと推奨事項を採用しています。
HTTP/1.1 origin servers:
HTTP / 1.1オリジンサーバー：
- SHOULD send an entity tag validator unless it is not feasible to generate one.
- エンティティタグバリデーターを生成できない場合を除き、エンティティータグバリデーターを送信する必要があります（SHOULD）。
- MAY send a weak entity tag instead of a strong entity tag, if performance considerations support the use of weak entity tags, or if it is unfeasible to send a strong entity tag.
- パフォーマンスの考慮により弱いエンティティタグの使用がサポートされている場合、または強いエンティティタグを送信できない場合は、強いエンティティタグの代わりに弱いエンティティタグを送信できます。
- SHOULD send a Last-Modified value if it is feasible to send one, unless the risk of a breakdown in semantic transparency that could result from using this date in an If-Modified-Since header would lead to serious problems.
- 送信可能な場合は、Last-Modified値を送信する必要があります。ただし、この日付をIf-Modified-Sinceヘッダーで使用することにより生じるセマンティックトランスペアレンシーの内訳のリスクが深刻な問題につながる場合を除きます。
In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity tag and a Last-Modified value.
つまり、HTTP / 1.1オリジンサーバーの推奨動作は、強力なエンティティタグとLast-Modified値の両方を送信することです。
In order to be legal, a strong entity tag MUST change whenever the associated entity value changes in any way. A weak entity tag SHOULD change whenever the associated entity changes in a semantically significant way.
合法であるためには、関連するエンティティ値が何らかの方法で変更されるたびに、強力なエンティティタグを変更する必要があります。弱いエンティティタグは、関連するエンティティが意味的に重要な方法で変更されるたびに変更する必要があります。
Note: in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the past.
注：意味的に透過的なキャッシングを提供するために、オリジンサーバーは、2つの異なるエンティティに特定の強いエンティティタグ値を再利用したり、2つの意味的に異なるエンティティに特定の弱いエンティティタグ値を再利用したりしないようにする必要があります。キャッシュエントリは、有効期限に関係なく、任意の長い期間存続する可能性があるため、キャッシュが過去のある時点で取得したバリデーターを使用してエントリの検証を二度と試みないことを期待するのは不適切な場合があります。
HTTP/1.1 clients:
HTTP / 1.1クライアント：
- If an entity tag has been provided by the origin server, MUST use that entity tag in any cache-conditional request (using If-Match or If-None-Match).
- エンティティタグがオリジンサーバーから提供されている場合は、そのエンティティタグをキャッシュ条件付きリクエストで使用する必要があります（If-MatchまたはIf-None-Matchを使用）。
- If only a Last-Modified value has been provided by the origin server, SHOULD use that value in non-subrange cache-conditional requests (using If-Modified-Since).
- オリジンサーバーからLast-Modified値のみが提供されている場合、サブレンジ以外のキャッシュ条件付きリクエストでその値を使用する必要があります（If-Modified-Sinceを使用）。
- If only a Last-Modified value has been provided by an HTTP/1.0 origin server, MAY use that value in subrange cache-conditional requests (using If-Unmodified-Since:). The user agent SHOULD provide a way to disable this, in case of difficulty.
- Last-Modified値のみがHTTP / 1.0オリジンサーバーから提供されている場合、サブレンジキャッシュ条件付きリクエストでその値を使用できます（If-Unmodified-Since：を使用）。ユーザーエージェントは、問題が発生した場合にこれを無効にする方法を提供する必要があります（SHOULD）。
- If both an entity tag and a Last-Modified value have been provided by the origin server, SHOULD use both validators in cache-conditional requests. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
- エンティティタグとLast-Modified値の両方がオリジンサーバーから提供されている場合、キャッシュ条件付きリクエストで両方のバリデーターを使用する必要があります（SHOULD）。これにより、HTTP / 1.0キャッシュとHTTP / 1.1キャッシュの両方が適切に応答できるようになります。
An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since or If-Unmodified-Since header field) and one or more entity tags (e.g., in an If-Match, If-None-Match, or If-Range header field) as cache validators, MUST NOT return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in the request.
HTTP / 1.1オリジンサーバーが、Last-Modified日付（たとえば、If-Modified-SinceまたはIf-Unmodified-Sinceヘッダーフィールド）と1つ以上のエンティティタグ（たとえば、キャッシュバリデーターとしてのIf-Match、If-None-Match、またはIf-Rangeヘッダーフィールド）は、リクエスト内のすべての条件付きヘッダーフィールドと一致しない限り、304（Not Modified）の応答ステータスを返さないでください。
An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity tags as cache validators, MUST NOT return a locally cached response to the client unless that cached response is consistent with all of the conditional header fields in the request.
HTTP / 1.1キャッシュプロキシは、Last-Modified日付と1つ以上のエンティティタグの両方を含む条件付きリクエストをキャッシュバリデータとして受信すると、ローカルにキャッシュされた応答をクライアントに返してはなりません。リクエストの条件付きヘッダーフィールド。
Note: The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative assumptions about the validators they receive.
注：これらのルールの背後にある一般的な原則は、HTTP / 1.1サーバーとクライアントは、応答と要求で利用可能な限り多くの非冗長情報を送信する必要があるということです。この情報を受信するHTTP / 1.1システムは、受信するバリデータについて最も保守的な仮定を行います。
HTTP/1.0 clients and caches will ignore entity tags. Generally, last-modified values received or used by these systems will support transparent and efficient caching, and so HTTP/1.1 origin servers should provide Last-Modified values. In those rare cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then HTTP/1.1 origin servers should not provide one.
HTTP / 1.0クライアントとキャッシュはエンティティタグを無視します。通常、これらのシステムで受信または使用される最終変更値は透過的で効率的なキャッシュをサポートするため、HTTP / 1.1オリジンサーバーは最終変更値を提供する必要があります。 Last-Modified値をHTTP / 1.0システムでバリデーターとして使用することで重大な問題が発生する可能性があるというまれなケースでは、HTTP / 1.1オリジンサーバーが提供するべきではありません。
The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality would open up a can of worms. Thus, comparisons of any other headers (except Last-Modified, for compatibility with HTTP/1.0) are never used for purposes of validating a cache entry.
エンティティタグの背後にある原則は、適切なキャッシュ検証メカニズムを選択するのに十分なリソースのセマンティクスを知っているのはサービスの作成者だけであり、バイト等価よりも複雑なバリデーター比較関数の仕様はワームの缶を開くことです。したがって、他のヘッダー（Last-Modifiedを除く、HTTP / 1.0との互換性を除く）の比較は、キャッシュエントリを検証する目的で使用されることはありません。
Unless specifically constrained by a cache-control (section 14.9) directive, a caching system MAY always store a successful response (see section 13.8) as a cache entry, MAY return it without validation if it is fresh, and MAY return it after successful validation. If there is neither a cache validator nor an explicit expiration time associated with a response, we do not expect it to be cached, but certain caches MAY violate this expectation (for example, when little or no network connectivity is available). A client can usually detect that such a response was taken from a cache by comparing the Date header to the current time.
特にcache-control（セクション14.9）ディレクティブによる制約がない限り、キャッシングシステムは常に成功した応答（セクション13.8を参照）をキャッシュエントリとして保存し、新しい場合は検証せずにそれを返し、検証が成功した後にそれを返す場合があります（MAY）。 。キャッシュバリデーターも、応答に関連付けられた明示的な有効期限もない場合、キャッシュされるとは想定されていませんが、特定のキャッシュはこの予想に違反する場合があります（たとえば、ネットワーク接続がほとんどまたはまったくない場合）。クライアントは通常、Dateヘッダーを現在の時刻と比較することにより、そのような応答がキャッシュから取得されたことを検出できます。
Note: some HTTP/1.0 caches are known to violate this expectation without providing any Warning.
注：一部のHTTP / 1.0キャッシュは、警告を提供せずにこの期待に違反することがわかっています。
However, in some cases it might be inappropriate for a cache to retain an entity, or to return it in response to a subsequent request. This might be because absolute semantic transparency is deemed necessary by the service author, or because of security or privacy considerations. Certain cache-control directives are therefore provided so that the server can indicate that certain resource entities, or portions thereof, are not to be cached regardless of other considerations.
ただし、場合によっては、キャッシュがエンティティを保持すること、または後続のリクエストに応じてエンティティを返すことが不適切な場合があります。これは、サービスの作成者が絶対的なセマンティックの透明性が必要であると見なした場合、またはセキュリティやプライバシーの考慮事項が原因である可能性があります。したがって、他の考慮事項に関係なく、特定のリソースエンティティまたはその一部がキャッシュされないことをサーバーが示すことができるように、特定のキャッシュ制御ディレクティブが提供されます。
Note that section 14.8 normally prevents a shared cache from saving and returning a response to a previous request if that request included an Authorization header.
セクション14.8は通常、前の要求にAuthorizationヘッダーが含まれている場合、共有キャッシュが前の要求を保存して応答を返すのを防ぎます。
A response received with a status code of 200, 203, 206, 300, 301 or 410 MAY be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control directive prohibits caching. However, a cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial Content) responses.
ステータスコード200、203、206、300、301、または410で受信した応答は、キャッシュに格納され、キャッシュ制御ディレクティブがキャッシュを禁止しない限り、有効期限メカニズムに従って、後続の要求に応答して使用される場合があります。ただし、RangeおよびContent-Rangeヘッダーをサポートしないキャッシュは、206（部分コンテンツ）応答をキャッシュしてはなりません（MUST NOT）。
A response received with any other status code (e.g. status codes 302 and 307) MUST NOT be returned in a reply to a subsequent request unless there are cache-control directives or another header(s) that explicitly allow it. For example, these include the following: an Expires header (section 14.21); a "max-age", "s-maxage", "must-revalidate", "proxy-revalidate", "public" or "private" cache-control directive (section 14.9).
他のステータスコード（ステータスコード302や307など）で受信した応答は、明示的に許可するキャッシュ制御ディレクティブまたは別のヘッダーがない限り、後続のリクエストへの応答で返してはなりません（MUST NOT）。たとえば、次のものが含まれます。Expiresヘッダー（セクション14.21）。 "max-age"、 "s-maxage"、 "must-revalidate"、 "proxy-revalidate"、 "public"または "private"キャッシュ制御ディレクティブ（セクション14.9）。
The purpose of an HTTP cache is to store information received in response to requests for use in responding to future requests. In many cases, a cache simply returns the appropriate parts of a response to the requester. However, if the cache holds a cache entry based on a previous response, it might have to combine parts of a new response with what is held in the cache entry.
HTTPキャッシュの目的は、将来の要求への応答に使用するために、要求に応答して受信した情報を格納することです。多くの場合、キャッシュは応答の適切な部分をリクエスタに返すだけです。ただし、キャッシュが以前の応答に基づいてキャッシュエントリを保持している場合、新しい応答の一部をキャッシュエントリに保持されているものと組み合わせる必要がある場合があります。
For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories:
キャッシュと非キャッシュプロキシの動作を定義する目的で、HTTPヘッダーを2つのカテゴリに分類します。
- End-to-end headers, which are transmitted to the ultimate recipient of a request or response. End-to-end headers in responses MUST be stored as part of a cache entry and MUST be transmitted in any response formed from a cache entry.
- 要求または応答の最終的な受信者に送信されるエンドツーエンドのヘッダー。応答のエンドツーエンドヘッダーは、キャッシュエントリの一部として格納する必要があり、キャッシュエントリから形成されたすべての応答で送信する必要があります。
- Hop-by-hop headers, which are meaningful only for a single transport-level connection, and are not stored by caches or forwarded by proxies.
- ホップバイホップヘッダー。これは、単一のトランスポートレベル接続でのみ意味があり、キャッシュに格納されたり、プロキシによって転送されたりすることはありません。
The following HTTP/1.1 headers are hop-by-hop headers:
次のHTTP / 1.1ヘッダーはホップバイホップヘッダーです。
- Connection - Keep-Alive - Proxy-Authenticate - Proxy-Authorization - TE - Trailers - Transfer-Encoding - Upgrade
- 接続-キープアライブ-プロキシ認証-プロキシ承認-TE-トレーラー-転送エンコーディング-アップグレード
All other headers defined by HTTP/1.1 are end-to-end headers.
HTTP / 1.1で定義されている他のすべてのヘッダーは、エンドツーエンドのヘッダーです。
Other hop-by-hop headers MUST be listed in a Connection header, (section 14.10) to be introduced into HTTP/1.1 (or later).
他のホップバイホップヘッダーは、HTTP / 1.1以降に導入される接続ヘッダー（セクション14.10）にリストされている必要があります。
Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent proxy SHOULD NOT modify an end-to-end header unless the definition of that header requires or specifically allows that.
ダイジェスト認証などのHTTP / 1.1プロトコルの一部の機能は、特定のエンドツーエンドヘッダーの値に依存します。透過的なプロキシは、そのヘッダーの定義がそれを必要とするか、または具体的に許可しない限り、エンドツーエンドヘッダーを変更するべきではありません（SHOULD NOT）。
A transparent proxy MUST NOT modify any of the following fields in a request or response, and it MUST NOT add any of these fields if not already present:
透過プロキシは、要求または応答の以下のフィールドを変更してはならず（MUST NOT）、まだ存在しない場合はこれらのフィールドを追加してはなりません（MUST NOT）。
- Content-Location
- コンテンツの場所
- Content-MD5
- Content-MD5
- ETag
- ETag
- Last-Modified
- 最終更新日
A transparent proxy MUST NOT modify any of the following fields in a response:
透過プロキシは、応答内の次のフィールドを変更してはなりません（MUST NOT）。
- Expires
- 期限切れ
but it MAY add any of these fields if not already present. If an Expires header is added, it MUST be given a field-value identical to that of the Date header in that response.
ただし、まだ存在しない場合は、これらのフィールドのいずれかを追加できます（MAY）。 Expiresヘッダーを追加する場合は、その応答のDateヘッダーと同じフィールド値を指定する必要があります。
A proxy MUST NOT modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:
プロキシは、no-transform cache-controlディレクティブを含むメッセージまたは任意のリクエストで、次のフィールドを変更または追加してはなりません（MUST NOT）。
- Content-Encoding
- コンテンツエンコーディング
- Content-Range
- コンテンツ範囲
- Content-Type
- コンテンツタイプ
A non-transparent proxy MAY modify or add these fields to a message that does not include no-transform, but if it does so, it MUST add a Warning 214 (Transformation applied) if one does not already appear in the message (see section 14.46).
非透過プロキシは、これらのフィールドをno-transformを含まないメッセージに変更または追加する場合がありますが、そうする場合、メッセージにまだ表示されていなければ、警告214（変換が適用されます）を追加する必要があります（セクションを参照） 14.46）。
Warning: unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms are introduced in later versions of HTTP. Such authentication mechanisms MAY rely on the values of header fields not listed here.
警告：エンドツーエンドのヘッダーを不必要に変更すると、新しいバージョンのHTTPでより強力な認証メカニズムが導入された場合、認証が失敗する可能性があります。そのような認証メカニズムはここにリストされていないヘッダーフィールドの値に依存するかもしれません。
The Content-Length field of a request or response is added or deleted according to the rules in section 4.4. A transparent proxy MUST preserve the entity-length (section 7.2.2) of the entity-body, although it MAY change the transfer-length (section 4.4).
リクエストまたはレスポンスのContent-Lengthフィールドは、セクション4.4のルールに従って追加または削除されます。透過プロキシは、転送長（セクション4.4）を変更することはできますが、エンティティ本体のエンティティ長（セクション7.2.2）を保持する必要があります。
When a cache makes a validating request to a server, and the server provides a 304 (Not Modified) response or a 206 (Partial Content) response, the cache then constructs a response to send to the requesting client.
キャッシュがサーバーに検証要求を行い、サーバーが304（Not Modified）応答または206（Partial Content）応答を提供すると、キャッシュは応答を構築して要求側クライアントに送信します。
If the status code is 304 (Not Modified), the cache uses the entity-body stored in the cache entry as the entity-body of this outgoing response. If the status code is 206 (Partial Content) and the ETag or Last-Modified headers match exactly, the cache MAY combine the contents stored in the cache entry with the new contents received in the response and use the result as the entity-body of this outgoing response, (see 13.5.4).
ステータスコードが304（変更されていない）の場合、キャッシュはキャッシュエントリに格納されているエンティティボディを、この発信応答のエンティティボディとして使用します。ステータスコードが206（部分的なコンテンツ）で、ETagまたはLast-Modifiedヘッダーが正確に一致する場合、キャッシュは、キャッシュエントリに格納されているコンテンツと、応答で受信した新しいコンテンツを組み合わせて、その結果をこの発信応答（13.5.4を参照）。
The end-to-end headers stored in the cache entry are used for the constructed response, except that
キャッシュエントリに格納されたエンドツーエンドヘッダーは、構築された応答に使用されますが、
- any stored Warning headers with warn-code 1xx (see section 14.46) MUST be deleted from the cache entry and the forwarded response.
- warn-code 1xx（セクション14.46を参照）で保存されている警告ヘッダーは、キャッシュエントリと転送された応答から削除する必要があります。
- any stored Warning headers with warn-code 2xx MUST be retained in the cache entry and the forwarded response.
- 保存されたwarn-code 2xxの警告ヘッダーは、キャッシュエントリと転送された応答に保持する必要があります。
- any end-to-end headers provided in the 304 or 206 response MUST replace the corresponding headers from the cache entry.
- 304または206応答で提供されるエンドツーエンドヘッダーは、キャッシュエントリの対応するヘッダーを置き換える必要があります。
Unless the cache decides to remove the cache entry, it MUST also replace the end-to-end headers stored with the cache entry with corresponding headers received in the incoming response, except for Warning headers as described immediately above. If a header field-name in the incoming response matches more than one header in the cache entry, all such old headers MUST be replaced.
キャッシュがキャッシュエントリを削除することを決定しない限り、キャッシュエントリと共に格納されたエンドツーエンドヘッダーを、直前に説明した警告ヘッダーを除いて、着信応答で受信した対応するヘッダーに置き換える必要があります。着信応答のヘッダーフィールド名がキャッシュエントリの複数のヘッダーと一致する場合、そのような古いヘッダーはすべて置換する必要があります。
In other words, the set of end-to-end headers received in the incoming response overrides all corresponding end-to-end headers stored with the cache entry (except for stored Warning headers with warn-code 1xx, which are deleted even if not overridden).
言い換えると、着信応答で受信されたエンドツーエンドヘッダーのセットは、キャッシュエントリと共に保存されたすべての対応するエンドツーエンドヘッダーを上書きします（warn-code 1xxの保存された警告ヘッダーを除く）。オーバーライドされます）。
Note: this rule allows an origin server to use a 304 (Not Modified) or a 206 (Partial Content) response to update any header associated with a previous response for the same entity or sub-ranges thereof, although it might not always be meaningful or correct to do so. This rule does not allow an origin server to use a 304 (Not Modified) or a 206 (Partial Content) response to entirely delete a header that it had provided with a previous response.
注：このルールにより、オリジンサーバーは304（未変更）または206（部分コンテンツ）応答を使用して、同じエンティティまたはそのサブ範囲の以前の応答に関連付けられたヘッダーを更新できますが、常に意味があるとは限りませんまたはそうするように修正します。このルールでは、元のサーバーが304（未変更）または206（部分コンテンツ）応答を使用して、以前の応答で提供したヘッダーを完全に削除することはできません。
A response might transfer only a subrange of the bytes of an entity-body, either because the request included one or more Range specifications, or because a connection was broken prematurely. After several such transfers, a cache might have received several ranges of the same entity-body.
リクエストに1つ以上のRange指定が含まれていたため、または接続が途中で切断されたために、応答はエンティティ本体のバイトのサブレンジのみを転送する可能性があります。そのようないくつかの転送の後、キャッシュは同じエンティティ本体の複数の範囲を受け取った可能性があります。
If a cache has a stored non-empty set of subranges for an entity, and an incoming response transfers another subrange, the cache MAY combine the new subrange with the existing set if both the following conditions are met:
キャッシュにエンティティのサブレンジの空ではないセットが格納されていて、着信応答が別のサブレンジを転送する場合、次の両方の条件が満たされると、キャッシュは新しいサブレンジと既存のセットを組み合わせることができます（MAY）。
- Both the incoming response and the cache entry have a cache validator.
- 着信応答とキャッシュエントリの両方にキャッシュバリデータがあります。
- The two cache validators match using the strong comparison function (see section 13.3.3).
- 2つのキャッシュバリデーターは、強力な比較関数を使用して一致します（セクション13.3.3を参照）。
If either requirement is not met, the cache MUST use only the most recent partial response (based on the Date values transmitted with every response, and using the incoming response if these values are equal or missing), and MUST discard the other partial information.
いずれかの要件が満たされていない場合、キャッシュは最新の部分応答のみを使用し（すべての応答で送信された日付値に基づき、これらの値が等しいか欠落している場合は着信応答を使用しなければなりません）、他の部分情報を破棄する必要があります。
Use of server-driven content negotiation (section 12.1), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests. See section 14.44 for use of the Vary header field by servers.
サーバー主導のコンテンツネゴシエーション（セクション12.1）を使用すると、応答にVaryヘッダーフィールドが存在することで示されるように、キャッシュが後続の要求に応答を使用できる条件と手順が変更されます。サーバーによるVaryヘッダーフィールドの使用については、セクション14.44を参照してください。
A server SHOULD use the Vary header field to inform a cache of what request-header fields were used to select among multiple representations of a cacheable response subject to server-driven negotiation. The set of header fields named by the Vary field value is known as the "selecting" request-headers.
サーバーは、Varyヘッダーフィールドを使用して、サーバー主導のネゴシエーションの対象となるキャッシュ可能な応答の複数の表現から選択するために使用されたリクエストヘッダーフィールドをキャッシュに通知する必要があります（SHOULD）。 Varyフィールド値によって名前が付けられたヘッダーフィールドのセットは、「選択」リクエストヘッダーと呼ばれます。
When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the new request match the corresponding stored request-headers in the original request.
キャッシュが、Request-URIがVaryヘッダーフィールドを含む1つ以上のキャッシュエントリを指定している後続のリクエストを受信した場合、選択されているすべてのリクエストヘッダーが新しい要求は、元の要求に格納されている対応する要求ヘッダーと一致します。
The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in section 4.2.
2つのリクエストからの選択リクエストヘッダーは、最初のリクエストの選択リクエストヘッダーを場所で線形ホワイトスペース（LWS）を追加または削除して2番目のリクエストの選択リクエストヘッダーに変換できる場合にのみ一致するように定義されていますこれは、対応するBNFで許可されているか、セクション4.2のメッセージヘッダーに関するルールに従って、複数のメッセージヘッダーフィールドを同じフィールド名で組み合わせることができます。
A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted by the origin server.
"*"のVaryヘッダーフィールド値は常に一致せず、そのリソースに対する後続のリクエストは元のサーバーによってのみ適切に解釈されます。
If the selecting request header fields for the cached entry do not match the selecting request header fields of the new request, then the cache MUST NOT use a cached entry to satisfy the request unless it first relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity to be used.
キャッシュされたエントリの選択リクエストヘッダーフィールドが新しいリクエストの選択リクエストヘッダーフィールドと一致しない場合、キャッシュは条件付きで最初のオリジンサーバーに新しいリクエストをリレーしない限り、キャッシュされたエントリを使用してリクエストを満たすことはできません。リクエストを送信すると、サーバーは304（変更なし）で応答します。これには、使用するエンティティを示すエンティティタグまたはContent-Locationが含まれます。
If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
エンティティタグがキャッシュされた表現に割り当てられた場合、転送されるリクエストは条件付きであり、リソースのすべてのキャッシュエントリのIf-None-Matchヘッダーフィールドにエンティティタグを含める必要があります。これにより、現在キャッシュに保持されているエンティティのセットがサーバーに伝達されるため、これらのエンティティのいずれかが要求されたエンティティと一致した場合、サーバーは304（Not Modified）応答のETagヘッダーフィールドを使用して、キャッシュにどのエントリを通知することができます適切です。新しい応答のエンティティタグが既存のエントリのエンティティタグと一致する場合、新しい応答を使用して既存のエントリのヘッダーフィールドを更新する必要があり（SHOULD）、結果をクライアントに返さなければなりません（MUST）。
If any of the existing cache entries contains only partial content for the associated entity, its entity-tag SHOULD NOT be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that entry.
既存のキャッシュエントリのいずれかに、関連付けられたエンティティの部分的なコンテンツのみが含まれている場合、そのエントリで完全に満たされる範囲に対するリクエストでない限り、そのエンティティタグはIf-None-Matchヘッダーフィールドに含めないでください。
If a cache receives a successful response whose Content-Location field matches that of an existing cache entry for the same Request-]URI, whose entity-tag differs from that of the existing entry, and whose Date is more recent than that of the existing entry, the existing entry SHOULD NOT be returned in response to future requests and SHOULD be deleted from the cache.
Content-Locationフィールドが同じRequest-] URIの既存のキャッシュエントリのものと一致し、エンティティタグが既存のエントリのものと異なり、日付が既存のものより新しい成功した応答をキャッシュが受信した場合エントリ、既存のエントリは将来のリクエストに応じて返されるべきではなく（SHOULD NOT）、キャッシュから削除されるべきです（SHOULD）。
For reasons of security and privacy, it is necessary to make a distinction between "shared" and "non-shared" caches. A non-shared cache is one that is accessible only to a single user. Accessibility in this case SHOULD be enforced by appropriate security mechanisms. All other caches are considered to be "shared." Other sections of this specification place certain constraints on the operation of shared caches in order to prevent loss of privacy or failure of access controls.
セキュリティとプライバシーの理由から、「共有」キャッシュと「非共有」キャッシュを区別する必要があります。非共有キャッシュは、単一のユーザーのみがアクセスできるキャッシュです。この場合のアクセシビリティは、適切なセキュリティメカニズムによって実施する必要があります（SHOULD）。他のすべてのキャッシュは「共有」されていると見なされます。この仕様の他のセクションでは、プライバシーの喪失やアクセス制御の失敗を防ぐために、共有キャッシュの操作に特定の制約を課しています。
A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) MAY store the response. However, the cache MUST treat this as a partial response. Partial responses MAY be combined as described in section 13.5.4; the result might be a full response or might still be partial. A cache MUST NOT return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code. A cache MUST NOT return a partial response using a status code of 200 (OK).
不完全な応答を受信するキャッシュ（たとえば、Content-Lengthヘッダーで指定されたよりもデータのバイト数が少ない場合）は、応答を格納できます（MAY）。ただし、キャッシュはこれを部分応答として扱う必要があります。部分応答は、セクション13.5.4で説明されているように組み合わせることができます。結果は完全な応答になる場合もあれば、部分的な場合もあります。キャッシュは、206（Partial Content）ステータスコードを使用して、明示的にマークを付けずにクライアントに部分応答を返してはなりません（MUST NOT）。キャッシュは、ステータスコード200（OK）を使用して部分的な応答を返してはなりません（MUST NOT）。
If a cache receives a 5xx response while attempting to revalidate an entry, it MAY either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it MAY return a previously received response unless the cached entry includes the "must-revalidate" cache-control directive (see section 14.9).
キャッシュがエントリの再検証を試みている間に5xx応答を受信した場合、キャッシュはこの応答を要求元のクライアントに転送するか、サーバーが応答に失敗したかのように振る舞う場合があります。後者の場合、キャッシュされたエントリに「must-revalidate」キャッシュ制御ディレクティブが含まれていない限り（セクション14.9を参照）、以前に受信した応答を返す場合があります。
Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any resources SHOULD NOT have side effects that would lead to erroneous behavior if these responses are taken from a cache. They MAY still have side effects, but a cache is not required to consider such side effects in its caching decisions. Caches are always expected to observe an origin server's explicit restrictions on caching.
オリジンサーバーがそれらの応答のキャッシュを明示的に禁止していない限り、リソースへのGETおよびHEADメソッドの適用は、これらの応答がキャッシュから取得された場合に誤った動作を引き起こすような副作用を持つべきではありません。それらはまだ副作用を持っているかもしれませんが、キャッシュはキャッシングの決定においてそのような副作用を考慮する必要はありません。キャッシュは常に、オリジンサーバーのキャッシングに関する明示的な制限を遵守する必要があります。
We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that responses from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache. See section 9.1.1 for related information.
このルールの1つの例外に注意してください。一部のアプリケーションでは、クエリURL（rel_path部分に「？」が含まれているもの）とともにGETおよびHEADを従来から使用して、重大な副作用のある操作を実行しているため、キャッシュはこのようなURIへの応答を新鮮なものとして処理してはなりません（MUST NOT）サーバーが明示的な有効期限を提供しない限り。これは特に、そのようなURIに対するHTTP / 1.0サーバーからの応答がキャッシュから取得されるべきではないことを意味します。関連情報については、セクション9.1.1を参照してください。
The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries to become non-transparently invalid. That is, although they might continue to be "fresh," they do not accurately reflect what the origin server would return for a new request on that resource.
起点サーバーのリソースで実行される特定のメソッドの影響により、1つ以上の既存のキャッシュエントリが透過的に無効になる場合があります。つまり、それらは引き続き「新鮮」である可能性がありますが、そのリソースに対する新しい要求に対してオリジンサーバーが返すものを正確に反映していません。
There is no way for the HTTP protocol to guarantee that all such cache entries are marked invalid. For example, the request that caused the change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules help reduce the likelihood of erroneous behavior.
HTTPプロトコルが、そのようなキャッシュエントリすべてが無効であるとマークされることを保証する方法はありません。たとえば、元のサーバーで変更を引き起こした要求が、キャッシュエントリが格納されているプロキシを経由していない可能性があります。ただし、いくつかのルールは、誤動作の可能性を減らすのに役立ちます。
In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from its storage, or will mark these as "invalid" and in need of a mandatory revalidation before they can be returned in response to a subsequent request.
このセクションでは、「エンティティを無効にする」というフレーズは、キャッシュがそのエンティティのすべてのインスタンスをストレージから削除するか、それらを「無効」としてマークし、必須の再検証が必要な場合に応答して返されるようにすることを意味します。後続のリクエスト。
Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present). These methods are:
一部のHTTPメソッドでは、キャッシュによってエンティティを無効にする必要があります。これは、Request-URI、またはLocationまたはContent-Locationヘッダー（存在する場合）によって参照されるエンティティーです。これらのメソッドは次のとおりです。
- PUT
- 置く
- DELETE
- 削除
- POST
- 役職
In order to prevent denial of service attacks, an invalidation based on the URI in a Location or Content-Location header MUST only be performed if the host part is the same as in the Request-URI.
サービス拒否攻撃を防ぐために、LocationまたはContent-LocationヘッダーのURIに基づく無効化は、ホスト部分がRequest-URIと同じである場合にのみ実行する必要があります。
A cache that passes through requests for methods it does not understand SHOULD invalidate any entities referred to by the Request-URI.
理解できないメソッドのリクエストを通過するキャッシュは、Request-URIによって参照されるエンティティを無効にする必要があります（SHOULD）。
All methods that might be expected to cause modifications to the origin server's resources MUST be written through to the origin server. This currently includes all methods except for GET and HEAD. A cache MUST NOT reply to such a request from a client before having transmitted the request to the inbound server, and having received a corresponding response from the inbound server. This does not prevent a proxy cache from sending a 100 (Continue) response before the inbound server has sent its final reply.
オリジンサーバーのリソースを変更することが予想されるすべてのメソッドは、オリジンサーバーに書き込まれる必要があります。これには現在、GETとHEADを除くすべてのメソッドが含まれています。キャッシュは、インバウンドサーバーにリクエストを送信し、インバウンドサーバーから対応するレスポンスを受信する前に、クライアントからのそのようなリクエストに応答してはなりません（MUST NOT）。これは、インバウンド・サーバーが最終応答を送信する前に、プロキシー・キャッシュが100（Continue）応答を送信することを妨げません。
The alternative (known as "write-back" or "copy-back" caching) is not allowed in HTTP/1.1, due to the difficulty of providing consistent updates and the problems arising from server, cache, or network failure prior to write-back.
HTTP / 1.1では、代替手段（「ライトバック」または「コピーバック」キャッシングとして知られています）は許可されていません。これは、一貫性のある更新を提供することが困難であり、書き込み前にサーバー、キャッシュ、またはネットワーク障害から発生する問題が原因です。バック。
If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8) response is received from a resource while any existing responses for the same resource are cached, the cache SHOULD use the new response to reply to the current request. It MAY insert it into cache storage and MAY, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response to be returned. If it inserts the new response into cache storage the rules in section 13.5.3 apply.
同じリソースの既存の応答がキャッシュされているときに、新しいキャッシュ可能な（セクション14.9.2、13.2.5、13.2.6および13.8を参照）応答がリソースから受信された場合、キャッシュは現在の応答に応答するために新しい応答を使用する必要があります（SHOULD）。リクエスト。それをキャッシュストレージに挿入してもよいし（MAY）、他のすべての要件を満たしている場合は、それを使用して、以前に古い応答が返される原因となっていた将来の要求に応答します。新しい応答をキャッシュストレージに挿入する場合、セクション13.5.3のルールが適用されます。
Note: a new response that has an older Date header value than existing cached responses is not cacheable.
注：既存のキャッシュされた応答よりも古い日付ヘッダー値を持つ新しい応答はキャッシュできません。
User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.
多くの場合、ユーザーエージェントには、「戻る」ボタンや履歴リストなどの履歴メカニズムがあり、これを使用して、セッションの前半で取得したエンティティを再表示できます。
History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.
履歴メカニズムとキャッシュは異なります。特に履歴メカニズムは、リソースの現在の状態の意味的に透過的なビューを表示しようとすべきではありません。むしろ、履歴メカニズムは、リソースが取得されたときにユーザーが見たものを正確に示すことを目的としています。
By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.
デフォルトでは、有効期限は履歴メカニズムには適用されません。エンティティがまだストレージ内にある場合、ユーザーが期限切れの履歴ドキュメントを更新するようにエージェントを明確に構成していない限り、エンティティが期限切れになっても履歴メカニズムはそれを表示する必要があります（SHOULD）。
This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.
これは、ビューが古くなっている可能性があることを履歴メカニズムがユーザーに通知することを禁止するものではありません。
Note: if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider it important that users not be presented with error messages or warning messages when they use navigation controls (such as BACK) to view previously fetched resources. Even though sometimes such resources ought not to cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects of improperly functioning history mechanisms.
注：履歴リストのメカニズムによりユーザーが古いリソースを不必要に表示できない場合、サービス作成者はHTTP有効期限コントロールとキャッシュコントロールの使用を避けようとする傾向があります。サービスの作成者は、ナビゲーションコントロール（[戻る]など）を使用して以前にフェッチしたリソースを表示するときに、ユーザーにエラーメッセージや警告メッセージが表示されないようにすることが重要だと考える場合があります。そのようなリソースはキャッシュされるべきではない、またはすぐに期限切れになるはずですが、ユーザーインターフェイスの考慮事項により、サービス作成者は、不適切に機能する影響を受けないように、キャッシュを防止する他の手段（「1回のみ」のURLなど）に頼らざるを得ない場合があります。歴史のメカニズム。
14 Header Field Definitions
14ヘッダーフィールドの定義
This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.
このセクションでは、すべての標準HTTP / 1.1ヘッダーフィールドの構文とセマンティクスを定義します。エンティティヘッダーフィールドの場合、送信者と受信者はどちらも、エンティティの送信者と受信者に応じて、クライアントまたはサーバーを指します。
The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers 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 request-headerフィールドを使用して、応答に受け入れ可能な特定のメディアタイプを指定できます。 Acceptヘッダーを使用して、インライン画像のリクエストの場合のように、リクエストが特定の小さなタイプのセットに限定されることを明示できます。
Accept = "Accept" ":" #( media-range [ accept-params ] )
Accept = "Accept" "："＃（media-range [accept-params]）
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" 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 MAY include media type parameters that are applicable to that range.
アスタリスク「*」文字は、メディアタイプを範囲にグループ化するために使用されます。「* / *」はすべてのメディアタイプを示し、「type / *」はそのタイプのすべてのサブタイプを示します。メディア範囲には、その範囲に適用可能なメディアタイプパラメータが含まれる場合があります。
Each media-range MAY be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (section 3.9). The default value is q=1.
各メディア範囲の後には、1つ以上のaccept-paramsが続く場合があり、相対的な品質係数を示す「q」パラメータで始まります。最初の「q」パラメーター（存在する場合）は、メディア範囲パラメーターをAccept-paramsから分離します。品質係数により、ユーザーまたはユーザーエージェントは、0から1までのqvalueスケールを使用して、そのメディア範囲の相対的な優先度を示すことができます（セクション3.9）。デフォルト値はq = 1です。
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
SHOULD be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in quality."
「私はオーディオ/ベーシックを好みますが、80％の品質低下で利用可能なオーディオタイプが最も良い場合は、それを送ってください」と解釈する必要があります。
If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.
Acceptヘッダーフィールドが存在しない場合、クライアントはすべてのメディアタイプを受け入れると見なされます。 Acceptヘッダーフィールドが存在し、サーバーが結合されたAcceptフィールド値に従って受け入れ可能な応答を送信できない場合、サーバーは406（受け入れられない）応答を送信する必要があります（SHOULD）。
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 preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity."
言葉で言うと、これは「text / htmlとtext / xcが推奨されるメディアタイプですが、存在しない場合はtext / x-dviエンティティを送信し、存在しない場合はtext / plainを送信してください。エンティティ。"
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/html, text/html;level=1, */*
have the following precedence:
次の優先順位があります。
1) text/html;level=1
2) text/html
3) text/*
4) */*
The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that 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:
次の値が関連付けられます。
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 which cannot interact with other rendering agents, this default set ought to be configurable by the user.
注：ユーザーエージェントには、特定のメディア範囲の品質値のデフォルトセットが提供される場合があります。ただし、ユーザーエージェントが他のレンダリングエージェントと対話できないクローズドシステムでない限り、このデフォルトセットはユーザーが構成できる必要があります。
The Accept-Charset request-header field can be used to indicate what character sets are acceptable for the response. This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability to a server which is capable of representing documents in those character sets.
Accept-Charsetリクエストヘッダーフィールドを使用して、どの文字セットが応答に受け入れられるかを示すことができます。このフィールドにより、クライアントは、より包括的な文字セットまたは特殊な目的の文字セットを理解でき、それらの文字セットでドキュメントを表現できるサーバーにその機能を通知できます。
Accept-Charset = "Accept-Charset" ":"
1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
Character set values are described in section 3.4. Each charset MAY be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An example is
文字セット値については、セクション3.4で説明します。各文字セットには、その文字セットに対するユーザーの好みを表す関連する品質値を与えることができます（MAY）。デフォルト値はq = 1です。例は
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets not explicitly mentioned get a quality value of 0, except for ISO-8859-1, which gets a quality value of 1 if not explicitly mentioned.
Accept-Charsetフィールドに存在する場合、特別な値 "*"は、Accept-Charsetフィールドのどこにも記載されていないすべての文字セット（ISO-8859-1を含む）に一致します。 Accept-Charsetフィールドに「*」が存在しない場合、明示的に指定されていない場合に品質値1を取得するISO-8859-1を除き、明示的に指定されていないすべての文字セットの品質値は0になります。
If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server SHOULD send an error response with the 406 (not acceptable) status code, though the sending of an unacceptable response is also allowed.
Accept-Charsetヘッダーが存在しない場合、デフォルトでは、任意の文字セットが受け入れられます。 Accept-Charsetヘッダーが存在し、サーバーがAccept-Charsetヘッダーに従って受け入れ可能な応答を送信できない場合、サーバーは406（受け入れ不可）ステータスコードを含むエラー応答を送信する必要がありますが、許容できない応答も許可されます。
The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings (section 3.5) that are acceptable in the response.
Accept-EncodingリクエストヘッダーフィールドはAcceptに似ていますが、応答で許容されるコンテンツコーディング（セクション3.5）を制限します。
Accept-Encoding = "Accept-Encoding" ":"
Accept-Encoding = "Accept-Encoding" "："
1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
Examples of its use are:
その使用例は次のとおりです。
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules:
サーバーは、Accept-Encodingフィールドに従って、次のルールを使用して、コンテンツコーディングが許容可能かどうかをテストします。
1. If the 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 3.9, a qvalue of 0 means "not acceptable.")
1. content-codingがAccept-Encodingフィールドにリストされているcontent-codingsの1つである場合、qvalueが0でない限り、それは許容されます（セクション3.9で定義されているように、qvalue 0は「許容されない」を意味します。」）
2. The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header field.
2. Accept-Encodingフィールドの特別な「*」記号は、ヘッダーフィールドに明示的にリストされていない使用可能なcontent-codingと一致します。
3. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
3. 複数のコンテンツコーディングが許容できる場合、ゼロ以外のqvalueが最も高い許容可能なコンテンツコーディングが優先されます。
4. The "identity" content-coding is always acceptable, unless specifically refused because the Accept-Encoding field includes "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.
4. Accept-Encodingフィールドに "identity; q = 0"が含まれているため、またはフィールドに "*; q = 0"が含まれ、明示的に "identity"が含まれていないために特に拒否されない限り、 "identity"コンテンツコーディングは常に許容されます。コンテンツコーディング。 Accept-Encodingフィールド値が空の場合、「ID」エンコーディングのみが受け入れられます。
If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
Accept-Encodingフィールドがリクエストに存在し、サーバーがAccept-Encodingヘッダーに従って受け入れ可能な応答を送信できない場合、サーバーは406（Not Acceptable）ステータスコードを含むエラー応答を送信する必要があります（SHOULD）。
If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.
Accept-Encodingフィールドがリクエストに存在しない場合、サーバーはクライアントがコンテンツコーディングを受け入れると想定してもよい（MAY）。この場合、「アイデンティティ」が利用可能なコンテンツコーディングの1つである場合、サーバーは、「アイデンティティ」コンテンツコーディングを使用する必要があります（別のコンテンツコーディングがクライアントにとって意味があるという追加情報がない場合）。
Note: If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings commonly understood by HTTP/1.0 clients (i.e.,
注：リクエストにAccept-Encodingフィールドが含まれておらず、「identity」コンテンツコーディングが利用できない場合、HTTP / 1.0クライアントで一般的に理解されるコンテンツコーディング（つまり、
"gzip" and "compress") are preferred; some older clients improperly display messages sent with other content-codings. The server might also make this decision based on information about the particular user-agent or client.
"gzip"および "compress"）が推奨されます。古いクライアントの中には、他のコンテンツコーディングで送信されたメッセージを正しく表示しないものがあります。サーバーは、特定のユーザーエージェントまたはクライアントに関する情報に基づいてこの決定を行うこともあります。
Note: Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will not work and are not permitted with x-gzip or x-compress.
注：ほとんどのHTTP / 1.0アプリケーションは、コンテンツコーディングに関連付けられたqvalueを認識または従いません。つまり、qvaluesは機能せず、x-gzipまたはx-compressでは許可されません。
The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request. Language tags are defined in section 3.10.
Accept-LanguageリクエストヘッダーフィールドはAcceptに似ていますが、リクエストへの応答として優先される自然言語のセットを制限します。言語タグはセクション3.10で定義されています。
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
Each language-range MAY be given an associated quality value which represents an estimate of the user's preference for the languages specified by that range. The quality value defaults to "q=1". For example,
各言語範囲には、その範囲で指定された言語に対するユーザーの好みの推定を表す関連する品質値を与えることができます。品質値のデフォルトは「q = 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 language-range matches a language-tag if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first tag character following the prefix is "-". The special range "*", if present in the Accept-Language field, matches every tag not matched by any other range present in the Accept-Language field.
「私はデンマーク語が好きですが、イギリス英語と他のタイプの英語を受け入れます。」言語範囲は、タグと完全に一致する場合、または接頭辞に続く最初のタグ文字が「-」になるようにタグの接頭辞と完全に一致する場合、言語タグと一致します。 Accept-Languageフィールドに存在する場合、特別な範囲 "*"は、Accept-Languageフィールドに存在する他のどの範囲とも一致しないすべてのタグに一致します。
Note: This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always true that if a user understands a language with a certain tag, then this user will also understand all languages with tags for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.
注：この接頭辞マッチングルールの使用は、言語タグが言語に割り当てられていることを意味するものではなく、ユーザーが特定のタグを持つ言語を理解している場合、このユーザーはタグを持つすべての言語も理解するこのタグが接頭辞であるもの。この場合、接頭辞ルールは接頭辞タグの使用を許可するだけです。
The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor assigned is 0. If no Accept-Language header is present in the request, the server SHOULD assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned a quality factor greater than 0 are acceptable.
Accept-Languageフィールドによって言語タグに割り当てられた言語品質係数は、言語タグと一致するフィールドの最も長い言語範囲の品質値です。タグに一致するフィールドの言語範囲がない場合、割り当てられた言語品質係数は0です。リクエストにAccept-Languageヘッダーが存在しない場合、サーバーはすべての言語が同等に受け入れ可能であると想定する必要があります（SHOULD）。 Accept-Languageヘッダーが存在する場合、0より大きい品質係数が割り当てられているすべての言語が受け入れ可能です。
It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic preferences of the user in every request. For a discussion of this issue, see section 15.1.4.
すべてのリクエストでユーザーの完全な言語設定を含むAccept-Languageヘッダーを送信することは、ユーザーのプライバシーの期待に反する場合があります。この問題の説明については、セクション15.1.4を参照してください。
As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field MUST NOT be given in the request.
了解度は個々のユーザーに大きく依存するため、クライアントアプリケーションでユーザーが使用できる言語設定を選択できるようにすることをお勧めします。選択肢が利用できない場合、Accept-Languageヘッダーフィールドをリクエストで指定してはなりません（MUST NOT）。
Note: When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an 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 get the best matching behavior.
注：言語設定の選択をユーザーが利用できるようにする場合、ユーザーは上記の言語マッチングの詳細に精通していないことを実装者に思い出させ、適切なガイダンスを提供する必要があります。例として、ユーザーは "en-gb"を選択すると、イギリス英語が利用できない場合にあらゆる種類の英語のドキュメントが提供されると想定する場合があります。このような場合、ユーザーエージェントは、「en」を追加して最適な一致動作を得るよう提案する場合があります。
The Accept-Ranges response-header field allows the server to indicate its acceptance of range requests for a resource:
Accept-Ranges応答ヘッダーフィールドを使用すると、サーバーはリソースの範囲要求の受け入れを示すことができます。
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
Origin servers that accept byte-range requests MAY send
バイト範囲リクエストを受け入れるオリジンサーバーは送信してもよい（MAY）
Accept-Ranges: bytes
Accept-Ranges：バイト
but are not required to do so. Clients MAY generate byte-range requests without having received this header for the resource involved. Range units are defined in section 3.12.
ただし、そうする必要はありません。クライアントは、関連するリソースのこのヘッダーを受信せずに、バイト範囲のリクエストを生成できます（MAY）。範囲の単位はセクション3.12で定義されています。
Servers that do not accept any kind of range request for a resource MAY send
リソースに対するどのような種類の範囲要求も受け入れないサーバーは送信してもよい（MAY）
Accept-Ranges: none
Accept-Ranges：なし
to advise the client not to attempt a range request.
範囲リクエストを試行しないようにクライアントにアドバイスします。
The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server. A cached response is "fresh" if its age does not exceed its freshness lifetime. Age values are calculated as specified in section 13.2.3.
Age応答ヘッダーフィールドは、送信元のサーバーで応答（またはその再検証）が生成されてからの送信者の推定時間を伝えます。キャッシュされた応答は、その存続期間がその存続期間を超えない場合、「新鮮」です。年齢の値は、セクション13.2.3で指定されているように計算されます。
Age = "Age" ":" age-value age-value = delta-seconds
年齢= "年齢" "："年齢の値年齢の値=デルタ秒
Age values are non-negative decimal integers, representing time in seconds.
経過時間の値は負でない10進整数であり、秒単位で時間を表します。
If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows, it MUST transmit an Age header with a value of 2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST include an Age header field in every response generated from its own cache. Caches SHOULD use an arithmetic type of at least 31 bits of range.
キャッシュが表すことができる最大の正の整数より大きい値を受信する場合、またはキャッシュの経過時間の計算のいずれかがオーバーフローする場合、キャッシュは2147483648（2 ^ 31）の値を持つAgeヘッダーを送信する必要があります。キャッシュを含むHTTP / 1.1サーバーは、自身のキャッシュから生成されるすべての応答にAgeヘッダーフィールドを含める必要があります。キャッシュは、少なくとも31ビットの範囲の算術型を使用する必要があります（SHOULD）。
The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header field MUST be present in a 405 (Method Not Allowed) response.
Allow entity-headerフィールドには、Request-URIで識別されるリソースがサポートするメソッドのセットがリストされています。このフィールドの目的は、厳密に、リソースに関連付けられた有効なメソッドを受信者に通知することです。 Allowヘッダーフィールドは、405（Method Not Allowed）応答に存在する必要があります。
Allow = "Allow" ":" #Method
Example of use:
使用例：
Allow: GET, HEAD, PUT
許可：GET、HEAD、PUT
This field cannot prevent a client from trying other methods. However, the indications given by the Allow header field value SHOULD be followed. The actual set of allowed methods is defined by the origin server at the time of each request.
このフィールドは、クライアントが他の方法を試みることを妨げることはできません。ただし、Allowヘッダーフィールドの値によって示される指示に従う必要があります。許可されたメソッドの実際のセットは、各リクエスト時に元のサーバーによって定義されます。
The Allow header field MAY be provided with a PUT request to recommend the methods to be supported by the new or modified resource. The server is not required to support these methods and SHOULD include an Allow header in the response giving the actual supported methods.
新しいまたは変更されたリソースによってサポートされるメソッドを推奨するために、AllowヘッダーフィールドにPUTリクエストが提供される場合があります。サーバーはこれらのメソッドをサポートする必要はなく、実際にサポートされているメソッドを示す応答にAllowヘッダーを含める必要があります（SHOULD）。
A proxy MUST NOT modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other means of communicating with the origin server.
プロキシは、指定されたすべてのメソッドを理解していない場合でも、Allowヘッダーフィールドを変更してはなりません（MUST NOT）。
A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--does so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
サーバーで自分自身を認証することを望むユーザーエージェント（通常は、必ずしもそうではないが、401応答を受け取った後）は、要求にAuthorization要求ヘッダーフィールドを含めることによって行います。 Authorizationフィールドの値は、要求されているリソースのレルムのユーザーエージェントの認証情報を含む資格情報で構成されます。
Authorization = "Authorization" ":" credentials
Authorization = "Authorization" "："資格情報
HTTP access authentication is described in "HTTP Authentication: Basic and Digest Access Authentication" [43]. If a request is authenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).
HTTPアクセス認証については、「HTTP認証：基本およびダイジェストアクセス認証」[43]を参照してください。リクエストが認証され、レルムが指定されている場合、同じクレデンシャルはこのレルム内の他のすべてのリクエストに対して有効である必要があります（チャレンジ値によって異なるクレデンシャルや同期クロックを使用するクレデンシャルなど、認証スキーム自体はそれ以外は必要ないと想定） 。
When a shared cache (see section 13.7) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:
共有キャッシュ（セクション13.7を参照）がAuthorizationフィールドを含む要求を受け取った場合、次の特定の例外のいずれかが当てはまらない限り、対応する応答を他の要求への応答として返してはなりません（MUST NOT）。
1. If the response includes the "s-maxage" cache-control directive, the cache MAY use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request. (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy MUST always revalidate it before re-using it.
1. 応答に「s-maxage」キャッシュ制御ディレクティブが含まれている場合、キャッシュは後続の要求への応答にその応答を使用できます（MAY）。ただし、（指定された最大経過時間が経過した場合）プロキシキャッシュは、最初にオリジンサーバーで再検証し、新しいリクエストのリクエストヘッダーを使用して、オリジンサーバーが新しいリクエストを認証できるようにする必要があります。 （これはs-maxageに定義された動作です。）応答に「s-maxage = 0」が含まれている場合、プロキシは再利用する前に常に再検証する必要があります。
2. If the response includes the "must-revalidate" cache-control directive, the cache MAY use that response in replying to a subsequent request. But if the response is stale, all caches MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request.
2. 応答に「must-revalidate」キャッシュ制御ディレクティブが含まれている場合、キャッシュは後続の要求への応答にその応答を使用できます（MAY）。ただし、応答が古くなっている場合は、すべてのキャッシュが最初にオリジンサーバーでそれを再検証し、新しいリクエストのリクエストヘッダーを使用して、オリジンサーバーが新しいリクエストを認証できるようにする必要があります。
3. If the response includes the "public" cache-control directive, it MAY be returned in reply to any subsequent request.
3. 応答に "public"キャッシュ制御ディレクティブが含まれている場合、後続の要求への応答として返される場合があります。
The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain. The directives specify behavior intended to prevent caches from adversely interfering with the request or response. These directives typically override the default caching algorithms. Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.
Cache-Control general-headerフィールドは、要求/応答チェーンに沿ったすべてのキャッシングメカニズムに従う必要があるディレクティブを指定するために使用されます。ディレクティブは、キャッシュが要求または応答に悪影響を与えることを防ぐための動作を指定します。これらのディレクティブは通常、デフォルトのキャッシュアルゴリズムをオーバーライドします。要求にディレクティブが存在しても、応答で同じディレクティブが指定されることを意味しないという点で、キャッシュディレクティブは単方向です。
Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see section 14.32).
HTTP / 1.0キャッシュはCache-Controlを実装せず、Pragma：no-cacheのみを実装する場合があることに注意してください（セクション14.32を参照）。
Cache directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives might be applicable to all recipients along the request/response chain. It is not possible to specify a cache-directive for a specific cache.
ディレクティブは要求/応答チェーン上のすべての受信者に適用できるため、キャッシュディレクティブは、そのアプリケーションに対する重要性に関係なく、プロキシまたはゲートウェイアプリケーションによってパススルーされる必要があります。特定のキャッシュにcache-directiveを指定することはできません。
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive | cache-response-directive
cache-directive = cache-request-directive | cache-response-directive
cache-request-directive =
"no-cache" ; Section 14.9.1
| "no-store" ; Section 14.9.2
| "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4
| "max-stale" [ "=" delta-seconds ] ; Section 14.9.3
| "min-fresh" "=" delta-seconds ; Section 14.9.3
| "no-transform" ; Section 14.9.5
| "only-if-cached" ; Section 14.9.4
| cache-extension ; Section 14.9.6
cache-response-directive =
"public" ; Section 14.9.1
| "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
| "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
| "no-store" ; Section 14.9.2
| "no-transform" ; Section 14.9.5
| "must-revalidate" ; Section 14.9.4
| "proxy-revalidate" ; Section 14.9.4
| "max-age" "=" delta-seconds ; Section 14.9.3
| "s-maxage" "=" delta-seconds ; Section 14.9.3
| cache-extension ; Section 14.9.6
cache-extension = token [ "=" ( token | quoted-string ) ]
cache-extension = token ["="（token | quoted-string）]
When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest of the request or response. This mechanism supports extensibility; implementations of future versions of the HTTP protocol might apply these directives to header fields not defined in HTTP/1.1.
ディレクティブが1＃field-nameパラメータなしで表示される場合、ディレクティブはリクエスト全体またはレスポンス全体に適用されます。そのようなディレクティブが1＃field-nameパラメーターと共に現れる場合、それは名前付きフィールドにのみ適用され、残りの要求または応答には適用されません。このメカニズムは拡張性をサポートします。 HTTPプロトコルの将来のバージョンの実装では、これらのディレクティブをHTTP / 1.1で定義されていないヘッダーフィールドに適用する可能性があります。
The cache-control directives can be broken down into these general categories:
キャッシュ制御ディレクティブは、次の一般的なカテゴリに分類できます。
- Restrictions on what are cacheable; these may only be imposed by the origin server.
- キャッシュ可能なものに関する制限。これらは、オリジンサーバーによってのみ課される場合があります。
- Restrictions on what may be stored by a cache; these may be imposed by either the origin server or the user agent.
- キャッシュに保存できるものに関する制限。これらは、起点サーバーまたはユーザーエージェントによって課せられる場合があります。
- Modifications of the basic expiration mechanism; these may be imposed by either the origin server or the user agent.
- 基本的な有効期限メカニズムの変更;これらは、起点サーバーまたはユーザーエージェントによって課せられる場合があります。
- Controls over cache revalidation and reload; these may only be imposed by a user agent.
- キャッシュの再検証とリロードを制御します。これらは、ユーザーエージェントによってのみ課される場合があります。
- Control over transformation of entities.
- エンティティの変換を制御します。
- Extensions to the caching system.
- キャッシングシステムの拡張。
By default, a response is cacheable if the requirements of the request method, request header fields, and the response status indicate that it is cacheable. Section 13.4 summarizes these defaults for cacheability. The following Cache-Control response directives allow an origin server to override the default cacheability of a response:
デフォルトでは、リクエストメソッド、リクエストヘッダーフィールド、およびレスポンスステータスの要件がキャッシュ可能であることを示している場合、レスポンスはキャッシュ可能です。セクション13.4は、キャッシュ可能性に関するこれらのデフォルトをまとめたものです。次のCache-Control応答ディレクティブを使用すると、オリジンサーバーは応答のデフォルトのキャッシュ可能性を上書きできます。
public Indicates that the response MAY be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also Authorization, section 14.8, for additional details.)
public通常はキャッシュ不可、または非共有キャッシュ内でのみキャッシュ可能であっても、応答がキャッシュによってキャッシュされる可能性があることを示します。 （詳細については、承認、セクション14.8も参照してください。）
private Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache MAY cache the response.
private応答メッセージのすべてまたは一部が単一のユーザーを対象とし、共有キャッシュによってキャッシュされてはならないことを示します。これにより、オリジンサーバーは、応答の指定された部分が1人のユーザーのみを対象としており、他のユーザーによる要求に対しては有効な応答ではないことを示すことができます。プライベート（非共有）キャッシュは応答をキャッシュしてもよい（MAY）。
Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.
注：プライベートという単語のこの使用法は、応答がキャッシュされる場所を制御するだけであり、メッセージコンテンツのプライバシーを保証することはできません。
no-cache If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
no-cache no-cacheディレクティブでフィールド名が指定されていない場合、キャッシュは、オリジンサーバーでの再検証に成功せずに、後続の要求を満たすために応答を使用してはなりません（MUST NOT）。これにより、オリジンサーバーは、クライアント要求に対して古い応答を返すように構成されているキャッシュによっても、キャッシュを防止できます。
If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
no-cacheディレクティブが1つ以上のフィールド名を指定している場合、キャッシュは、キャッシングに関する他の制限に従って、後続の要求を満たすために応答を使用できます（MAY）。ただし、指定されたフィールド名は、オリジンサーバーでの再検証に成功せずに、後続の要求への応答で送信してはなりません（MUST NOT）。これにより、オリジンサーバーは、応答内の特定のヘッダーフィールドの再利用を防ぎながら、残りの応答のキャッシュを許可できます。
Note: Most HTTP/1.0 caches will not recognize or obey this directive.
注：ほとんどのHTTP / 1.0キャッシュは、このディレクティブを認識または従いません。
no-store The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and MAY be sent either in a response or in a request. If sent in a request, a cache MUST NOT store any part of either this request or any response to it. If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non-shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
no-store no-storeディレクティブの目的は、機密情報（バックアップテープなど）の不注意によるリリースまたは保持を防ぐことです。 no-storeディレクティブはメッセージ全体に適用され、応答または要求で送信される場合があります。リクエストで送信される場合、キャッシュはこのリクエストまたはリクエストへの応答のいずれの部分も保存してはなりません（MUST NOT）。応答で送信される場合、キャッシュは、この応答またはそれを引き出した要求のいずれの部分も格納してはなりません（MUST NOT）。このディレクティブは、非共有キャッシュと共有キャッシュの両方に適用されます。この場合の「保存しない」とは、キャッシュが情報を意図的に不揮発性ストレージに保存してはならず、情報を転送した後、できるだけ早く揮発性ストレージから情報を削除するよう最善を尽くさなければならないことを意味します。
Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). History buffers MAY store such responses as part of their normal operation.
このディレクティブが応答に関連付けられている場合でも、ユーザーはそのような応答をキャッシュシステムの外部に明示的に保存することがあります（たとえば、[名前を付けて保存]ダイアログを使用）。履歴バッファは、通常の操作の一部としてそのような応答を格納してもよい（MAY）。
The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about accidental releases of information via unanticipated accesses to cache data structures. While the use of this directive might improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
このディレクティブの目的は、キャッシュデータ構造への予期しないアクセスによる情報の偶発的なリリースを懸念する特定のユーザーおよびサービス作成者の規定された要件を満たすことです。このディレクティブを使用するとプライバシーが向上する場合がありますが、プライバシーを確保するための信頼できるメカニズムや十分なメカニズムではありません。特に、悪意のある、または侵害されたキャッシュはこのディレクティブを認識または従わず、通信ネットワークは盗聴に対して脆弱である可能性があります。
The expiration time of an entity MAY be specified by the origin server using the Expires header (see section 14.21). Alternatively, it MAY be specified using the max-age directive in a response. When the max-age cache-control directive is present in a cached response, the response is stale if its current age is greater than the age value given (in seconds) at the time of a new request for that resource. The max-age directive on a response implies that the response is cacheable (i.e., "public") unless some other, more restrictive cache directive is also present.
エンティティの有効期限は、元のサーバーがExpiresヘッダーを使用して指定できます（セクション14.21を参照）。または、応答でmax-ageディレクティブを使用して指定してもよい（MAY）。キャッシュされた応答にmax-age cache-controlディレクティブが存在する場合、現在の経過時間がそのリソースに対する新しいリクエスト時に指定された経過時間（秒単位）より大きい場合、応答は古くなります。応答のmax-ageディレクティブは、他のより制限的なキャッシュディレクティブも存在しない限り、応答がキャッシュ可能（つまり「パブリック」）であることを意味します。
If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer expiration time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be useful if certain HTTP/1.0 caches improperly calculate ages or expiration times, perhaps due to desynchronized clocks.
応答にExpiresヘッダーとmax-ageディレクティブの両方が含まれている場合、Expiresヘッダーの方が制限が厳しい場合でも、max-ageディレクティブはExpiresヘッダーをオーバーライドします。このルールにより、元のサーバーは、特定の応答に対して、HTTP / 1.0キャッシュよりもHTTP / 1.1（またはそれ以降）キャッシュに長い有効期限を提供できます。これは、特定のHTTP / 1.0キャッシュが、おそらく非同期化されたクロックが原因で、経過時間または有効期限を正しく計算しない場合に役立ちます。
Many HTTP/1.0 cache implementations will treat an Expires value that is less than or equal to the response Date value as being equivalent to the Cache-Control response directive "no-cache". If an HTTP/1.1 cache receives such a response, and the response does not include a Cache-Control header field, it SHOULD consider the response to be non-cacheable in order to retain compatibility with HTTP/1.0 servers.
多くのHTTP / 1.0キャッシュ実装は、応答の日付値以下のExpires値を、Cache-Control応答ディレクティブ「no-cache」と同等のものとして扱います。 HTTP / 1.1キャッシュがそのような応答を受信し、その応答にCache-Controlヘッダーフィールドが含まれていない場合、HTTP / 1.0サーバーとの互換性を維持するために、応答をキャッシュ不可と見なすべきです（SHOULD）。
Note: An origin server might wish to use a relatively new HTTP cache control feature, such as the "private" directive, on a network including older caches that do not understand that feature. The origin server will need to combine the new feature with an Expires field whose value is less than or equal to the Date value. This will prevent older caches from improperly caching the response.
注：オリジンサーバーは、「プライベート」ディレクティブなどの比較的新しいHTTPキャッシュ制御機能を、その機能を理解していない古いキャッシュを含むネットワークで使用したい場合があります。オリジンサーバーは、新しい機能を、日付の値以下のExpiresフィールドと組み合わせる必要があります。これにより、古いキャッシュが応答を不適切にキャッシュするのを防ぎます。
s-maxage If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage directive also implies the semantics of the proxy-revalidate directive (see section 14.9.4), i.e., that the shared cache must not use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. The s-maxage directive is always ignored by a private cache.
s-maxage応答にs-maxageディレクティブが含まれている場合、共有キャッシュ（プライベートキャッシュではない）の場合、このディレクティブで指定された最大経過時間は、max-ageディレクティブまたはExpiresヘッダーで指定された最大経過時間を上書きします。 s-maxageディレクティブは、proxy-revalidateディレクティブ（セクション14.9.4を参照）のセマンティクスも意味します。つまり、共有キャッシュは、古くなってからエントリを使用して、最初にそれを再検証せずに後続のリクエストに応答することはできませんオリジンサーバー。 s-maxageディレクティブは、プライベートキャッシュによって常に無視されます。
Note that most older caches, not compliant with this specification, do not implement any cache-control directives. An origin server wishing to use a cache-control directive that restricts, but does not prevent, caching by an HTTP/1.1-compliant cache MAY exploit the requirement that the max-age directive overrides the Expires header, and the fact that pre-HTTP/1.1-compliant caches do not observe the max-age directive.
この仕様に準拠していない古いキャッシュのほとんどは、キャッシュ制御ディレクティブを実装していません。 HTTP / 1.1準拠のキャッシュによるキャッシュを制限するが防止はしないキャッシュ制御ディレクティブの使用を希望するオリジンサーバーは、max-ageディレクティブがExpiresヘッダーをオーバーライドするという要件、およびHTTPより前の/1.1準拠のキャッシュは、max-ageディレクティブを監視しません。
Other directives allow a user agent to modify the basic expiration mechanism. These directives MAY be specified on a request:
その他のディレクティブを使用すると、ユーザーエージェントは基本的な有効期限メカニズムを変更できます。これらのディレクティブはリクエストで指定してもよいです：
max-age Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. Unless max-stale directive is also included, the client is not willing to accept a stale response.
max-ageクライアントが、指定された時間（秒単位）以下の応答をクライアントが受け入れる用意があることを示します。 max-staleディレクティブも含まれていない限り、クライアントは古い応答を受け入れる用意がありません。
min-fresh Indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.
min-freshクライアントが、フレッシュネスライフタイムが現在の経過時間と指定された時間（秒単位）を足したものである応答を受け入れる用意があることを示します。つまり、クライアントは、少なくとも指定された秒数の間、まだ新鮮な応答を望んでいます。
max-stale Indicates that the client is willing to accept a response that has exceeded its expiration time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age.
max-staleクライアントが有効期限を超えた応答を受け入れる用意があることを示します。 max-staleに値が割り当てられている場合、クライアントは、指定された秒数を超えて有効期限を超えた応答を受け入れる用意があります。 max-staleに値が割り当てられていない場合、クライアントは任意の年齢の古い応答を受け入れてもかまいません。
If a cache returns a stale response, either because of a max-stale directive on a request, or because the cache is configured to override the expiration time of a response, the cache MUST attach a Warning header to the stale response, using Warning 110 (Response is stale).
リクエストのmax-staleディレクティブが原因で、またはキャッシュが応答の有効期限を上書きするように構成されているために、キャッシュが失効した応答を返す場合、キャッシュは警告110を使用して、失効した応答に警告ヘッダーを添付する必要があります（応答が古くなっています）。
A cache MAY be configured to return stale responses without validation, but only if this does not conflict with any "MUST"-level requirements concerning cache validation (e.g., a "must-revalidate" cache-control directive).
キャッシュを検証せずに古い応答を返すように構成できますが、これは、キャッシュ検証に関する「MUST」レベルの要件（「must-revalidate」キャッシュ制御ディレクティブなど）と競合しない場合のみです。
If both the new request and the cached entry include "max-age" directives, then the lesser of the two values is used for determining the freshness of the cached entry for that request.
新しいリクエストとキャッシュされたエントリの両方に「max-age」ディレクティブが含まれている場合、そのリクエストのキャッシュされたエントリの新しさを判断するために、2つの値の小さい方が使用されます。
Sometimes a user agent might want or need to insist that a cache revalidate its cache entry with the origin server (and not just with the next cache along the path to the origin server), or to reload its cache entry from the origin server. End-to-end revalidation might be necessary if either the cache or the origin server has overestimated the expiration time of the cached response. End-to-end reload may be necessary if the cache entry has become corrupted for some reason.
ユーザーエージェントは、キャッシュがオリジンサーバーで（オリジンサーバーへのパスに沿った次のキャッシュだけでなく）オリジンサーバーでキャッシュエントリを再検証することを要求したり、要求したりする必要がある場合があります。キャッシュまたはオリジンサーバーのいずれかがキャッシュされた応答の有効期限を過大評価した場合、エンドツーエンドの再検証が必要になることがあります。何らかの理由でキャッシュエントリが破損した場合は、エンドツーエンドのリロードが必要になることがあります。
End-to-end revalidation may be requested either when the client does not have its own local cached copy, in which case we call it "unspecified end-to-end revalidation", or when the client does have a local cached copy, in which case we call it "specific end-to-end revalidation."
エンドツーエンドの再検証は、クライアントに独自のローカルキャッシュコピーがない場合に要求されることがあります。その場合、「未指定のエンドツーエンド再検証」と呼ばれます。または、クライアントにローカルキャッシュコピーがある場合、これを「特定のエンドツーエンドの再検証」と呼びます。
The client can specify these three kinds of action using Cache-Control request directives:
クライアントは、Cache-Controlリクエストディレクティブを使用して、次の3種類のアクションを指定できます。
End-to-end reload The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field names MUST NOT be included with the no-cache directive in a request. The server MUST NOT use a cached copy when responding to such a request.
エンドツーエンドのリロードリクエストには「no-cache」キャッシュ制御ディレクティブ、またはHTTP / 1.0クライアントとの互換性のために「Pragma：no-cache」が含まれています。リクエストのno-cacheディレクティブにフィールド名を含めることはできません。サーバーは、そのような要求に応答するときにキャッシュされたコピーを使用してはなりません（MUST NOT）。
Specific end-to-end revalidation The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request includes a cache-validating conditional with the client's current validator.
特定のエンドツーエンドの再検証リクエストには、「max-age = 0」のキャッシュ制御ディレクティブが含まれています。これにより、オリジンサーバーへのパスに沿った各キャッシュは、次のキャッシュまたはサーバーで独自のエントリを再検証します。最初のリクエストには、クライアントの現在のバリデータを使用した条件付きキャッシュ検証が含まれます。
Unspecified end-to-end revalidation The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request does not include a cache-validating conditional; the first cache along the path (if any) that holds a cache entry for this resource includes a cache-validating conditional with its current validator.
未指定のエンドツーエンドの再検証リクエストには、「max-age = 0」キャッシュ制御ディレクティブが含まれています。これにより、起点サーバーへのパスに沿った各キャッシュは、次のキャッシュまたはサーバーで独自のエントリを再検証します。最初のリクエストには、キャッシュ検証条件が含まれていません。このリソースのキャッシュエントリを保持するパスに沿った最初のキャッシュ（存在する場合）には、現在のバリデータを使用した条件付きキャッシュ検証が含まれます。
max-age When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with the cache entry. In this case, the cache MAY use either validator in making its own request without affecting semantic transparency.
max-age max-age = 0ディレクティブを使用して中間キャッシュを強制し、独自のキャッシュエントリを再検証し、クライアントがリクエストで独自のバリデーターを提供した場合、提供されたバリデーターは現在保存されているバリデーターと異なる場合があります。キャッシュエントリ。この場合、キャッシュは、セマンティックの透過性に影響を与えずに、独自のリクエストを行う際にいずれかのバリデーターを使用できます。
However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate cache can compare the returned validator with the one provided in the client's request, using the strong comparison function. If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) response.
ただし、バリデーターの選択はパフォーマンスに影響を与える可能性があります。最善の方法は、中間キャッシュが要求を行うときに独自のバリデーターを使用することです。サーバーが304（変更されていません）で応答した場合、キャッシュは検証されたコピーを200（OK）応答でクライアントに返すことができます。ただし、サーバーが新しいエンティティとキャッシュバリデーターで応答した場合、中間キャッシュは、強力な比較関数を使用して、返されたバリデーターをクライアントのリクエストで提供されたバリデーターと比較できます。クライアントのバリデーターがオリジンサーバーのバリデーターと等しい場合、中間キャッシュは単に304（Not Modified）を返します。それ以外の場合は、200（OK）応答で新しいエンティティを返します。
If a request includes the no-cache directive, it SHOULD NOT include min-fresh, max-stale, or max-age.
リクエストにno-cacheディレクティブが含まれている場合は、min-fresh、max-stale、またはmax-ageを含めないでください。
only-if-cached In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those responses that it currently has stored, and not to reload or revalidate with the origin server. To do this, the client may include the only-if-cached directive in a request. If it receives this directive, a cache SHOULD either respond using a cached entry that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status. However, if a group of caches is being operated as a unified system with good internal connectivity, such a request MAY be forwarded within that group of caches.
only-if-cachedネットワーク接続が極端に悪い場合など、場合によっては、クライアントはキャッシュに、現在格納されている応答のみを返し、配信元サーバーで再読み込みまたは再検証しないようにすることがあります。これを行うために、クライアントは、要求にonly-if-cachedディレクティブを含めることができます。このディレクティブを受信した場合、キャッシュは、リクエストの他の制約と一致するキャッシュされたエントリを使用して応答するか、504（ゲートウェイタイムアウト）ステータスで応答する必要があります（SHOULD）。ただし、キャッシュのグループが内部接続が良好な統合システムとして運用されている場合、そのような要求はそのキャッシュのグループ内で転送される場合があります。
must-revalidate Because a cache MAY be configured to ignore a server's specified expiration time, and because a client request MAY include a max-stale directive (which has a similar effect), the protocol also includes a mechanism for the origin server to require revalidation of a cache entry on any subsequent use. When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. (I.e., the cache MUST do an end-to-end revalidation every time, if, based solely on the origin server's Expires or max-age value, the cached response is stale.)
キャッシュはサーバーの指定された有効期限を無視するように構成されている可能性があり、クライアントのリクエストにはmax-staleディレクティブが含まれている可能性があるため（同様の効果があります）、プロトコルには、元のサーバーが再検証を要求するメカニズムも含まれている可能性があります以降の使用に関するキャッシュエントリの。キャッシュが受信した応答にmust-revalidateディレクティブが存在する場合、そのキャッシュは、古くなってからエントリを使用してはならず、最初にオリジンサーバーで再検証せずに後続のリクエストに応答することはできません。 （つまり、元のサーバーのExpiresまたはmax-age値のみに基づいて、キャッシュされた応答が古くなっている場合、キャッシュは毎回エンドツーエンドの再検証を実行する必要があります。）
The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances an HTTP/1.1 cache MUST obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.
特定のプロトコル機能の信頼できる操作をサポートするには、再検証が必要なディレクティブが必要です。すべての状況で、HTTP / 1.1キャッシュは、再検証が必要なディレクティブに従う必要があります。特に、キャッシュが何らかの理由でオリジンサーバーに到達できない場合は、504（ゲートウェイタイムアウト）応答を生成する必要があります。
Servers SHOULD send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in incorrect operation, such as a silently unexecuted financial transaction. Recipients MUST NOT take any automated action that violates this directive, and MUST NOT automatically provide an unvalidated copy of the entity if revalidation fails.
サーバーは、エンティティのリクエストの再検証に失敗すると、サイレントで実行されない金融トランザクションなどの不正な操作が発生する可能性がある場合にのみ、revalidateディレクティブを送信する必要があります（SHOULD）。受信者は、このディレクティブに違反する自動化されたアクションを実行してはならず、再検証が失敗した場合、エンティティの検証されていないコピーを自動的に提供してはなりません。
Although this is not recommended, user agents operating under severe connectivity constraints MAY violate this directive but, if so, MUST explicitly warn the user that an unvalidated response has been provided. The warning MUST be provided on each unvalidated access, and SHOULD require explicit user confirmation.
これは推奨されませんが、厳しい接続制約の下で動作しているユーザーエージェントはこのディレクティブに違反する可能性がありますが、そうであれば、未検証の応答が提供されたことをユーザーに明示的に警告する必要があります。検証されていないアクセスごとに警告を提供する必要があり、明示的なユーザー確認を必要とします（SHOULD）。
proxy-revalidate The proxy-revalidate directive has the same meaning as the must-revalidate directive, except that it does not apply to non-shared user agent caches. It can be used on a response to an authenticated request to permit the user's cache to store and later return the response without needing to revalidate it (since it has already been authenticated once by that user), while still requiring proxies that service many users to revalidate each time (in order to make sure that each user has been authenticated). Note that such authenticated responses also need the public cache control directive in order to allow them to be cached at all.
proxy-revalidate proxy-revalidateディレクティブは、非共有のユーザーエージェントキャッシュには適用されないことを除いて、must-revalidateディレクティブと同じ意味です。これは、認証された要求への応答で使用して、ユーザーのキャッシュに保存し、後で再検証する必要なく応答を返すことができます（既にそのユーザーによって一度認証されているため）一方で、多くのユーザーにサービスを提供するプロキシを必要とします毎回再検証します（各ユーザーが認証されていることを確認するため）。そのような認証された応答は、それらをまったくキャッシュできるようにするために、パブリックキャッシュ制御ディレクティブも必要であることに注意してください。
no-transform Implementors of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A non-transparent proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link.
no-transform中間キャッシュ（プロキシ）のインプリメンターは、特定のエンティティボディのメディアタイプを変換すると便利であることがわかりました。非透過プロキシーは、例えば、キャッシュ・スペースを節約するため、または低速リンク上のトラフィック量を削減するために、画像フォーマット間で変換する場合があります。
Serious operational problems occur, however, when these transformations are applied to entity bodies intended for certain kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end authentication, all depend on receiving an entity body that is bit for bit identical to the original entity-body.
ただし、これらの変換を特定の種類のアプリケーションを対象としたエンティティボディに適用すると、深刻な運用上の問題が発生します。たとえば、医用画像処理、科学データ分析、エンドツーエンド認証を使用するアプリケーションはすべて、元のエンティティボディと少しずつ同じエンティティボディを受信することに依存しています。
Therefore, if a message includes the no-transform directive, an intermediate cache or proxy MUST NOT change those headers that are listed in section 13.5.2 as being subject to the no-transform directive. This implies that the cache or proxy MUST NOT change any aspect of the entity-body that is specified by these headers, including the value of the entity-body itself.
したがって、メッセージにno-transformディレクティブが含まれている場合、中間キャッシュまたはプロキシは、セクション13.5.2でno-transformディレクティブの対象としてリストされているヘッダーを変更してはなりません（MUST NOT）。これは、キャッシュまたはプロキシーが、エンティティー本体自体の値を含め、これらのヘッダーで指定されているエンティティー本体の側面を変更してはならないことを意味します。
The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional assigned value. Informational extensions (those which do not require a change in cache behavior) MAY be added without changing the semantics of other directives. Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives. Both the new directive and the standard directive are supplied, such that applications which do not understand the new directive will default to the behavior specified by the standard directive, and those that understand the new directive will recognize it as modifying the requirements associated with the standard directive. In this way, extensions to the cache-control directives can be made without requiring changes to the base protocol.
Cache-Controlヘッダーフィールドは、1つ以上のキャッシュ拡張トークンを使用して拡張できます。それぞれにオプションの値が割り当てられています。情報拡張（キャッシュの動作を変更する必要のないもの）は、他のディレクティブのセマンティクスを変更せずに追加できます（MAY）。動作拡張機能は、キャッシュディレクティブの既存のベースに対する修飾子として機能するように設計されています。新しいディレクティブと標準ディレクティブの両方が提供され、新しいディレクティブを理解しないアプリケーションはデフォルトで標準ディレクティブによって指定された動作になり、新しいディレクティブを理解するアプリケーションはそれを標準に関連する要件の変更として認識します指令。このようにして、ベースプロトコルを変更することなく、キャッシュ制御ディレクティブを拡張できます。
This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version, obeying certain extensions, and ignoring all directives that it does not understand.
この拡張メカニズムは、ネイティブHTTPバージョンに定義されたすべてのキャッシュ制御ディレクティブに従い、特定の拡張に従い、理解できないすべてのディレクティブを無視するHTTPキャッシュに依存します。
For example, consider a hypothetical new response directive called community which acts as a modifier to the private directive. We define this new directive to mean that, in addition to any non-shared cache, any cache which is shared only by members of the community named within its value may cache the response. An origin server wishing to allow the UCI community to use an otherwise private response in their shared cache(s) could do so by including
たとえば、プライベートディレクティブの修飾子として機能するコミュニティと呼ばれる架空の新しい応答ディレクティブについて考えてみます。この新しいディレクティブを定義して、非共有キャッシュに加えて、その値内で指定されたコミュニティのメンバーのみが共有するキャッシュが応答をキャッシュできることを意味します。 UCIコミュニティが共有キャッシュで他の方法でプライベートな応答を使用できるようにしたいオリジンサーバーは、
Cache-Control: private, community="UCI"
Cache-Control：private、community = "UCI"
A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since it will also see and understand the private directive and thus default to the safe behavior.
このヘッダーフィールドを参照するキャッシュは、コミュニティキャッシュ拡張機能を理解していない場合でも正しく動作します。プライベートディレクティブも参照および理解するため、デフォルトで安全な動作が行われるためです。
Unrecognized cache-directives MUST be ignored; it is assumed that any cache-directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard directives (or the response's default cacheability) such that the cache behavior will remain minimally correct even if the cache does not understand the extension(s).
認識されないキャッシュディレクティブは無視する必要があります。 HTTP / 1.1キャッシュによって認識されない可能性が高いcache-directiveは標準のディレクティブ（または応答のデフォルトのキャッシュ可能性）と組み合わされ、キャッシュが拡張機能を理解していなくても、キャッシュの動作が最小限に留まると想定されています（ s）。
The Connection general-header field allows the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections.
接続の一般ヘッダーフィールドを使用すると、送信者は、特定の接続に必要なオプションを指定できます。また、プロキシは、他の接続を介して通信してはいけません。
The Connection header has the following grammar:
Connectionヘッダーの文法は次のとおりです。
Connection = "Connection" ":" 1#(connection-token)
connection-token = token
HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option.
HTTP / 1.1プロキシは、メッセージが転送される前に接続ヘッダーフィールドを解析し、このフィールドの各接続トークンについて、接続トークンと同じ名前のメッセージからヘッダーフィールドを削除する必要があります。接続オプションは、対応する追加ヘッダーフィールドではなく、接続ヘッダーフィールドに接続トークンが存在することによって通知されます。その接続オプションに関連付けられたパラメーターがない場合、追加ヘッダーフィールドは送信されない可能性があるためです。
Message headers listed in the Connection header MUST NOT include end-to-end headers, such as Cache-Control.
Connectionヘッダーにリストされているメッセージヘッダーには、Cache-Controlなどのエンドツーエンドヘッダーを含めることはできません。
HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example,
HTTP / 1.1は、送信者が応答の完了後に接続が閉じられることを通知するための「閉じる」接続オプションを定義します。例えば、
Connection: close
接続：閉じる
in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete.
要求または応答ヘッダーフィールドのいずれかで、現在の要求/応答が完了した後、接続が「永続的」（セクション8.1）と見なされるべきではないことを示します。
HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.
持続的接続をサポートしないHTTP / 1.1アプリケーションは、すべてのメッセージに「閉じる」接続オプションを含める必要があります。
A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the connection-token. This protects against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See section 19.6.2.
接続ヘッダーを含むHTTP / 1.0（またはそれよりも低いバージョン）メッセージを受信するシステムは、このフィールドの各接続トークンについて、接続と同じ名前のメッセージからヘッダーフィールドを削除して無視する必要があります。トークン。これにより、HTTP / 1.1より前のプロキシによるこのようなヘッダーフィールドの誤った転送から保護されます。セクション19.6.2を参照してください。
The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.
Content-Encodingエンティティヘッダーフィールドは、メディアタイプの修飾子として使用されます。存在する場合、その値は、エンティティ本体に適用されている追加のコンテンツコーディングを示します。したがって、Content-Typeヘッダーフィールドによって参照されるメディアタイプを取得するために、どのデコードメカニズムを適用する必要があるかを示します。 Content-Encodingは主に、基になるメディアタイプのIDを失うことなくドキュメントを圧縮できるようにするために使用されます。
Content-Encoding = "Content-Encoding" ":" 1#content-coding
Content codings are defined in section 3.5. An example of its use is
コンテンツのコーディングはセクション3.5で定義されています。その使用例は
Content-Encoding: gzip
コンテンツのエンコード：gzip
The content-coding is a characteristic of the entity identified by the Request-URI. Typically, the entity-body is stored with this encoding and is only decoded before rendering or analogous usage. However, a non-transparent proxy MAY modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control directive is present in the message.
content-codingは、Request-URIによって識別されるエンティティの特性です。通常、エンティティ本体はこのエンコーディングで保存され、レンダリングまたは類似の使用の前にのみデコードされます。ただし、「no-transform」キャッシュ制御ディレクティブがメッセージに含まれていない限り、新しいコーディングが受信者に受け入れられることがわかっている場合、非透過プロキシはコンテンツコーディングを変更できます（MAY）。
If the content-coding of an entity is not "identity", then the response MUST include a Content-Encoding entity-header (section 14.11) that lists the non-identity content-coding(s) used.
エンティティのコンテンツコーディングが「アイデンティティ」ではない場合、応答には、使用された非アイデンティティコンテンツコーディングをリストするコンテンツエンコーディングエンティティヘッダー（セクション14.11）を含める必要があります。
If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type).
リクエストメッセージ内のエンティティのコンテンツコーディングがオリジンサーバーで受け入れられない場合、サーバーはステータスコード415（サポートされていないメディアタイプ）で応答する必要があります（SHOULD）。
If multiple encodings have been applied to an entity, the content codings MUST be listed in the order in which they were applied. Additional information about the encoding parameters MAY be provided by other entity-header fields not defined by this specification.
エンティティに複数のエンコーディングが適用されている場合、コンテンツコーディングは、それらが適用された順序でリストされている必要があります。エンコーディングパラメータに関する追加情報は、この仕様で定義されていない他のエンティティヘッダーフィールドによって提供される場合があります。
The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this might not be equivalent to all the languages used within the entity-body.
Content-Languageエンティティヘッダーフィールドは、囲まれたエンティティの対象読者の自然言語を記述します。これは、エンティティ本体で使用されるすべての言語と同等ではない場合があることに注意してください。
Content-Language = "Content-Language" ":" 1#language-tag
Language tags are defined in section 3.10. The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate field is
言語タグはセクション3.10で定義されています。 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 an entity 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は、あらゆるメディアタイプに適用できます（テキストドキュメントに限定されません）。
The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
Content-Lengthエンティティヘッダーフィールドは、10進数のOCTETで受信者に送信されたエンティティボディのサイズを示します。または、HEADメソッドの場合、送信されたエンティティボディのサイズを示しますリクエストはGETでした。
Content-Length = "Content-Length" ":" 1*DIGIT
An example is
例は
Content-Length: 3495
コンテンツの長さ：3495
Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4.
アプリケーションは、セクション4.4のルールで禁止されていない限り、メッセージ本文の転送長を示すためにこのフィールドを使用する必要があります（SHOULD）。
Any Content-Length greater than or equal to zero is a valid value. Section 4.4 describes how to determine the length of a message-body if a Content-Length is not given.
ゼロ以上のContent-Lengthは有効な値です。 4.4節では、Content-Lengthが指定されていない場合にメッセージ本文の長さを決定する方法について説明します。
Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional field used within the "message/external-body" content-type. In HTTP, it SHOULD be sent whenever the message's length can be determined prior to being transferred, unless this is prohibited by the rules in section 4.4.
このフィールドの意味は、MIMEの対応する定義とは大きく異なります。MIMEでは、「message / external-body」コンテンツタイプ内で使用されるオプションのフィールドです。 HTTPでは、セクション4.4のルールで禁止されていない限り、転送前にメッセージの長さを決定できる場合はいつでも送信する必要があります。
The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant which is returned.
Content-Locationエンティティヘッダーフィールドは、要求されたリソースのURIとは別の場所からエンティティにアクセスできる場合に、メッセージに含まれるエンティティのリソースの場所を提供するために使用できます。サーバーは、応答エンティティに対応するバリアントのContent-Locationを提供する必要があります（SHOULD）。特に、リソースに複数のエンティティが関連付けられていて、それらのエンティティに実際に個別にアクセスできる個別の場所がある場合、サーバーは、返される特定のバリアントのContent-Locationを提供する必要があります（SHOULD）。
Content-Location = "Content-Location" ":" ( absoluteURI | relativeURI )
Content-Location = "Content-Location" "："（absoluteURI | relativeURI）
The value of Content-Location also defines the base URI for the entity.
Content-Locationの値は、エンティティのベースURIも定義します。
The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of the resource corresponding to this particular entity at the time of the request. Future requests MAY specify the Content-Location URI as the request-URI if the desire is to identify the source of that particular entity.
Content-Location値は、要求された元のURIの代わりにはなりません。これは、リクエスト時のこの特定のエンティティに対応するリソースの場所のステートメントにすぎません。将来のリクエストでは、特定のエンティティのソースを識別したい場合は、Content-Location URIをリクエストURIとして指定できます。
A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple entities retrieved from a single requested resource, as described in section 13.6.
キャッシュは、それを取得するために使用されたURIとは異なるContent-Locationを持つエンティティが、そのContent-Location URIに対する以降の要求に応答するために使用できると想定することはできません。ただし、セクション13.6で説明されているように、Content-Locationを使用して、1つの要求されたリソースから取得した複数のエンティティを区別できます。
If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.
Content-Locationが相対URIの場合、相対URIはRequest-URIに関連して解釈されます。
The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases.
PUTまたはPOSTリクエストのContent-Locationヘッダーの意味は定義されていません。これらの場合、サーバーはそれを自由に無視できます。
The Content-MD5 entity-header field, as defined in RFC 1864 [23], is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.)
RFC 1864 [23]で定義されているContent-MD5エンティティヘッダーフィールドは、エンティティボディのエンドツーエンドのメッセージ整合性チェック（MIC）を提供するためのエンティティボディのMD5ダイジェストです。 （注：MICは、送信中のエンティティ本体の偶発的な変更を検出するのに適していますが、悪意のある攻撃に対する証拠ではありません。）
Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
The Content-MD5 header field MAY be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients MAY generate the Content-MD5 header field; proxies and gateways MUST NOT generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including gateways and proxies, MAY check that the digest value in this header field matches that of the entity-body as received.
Content-MD5ヘッダーフィールドは、エンティティ本体の整合性チェックとして機能するために、オリジンサーバーまたはクライアントによって生成される場合があります。オリジンサーバーまたはクライアントのみがContent-MD5ヘッダーフィールドを生成できます。プロキシとゲートウェイはそれを生成してはなりません。これは、エンドツーエンドの整合性チェックとしてその値を無効にするためです。ゲートウェイやプロキシを含むエンティティボディの受信者は、このヘッダーフィールドのダイジェスト値が受信したエンティティボディのダイジェスト値と一致することを確認できます。
The MD5 digest is computed based on the content of the entity-body, including any content-coding that has been applied, but not including any transfer-encoding applied to the message-body. If the message is received with a transfer-encoding, that encoding MUST be removed prior to checking the Content-MD5 value against the received entity.
MD5ダイジェストは、エンティティ本体のコンテンツに基づいて計算されます。これには、適用されたコンテンツコーディングは含まれますが、メッセージ本体に適用された転送エンコーディングは含まれません。メッセージがtransfer-encodingで受信された場合、Content-MD5値を受信エンティティと照合する前に、そのエンコーディングを削除する必要があります。
This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would be sent if no transfer-encoding were being applied.
これは、ダイジェストがエンティティボディのオクテットで正確に計算され、転送エンコーディングが適用されていない場合に送信されるという結果になります。
HTTP extends RFC 1864 to permit the digest to be computed for MIME
composite media-types (e.g., multipart/* and message/rfc822), but
this does not change how the digest is computed as defined in the
preceding paragraph.
There are several consequences of this. The entity-body for composite types MAY contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application. The Transfer-Encoding header field is not allowed within body-parts.
これにはいくつかの影響があります。複合型のエンティティボディには、それぞれ独自のMIMEおよびHTTPヘッダー（Content-MD5、Content-Transfer-Encoding、およびContent-Encodingヘッダーを含む）を持つ多くのボディパーツを含めることができます（MAY）。 body-partにContent-Transfer-EncodingまたはContent-Encodingヘッダーがある場合、body-partのコンテンツにはエンコーディングが適用されていると見なされ、body-partはそのままContent-MD5ダイジェストに含まれます-つまり、アプリケーションの後。 Transfer-Encodingヘッダーフィールドは、body-parts内では許可されていません。
Conversion of all line breaks to CRLF MUST NOT be done before computing or checking the digest: the line break convention used in the text actually transmitted MUST be left unaltered when computing the digest.
すべての改行のCRLFへの変換は、ダイジェストを計算またはチェックする前に行わないでください。実際に送信されるテキストで使用される改行規則は、ダイジェストを計算するときに変更しないでください。
Note: while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another is that HTTP more frequently uses binary content types than MIME, so it is worth noting that, in such cases, the byte order used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types with any of several line break conventions and not just the canonical form using CRLF.
注：Content-MD5の定義は、MIMEエンティティ本体のRFC 1864と同様にHTTPでもまったく同じですが、HTTPエンティティ本体へのContent-MD5の適用が、MIMEエンティティへの適用とは異なる方法がいくつかあります。体。 1つは、MIMEとは異なり、HTTPはContent-Transfer-Encodingを使用せず、Transfer-EncodingおよびContent-Encodingを使用することです。もう1つは、HTTPがMIMEよりもバイナリコンテンツタイプをより頻繁に使用することです。そのため、そのような場合、ダイジェストの計算に使用されるバイトオーダーは、タイプに定義された送信バイトオーダーです。最後に、HTTPはCRLFを使用した標準形式だけでなく、いくつかの改行規則のいずれかを使用したテキストタイプの送信を許可します。
The Content-Range entity-header is sent with a partial entity-body to specify where in the full entity-body the partial body should be applied. Range units are defined in section 3.12.
Content-Rangeエンティティヘッダーは、エンティティボディ全体とともに送信され、エンティティボディ全体のどこに部分ボディを適用するかを指定します。範囲の単位はセクション3.12で定義されています。
Content-Range = "Content-Range" ":" content-range-spec
Content-Range = "Content-Range" "：" content-range-spec
content-range-spec = byte-content-range-spec byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( instance-length | "*" )
content-range-spec = byte-content-range-spec byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/"（instance-length | "*"）
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
| "*"
instance-length = 1*DIGIT
The header SHOULD indicate the total length of the full entity-body, unless this length is unknown or difficult to determine. The asterisk "*" character means that the instance-length is unknown at the time when the response was generated.
ヘッダーは、この長さが不明であるか判別が難しい場合を除いて、エンティティ本体全体の全長を示す必要があります（SHOULD）。アスタリスク「*」文字は、応答が生成された時点ではインスタンスの長さが不明であることを意味します。
Unlike byte-ranges-specifier values (see section 14.35.1), a byte-range-resp-spec MUST only specify one range, and MUST contain absolute byte positions for both the first and last byte of the range.
byte-ranges-specifier値（セクション14.35.1を参照）とは異なり、byte-range-resp-specは1つの範囲のみを指定する必要があり、範囲の最初と最後の両方のバイトの絶対バイト位置を含める必要があります。
A byte-content-range-spec with a byte-range-resp-spec whose last-byte-pos value is less than its first-byte-pos value, or whose instance-length value is less than or equal to its last-byte-pos value, is invalid. The recipient of an invalid byte-content-range-spec MUST ignore it and any content transferred along with it.
last-byte-posの値がfirst-byte-posの値よりも小さいか、instance-lengthの値が最後のバイト以下のbyte-range-resp-specを持つbyte-content-range-specバイト位置の値が無効です。無効なbyte-content-range-specの受信者は、それとそれとともに転送されるすべてのコンテンツを無視する必要があります。
A server sending a response with status code 416 (Requested range not satisfiable) SHOULD include a Content-Range field with a byte-range-resp-spec of "*". The instance-length specifies the current length of the selected resource. A response with status code 206 (Partial Content) MUST NOT include a Content-Range field with a byte-range-resp-spec of "*".
ステータスコード416（要求された範囲は満足できない）で応答を送信するサーバーは、バイト範囲のresp-specが「*」のContent-Rangeフィールドを含める必要があります（SHOULD）。 instance-lengthは、選択されたリソースの現在の長さを指定します。ステータスコード206（部分的なコンテンツ）の応答には、byte-range-resp-specが "*"のContent-Rangeフィールドを含めることはできません。
Examples of byte-content-range-spec values, assuming that the entity contains a total of 1234 bytes:
エンティティに合計1234バイトが含まれていると想定した、byte-content-range-spec値の例：
. The first 500 bytes: bytes 0-499/1234
。最初の500バイト：バイト0-499 / 1234
. The second 500 bytes: bytes 500-999/1234
。 2番目の500バイト：バイト500-999 / 1234
. All except for the first 500 bytes: bytes 500-1233/1234
。最初の500バイトを除くすべて：バイト500-1233 / 1234
. The last 500 bytes: bytes 734-1233/1234
。最後の500バイト：バイト734-1233 / 1234
When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header, and a Content-Length header showing the number of bytes actually transferred. For example,
HTTPメッセージに単一の範囲のコンテンツが含まれている場合（たとえば、単一の範囲の要求への応答、または穴のない重複する一連の範囲の要求への応答）、このコンテンツはContent-Rangeで送信されますヘッダー、および実際に転送されたバイト数を示すContent-Lengthヘッダー。例えば、
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
When an HTTP message includes the content of multiple ranges (for example, a response to a request for multiple non-overlapping ranges), these are transmitted as a multipart message. The multipart media type used for this purpose is "multipart/byteranges" as defined in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
HTTPメッセージに複数の範囲のコンテンツ（たとえば、重複しない複数の範囲に対する要求への応答）が含まれている場合、これらはマルチパートメッセージとして送信されます。この目的で使用されるマルチパートメディアタイプは、付録19.2で定義されている「multipart / byteranges」です。互換性の問題については、付録19.6.3を参照してください。
A response to a request for a single range MUST NOT be sent using the multipart/byteranges media type. A response to a request for multiple ranges, whose result is a single range, MAY be sent as a multipart/byteranges media type with one part. A client that cannot decode a multipart/byteranges message MUST NOT ask for multiple byte-ranges in a single request.
単一の範囲に対する要求への応答は、multipart / byterangesメディアタイプを使用して送信してはなりません（MUST NOT）。結果が単一の範囲である複数の範囲に対する要求への応答は、1つの部分を持つmultipart / byterangesメディアタイプとして送信される場合があります。 multipart / byterangesメッセージをデコードできないクライアントは、単一のリクエストで複数のバイト範囲を要求してはなりません（MUST NOT）。
When a client requests multiple byte-ranges in one request, the server SHOULD return them in the order that they appeared in the request.
クライアントが1つの要求で複数のバイト範囲を要求すると、サーバーは、要求に現れた順序でそれらを返す必要があります（SHOULD）。
If the server ignores a byte-range-spec because it is syntactically invalid, the server SHOULD treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing the full entity).
構文的に無効であるためにサーバーがbyte-range-specを無視する場合、サーバーはリクエストを無効なRangeヘッダーフィールドが存在しないかのように処理する必要があります（SHOULD）。 （通常、これはエンティティ全体を含む200応答を返すことを意味します）。
If the server receives a request (other than one including an If-Range request-header field) with an unsatisfiable Range request-header field (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected resource), it SHOULD return a response code of 416 (Requested range not satisfiable) (section 10.4.17).
サーバーが要求（If-Range要求ヘッダーフィールドを含むものを除く）を受け取り、範囲が満たされないRange要求ヘッダーフィールド（つまり、すべてのbyte-range-spec値のfirst-byte-pos値が大きい）選択されたリソースの現在の長さよりも）、それは応答コード416（要求された範囲は満足できない）（セクション10.4.17）を返す必要があります。
Note: clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for an unsatisfiable Range request-header, since not all servers implement this request-header.
注：すべてのサーバーがこのリクエストヘッダーを実装しているわけではないため、クライアントはサーバーに依存して、満足できない範囲のリクエストヘッダーに対して200（OK）応答の代わりに416（要求された範囲が満足できない）応答を送信することはできません。
The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.
Content-Typeエンティティヘッダーフィールドは、受信者に送信されたエンティティボディのメディアタイプを示します。HEADメソッドの場合は、リクエストがGETであった場合に送信されるメディアタイプを示します。
Content-Type = "Content-Type" ":" media-type
Content-Type = "Content-Type" "："メディアタイプ
Media types are defined in section 3.7. An example of the field is
メディアタイプはセクション3.7で定義されています。フィールドの例は
Content-Type: text/html; charset=ISO-8859-4
Further discussion of methods for identifying the media type of an entity is provided in section 7.2.1.
エンティティのメディアタイプを識別する方法については、セクション7.2.1で詳しく説明します。
The Date general-header field represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822. The field value is an HTTP-date, as described in section 3.3.1; it MUST be sent in RFC 1123 [8]-date format.
Date general-headerフィールドは、メッセージが発信された日時を表し、RFC 822のorig-dateと同じセマンティクスを持っています。フィールド値は、セクション3.3.1で説明されているように、HTTP-dateです。 RFC 1123 [8] -date形式で送信する必要があります。
Date = "Date" ":" HTTP-date
日付= "日付" "：" HTTP日付
An example is
例は
Date: Tue, 15 Nov 1994 08:12:31 GMT
Origin servers MUST include a Date header field in all responses, except in these cases:
オリジンサーバーは、次の場合を除いて、すべての応答に日付ヘッダーフィールドを含める必要があります。
1. If the response status code is 100 (Continue) or 101 (Switching Protocols), the response MAY include a Date header field, at the server's option.
1. 応答ステータスコードが100（続行）または101（スイッチングプロトコル）の場合、サーバーのオプションで、応答に日付ヘッダーフィールドを含めることができます（MAY）。
2. If the response status code conveys a server error, e.g. 500 (Internal Server Error) or 503 (Service Unavailable), and it is inconvenient or impossible to generate a valid Date.
2. レスポンスステータスコードがサーバーエラーを伝える場合。 500（内部サーバーエラー）または503（サービスを利用できません）。有効な日付を生成するのは不便または不可能です。
3. If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, the rules in section 14.18.1 MUST be followed.
3. サーバーに現在の時刻の妥当な概算を提供できるクロックがない場合、その応答には日付ヘッダーフィールドを含めてはなりません（MUST NOT）。この場合、セクション14.18.1のルールに従う必要があります。
A received message that does not have a Date header field MUST be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires a Date. An HTTP implementation without a clock MUST NOT cache responses without revalidating them on every use. An HTTP cache, especially a shared cache, SHOULD use a mechanism, such as NTP [28], to synchronize its clock with a reliable external standard.
メッセージが受信者によってキャッシュされるか、日付を必要とするプロトコルを介してゲートウェイ処理される場合、Dateヘッダーフィールドを持たない受信メッセージは、受信者によって1が割り当てられる必要があります。クロックなしのHTTP実装は、使用するたびに再検証せずに応答をキャッシュしてはなりません（MUST NOT）。 HTTPキャッシュ、特に共有キャッシュは、NTP [28]などのメカニズムを使用して、クロックを信頼できる外部標準と同期させる必要があります（SHOULD）。
Clients SHOULD only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even then it is optional. A client without a clock MUST NOT send a Date header field in a request.
クライアントは、PUTおよびPOSTリクエストの場合のように、エンティティボディを含むメッセージで日付ヘッダーフィールドのみを送信する必要があります（SHOULD）。それでもオプションです。クロックのないクライアントは、リクエストで日付ヘッダーフィールドを送信してはいけません。
The HTTP-date sent in a Date header SHOULD NOT represent a date and time subsequent to the generation of the message. It SHOULD represent the best available approximation of the date and time of message generation, unless the implementation has no means of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the entity is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic value.
Dateヘッダーで送信されるHTTP日付は、メッセージの生成後の日付と時刻を表すべきではありません（SHOULD NOT）。これは、実装が適度に正確な日付と時刻を生成する手段を持っていない場合を除き、メッセージ生成の日付と時刻の利用可能な最良の概算を表す必要があります。理論的には、日付はエンティティが生成される直前の瞬間を表す必要があります。実際には、日付は、メッセージの生成中にいつでも、そのセマンティック値に影響を与えることなく生成できます。
Some origin server implementations might not have a clock available. An origin server without a clock MUST NOT assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or user with a reliable clock. It MAY assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration" of responses without storing separate Expires values for each resource).
元のサーバーの実装によっては、使用可能なクロックがない場合があります。クロックのないオリジンサーバーは、ExpiresまたはLast-Modifiedの値を、信頼できるクロックを持つシステムまたはユーザーがリソースに関連付けていない限り、応答に割り当ててはなりません（MUST NOT）。サーバーの構成時またはそれ以前に、過去であることがわかっているExpires値を割り当てることができます（これにより、リソースごとに個別のExpires値を格納することなく、応答の「事前有効期限」が可能になります）。
The ETag response-header field provides the current value of the entity tag for the requested variant. The headers used with entity tags are described in sections 14.24, 14.26 and 14.44. The entity tag MAY be used for comparison with other entities from the same resource (see section 13.3.3).
ETagレスポンスヘッダーフィールドは、リクエストされたバリアントのエンティティタグの現在の値を提供します。エンティティタグで使用されるヘッダーについては、セクション14.24、14.26、および14.44で説明します。エンティティタグは、同じリソースの他のエンティティとの比較に使用できます（セクション13.3.3を参照）。
ETag = "ETag" ":" entity-tag
ETag = "ETag" "："エンティティタグ
Examples:
例：
ETag: "xyzzy" ETag: W/"xyzzy" ETag: ""
ETag： "xyzzy" ETag：W / "xyzzy" ETag： ""
The Expect request-header field is used to indicate that particular server behaviors are required by the client.
Expectリクエストヘッダーフィールドは、特定のサーバー動作がクライアントに必要であることを示すために使用されます。
Expect = "Expect" ":" 1#expectation
expectation = "100-continue" | expectation-extension
expectation-extension = token [ "=" ( token | quoted-string )
*expect-params ]
expect-params = ";" token [ "=" ( token | quoted-string ) ]
A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request MUST respond with appropriate error status. The server MUST respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with the request, some other 4xx status.
リクエストのExpectフィールドの期待値を理解できない、またはそれらに準拠できないサーバーは、適切なエラーステータスで応答する必要があります。サーバーは、期待値のいずれかを満たすことができない場合、または要求に他の問題がある場合、他の4xxステータスがある場合、417（期待値失敗）ステータスで応答する必要があります。
This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing an Expect field that includes an expectation-extension that it does not support, it MUST respond with a 417 (Expectation Failed) status.
このヘッダーフィールドは、将来の拡張に備えて拡張可能な構文で定義されています。サーバーが、サポートしていないExpectation-Extensionを含むExpectフィールドを含むリクエストを受信した場合、サーバーは417（Expectation Failed）ステータスで応答する必要があります。
Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive for quoted-string expectation-extensions.
期待値の比較は、引用符で囲まれていないトークン（100継続トークンを含む）では大文字と小文字が区別されず、引用符で囲まれた文字列の期待値拡張では大文字と小文字が区別されます。
The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST return a 417 (Expectation Failed) status if it receives a request with an expectation that it cannot meet. However, the Expect request-header itself is end-to-end; it MUST be forwarded if the request is forwarded.
Expectメカニズムはホップバイホップです。つまり、HTTP / 1.1プロキシは、満たすことができないという期待のあるリクエストを受け取った場合、417（Expectedation Failed）ステータスを返さなければなりません（MUST）。ただし、Expectリクエストヘッダー自体はエンドツーエンドです。リクエストが転送される場合は転送する必要があります。
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.
古いHTTP / 1.0およびHTTP / 1.1アプリケーションの多くは、Expectヘッダーを理解していません。
See section 8.2.3 for the use of the 100 (continue) status.
100（継続）ステータスの使用については、セクション8.2.3を参照してください。
The Expires entity-header field gives the date/time after which the response is considered stale. A stale cache entry may not normally be returned by a cache (either a proxy cache or a user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the entity). See section 13.2 for further discussion of the expiration model.
Expiresエンティティヘッダーフィールドは、応答が古くなったと見なされるまでの日時を示します。古いキャッシュエントリは、最初にオリジンサーバー（またはエンティティの新しいコピーを持つ中間キャッシュ）で検証されない限り、通常はキャッシュ（プロキシキャッシュまたはユーザーエージェントキャッシュ）によって返されない場合があります。有効期限モデルの詳細については、セクション13.2を参照してください。
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
Expiresフィールドの存在は、元のリソースがその時間に、その前に、またはその後に変更または存在しなくなることを意味しません。
The format is an absolute date and time as defined by HTTP-date in section 3.3.1; it MUST be in RFC 1123 date format:
形式は、セクション3.3.1のHTTP-dateで定義されている絶対日時です。 RFC 1123の日付形式である必要があります。
Expires = "Expires" ":" HTTP-date
Expires = "Expires" "：" HTTP-date
An example of its use is
その使用例は
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Note: if a response includes a Cache-Control field with the max-age directive (see section 14.9.3), that directive overrides the Expires field.
注：応答にmax-ageディレクティブのあるCache-Controlフィールドが含まれている場合（セクション14.9.3を参照）、そのディレクティブはExpiresフィールドをオーバーライドします。
HTTP/1.1 clients and caches MUST treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
HTTP / 1.1クライアントとキャッシュは、他の無効な日付形式、特に過去のように値「0」を含む（つまり、「期限切れ」）を扱わなければなりません（MUST）。
To mark a response as "already expired," an origin server sends an Expires date that is equal to the Date header value. (See the rules for expiration calculations in section 13.2.4.)
応答に「期限切れ」というマークを付けるために、オリジンサーバーは、Dateヘッダー値と等しいExpires日付を送信します。 （セクション13.2.4の有効期限計算のルールを参照してください。）
To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.
応答に「有効期限なし」のマークを付けるために、オリジンサーバーは、応答が送信されてから約1年後にExpires日付を送信します。 HTTP / 1.1サーバーは、1年以上先のExpires日付を送信すべきではありません（SHOULD NOT）。
The presence of an Expires header field with a date value of some time in the future on a response that otherwise would by default be non-cacheable indicates that the response is cacheable, unless indicated otherwise by a Cache-Control header field (section 14.9).
そうでなければデフォルトでキャッシュ不可になる応答に将来の日付値を持つExpiresヘッダーフィールドが存在することは、Cache-Controlヘッダーフィールド（セクション14.9）によって別段の指示がない限り、応答がキャッシュ可能であることを示します。 。
The From request-header field, if given, SHOULD contain an Internet e-mail address for the human user who controls the requesting user agent. The address SHOULD be machine-usable, as defined by "mailbox" in RFC 822 [9] as updated by RFC 1123 [8]:
From request-headerフィールドが指定されている場合、SHOULDには、要求しているユーザーエージェントを制御する人間のユーザーのインターネット電子メールアドレスが含まれている必要があります。 RFC 1123 [8]によって更新されたRFC 822 [9]の「メールボックス」で定義されているように、アドレスはマシンで使用可能である必要があります（SHOULD）。
From = "From" ":" mailbox
From = "From" "："メールボックス
An example is:
例は次のとおりです。
From: webmaster@w3.org
差出人：webmaster@w3.org
This header field MAY be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It SHOULD NOT be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents SHOULD include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end.
このヘッダーフィールドは、ロギングの目的で、および無効または不要な要求のソースを識別する手段として使用できます。安全でない形式のアクセス保護として使用しないでください。このフィールドの解釈は、実行されたメソッドの責任を受け入れる、指定された人に代わってリクエストが実行されていることです。特に、ロボットエージェントは、受信側で問題が発生した場合にロボットの実行責任者に連絡できるように、このヘッダーを含める必要があります（SHOULD）。
The Internet e-mail address in this field MAY be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original issuer's address SHOULD be used.
このフィールドのインターネット電子メールアドレスは、要求を発行したインターネットホストとは別の場合があります。たとえば、リクエストがプロキシを介して渡される場合、元の発行者のアドレスを使用する必要があります（SHOULD）。
The client SHOULD NOT send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at any time prior to a request.
クライアントは、ユーザーのプライバシー上の関心やサイトのセキュリティポリシーと競合する可能性があるため、ユーザーの承認なしにFromヘッダーフィールドを送信しないでください。ユーザーがリクエストの前にいつでもこのフィールドの値を無効化、有効化、および変更できるようにすることを強くお勧めします。
The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL, as described in section 3.2.2). The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address.
Host request-headerフィールドは、ユーザーまたは参照リソース（セクション3.2.2で説明されているように、通常はHTTP URL）によって与えられた元のURIから取得した、要求されているリソースのインターネットホストとポート番号を指定します。 Hostフィールドの値は、元のURLで指定されたオリジンサーバーまたはゲートウェイの命名機関を表す必要があります。これにより、起点サーバーまたはゲートウェイは、単一のIPアドレス上の複数のホスト名のサーバーのルート「/」URLなど、内部的にあいまいなURLを区別できます。
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL). For example, a request on the origin server for <http://www.w3.org/pub/WWW/> would properly include:
後続のポート情報のない「ホスト」は、要求されたサービスのデフォルトポートを意味します（たとえば、HTTP URLの場合は「80」）。たとえば、<http://www.w3.org/pub/WWW/>に対するオリジンサーバーのリクエストには、適切に次のものが含まれます。
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.
クライアントは、すべてのHTTP / 1.1要求メッセージにホストヘッダーフィールドを含める必要があります。要求されたURIに、要求されているサービスのインターネットホスト名が含まれていない場合は、Hostヘッダーフィールドに空の値を指定する必要があります。 HTTP / 1.1プロキシは、転送するすべての要求メッセージに、プロキシによって要求されているサービスを識別する適切なホストヘッダーフィールドが含まれていることを確認する必要があります。すべてのインターネットベースのHTTP / 1.1サーバーは、ホストヘッダーフィールドがないHTTP / 1.1要求メッセージに対して400（Bad Request）ステータスコードで応答する必要があります。
See sections 5.2 and 19.6.1.1 for other requirements relating to Host.
ホストに関連するその他の要件については、セクション5.2および19.6.1.1を参照してください。
The If-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field. Entity tags are defined in section 3.11. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used, on updating requests, to prevent inadvertent modification of the wrong version of a resource. As a special case, the value "*" matches any current entity of the resource.
If-Matchリクエストヘッダーフィールドは、条件付きにするためのメソッドで使用されます。以前にリソースから取得した1つ以上のエンティティを持つクライアントは、関連するエンティティタグのリストをIf-Matchヘッダーフィールドに含めることにより、それらのエンティティの1つが最新であることを確認できます。エンティティタグはセクション3.11で定義されています。この機能の目的は、最小限のトランザクションオーバーヘッドでキャッシュ情報を効率的に更新できるようにすることです。また、リクエストの更新時に、誤ったバージョンのリソースが誤って変更されるのを防ぐためにも使用されます。特殊なケースとして、値「*」はリソースの現在のエンティティと一致します。
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource, then the server MAY perform the requested method as if the If-Match header field did not exist.
エンティティタグのいずれかが、そのリソースに対する同様のGETリクエスト（If-Matchヘッダーなし）への応答で返されるエンティティのエンティティタグと一致する場合、または「*」が指定されていて現在のエンティティが存在する場合そのリソースの場合、サーバーは、If-Matchヘッダーフィールドが存在しない場合と同様に、要求されたメソッドを実行できます。
A server MUST use the strong comparison function (see section 13.3.3) to compare the entity tags in If-Match.
サーバーは、強力な比較関数（セクション13.3.3を参照）を使用して、If-Matchのエンティティタグを比較する必要があります。
If none of the entity tags match, or if "*" is given and no current entity exists, the server MUST NOT perform the requested method, and MUST return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method, such as PUT, from modifying a resource that has changed since the client last retrieved it.
一致するエンティティタグがない場合、または「*」が指定されていて現在のエンティティが存在しない場合、サーバーは要求されたメソッドを実行してはならず（MUST NOT）、412（Precondition Failed）応答を返す必要があります。この動作は、クライアントが最後にリソースを取得してから変更されたリソースをPUTなどの更新メソッドが変更できないようにする場合に最も役立ちます。
If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status, then the If-Match header MUST be ignored.
リクエストが、If-Matchヘッダーフィールドなしで、2xxまたは412ステータス以外の結果になる場合は、If-Matchヘッダーを無視する必要があります。
The meaning of "If-Match: *" is that the method SHOULD be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see section 14.44) exists, and MUST NOT be performed if the representation does not exist.
「If-Match：*」の意味は、配信元サーバー（またはキャッシュ、おそらくVaryメカニズムを使用して、セクション14.44を参照）によって選択された表現が存在する場合にメソッドを実行する必要がある（SHOULD）。表現が存在しません。
A request intended to update a resource (e.g., a PUT) MAY include an If-Match header field to signal that the request method MUST NOT be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without their knowledge. Examples:
リソース（PUTなど）を更新することを意図したリクエストには、If-Match値に対応するエンティティ（単一のエンティティタグ）がもはや存在しない場合、リクエストメソッドを適用してはならないことを示すIf-Matchヘッダーフィールドを含めることができます（MAY）。そのリソースの表現。これにより、ユーザーは、知らないうちにリソースが変更された場合に、要求が成功することを望まないことを示すことができます。例：
If-Match: "xyzzy" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: *
If-Match： "xyzzy" If-Match： "xyzzy"、 "r2d2xxxx"、 "c3piozzzz" If-Match：*
The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields is undefined by this specification.
If-Matchヘッダーフィールドと、If-None-MatchまたはIf-Modified-Sinceヘッダーフィールドの両方を持つリクエストの結果は、この仕様では定義されていません。
The If-Modified-Since request-header field is used with a method to make it conditional: if the requested variant has not been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (not modified) response will be returned without any message-body.
If-Modified-Since要求ヘッダーフィールドは、条件付きにするためのメソッドで使用されます。要求されたバリアントがこのフィールドで指定された時間以降に変更されていない場合、エンティティはサーバーから返されません。代わりに、メッセージ本文なしで304（変更されていない）応答が返されます。
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
If-Modified-Since = "If-Modified-Since" "：" HTTP日付
An example of the field is:
フィールドの例は次のとおりです。
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A GET method with an If-Modified-Since header and no Range header requests that the identified entity be transferred only if it has been modified since the date given by the If-Modified-Since header. The algorithm for determining this includes the following cases:
If-Modified-Sinceヘッダーがあり、RangeヘッダーがないGETメソッドは、If-Modified-Sinceヘッダーで指定された日付以降に変更された場合にのみ、識別されたエンティティの転送を要求します。これを決定するアルゴリズムには、以下のケースが含まれます。
a) If the request would normally result in anything other than a 200 (OK) status, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is invalid.
a) リクエストが通常200（OK）ステータス以外になる場合、または渡されたIf-Modified-Since日付が無効な場合、応答は通常のGETの場合とまったく同じです。サーバーの現在時刻より後の日付は無効です。
b) If the variant has been modified since the If-Modified-Since date, the response is exactly the same as for a normal GET.
b) If-Modified-Sinceの日付以降にバリアントが変更されている場合、応答は通常のGETの場合とまったく同じです。
c) If the variant has not been modified since a valid If-Modified-Since date, the server SHOULD return a 304 (Not Modified) response.
c) 有効なIf-Modified-Since日付以降にバリアントが変更されていない場合、サーバーは304（Not Modified）応答を返す必要があります（SHOULD）。
The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead.
この機能の目的は、最小限のトランザクションオーバーヘッドでキャッシュ情報を効率的に更新できるようにすることです。
Note: The Range request-header field modifies the meaning of If-Modified-Since; see section 14.35 for full details.
注：Rangeリクエストヘッダーフィールドは、If-Modified-Sinceの意味を変更します。詳細については、セクション14.35を参照してください。
Note: If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.
注：If-Modified-Since時間はサーバーによって解釈され、そのクロックはクライアントと同期していない可能性があります。
Note: When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If-Modified-Since header field for cache validation, clients are advised to use the exact date string received in a previous Last-Modified header field whenever possible.
注：一部のサーバーは、If-Modified-Sinceヘッダーフィールドを処理するときに、304（Not Modified）応答を送信するかどうかを決定するために、小なり関数ではなく正確な日付比較関数を使用します。キャッシュ検証のためにIf-Modified-Sinceヘッダーフィールドを送信するときに最良の結果を得るには、クライアントは、可能な限り、前回のLast-Modifiedヘッダーフィールドで受信した正確な日付文字列を使用することをお勧めします。
Note: If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time. The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the client and server. This includes the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since date is derived from the client's clock without correction to the server's clock. Corrections for different time bases between client and server are at best approximate due to network latency.
注：クライアントが、同じ要求に対してLast-Modifiedヘッダーから取得した日付ではなく、If-Modified-Sinceヘッダーで任意の日付を使用する場合、クライアントは、この日付がサーバーの理解で解釈されることを認識している必要があります。時間の。クライアントは、クライアントとサーバー間の時間のエンコーディングが異なるため、非同期のクロックと丸めの問題を考慮する必要があります。これには、ドキュメントが最初に要求された時間と後続の要求のIf-Modified-Since日付の間に変更された場合の競合状態の可能性、およびIf-Modified-Since日付の場合のクロックスキュー関連の問題の可能性が含まれます。サーバーのクロックを修正せずに、クライアントのクロックから導出されます。クライアントとサーバー間の異なるタイムベースの修正は、ネットワークのレイテンシのため、せいぜい概算です。
The result of a request having both an If-Modified-Since header field and either an If-Match or an If-Unmodified-Since header fields is undefined by this specification.
If-Modified-Sinceヘッダーフィールドと、If-MatchまたはIf-Unmodified-Sinceヘッダーフィールドの両方を持つリクエストの結果は、この仕様では定義されていません。
The If-None-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent a method (e.g. PUT) from inadvertently modifying an existing resource when the client believes that the resource does not exist.
If-None-Match要求ヘッダーフィールドは、条件付きにするためのメソッドで使用されます。リソースから以前に取得した1つ以上のエンティティを持つクライアントは、関連するエンティティタグのリストをIf-None-Matchヘッダーフィールドに含めることにより、それらのエンティティが現在のものでないことを確認できます。この機能の目的は、最小限のトランザクションオーバーヘッドでキャッシュ情報を効率的に更新できるようにすることです。また、リソースが存在しないとクライアントが判断したときに、メソッド（PUTなど）が既存のリソースを誤って変更しないようにするためにも使用されます。
As a special case, the value "*" matches any current entity of the resource.
特殊なケースとして、値「*」はリソースの現在のエンティティと一致します。
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource, then the server MUST NOT perform the requested method, unless required to do so because the resource's modification date fails to match that supplied in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server SHOULD respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the entities that matched. For all other request methods, the server MUST respond with a status of 412 (Precondition Failed).
エンティティタグのいずれかが、そのリソースに対する同様のGETリクエスト（If-None-Matchヘッダーなし）への応答で返されるエンティティのエンティティタグと一致する場合、または「*」が指定されており、現在のそのリソースのエンティティが存在する場合、リソースの変更日がリクエストのIf-Modified-Sinceヘッダーフィールドで提供されたものと一致しないため、サーバーは要求されたメソッドを実行してはなりません（実行する必要がない場合）。代わりに、リクエストメソッドがGETまたはHEADの場合、サーバーは、一致したエンティティのいずれかのキャッシュ関連ヘッダーフィールド（特にETag）を含め、304（Not Modified）レスポンスで応答する必要があります（SHOULD）。他のすべての要求メソッドの場合、サーバーはステータス412（前提条件の失敗）で応答する必要があります。
See section 13.3.3 for rules on how to determine if two entities tags match. The weak comparison function can only be used with GET or HEAD requests.
2つのエンティティタグが一致するかどうかを判断する方法のルールについては、セクション13.3.3を参照してください。弱比較関数は、GETまたはHEADリクエストでのみ使用できます。
If none of the entity tags match, then the server MAY perform the requested method as if the If-None-Match header field did not exist, but MUST also ignore any If-Modified-Since header field(s) in the request. That is, if no entity tags match, then the server MUST NOT return a 304 (Not Modified) response.
一致するエンティティタグがない場合、サーバーは、If-None-Matchヘッダーフィールドが存在しないかのように要求されたメソッドを実行できますが、要求内のすべてのIf-Modified-Sinceヘッダーフィールドも無視する必要があります。つまり、一致するエンティティタグがない場合、サーバーは304（Not Modified）応答を返してはなりません（MUST NOT）。
If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the If-None-Match header MUST be ignored. (See section 13.3.4 for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
リクエストで、If-None-Matchヘッダーフィールドがないと、2xxまたは304ステータス以外の結果になる場合、If-None-Matchヘッダーは無視する必要があります。 （If-Modified-SinceとIf-None-Matchの両方が同じリクエストに含まれる場合のサーバーの動作については、セクション13.3.4を参照してください。）
The meaning of "If-None-Match: *" is that the method MUST NOT be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see section 14.44) exists, and SHOULD be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
「If-None-Match：*」の意味は、オリジンサーバー（またはキャッシュ、おそらくVaryメカニズムを使用して、セクション14.44を参照）によって選択された表現が存在する場合、メソッドを実行してはならず（MUST NOT）、実行する必要がある（SHOULD）表現が存在しない場合。この機能は、PUT操作間の競合を防ぐのに役立つことを目的としています。
Examples:
例：
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *
The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header fields is undefined by this specification.
If-None-Matchヘッダーフィールドと、If-MatchまたはIf-Unmodified-Sinceヘッダーフィールドの両方を持つリクエストの結果は、この仕様では定義されていません。
If a client has a partial copy of an entity in its cache, and wishes to have an up-to-date copy of the entire entity in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the condition fails because the entity has been modified, the client would then have to make a second request to obtain the entire current entity-body.
クライアントのキャッシュにエンティティの部分的なコピーがあり、キャッシュ全体にエンティティ全体の最新のコピーを保持したい場合は、条件付きGETでRangeリクエストヘッダーを使用できます（いずれかまたは両方を使用）ただし、エンティティが変更されたために条件が失敗した場合、クライアントは、現在のエンティティボディ全体を取得するために2番目のリクエストを行う必要があります。
The If-Range header allows a client to "short-circuit" the second request. Informally, its meaning is `if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'.
If-Rangeヘッダーを使用すると、クライアントは2番目の要求を「短絡」できます。非公式には、その意味は「エンティティが変更されていない場合、欠落している部分を私に送ってください。それ以外の場合は、新しいエンティティ全体を送ってください。
If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
If-Range = "If-Range" "："（entity-tag | HTTP-date）
If the client has no entity tag for an entity, but does have a Last-Modified date, it MAY use that date in an If-Range header. (The server can distinguish between a valid HTTP-date and any form of entity-tag by examining no more than two characters.) The If-Range header SHOULD only be used together with a Range header, and MUST be ignored if the request does not include a Range header, or if the server does not support the sub-range operation.
クライアントにエンティティのエンティティタグがなく、Last-Modified日付がある場合、クライアントはその日付をIf-Rangeヘッダーで使用できます（MAY）。 （サーバーは、有効なHTTP日付とエンティティタグの任意の形式を2文字以内で区別することで区別できます。）If-RangeヘッダーはRangeヘッダーと一緒にのみ使用する必要があり（SHOULD）、リクエストがそうである場合は無視する必要があります。 Rangeヘッダーを含めないか、サーバーがサブ範囲操作をサポートしていない場合。
If the entity tag given in the If-Range header matches the current entity tag for the entity, then the server SHOULD provide the specified sub-range of the entity using a 206 (Partial content) response. If the entity tag does not match, then the server SHOULD return the entire entity using a 200 (OK) response.
If-Rangeヘッダーで指定されたエンティティタグがエンティティの現在のエンティティタグと一致する場合、サーバーは206（部分的コンテンツ）応答を使用してエンティティの指定されたサブ範囲を提供する必要があります（SHOULD）。エンティティタグが一致しない場合、サーバーは200（OK）応答を使用してエンティティ全体を返す必要があります（SHOULD）。
The If-Unmodified-Since request-header field is used with a method to make it conditional. If the requested resource has not been modified since the time specified in this field, the server SHOULD perform the requested operation as if the If-Unmodified-Since header were not present.
If-Unmodified-Sinceリクエストヘッダーフィールドは、条件付きにするためのメソッドで使用されます。このフィールドで指定された時間以降に要求されたリソースが変更されていない場合、サーバーは、If-Unmodified-Sinceヘッダーが存在しないかのように要求された操作を実行する必要があります（SHOULD）。
If the requested variant has been modified since the specified time, the server MUST NOT perform the requested operation, and MUST return a 412 (Precondition Failed).
要求されたバリアントが指定された時間以降に変更されている場合、サーバーは要求された操作を実行してはならず（MUST NOT）、412（前提条件の失敗）を返さなければなりません（MUST）。
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
If-Unmodified-Since = "If-Unmodified-Since" "：" HTTP日付
An example of the field is:
フィールドの例は次のとおりです。
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If the request normally (i.e., without the If-Unmodified-Since header) would result in anything other than a 2xx or 412 status, the If-Unmodified-Since header SHOULD be ignored.
リクエストが正常に（つまり、If-Unmodified-Sinceヘッダーなしで）2xxまたは412ステータス以外になる場合、If-Unmodified-Sinceヘッダーは無視されるべきです（SHOULD）。
If the specified date is invalid, the header is ignored.
指定された日付が無効な場合、ヘッダーは無視されます。
The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since header fields is undefined by this specification.
If-Unmodified-Sinceヘッダーフィールドと、If-None-MatchまたはIf-Modified-Sinceヘッダーフィールドの両方を持つリクエストの結果は、この仕様では定義されていません。
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.
Last-Modifiedエンティティヘッダーフィールドは、配信元サーバーがバリアントが最後に変更されたと信じる日時を示します。
Last-Modified = "Last-Modified" ":" HTTP-date
Last-Modified = "Last-Modified" "：" HTTP-date
An example of its use is
その使用例は
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
The exact meaning of this header field depends on the implementation of the origin server and the nature of the original resource. For files, it may be just the file system last-modified time. For entities with dynamically included parts, it may be the most recent of the set of last-modify times for its component parts. For database gateways, it may be the last-update time stamp of the record. For virtual objects, it may be the last time the internal state changed.
このヘッダーフィールドの正確な意味は、配信元サーバーの実装と元のリソースの性質によって異なります。ファイルの場合、それはファイルシステムの最終変更時刻である可能性があります。動的に含まれるパーツを持つエンティティの場合、それは、そのコンポーネントパーツの最終変更時刻のセットの最新のものである可能性があります。データベースゲートウェイの場合は、レコードの最終更新タイムスタンプである場合があります。仮想オブジェクトの場合、内部状態が最後に変更された可能性があります。
An origin server MUST NOT send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's last modification would indicate some time in the future, the server MUST replace that date with the message origination date.
オリジンサーバーは、サーバーのメッセージ発生時刻より後の最終変更日を送信してはなりません（MUST NOT）。そのような場合、リソースの最後の変更が将来のある時点を示す場合、サーバーはその日付をメッセージの開始日で置き換えなければなりません（MUST）。
An origin server SHOULD obtain the Last-Modified value of the entity as close as possible to the time that it generates the Date value of its response. This allows a recipient to make an accurate assessment of the entity's modification time, especially if the entity changes near the time that the response is generated.
オリジンサーバーは、エンティティのLast-Modified値を、その応答のDate値を生成する時刻に可能な限り近く取得する必要があります（SHOULD）。これにより、特に応答が生成された時刻近くにエンティティが変更された場合に、受信者はエンティティの変更時刻を正確に評価できます。
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
HTTP / 1.1サーバーは、可能な限りLast-Modifiedを送信する必要があります（SHOULD）。
The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI.
Location応答ヘッダーフィールドは、要求の完了または新しいリソースの識別のために、受信者をRequest-URI以外の場所にリダイレクトするために使用されます。 201（Created）応答の場合、Locationは、要求によって作成された新しいリソースの場所です。 3xx応答の場合、ロケーションは、リソースへの自動リダイレクトのためのサーバーの優先URIを示す必要があります（SHOULD）。フィールド値は、単一の絶対URIで構成されています。
Location = "Location" ":" absoluteURI
場所= "場所" "："絶対URI
An example is:
例は次のとおりです。
Location: http://www.w3.org/pub/WWW/People.html
Note: The Content-Location header field (section 14.14) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request. It is therefore possible for a response to contain header fields for both Location and Content-Location. Also see section 13.10 for cache requirements of some methods.
注：Content-Locationヘッダーフィールド（セクション14.14）はLocationとは異なり、Content-Locationはリクエストに含まれるエンティティの元の場所を識別します。したがって、応答にLocationとContent-Locationの両方のヘッダーフィールドを含めることができます。一部のメソッドのキャッシュ要件については、セクション13.10も参照してください。
The Max-Forwards request-header field provides a mechanism with the TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain.
Max-Forwardsリクエストヘッダーフィールドは、TRACE（セクション9.8）およびOPTIONS（セクション9.2）メソッドを備えたメカニズムを提供し、リクエストを次のインバウンドサーバーに転送できるプロキシまたはゲートウェイの数を制限します。これは、クライアントが途中のチェーンで失敗またはループしているように見えるリクエストチェーンをトレースしようとしている場合に役立ちます。
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.
Max-Forwards値は、この要求メッセージが転送される残りの回数を示す10進整数です。
Each proxy or gateway recipient of 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 recipient MUST NOT forward the request; instead, it MUST respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message MUST contain an updated Max-Forwards field with a value decremented by one (1).
Max-Forwardsヘッダーフィールドを含むTRACEまたはOPTIONSリクエストの各プロキシまたはゲートウェイ受信者は、リクエストを転送する前にその値を確認および更新する必要があります。受信した値がゼロ（0）の場合、受信者はリクエストを転送してはなりません（MUST NOT）。代わりに、最終的な受信者として応答する必要があります。受信したMax-Forwards値がゼロより大きい場合、転送されるメッセージには、値が1減少した更新済みのMax-Forwardsフィールドが含まれている必要があります。
The Max-Forwards header field MAY be ignored for all other methods defined by this specification and for any extension methods for which it is not explicitly referred to as part of that method definition.
Max-Forwardsヘッダーフィールドは、この仕様で定義されている他のすべてのメソッド、およびそのメソッド定義の一部として明示的に参照されていない拡張メソッドでは無視される場合があります。
The Pragma general-header field is used to include implementation-specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives.
Pragma general-headerフィールドは、要求/応答チェーンに沿って任意の受信者に適用される可能性がある実装固有のディレクティブを含めるために使用されます。すべてのプラグマディレクティブは、プロトコルの観点からオプションの動作を指定します。ただし、一部のシステムでは、動作がディレクティブと一致している必要がある場合があります。
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" ( token | quoted-string ) ]
When the no-cache directive is present in a request message, an application SHOULD forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive has the same semantics as the no-cache cache-directive (see section 14.9) and is defined here for backward compatibility with HTTP/1.0. Clients SHOULD include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant.
no-cacheディレクティブが要求メッセージに存在する場合、アプリケーションは、要求されているもののキャッシュされたコピーがある場合でも、要求をオリジンサーバーに転送する必要があります（SHOULD）。このプラグマディレクティブは、no-cache cache-directive（セクション14.9を参照）と同じセマンティクスを持ち、HTTP / 1.0との下位互換性のためにここで定義されています。 HTTP / 1.1に準拠していないことがわかっているサーバーにキャッシュなしのリクエストが送信される場合、クライアントは両方のヘッダーフィールドを含める必要があります（SHOULD）。
Pragma directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives might be applicable to all recipients along the request/response chain. It is not possible to specify a pragma for a specific recipient; however, any pragma directive not relevant to a recipient SHOULD be ignored by that recipient.
ディレクティブは要求/応答チェーンに沿ったすべての受信者に適用できるため、プラグマディレクティブは、そのアプリケーションに対する重要性に関係なく、プロキシまたはゲートウェイアプリケーションによってパススルーされる必要があります。特定の受信者にプラグマを指定することはできません。ただし、受信者に関連しないプラグマディレクティブは、その受信者によって無視される必要があります（SHOULD）。
HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache". No new Pragma directives will be defined in HTTP.
HTTP / 1.1キャッシュは、「プラグマ：no-cache」を、クライアントが「Cache-Control：no-cache」を送信したかのように扱う必要があります（SHOULD）。新しいプラグマディレクティブはHTTPで定義されません。
Note: because the meaning of "Pragma: no-cache as a response header field is not actually specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in a response
注：「プラグマ：応答ヘッダーフィールドとしてのno-cache」の意味は実際には指定されていないため、応答内の「Cache-Control：no-cache」の信頼できる代替にはなりません。
The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI.
Proxy-Authenticate応答ヘッダーフィールドは、407（Proxy Authentication Required）応答の一部として含まれている必要があります。フィールド値は、このリクエストURIのプロキシに適用可能な認証スキームとパラメータを示すチャレンジで構成されます。
Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" [43]. Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and SHOULD NOT be passed on to downstream clients. However, an intermediate proxy might need to obtain its own credentials by requesting them from the downstream client, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate header field.
HTTPアクセス認証プロセスは、「HTTP認証：基本およびダイジェストアクセス認証」[43]で説明されています。 WWW-Authenticateとは異なり、Proxy-Authenticateヘッダーフィールドは現在の接続にのみ適用され、ダウンストリームクライアントに渡すべきではありません（SHOULD NOT）。ただし、中間プロキシは、ダウンストリームクライアントに要求することで独自の資格情報を取得する必要がある場合があります。これは、プロキシがProxy-Authenticateヘッダーフィールドを転送しているように見える場合があります。
The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy which requires authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.
Proxy-Authorizationリクエストヘッダーフィールドを使用すると、クライアントは、認証が必要なプロキシに対して自身（またはそのユーザー）を識別できます。 Proxy-Authorizationフィールドの値は、要求されているリソースのプロキシまたはレルム、あるいはその両方のユーザーエージェントの認証情報を含む資格情報で構成されています。
Proxy-Authorization = "Proxy-Authorization" ":" credentials
Proxy-Authorization = "Proxy-Authorization" "："資格情報
The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" [43] . Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.
HTTPアクセス認証プロセスは、「HTTP認証：基本およびダイジェストアクセス認証」[43]で説明されています。承認とは異なり、Proxy-Authorizationヘッダーフィールドは、Proxy-Authenticateフィールドを使用して認証を要求した次の送信プロキシにのみ適用されます。チェーンで複数のプロキシが使用されている場合、Proxy-Authorizationヘッダーフィールドは、資格情報の受信を予期していた最初の送信プロキシによって消費されます。プロキシーが指定された要求を協調的に認証するメカニズムである場合、プロキシーは資格情報をクライアント要求から次のプロキシーにリレーしてもよい（MAY）。
Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful for any HTTP entity. (However, not all clients and servers need to support byte-range operations.)
すべてのHTTPエンティティはHTTPメッセージ内でバイトのシーケンスとして表されるため、バイト範囲の概念はどのHTTPエンティティにとっても意味があります。 （ただし、すべてのクライアントとサーバーがバイト範囲操作をサポートする必要があるわけではありません。）
Byte range specifications in HTTP apply to the sequence of bytes in the entity-body (not necessarily the same as the message-body).
HTTPのバイト範囲の指定は、エンティティ本体のバイトシーケンスに適用されます（メッセージ本体と同じである必要はありません）。
A byte range operation MAY specify a single range of bytes, or a set of ranges within a single entity.
バイト範囲操作は、単一のバイト範囲、または単一のエンティティ内の一連の範囲を指定する場合があります。
ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [last-byte-pos]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
The first-byte-pos value in a byte-range-spec gives the byte-offset of the first byte in a range. The last-byte-pos value gives the byte-offset of the last byte in the range; that is, the byte positions specified are inclusive. Byte offsets start at zero.
byte-range-specのfirst-byte-pos値は、範囲の最初のバイトのバイトオフセットを示します。 last-byte-pos値は、範囲内の最後のバイトのバイトオフセットを示します。つまり、指定されたバイト位置は包括的です。バイトオフセットはゼロから始まります。
If the last-byte-pos value is present, it MUST be greater than or equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec is syntactically invalid. The recipient of a byte-range-set that includes one or more syntactically invalid byte-range-spec values MUST ignore the header field that includes that byte-range-set.
last-byte-pos値が存在する場合、そのbyte-range-specのfirst-byte-pos以上である必要があります。そうでない場合、byte-range-specは構文的に無効です。 1つ以上の構文的に無効なbyte-range-spec値を含むbyte-range-setの受信者は、そのbyte-range-setを含むヘッダーフィールドを無視する必要があります。
If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the entity-body, last-byte-pos is taken to be equal to one less than the current length of the entity-body in bytes.
last-byte-pos値が存在しない場合、または値がエンティティー本体の現在の長さ以上である場合、last-byte-posはエンティティーの現在の長さより1少ないと見なされます。 -body（バイト単位）。
By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the entity.
クライアントはlast-byte-posを選択することで、エンティティのサイズを知らなくても、取得するバイト数を制限できます。
suffix-byte-range-spec = "-" suffix-length suffix-length = 1*DIGIT
suffix-byte-range-spec = "-" suffix-length suffix-length = 1 * DIGIT
A suffix-byte-range-spec is used to specify the suffix of the entity-body, of a length given by the suffix-length value. (That is, this form specifies the last N bytes of an entity-body.) If the entity is shorter than the specified suffix-length, the entire entity-body is used.
suffix-byte-range-specは、エンティティ本体の接尾辞を指定するために使用され、長さはsuffix-length値で指定されます。 （つまり、この形式はエンティティ本体の最後のNバイトを指定します。）エンティティが指定されたサフィックス長より短い場合、エンティティ本体全体が使用されます。
If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current length of the entity-body, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server SHOULD return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server SHOULD return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the entity-body.
構文的に有効なbyte-range-setに、first-byte-posがエンティティボディの現在の長さより短い少なくとも1つのbyte-range-spec、または非-zero suffix-length、次にバイト範囲セットは満足できます。そうでなければ、バイト範囲セットは満足できません。バイト範囲セットが満足できない場合、サーバーはステータス416（要求された範囲が満足できない）の応答を返す必要があります（SHOULD）。それ以外の場合、サーバーはエンティティ本体の充足可能な範囲を含むステータス206（部分コンテンツ）の応答を返す必要があります（SHOULD）。
Examples of byte-ranges-specifier values (assuming an entity-body of length 10000):
バイト範囲指定子値の例（エンティティ本体が長さ10000であると想定）：
- The first 500 bytes (byte offsets 0-499, inclusive): bytes=0- 499
- 最初の500バイト（バイトオフセット0〜499を含む）：バイト= 0〜499
- The second 500 bytes (byte offsets 500-999, inclusive): bytes=500-999
- 2番目の500バイト（バイトオフセット500〜999を含む）：バイト= 500〜999
- The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=-500
- 最後の500バイト（バイトオフセット9500〜9999）：バイト= -500
- Or bytes=9500-
- またはbytes = 9500-
- The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
- 最初と最後のバイトのみ（バイト0および9999）：バイト= 0-0、-1
- Several legal but not canonical specifications of the second 500 bytes (byte offsets 500-999, inclusive): bytes=500-600,601-999 bytes=500-700,601-999
- 2番目の500バイトの正規ではない正規の仕様（バイトオフセット500〜999を含む）：バイト= 500〜600、601〜999バイト= 500〜700、601〜999
HTTP retrieval requests using conditional or unconditional GET methods MAY request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header, which applies to the entity returned as the result of the request:
条件付きまたは無条件のGETメソッドを使用するHTTP取得リクエストは、リクエストの結果として返されるエンティティに適用されるRangeリクエストヘッダーを使用して、エンティティ全体ではなく、エンティティの1つ以上のサブ範囲をリクエストできます。
Range = "Range" ":" ranges-specifier
範囲= "範囲" "："範囲指定子
A server MAY ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large entities.
サーバーはRangeヘッダーを無視してもよい（MAY）。ただし、範囲は部分的に失敗した転送からの効率的な回復をサポートし、大きなエンティティの効率的な部分的な取得をサポートするため、HTTP / 1.1オリジンサーバーと中間キャッシュは、可能な場合はバイト範囲をサポートする必要があります。
If the server supports the Range header and the specified range or ranges are appropriate for the entity:
サーバーがRangeヘッダーをサポートし、指定された範囲がエンティティに適している場合：
- The presence of a Range header in an unconditional GET modifies what is returned if the GET is otherwise successful. In other words, the response carries a status code of 206 (Partial Content) instead of 200 (OK).
- 無条件のGETにRangeヘッダーが存在すると、GETが成功した場合に返されるものが変更されます。つまり、応答には200（OK）ではなく206（Partial Content）のステータスコードが含まれます。
- The presence of a Range header in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match, or one or both of If-Unmodified-Since and If-Match) modifies what is returned if the GET is otherwise successful and the condition is true. It does not affect the 304 (Not Modified) response returned if the conditional is false.
- 条件付きGET（If-Modified-SinceとIf-None-Matchの一方または両方、またはIf-Unmodified-SinceとIf-Matchの一方または両方を使用する要求）にRangeヘッダーが存在すると、次の場合に返される内容が変更されますそれ以外の場合、GETは成功し、条件はtrueです。条件がfalseの場合に返される304（Not Modified）応答には影響しません。
In some cases, it might be more appropriate to use the If-Range header (see section 14.27) in addition to the Range header.
場合によっては、Rangeヘッダーに加えて、If-Rangeヘッダー（セクション14.27を参照）を使用する方が適切な場合があります。
If a proxy that supports ranges receives a Range request, forwards the request to an inbound server, and receives an entire entity in reply, it SHOULD only return the requested range to its client. It SHOULD store the entire received response in its cache if that is consistent with its cache allocation policies.
範囲をサポートするプロキシがRangeリクエストを受信し、そのリクエストを受信サーバーに転送し、応答としてエンティティ全体を受信する場合、リクエストされた範囲のみをクライアントに返す必要があります（SHOULD）。キャッシュ割り当てポリシーと一致している場合は、受信した応答全体をキャッシュに格納する必要があります（SHOULD）。
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.
クライアントは、Referer [sic] request-headerフィールドを使用して、サーバーの利点のために、Request-URIの取得元であるリソースのアドレス（URI）を指定できます（ヘッダーフィールドのスペルが間違っていますが、「referrer」）。サーバーは、Refererリクエストヘッダーを使用して、関心のあるリソースへのバックリンク、ロギング、最適化されたキャッシングなどのリストを生成できます。また、メンテナンスのために古いリンクや誤って入力されたリンクをトレースできます。ユーザーキーボードからの入力など、独自のURIを持たないソースからRequest-URIを取得した場合は、Refererフィールドを送信してはなりません（MUST NOT）。
Referer = "Referer" ":" ( absoluteURI | relativeURI )
Referer = "Referer" "："（absoluteURI | relativeURI）
Example:
例：
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
If the field value is a relative URI, it SHOULD be interpreted relative to the Request-URI. The URI MUST NOT include a fragment. See section 15.1.3 for security considerations.
フィールド値が相対URIの場合、Request-URIを基準として解釈する必要があります（SHOULD）。 URIにフラグメントを含めることはできません。セキュリティに関する考慮事項については、セクション15.1.3を参照してください。
The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. This field MAY also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing the redirected request. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.
Retry-After応答ヘッダーフィールドを503（Service Unavailable）応答とともに使用して、要求元のクライアントがサービスを利用できないと予想される期間を示すことができます。このフィールドは、リダイレクトされた要求を発行する前にユーザーエージェントが待機するように求められる最小時間を示すために、任意の3xx（リダイレクト）応答とも使用される場合があります。このフィールドの値は、HTTP日付、または応答時間からの秒数（10進数）の整数のいずれかです。
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
Retry-After = "Retry-After" "："（HTTP-date | delta-seconds）
Two examples of its use are
その使用例は2つあります。
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
後者の例では、遅延は2分です。
The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server response-headerフィールドには、要求を処理するために起点サーバーが使用するソフトウェアに関する情報が含まれています。このフィールドには、複数の製品トークン（セクション3.8）およびサーバーと重要なサブ製品を識別するコメントを含めることができます。製品トークンは、アプリケーションを識別するために重要度の高い順にリストされています。
Server = "Server" ":" 1*( product | comment )
Example:
例：
Server: CERN/3.0 libwww/2.17
If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field (as described in section 14.45).
応答がプロキシを介して転送されている場合、プロキシアプリケーションはサーバーの応答ヘッダーを変更してはなりません。代わりに、Viaフィールドを含める必要があります（セクション14.45で説明）。
Note: Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable option.
注：サーバーの特定のソフトウェアバージョンを明らかにすると、サーバーマシンが、セキュリティホールを含むことがわかっているソフトウェアに対する攻撃に対してより脆弱になる可能性があります。サーバーの実装者は、このフィールドを構成可能なオプションにすることをお勧めします。
The TE request-header field indicates what extension transfer-codings it is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in section 3.6).
TE要求ヘッダーフィールドは、応答で受け入れることができる拡張転送コーディングと、チャンク化された転送コーディングでトレーラーフィールドを受け入れる意思があるかどうかを示します。その値は、キーワード「予告編」および/またはオプションの受け入れパラメーター（セクション3.6で説明）を含む拡張転送コーディング名のコンマ区切りリストで構成されます。
TE = "TE" ":" #( t-codings )
t-codings = "trailers" | ( transfer-extension [ accept-params ] )
The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, as defined in section 3.6.1. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
キーワード「予告編」の存在は、セクション3.6.1で定義されているように、クライアントがチャンク転送コーディングで予告編フィールドを受け入れる用意があることを示します。このキーワードは、それ自体が転送コーディングを表していない場合でも、転送コーディング値で使用するために予約されています。
Examples of its use are:
その使用例は次のとおりです。
TE: deflate
TE:
TE: trailers, deflate;q=0.5
The TE header field only applies to the immediate connection. Therefore, the keyword MUST be supplied within a Connection header field (section 14.10) whenever TE is present in an HTTP/1.1 message.
TEヘッダーフィールドは、即時接続にのみ適用されます。したがって、TEがHTTP / 1.1メッセージに存在する場合は常に、キーワードはConnectionヘッダーフィールド（セクション14.10）内に指定する必要があります。
A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules:
サーバーは、TEフィールドに従って、以下のルールを使用して、転送コーディングが受け入れ可能かどうかをテストします。
1. The "chunked" transfer-coding is always acceptable. If the keyword "trailers" is listed, the client indicates that it is willing to accept trailer fields in the chunked response on behalf of itself and any downstream clients. The implication is that, if given, the client is stating that either all downstream clients are willing to accept trailer fields in the forwarded response, or that it will attempt to buffer the response on behalf of downstream recipients.
1. 「チャンクされた」転送コーディングは常に許容されます。キーワード「予告編」がリストされている場合、クライアントは、自分自身とダウンストリームクライアントに代わってチャンクされた応答の予告フィールドを受け入れる用意があることを示します。つまり、クライアントは、指定された場合、すべてのダウンストリームクライアントが転送された応答のトレーラーフィールドを受け入れる用意があるか、またはダウンストリームの受信者に代わって応答をバッファリングしようとすることを示しています。
Note: HTTP/1.1 does not define any means to limit the size of a chunked response such that a client can be assured of buffering the entire response.
注：HTTP / 1.1では、クライアントが応答全体を確実にバッファリングできるように、チャンク化された応答のサイズを制限する手段を定義していません。
2. If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it is accompanied by a qvalue of 0. (As defined in section 3.9, a qvalue of 0 means "not acceptable.")
2. テストされる転送コーディングがTEフィールドにリストされている転送コーディングの1つである場合、qvalueが0でない限り、それは受け入れられます（セクション3.9で定義されているように、qvalue 0は「受け入れられないことを意味します。 "）
3. If multiple transfer-codings are acceptable, then the acceptable transfer-coding with the highest non-zero qvalue is preferred. The "chunked" transfer-coding always has a qvalue of 1.
3. 複数の転送コーディングが受け入れられる場合、ゼロ以外のqvalueが最も高い受け入れ可能な転送コーディングが優先されます。 「チャンクされた」転送コーディングのqvalueは常に1です。
If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding is always acceptable.
TEフィールド値が空の場合、またはTEフィールドが存在しない場合、転送コーディングは「チャンク」のみです。 transfer-codingのないメッセージは常に受け入れられます。
The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding.
Trailerの一般フィールド値は、チャンク転送コーディングでエンコードされたメッセージのトレーラーに特定のヘッダーフィールドセットが存在することを示します。
Trailer = "Trailer" ":" 1#field-name
An HTTP/1.1 message SHOULD include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient to know which header fields to expect in the trailer.
HTTP / 1.1メッセージは、空でないトレーラーでチャンク転送コーディングを使用して、メッセージにトレーラーヘッダーフィールドを含める必要があります（SHOULD）。そうすることで、受信者はトレーラーで予期されるヘッダーフィールドを知ることができます。
If no Trailer header field is present, the trailer SHOULD NOT include any header fields. See section 3.6.1 for restrictions on the use of trailer fields in a "chunked" transfer-coding.
トレーラーヘッダーフィールドが存在しない場合、トレーラーにはヘッダーフィールドを含めないでください。 「チャンク」転送コーディングでのトレーラフィールドの使用に関する制限については、セクション3.6.1を参照してください。
Message header fields listed in the Trailer header field MUST NOT include the following header fields:
Trailerヘッダーフィールドにリストされているメッセージヘッダーフィールドには、次のヘッダーフィールドを含めないでください。
. Transfer-Encoding
。転送エンコーディング
. Content-Length
。コンテンツの長さ
. Trailer
。トレーラー
The Transfer-Encoding general-header field indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the transfer-coding is a property of the message, not of the entity.
Transfer-Encoding general-headerフィールドは、送信者と受信者の間でメッセージを安全に転送するために、メッセージ本文に適用された変換のタイプ（存在する場合）を示します。これはcontent-codingとは異なり、転送コーディングはエンティティではなくメッセージのプロパティです。
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
Transfer-codings are defined in section 3.6. An example is:
転送コーディングはセクション3.6で定義されています。例は次のとおりです。
Transfer-Encoding: chunked
Transfer-Encoding：チャンク
If multiple encodings have been applied to an entity, the transfer-codings MUST be listed in the order in which they were applied. Additional information about the encoding parameters MAY be provided by other entity-header fields not defined by this specification.
エンティティに複数のエンコーディングが適用されている場合、それらが適用された順にtransfer-codingsをリストする必要があります。エンコーディングパラメータに関する追加情報は、この仕様で定義されていない他のエンティティヘッダーフィールドによって提供される場合があります。
Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.
古いHTTP / 1.0アプリケーションの多くは、Transfer-Encodingヘッダーを理解していません。
The Upgrade general-header allows the client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. The server MUST use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
Upgrade汎用ヘッダーを使用すると、クライアントは、サポートする追加の通信プロトコルを指定でき、サーバーがプロトコルを切り替えるのに適切であると判断した場合に使用します。サーバーは、101（Switching Protocols）応答内のUpgradeヘッダーフィールドを使用して、切り替えられるプロトコルを示す必要があります。
Upgrade = "Upgrade" ":" 1#product
For example,
例えば、
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by the server, possibly according to the nature of the method and/or resource being requested).
Upgradeヘッダーフィールドは、HTTP / 1.1から互換性のない他のプロトコルに移行するための簡単なメカニズムを提供することを目的としています。これは、現在の要求がHTTP / 1.1を使用して行われた場合でも、クライアントが別のプロトコル（メジャーバージョン番号が大きい新しいバージョンのHTTPなど）を使用したいという希望を宣伝できるようにすることで実現します。これにより、クライアントがより一般的にサポートされているプロトコルでリクエストを開始できると同時に、利用可能な場合は「より良い」プロトコルを使用することをサーバーに示します（「より良い」はサーバーによって決定されます）。 、おそらくメソッドやリクエストされているリソースの性質に応じて）。
The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, although the first action after changing the protocol MUST be a response to the initial HTTP request containing the Upgrade header field.
Upgradeヘッダーフィールドは、既存のトランスポート層接続でのアプリケーション層プロトコルの切り替えにのみ適用されます。アップグレードを使用してプロトコルの変更を要求することはできません。サーバーによるその受け入れと使用はオプションです。プロトコル変更後のアプリケーション層通信の機能と性質は、選択した新しいプロトコルに完全に依存しますが、プロトコル変更後の最初のアクションは、Upgradeヘッダーフィールドを含む最初のHTTP要求への応答でなければなりません。
The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword MUST be supplied within a Connection header field (section 14.10) whenever Upgrade is present in an HTTP/1.1 message.
Upgradeヘッダーフィールドは、直接接続にのみ適用されます。したがって、アップグレードがHTTP / 1.1メッセージに存在する場合は常に、アップグレードキーワードを接続ヘッダーフィールド（セクション14.10）内に指定する必要があります。
The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it is more appropriate to use a 301, 302, 303, or 305 redirection response.
Upgradeヘッダーフィールドを使用して、別の接続のプロトコルへの切り替えを示すことはできません。そのためには、301、302、303、または305リダイレクト応答を使用する方が適切です。
This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined by the HTTP version rules of section 3.1 and future updates to this specification. Any token can be used as a protocol name; however, it will only be useful if both the client and server associate the name with the same protocol.
この仕様では、セクション3.1のHTTPバージョンルールとこの仕様の将来の更新で定義されているように、ハイパーテキスト転送プロトコルのファミリで使用するプロトコル名「HTTP」のみを定義しています。任意のトークンをプロトコル名として使用できます。ただし、クライアントとサーバーの両方が名前を同じプロトコルに関連付ける場合にのみ役立ちます。
The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens (section 3.8) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.
User-Agentリクエストヘッダーフィールドには、リクエストを発信したユーザーエージェントに関する情報が含まれます。これは、統計上の目的、プロトコル違反の追跡、特定のユーザーエージェントの制限を回避するために応答を調整するためのユーザーエージェントの自動認識のためのものです。ユーザーエージェントは、リクエストにこのフィールドを含める必要があります。このフィールドには、複数の製品トークン（セクション3.8）と、ユーザーエージェントの重要な部分を形成するエージェントおよびサブ製品を識別するコメントを含めることができます。慣例により、製品トークンは、アプリケーションを識別するために重要度の高い順にリストされています。
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
例：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation. For uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation. A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the appropriate representation. See section 13.6 for use of the Vary header field by caches.
Varyフィールド値は、応答が新しい間、キャッシュが再検証なしで後続の要求に応答するために応答を使用することを許可されるかどうかを完全に決定する一連の要求ヘッダーフィールドを示します。キャッシュ不可または失効した応答の場合、Varyフィールドの値は、表現の選択に使用された基準についてユーザーエージェントにアドバイスします。 「*」のVaryフィールド値は、キャッシュが後続の要求の要求ヘッダーから、この応答が適切な表現であるかどうかを判断できないことを意味します。キャッシュによるVaryヘッダーフィールドの使用については、セクション13.6を参照してください。
Vary = "Vary" ":" ( "*" | 1#field-name )
An HTTP/1.1 server SHOULD include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that resource. A server MAY include a Vary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide the user agent with useful information about the dimensions over which the response varies at the time of the response.
HTTP / 1.1サーバーは、サーバー主導のネゴシエーションの対象となるキャッシュ可能な応答を持つVaryヘッダーフィールドを含める必要があります（SHOULD）。そうすることで、キャッシュはそのリソースに対する将来の要求を適切に解釈し、そのリソースでのネゴシエーションの存在についてユーザーエージェントに通知することができます。サーバーは、サーバー主導のネゴシエーションの対象となる、キャッシュできない応答を持つVaryヘッダーフィールドを含めることができます。これは、応答時に応答が変化するディメンションに関する有用な情報をユーザーエージェントに提供する可能性があるためです。
A Vary field value consisting of a list of field-names signals that the representation selected for the response is based on a selection algorithm which considers ONLY the listed request-header field values in selecting the most appropriate representation. A cache MAY assume that the same selection will be made for future requests with the same values for the listed field names, for the duration of time for which the response is fresh.
フィールド名のリストで構成されるVaryフィールド値は、応答に対して選択された表現が、最も適切な表現を選択する際にリストされたリクエストヘッダーフィールド値のみを考慮する選択アルゴリズムに基づいていることを通知します。キャッシュは、リストされたフィールド名に同じ値を持つ将来のリクエストに対して、応答が新しい間、同じ選択が行われると想定してもよい（MAY）。
The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names are case-insensitive.
指定されたフィールド名は、この仕様で定義されている一連の標準リクエストヘッダーフィールドに限定されません。フィールド名は大文字と小文字を区別しません。
A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address of the client), play a role in the selection of the response representation. The "*" value MUST NOT be generated by a proxy server; it may only be generated by an origin server.
「*」のVaryフィールド値は、リクエストヘッダー（クライアントのネットワークアドレスなど）に限定されない未指定のパラメーターが、応答表現の選択に役割を果たすことを示します。 「*」の値は、プロキシサーバーによって生成されてはいけません。オリジンサーバーによってのみ生成されます。
The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 [9] and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.
Via一般ヘッダーフィールドは、リクエストでユーザーエージェントとサーバーの間、および応答でオリジンサーバーとクライアントの間の中間プロトコルと受信者を示すためにゲートウェイとプロキシで使用する必要があります。これはRFC 822 [9]の「Received」フィールドに類似しており、メッセージ転送の追跡、要求ループの回避、および要求/応答チェーンに沿ったすべての送信者のプロトコル機能の識別に使用することを目的としています。
Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
The received-protocol indicates the protocol version of the message received by the server or client along each segment of the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded so that information about the protocol capabilities of upstream applications remains visible to all recipients.
received-protocolは、要求/応答チェーンの各セグメントに沿ってサーバーまたはクライアントが受信したメッセージのプロトコルバージョンを示します。受信プロトコルバージョンは、メッセージが転送されるときにViaフィールド値に追加されるため、アップストリームアプリケーションのプロトコル機能に関する情報はすべての受信者に表示されたままになります。
The protocol-name is optional if and only if it would be "HTTP". The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to be sensitive information, it MAY be replaced by a pseudonym. If the port is not given, it MAY be assumed to be the default port of the received-protocol.
protocol-nameは、 "HTTP"の場合にのみオプションです。 received-byフィールドは通常、その後メッセージを転送した受信者サーバーまたはクライアントのホストおよびオプションのポート番号です。ただし、実際のホストが機密情報であると見なされる場合は、仮名に置き換えることができます。ポートが指定されていない場合、それは受信プロトコルのデフォルトポートであると見なされる場合があります。
Multiple Via field values represents each proxy or gateway that has forwarded the message. Each recipient MUST append its information such that the end result is ordered according to the sequence of forwarding applications.
複数のViaフィールド値は、メッセージを転送した各プロキシまたはゲートウェイを表します。各受信者は、転送アプリケーションのシーケンスに従って最終結果が順序付けられるように、その情報を追加する必要があります。
Comments MAY be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and Server header fields. However, all comments in the Via field are optional and MAY be removed by any recipient prior to forwarding the message.
User-AgentおよびServerヘッダーフィールドと同様に、Viaヘッダーフィールドでコメントを使用して、受信者プロキシまたはゲートウェイのソフトウェアを識別できます。ただし、[Via]フィールドのすべてのコメントはオプションであり、メッセージを転送する前に受信者が削除してもかまいません。
For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin server at www.ics.uci.edu. The request received by www.ics.uci.edu would then have the following Via header field:
たとえば、要求メッセージはHTTP / 1.0ユーザーエージェントから "fred"という名前の内部プロキシコードに送信され、HTTP / 1.1を使用して要求をnowhere.comのパブリックプロキシに転送します。 www.ics.uci.eduのオリジンサーバーに転送します。 www.ics.uci.eduが受け取ったリクエストには、次のViaヘッダーフィールドがあります。
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Via：1.0 fred、1.1 nowhere.com（Apache / 1.1）
Proxies and gateways used as a portal through a network firewall SHOULD NOT, by default, forward the names and ports of hosts within the firewall region. This information SHOULD only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall SHOULD be replaced by an appropriate pseudonym for that host.
ネットワークファイアウォールを介してポータルとして使用されるプロキシとゲートウェイは、デフォルトでは、ファイアウォールリージョン内のホストの名前とポートを転送すべきではありません（SHOULD NOT）。この情報は、明示的に有効化されている場合にのみ伝達されるべきです（SHOULD）。有効になっていない場合、ファイアウォールの背後にあるホストの受信ホストは、そのホストの適切な仮名に置き換えられる必要があります（SHOULD）。
For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. For example,
内部構造を隠すための強力なプライバシー要件がある組織の場合、プロキシは、Viaヘッダーフィールドエントリの順序付けられたサブシーケンスを、同じ受信プロトコル値と組み合わせて、そのような単一のエントリにすることができます（MAY）。例えば、
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
Via：1.0 ricky、1.1 ethel、1.1 fred、1.0 lucy
could be collapsed to
に崩壊する可能性があります
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Via：1.0 ricky、1.1 mertz、1.0 lucy
Applications SHOULD NOT combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. Applications MUST NOT combine entries which have different received-protocol values.
アプリケーションは、それらがすべて同じ組織的な制御下にあり、ホストがすでに仮名に置き換えられていない限り、複数のエントリを組み合わせるべきではありません（SHOULD NOT）。アプリケーションは、異なる受信プロトコル値を持つエントリを組み合わせてはなりません（MUST NOT）。
The Warning general-header field is used to carry additional information about the status or transformation of a message which might not be reflected in the message. This information is typically used to warn about a possible lack of semantic transparency from caching operations or transformations applied to the entity body of the message.
警告の一般ヘッダーフィールドは、メッセージに反映されない可能性があるメッセージのステータスまたは変換に関する追加情報を伝えるために使用されます。この情報は、通常、メッセージのエンティティ本体に適用されるキャッシング操作または変換による意味の透過性の欠如の可能性について警告するために使用されます。
Warning headers are sent with responses using:
警告ヘッダーは、以下を使用して応答とともに送信されます。
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text [SP warn-date]
警告値= warn-code SP warn-agent SP warn-text [SP warn-date]
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
warn-date = <"> HTTP-date <">
A response MAY carry more than one Warning header.
応答には、複数の警告ヘッダーが含まれる場合があります。
The warn-text SHOULD be in a natural language and character set that is most likely to be intelligible to the human user receiving the response. This decision MAY be based on any available knowledge, such as the location of the cache or user, the Accept-Language field in a request, the Content-Language field in a response, etc. The default language is English and the default character set is ISO-8859-1.
警告テキストは、応答を受け取る人間のユーザーが理解できる可能性が最も高い自然言語と文字セットである必要があります（SHOULD）。この決定は、キャッシュまたはユーザーの場所、リクエストのAccept-Languageフィールド、レスポンスのContent-Languageフィールドなど、利用可能な知識に基づいている場合があります。デフォルトの言語は英語で、デフォルトの文字セットです。 ISO-8859-1です。
If a character set other than ISO-8859-1 is used, it MUST be encoded in the warn-text using the method described in RFC 2047 [14].
ISO-8859-1以外の文字セットを使用する場合は、RFC 2047 [14]で説明されている方法を使用して、警告テキストでエンコードする必要があります。
Warning headers can in general be applied to any message, however some specific warn-codes are specific to caches and can only be applied to response messages. New Warning headers SHOULD be added after any existing Warning headers. A cache MUST NOT delete any Warning header that it received with a message. However, if a cache successfully validates a cache entry, it SHOULD remove any Warning headers previously attached to that entry except as specified for specific Warning codes. It MUST then add any Warning headers received in the validating response. In other words, Warning headers are those that would be attached to the most recent relevant response.
警告ヘッダーは一般にどのメッセージにも適用できますが、一部の特定の警告コードはキャッシュに固有であり、応答メッセージにのみ適用できます。新しい警告ヘッダーは、既存の警告ヘッダーの後に追加する必要があります。キャッシュは、メッセージとともに受信した警告ヘッダーを削除してはなりません（MUST NOT）。ただし、キャッシュがキャッシュエントリの検証に成功した場合は、特定の警告コードで指定されている場合を除き、そのエントリに以前に付加された警告ヘッダーを削除する必要があります。次に、検証応答で受信した警告ヘッダーを追加する必要があります。つまり、警告ヘッダーは、最新の関連する応答に添付されるヘッダーです。
When multiple Warning headers are attached to a response, the user agent ought to inform the user of as many of them as possible, in the order that they appear in the response. If it is not possible to inform the user of all of the warnings, the user agent SHOULD follow these heuristics:
複数の警告ヘッダーが応答に添付されている場合、ユーザーエージェントは、それらを応答に表示される順序で、できるだけ多くのことをユーザーに通知する必要があります。すべての警告をユーザーに通知することが不可能な場合、ユーザーエージェントは次のヒューリスティックに従う必要があります。
- Warnings that appear early in the response take priority over those appearing later in the response.
- 応答の早い段階で表示される警告は、応答の後半に表示される警告よりも優先されます。
- Warnings in the user's preferred character set take priority over warnings in other character sets but with identical warn-codes and warn-agents.
- ユーザーの優先文字セットの警告は、他の文字セットの警告よりも優先されますが、警告コードと警告エージェントは同じです。
Systems that generate multiple Warning headers SHOULD order them with this user agent behavior in mind.
複数の警告ヘッダーを生成するシステムは、このユーザーエージェントの動作を念頭に置いてそれらを並べるべきです（SHOULD）。
Requirements for the behavior of caches with respect to Warnings are stated in section 13.1.2.
警告に関するキャッシュの動作の要件は、セクション13.1.2に記載されています。
This is a list of the currently-defined warn-codes, each with a recommended warn-text in English, and a description of its meaning.
これは、現在定義されている警告コードのリストであり、それぞれに英語の推奨警告テキストとその意味の説明が含まれています。
110 Response is stale MUST be included whenever the returned response is stale.
110応答は古くなっています返された応答が古くなっている場合は必ず含める必要があります。
111 Revalidation failed MUST be included if a cache returns a stale response because an attempt to revalidate the response failed, due to an inability to reach the server.
111サーバーに到達できないために応答の再検証に失敗したため、キャッシュが失効した応答を返す場合、111再検証の失敗を含める必要があります。
112 Disconnected operation SHOULD be included if the cache is intentionally disconnected from the rest of the network for a period of time.
112切断された操作は、一定期間キャッシュが残りのネットワークから意図的に切断されている場合に含める必要があります。
113 Heuristic expiration MUST be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours.
113キャッシュがヒューリスティックに24時間を超えるフレッシュネスライフタイムを選択し、応答の経過時間が24時間を超える場合は、ヒューリスティックな有効期限を含める必要があります。
199 Miscellaneous warning The warning text MAY include arbitrary information to be presented to a human user, or logged. A system receiving this warning MUST NOT take any automated action, besides presenting the warning to the user.
199その他の警告警告テキストには、人間のユーザーに提示する、またはログに記録する任意の情報を含めることができます。この警告を受け取るシステムは、ユーザーに警告を表示する以外に、自動化されたアクションを実行してはなりません。
214 Transformation applied MUST be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the response, unless this Warning code already appears in the response.
214適用された変換は、応答のコンテンツコーディング（Content-Encodingヘッダーで指定）またはメディアタイプ（Content-Typeヘッダーで指定）を変更する変換を適用する場合、中間キャッシュまたはプロキシによって追加する必要があります。または、この警告コードがすでに応答に表示されていない限り、応答のエンティティ本体。
299 Miscellaneous persistent warning The warning text MAY include arbitrary information to be presented to a human user, or logged. A system receiving this warning MUST NOT take any automated action.
299その他の永続的な警告警告テキストには、人間のユーザーに提示する、またはログに記録する任意の情報を含めることができます。この警告を受信するシステムは、自動化されたアクションを実行してはなりません。
If an implementation sends a message with one or more Warning headers whose version is HTTP/1.0 or lower, then the sender MUST include in each warning-value a warn-date that matches the date in the response.
実装がHTTP / 1.0以下のバージョンの1つ以上の警告ヘッダーを含むメッセージを送信する場合、送信者は各警告値に応答の日付と一致する警告日付を含める必要があります。
If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from the Date value in the response, then that warning-value MUST be deleted from the message before storing, forwarding, or using it. (This prevents bad consequences of naive caching of Warning header fields.) If all of the warning-values are deleted for this reason, the Warning header MUST be deleted as well.
実装がwarn-dateを含むwarning-valueを含むメッセージを受信し、そのwarn-dateが応答のDate値と異なる場合、そのwarning-valueは、保存、転送、または前にメッセージから削除する必要があります。それを使用します。 （これにより、Warningヘッダーフィールドの単純なキャッシュによる悪影響を防ぎます。）この理由ですべてのwarning-valuesが削除された場合、Warningヘッダーも削除する必要があります。
The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.
WWW-Authenticate応答ヘッダーフィールドは、401（無許可）応答メッセージに含まれている必要があります。フィールド値は、Request-URIに適用可能な認証方式とパラメーターを示す少なくとも1つのチャレンジで構成されます。
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" [43]. User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.
HTTPアクセス認証プロセスは、「HTTP認証：基本およびダイジェストアクセス認証」[43]で説明されています。ユーザーエージェントは、WWW-Authenticateフィールドの値を解析する際に特別な注意を払うことをお勧めします。複数のチャレンジが含まれている可能性があるか、複数のWWW-Authenticateヘッダーフィールドが提供されている場合、チャレンジ自体の内容にカンマ区切りを含めることができます認証パラメータのリスト。
15 Security Considerations
15セキュリティに関する考慮事項
This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks.
このセクションは、このドキュメントで説明されているHTTP / 1.1のセキュリティ制限について、アプリケーション開発者、情報プロバイダー、およびユーザーに通知することを目的としています。議論には、明らかにされた問題に対する決定的な解決策は含まれていませんが、セキュリティリスクを低減するためのいくつかの提案をしています。
HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, encryption keys, etc.), and SHOULD be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers and implementors be particularly careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate highly adverse publicity for the implementor's company.
HTTPクライアントは、大量の個人情報（ユーザーの名前、場所、メールアドレス、パスワード、暗号化キーなど）に関係していることが多く、HTTPプロトコルを介して他のソースに意図せずにこの情報が漏洩しないように十分注意する必要があります。 。ユーザーがそのような情報の普及を制御するための便利なインターフェースを提供し、設計者と実装者がこの領域で特に注意することを強くお勧めします。歴史は、この領域のエラーがしばしば深刻なセキュリティおよび/またはプライバシーの問題を引き起こし、実装者の会社に非常に不利な宣伝を生成することを示しています。
A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries. People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without the permission of any individuals that are identifiable by the published results.
サーバーは、ユーザーの要求に関する個人データを保存する立場にあり、ユーザーの読み取りパターンや関心のある主題を識別する可能性があります。この情報は本質的に明らかに機密情報であり、その取り扱いは特定の国の法律によって制約される場合があります。 HTTPプロトコルを使用してデータを提供する人々は、公開された結果によって識別可能な個人の許可なしに、そのような資料が配布されないようにする責任があります。
Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any a priori method of determining the sensitivity of any particular piece of information within the context of any given request. Therefore, applications SHOULD supply as much control over this information as possible to the provider of that information. Four header fields are worth special mention in this context: Server, Via, Referer and From.
一般的なデータ転送プロトコルと同様に、HTTPは転送されるデータの内容を規制できません。また、特定の要求のコンテキスト内で特定の情報の機密性を判断するアプリオリな方法もありません。したがって、アプリケーションは、この情報をできるだけ多くの制御でその情報のプロバイダーに提供する必要があります。このコンテキストでは、Server、Via、Referer、およびFromの4つのヘッダーフィールドについて特に言及する価値があります。
Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Implementors SHOULD make the Server header field a configurable option.
サーバーの特定のソフトウェアバージョンを明らかにすると、サーバーマシンがセキュリティホールを含むことがわかっているソフトウェアに対する攻撃に対してより脆弱になる可能性があります。実装者は、サーバーヘッダーフィールドを構成可能なオプションにする必要があります。
Proxies which serve as a portal through a network firewall SHOULD take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular, they SHOULD remove, or replace with sanitized versions, any Via fields generated behind the firewall.
ネットワークファイアウォールを介してポータルとして機能するプロキシは、ファイアウォールの背後にあるホストを識別するヘッダー情報の転送に関して、特別な予防策を講じるべきです（SHOULD）。特に、ファイアウォールの背後で生成されたViaフィールドを削除するか、サニタイズされたバージョンで置き換える必要があります（SHOULD）。
The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can be abused if user details are not separated from the information contained in the Referer. Even when the personal information has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate.
リファラーヘッダーを使用すると、読み取りパターンを調査し、逆リンクを描画できます。これは非常に便利ですが、ユーザーの詳細がリファラーに含まれる情報から分離されていないと、その能力が悪用される可能性があります。個人情報が削除された場合でも、Refererヘッダーは、公開が不適切な非公開ドキュメントのURIを示している可能性があります。
The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and hence it SHOULD NOT be transmitted without the user being able to disable, enable, and modify the contents of the field. The user MUST be able to set the contents of this field within a user preference or application defaults configuration.
差出人フィールドで送信される情報は、ユーザーのプライバシー保護またはサイトのセキュリティポリシーと競合する可能性があるため、ユーザーがフィールドの内容を無効化、有効化、および変更できない限り、情報を送信しないでください。ユーザーは、ユーザー設定またはアプリケーションのデフォルト構成内でこのフィールドの内容を設定できる必要があります。
We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information.
必須ではありませんが、ユーザーがFromおよびReferer情報の送信を有効または無効にするための便利なトグルインターフェイスを提供することをお勧めします。
The User-Agent (section 14.43) or Server (section 14.38) header fields can sometimes be used to determine that a specific client or server have a particular security hole which might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has no better mechanism.
User-Agent（セクション14.43）またはServer（セクション14.38）のヘッダーフィールドを使用して、特定のクライアントまたはサーバーに特定のセキュリティホールが存在することを確認できます。残念ながら、この同じ情報は、HTTPが現在より優れたメカニズムを備えていない他の貴重な目的によく使用されます。
Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information.
リンクのソースはプライベートな情報であるか、それ以外の場合はプライベートな情報ソースである可能性があるため、Refererフィールドを送信するかどうかをユーザーが選択できるようにすることを強くお勧めします。たとえば、ブラウザクライアントには、オープン/匿名でブラウジングするためのトグルスイッチがあり、それぞれリファラーと送信元の情報の送信を有効/無効にすることができます。
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
参照ページがセキュアなプロトコルで転送された場合、クライアントは（非セキュアな）HTTPリクエストにリファラーヘッダーフィールドを含めないでください。
Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead
HTTPプロトコルを使用するサービスの作成者は、機密データの送信にGETベースのフォームを使用しないでください。これにより、このデータがRequest-URIでエンコードされるためです。多くの既存のサーバー、プロキシ、およびユーザーエージェントは、リクエストURIを第三者が見ることができる場所に記録します。サーバーは代わりにPOSTベースのフォーム送信を使用できます
Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header in particular can reveal information the user would consider to be of a private nature, because the understanding of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option to configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration process include a message which makes the user aware of the loss of privacy involved.
Acceptリクエストヘッダーは、アクセスされているすべてのサーバーにユーザーに関する情報を公開できます。特にAccept-Languageヘッダーは、特定の言語の理解が特定の民族グループのメンバーシップと強く相関していることが多いため、ユーザーが私的な性質のものであると考える情報を明らかにする可能性があります。 Accept-Languageヘッダーのコンテンツをすべてのリクエストで送信するように設定するオプションを提供するユーザーエージェントは、設定プロセスに、ユーザーに関連するプライバシーの喪失を知らせるメッセージを含めることを強くお勧めします。
An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default, and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any Vary response-header fields generated by the server, that such sending could improve the quality of service.
プライバシーの損失を制限するアプローチは、ユーザーエージェントがデフォルトでAccept-Languageヘッダーの送信を省略し、サーバーがそれを検出した場合にサーバーにAccept-Languageヘッダーの送信を開始するかどうかをユーザーに確認することです。サーバーによって生成されたVary応答ヘッダーフィールドの場合、そのような送信によりサービス品質が向上する可能性があります。
Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability SHOULD warn users about the loss of privacy which can be involved.
すべてのリクエストで送信される、ユーザーがカスタマイズした複雑なAcceptヘッダーフィールドは、特にこれらに品質値が含まれている場合、比較的信頼性が高く存続期間の長いユーザー識別子としてサーバーで使用できます。このようなユーザーIDにより、コンテンツプロバイダーはクリックトレイルトラッキングを実行でき、協調するコンテンツプロバイダーは、クロスサーバークリックトレイルまたは個々のユーザーのフォーム送信に一致することができます。プロキシの背後にない多くのユーザーの場合、ユーザーエージェントを実行しているホストのネットワークアドレスも、長期間有効なユーザー識別子として機能します。プロキシを使用してプライバシーを強化する環境では、ユーザーエージェントは、ヘッダーの受け入れ構成オプションをエンドユーザーに提供する際に慎重になる必要があります。極端なプライバシー対策として、プロキシはリレーされたリクエストのAcceptヘッダーをフィルタリングできます。高度なヘッダー設定機能を提供する汎用ユーザーエージェントは、関与する可能性のあるプライバシーの喪失についてユーザーに警告する必要があります。
Implementations of HTTP origin servers SHOULD be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators. If an HTTP server translates HTTP URIs directly into file system calls, the server MUST take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On such a system, an HTTP server MUST disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access control files, configuration files, and script code) MUST be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor bugs in such HTTP server implementations have turned into security risks.
HTTPオリジンサーバーの実装では、HTTPリクエストによって返されるドキュメントを、サーバー管理者が意図したものだけに制限するように注意する必要があります。 HTTPサーバーがHTTP URIを直接ファイルシステムコールに変換する場合、サーバーはHTTPクライアントへの配信が意図されていないファイルを提供しないように特別な注意を払わなければなりません。たとえば、UNIX、Microsoft Windows、およびその他のオペレーティングシステムでは、現在の1つ上のディレクトリレベルを示すパスコンポーネントとして「..」を使用します。そのようなシステムでは、HTTPサーバーは、HTTPサーバーを介してアクセスできるように意図されたリソース以外のリソースへのアクセスを許可する場合は、Request-URI内のそのような構成を許可しない必要があります。同様に、サーバーへの内部参照のみを目的としたファイル（アクセス制御ファイル、構成ファイル、スクリプトコードなど）は、機密情報が含まれている可能性があるため、不適切な取得から保護する必要があります。経験上、このようなHTTPサーバー実装のマイナーなバグがセキュリティリスクになっていることがわかっています。
Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. Clients need to be cautious in assuming the continuing validity of an IP number/DNS name association.
HTTPを使用するクライアントは、ドメインネームサービスに大きく依存しているため、一般に、IPアドレスとDNS名の意図的な誤関連付けに基づいてセキュリティ攻撃を受けやすくなります。クライアントは、IP番号/ DNS名の関連付けの継続的な有効性を想定する際に注意する必要があります。
In particular, HTTP clients SHOULD rely on their name resolver for confirmation of an IP number/DNS name association, rather than caching the result of previous host name lookups. Many platforms already can cache host name lookups locally when appropriate, and they SHOULD be configured to do so. It is proper for these lookups to be cached, however, only when the TTL (Time To Live) information reported by the name server makes it likely that the cached information will remain useful.
特に、HTTPクライアントは、以前のホスト名ルックアップの結果をキャッシュするのではなく、IP番号/ DNS名の関連付けの確認をネームリゾルバーに依存する必要があります（SHOULD）。多くのプラットフォームはすでに適切な場合にホスト名のルックアップをローカルにキャッシュすることができ、そのように構成する必要があります（SHOULD）。ただし、これらのルックアップがキャッシュされるのは適切ですが、ネームサーバーから報告されたTTL（Time To Live）情報により、キャッシュされた情報が引き続き有用である可能性が高い場合にのみ使用してください。
If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS.
HTTPクライアントがホスト名ルックアップの結果をキャッシュしてパフォーマンスを向上させる場合、DNSから報告されたTTL情報を監視する必要があります。
If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server's IP address changes. As network renumbering is expected to become increasingly common [24], the possibility of this form of attack will grow. Observing this requirement thus reduces this potential security vulnerability.
HTTPクライアントがこのルールを守らない場合、以前にアクセスしたサーバーのIPアドレスが変更されると、クライアントがなりすまされる可能性があります。ネットワークの再番号付けがますます一般的になると予想されるため[24]、この形式の攻撃の可能性が高まります。したがって、この要件を遵守することで、この潜在的なセキュリティの脆弱性が軽減されます。
This requirement also improves the load-balancing behavior of clients for replicated servers using the same DNS name and reduces the likelihood of a user's experiencing failure in accessing sites which use that strategy.
この要件により、同じDNS名を使用する複製サーバーのクライアントの負荷分散動作も改善され、その戦略を使用するサイトへのアクセスでユーザーが失敗する可能性が減少します。
If a single server supports multiple organizations that do not trust one another, then it MUST check the values of Location and Content-Location headers in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority.
単一のサーバーが相互に信頼しない複数の組織をサポートしている場合、これらの組織の制御下で生成された応答のLocationヘッダーとContent-Locationヘッダーの値をチェックして、それらがリソースを無効にしようとしないことを確認する必要があります。彼らには権限がありません。
RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details.
HTTPで頻繁に実装されるContent-Disposition（セクション19.5.1を参照）ヘッダーの派生元であるRFC 1806 [35]には、非常に深刻なセキュリティに関する考慮事項がいくつかあります。 Content-DispositionはHTTP標準の一部ではありませんが、広く実装されているため、実装者に対するその使用とリスクを文書化しています。詳細については、RFC 2183 [49]（RFC 1806を更新）を参照してください。
Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials. This is a significant defect that requires further extensions to HTTP. Circumstances under which credential caching can interfere with the application's security model include but are not limited to:
既存のHTTPクライアントとユーザーエージェントは、通常、認証情報を無期限に保持します。 HTTP / 1.1。は、サーバーがクライアントにこれらのキャッシュされた資格情報を破棄するように指示する方法を提供しません。これは、HTTPをさらに拡張する必要がある重大な欠陥です。資格情報のキャッシュがアプリケーションのセキュリティモデルに干渉する可能性のある状況には、以下が含まれますが、これらに限定されません。
- Clients which have been idle for an extended period following which the server might wish to cause the client to reprompt the user for credentials.
- サーバーがクライアントにユーザーに資格情報の再入力を要求させる可能性のある、長期間アイドル状態であったクライアント。
- Applications which include a session termination indication (such as a `logout' or `commit' button on a page) after which the server side of the application `knows' that there is no further reason for the client to retain the credentials.
- セッション終了指示（ページの「ログアウト」または「コミット」ボタンなど）を含むアプリケーション。その後、アプリケーションのサーバー側は、クライアントが資格情報を保持する理由がないことを「認識」します。
This is currently under separate study. There are a number of work-arounds to parts of this problem, and we encourage the use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.
これは現在別の研究の下にあります。この問題の一部にはいくつかの回避策があり、スクリーンセーバー、アイドルタイムアウト、およびこの問題に固有のセキュリティ問題を軽減するその他の方法でパスワード保護を使用することをお勧めします。特に、資格情報をキャッシュするユーザーエージェントは、ユーザー制御下でキャッシュされた資格情報を破棄するためのすぐにアクセス可能なメカニズムを提供することが推奨されます。
By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise of the systems on which the proxies run can result in serious security and privacy problems. Proxies have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers. A compromised proxy, or a proxy implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.
その性質上、HTTPプロキシは中間者であり、中間者攻撃の機会を表します。プロキシが実行されているシステムの侵害は、深刻なセキュリティとプライバシーの問題を引き起こす可能性があります。プロキシは、セキュリティ関連情報、個々のユーザーと組織に関する個人情報、およびユーザーとコンテンツプロバイダーが所有する専有情報にアクセスできます。侵害されたプロキシ、またはセキュリティとプライバシーの考慮事項を考慮せずに実装または構成されたプロキシは、さまざまな潜在的な攻撃の実行に使用される可能性があります。
Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information, and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use developed and followed. (Section 15.1.1).
プロキシオペレーターは、機密情報を含むまたは転送するシステムを保護するのと同様に、プロキシが実行されるシステムを保護する必要があります。特に、プロキシで収集されたログ情報には、機密性の高い個人情報や組織に関する情報が含まれていることがよくあります。ログ情報は慎重に保護する必要があり、使用のための適切なガイドラインを作成して従う必要があります。 （セクション15.1.1）。
Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents should be protected as sensitive information.
キャッシュの内容は悪意のある悪用の魅力的なターゲットであるため、キャッシュプロキシは潜在的な脆弱性をさらに提供します。キャッシュの内容はHTTPリクエストの完了後も存続するため、ユーザーがネットワークから情報が削除されたとユーザーが信じた後も、キャッシュへの攻撃によって情報が明らかになる可能性があります。したがって、キャッシュの内容は機密情報として保護する必要があります。
Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the configuration options they provide to proxy operators (especially the default configuration).
プロキシの実装者は、設計とコーディングの決定、およびプロキシオペレータに提供する構成オプション（特にデフォルトの構成）のプライバシーとセキュリティへの影響を考慮する必要があります。
Users of a proxy need to be aware that they are no trustworthier than the people who run the proxy; HTTP itself cannot solve this problem.
プロキシのユーザーは、プロキシを実行する人々よりも信頼できないことに注意する必要があります。 HTTP自体はこの問題を解決できません。
The judicious use of cryptography, when appropriate, may suffice to protect against a broad range of security and privacy attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification.
適切な場合、暗号化の賢明な使用は、幅広いセキュリティおよびプライバシー攻撃から保護するのに十分かもしれません。このような暗号化は、HTTP / 1.1仕様の範囲を超えています。
They exist. They are hard to defend against. Research continues. Beware.
それらは存在します。彼らは防御するのが難しい。研究は続く。注意してください。
16 Acknowledgments
16謝辞
This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME [7]. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and Internet mail message formats.
この仕様では、RFC 822 [9]に対してDavid H. Crockerによって定義された拡張BNFと汎用構造を多用しています。同様に、Nathaniel BorensteinおよびNed FreedがMIMEに提供する定義の多くを再利用します[7]。この仕様に含めることで、HTTPとインターネットメールメッセージフォーマット間の関係に関する過去の混乱を減らすのに役立つことを期待しています。
The HTTP protocol has evolved considerably over the years. It has benefited from a large and active developer community--the many people who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol.
HTTPプロトコルは、長年にわたってかなり進化してきました。これは、大規模でアクティブな開発者コミュニティ（www-talkメーリングリストに参加した多くの人々）の恩恵を受けており、HTTPとWorld-Wide Webの成功に最も責任を負っているのはそのコミュニティです。一般的な。マークアンドリーセン、ロバートカイリア、ダニエルW.コノリー、ボブデニー、ジョンフランクス、ジャンフランソワグロフ、フィリップM.ハラムベイカー、ホーコンW.リー、アリルオトネン、ロブマックール、ルーモントゥリ、デイブラゲット、トニーサンダース、 Marc VanHeyningenは、プロトコルの初期の側面を定義するための彼らの努力に対して特別な評価を受けるに値します。
This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already mentioned, the following individuals have contributed to this specification:
このドキュメントは、HTTP-WGに参加しているすべての人々のコメントから大きな恩恵を受けています。すでに述べたものに加えて、以下の個人がこの仕様に貢献しました：
Gary Adams Ross Patterson Harald Tveit Alvestrand Albert Lunde Keith Ball John C. Mallery Brian Behlendorf Jean-Philippe Martin-Flatin Paul Burchard Mitra Maurizio Codogno David Morris Mike Cowlishaw Gavin Nicol Roman Czyborra Bill Perry Michael A. Dolan Jeffrey Perry David J. Fiander Scott Powers Alan Freier Owen Rees Marc Hedlund Luigi Rizzo Greg Herlihy David Robinson Koen Holtman Marc Salomon Alex Hopmann Rich Salz Bob Jernigan Allan M. Schiffman Shel Kaphan Jim Seidman Rohit Khare Chuck Shotton John Klensin Eric W. Sink Martijn Koster Simon E. Spero Alexei Kosut Richard N. Taylor David M. Kristol Robert S. Thau Daniel LaLiberte Bill (BearHeart) Weinman Ben Laurie Francois Yergeau Paul J. Leach Mary Ellen Zurko Daniel DuBois Josh Cohen
ゲイリーアダムスロスパターソンハラルドトベイトアルヴェストランドアルバートルンドキースボールジョンC.マレリーブライアンベーレンドルフジャンフィリップマーティンフラティンポールバーチャードミトラマウリツィオコドニョデビッドモリスマイクカウショウギャビンニコルローマンチボラビルペリーマイケルA.ドランジェフリーペリーデビッドJ.フィアンダースコットパワーズアランフレイエオーウェンリースマルクヘドルンドルイージリッツォグレッグハーリヒデビッドロビンソンケンホルトマンマークサロモンアレックスホップマンリッチサルツボブジャーニガンアランM.シフマンシェルカパンジムサイドマンロヒトカーレチャックショットトンジョンクレンシンエリックW.シンクマーティンコスターサイモンE.スペロアレクセイコウテイラーデイビッドM.クリストルロバートS.タウダニエルラリベルテビル（ベアハート）ウェインマンベンローリーフランソワヤーゴーポールJ.リーチメアリーエレンズルコダニエルデュボアジョシュコーエン
Much of the content and presentation of the caching design is due to suggestions and comments from individuals including: Shel Kaphan, Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
キャッシングデザインのコンテンツとプレゼンテーションの多くは、Shel Kaphan、Paul Leach、Koen Holtman、David Morris、Larry Masinterなどの個人からの提案とコメントによるものです。
Most of the specification of ranges is based on work originally done by Ari Luotonen and John Franks, with additional input from Steve Zilles.
範囲の仕様の大部分は、Ari LuotonenとJohn Franksによって最初に行われた作業に基づいており、Steve Zillesからの追加の入力があります。
Thanks to the "cave men" of Palo Alto. You know who you are.
パロアルトの「洞窟男」に感謝します。あなたはあなたが誰であるか知っています。
Jim Gettys (the current editor of this document) wishes particularly to thank Roy Fielding, the previous editor of this document, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
Jim Gettys（このドキュメントの現在の編集者）は、John Klensin、Jeff Mogul、Paul Leach、Dave Kristol、Koen Holtman、John Franks、Josh Cohen、Alex Hopmann、このドキュメントの以前の編集者であるRoy Fieldingに特に感謝します。スコット・ローレンスとラリー・マシンターの協力。また、「MUST / MAY / SHOULD」監査を実行していただいたJeff MogulとScott Lawrenceに特に感謝します。
The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik Frystyk implemented RFC 2068 early, and we wish to thank them for the discovery of many of the problems that this document attempts to rectify.
Apacheグループ、ジグソーの作者であるAnselm Baird-Smith、およびHenrik Frystykは、RFC 2068を早期に実装しました。このドキュメントが修正しようとしている多くの問題の発見に感謝します。
17 References
17参考文献
[1] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[1] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1995年3月。
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D. and B. Alberti, "The Internet Gopher Protocol (a distributed document search and retrieval protocol)", RFC 1436, March 1993.
[2] Anklesaria、F.、McCahill、M.、Lindner、P.、Johnson、D.、Torrey、D。およびB. Alberti、「インターネットGopherプロトコル（分散ドキュメント検索および検索プロトコル）」、RFC 1436、1993年3月。
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC 1630, June 1994.
[3] Berners-Lee、T。、「WWWのUniversal Resource Identifiers」、RFC 1630、1994年6月。
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[4] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[5] Berners-Lee、T。およびD. Connolly、「Hypertext Markup Language-2.0」、RFC 1866、1995年11月。
[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[6] Berners-Lee、T.、Fielding、R。およびH. Frystyk、「Hypertext Transfer Protocol-HTTP / 1.0」、RFC 1945、1996年5月。
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[7] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1123, October 1989.
[8] ブレーデン、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1123、1989年10月。
[9] Crocker, D., "Standard for The Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[9] Crocker、D。、「ARPAインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月。
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype Functional Specification," (v1.5), Thinking Machines Corporation, April 1990.
[10] デービス、F。、カーレ、B。、モリス、H。、セーラム、J。、シェン、T。、王、R。、スイ、J。、およびM.グリンバウム、「WAISインターフェイスプロトコルプロトタイプ機能仕様」（ v1.5）、Thinking Machines Corporation、1990年4月。
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[11] Fielding、R。、「Relative Uniform Resource Locators」、RFC 1808、1995年6月。
[12] Horton, M. and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, December 1987.
[12] Horton、M.およびR. Adams、「Standard for Interchange of Interchange of USENET Messages」、RFC 1036、1987年12月。
[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[13] Kantor、B。およびP. Lapsley、「Network News Transfer Protocol」、RFC 977、1986年2月。
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[14] Moore、K。、「MIME（Multipurpose Internet Mail Extensions）Part Three：Message Header Extensions for Non-ASCII Text」、RFC 2047、1996年11月。
[15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC 1867, November 1995.
[15] Nebel、E。およびL. Masinter、「HTMLでのフォームベースのファイルのアップロード」、RFC 1867、1995年11月。
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[16] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[17] Postel, J., "Media Type Registration Procedure", RFC 1590, November 1996.
[17] Postel、J。、「Media Type Registration Procedure」、RFC 1590、1996年11月。
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[18] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[19] Reynolds、J.およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
[20] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[20] Sollins、K。およびL. Masinter、「Uniform Resource Namesの機能要件」、RFC 1737、1994年12月。
[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[21] US-ASCII。コード化文字セット-情報交換のための7ビットのアメリカ標準コード。標準ANSI X3.4-1986、ANSI、1986。
[22] ISO-8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
[22] ISO-8859。国際標準-情報処理-8ビットシングルバイトコード化グラフィック文字セット-パート1：ラテンアルファベットNo. 1、ISO-8859-1：1987。パート2：ラテンアルファベットNo. 2、ISO-8859-2、1987。パート3：ラテンアルファベットNo. 3、ISO-8859-3、1988。パート4：ラテンアルファベットNo. 4、ISO-8859-4、1988 。パート5：ラテン/キリル文字、ISO-8859-5、1988。パート6：ラテン/アラビア文字、ISO-8859-6、1987。パート7：ラテン/ギリシャ文字、ISO-8859-7、1987。 8：ラテン/ヘブライアルファベット、ISO-8859-8、1988。パート9：ラテンアルファベットNo. 5、ISO-8859-9、1990。
[23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[23] Meyers、J。およびM. Rose、「The Content-MD5 Header Field」、RFC 1864、1995年10月。
[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[24] Carpenter、B。およびY. Rekhter、「Renumbering Needs Work」、RFC 1900、1996年2月。
[25] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[25] Deutsch、P。、「GZIPファイル形式仕様バージョン4.3」、RFC 1952、1996年5月。
[26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat ency.html.
[26] Venkata N. Padmanabhan、およびJeffrey C. Mogul。 「HTTPレイテンシの改善」、コンピュータネットワークとISDNシステム、v。28、25-35ページ、1995年12月。Proc。第2回国際WWW会議'94：モザイクとウェブ、1994年10月。http：//www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat ency.htmlから入手できます。
[27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>, ISI Research Report ISI/RR-98-463, (original report dated Aug. 1996), USC/Information Sciences Institute, August 1998.
[27] Joe Touch、John Heidemann、およびKatia Obraczka。 「HTTPパフォーマンスの分析」、<URL：http://www.isi.edu/touch/pubs/http-perf96/>、ISI Research Report ISI / RR-98-463、（1996年8月付けのオリジナルレポート）、 USC /情報科学研究所、1998年8月。
[28] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[28] Mills、D。、「Network Time Protocol（Version 3）Specification、Implementation and Analysis」、RFC 1305、Marc 1992。
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[29] Deutsch、P。、「DEFLATE Compressed Data Format Specification version 1.3」、RFC 1951、1996年5月。
[30] S. Spero, "Analysis of HTTP Performance Problems," http://sunsite.unc.edu/mdma-release/http-prob.html.
[30] S. Spero、「Analysis of HTTP Performance Problems」、http：//sunsite.unc.edu/mdma-release/http-prob.html。
[31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[31] Deutsch、P。およびJ. Gailly、「ZLIB Compressed Data Format Specification version 3.3」、RFC 1950、1996年5月。
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
[32] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Leach、P.、Luotonen、A.、Sink、E.、L。Stewart、「An Extension to HTTP：Digest Access Authentication」、RFC 2069、 1997年1月。
[33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[33] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H. and T. Berners-Lee、 "Hypertext Transfer Protocol-HTTP / 1.1"、RFC 2068、January 1997。
[34] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[34] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[35] Troost, R. and Dorner, S., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[35] Troost、R.およびDorner、S。、「Communicating Presentation Information in Internet Messages：The Content-Disposition Header」、RFC 1806、1995年6月。
[36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997. [jg639]
[36] Mogul、J.、Fielding、R.、Gettys、J。およびH. Frystyk、「HTTPバージョン番号の使用と解釈」、RFC 2145、1997年5月。[jg639]
[37] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. [jg640]
[37] Palme、J。、「Common Internet Message Headers」、RFC 2076、1997年2月。[jg640]
[38] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO-10646", RFC 2279, January 1998. [jg641]
[38] Yergeau、F。、「UTF-8、UnicodeおよびISO-10646の変換フォーマット」、RFC 2279、1998年1月。[jg641]
[39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E., Lie, H., and C. Lilley. "Network Performance Effects of HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes France, September 1997.[jg642]
[39] Nielsen、H.F.、Gettys、J.、Baird-Smith、A.、Prud'hommeaux、E.、Lie、H。、およびC. Lilley。 「HTTP / 1.1、CSS1、PNGのネットワークパフォーマンスへの影響」、ACM SIGCOMM '97、カンヌフランス、1997年9月の議事録。[jg642]
[40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [jg643]
[40] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。[jg643]
[41] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [jg644]
[41] Alvestrand、H。、「文字セットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。[jg644]
[42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 2396, August 1998. [jg645]
[42] Berners-Lee、T.、Fielding、R。およびL. Masinter、「Uniform Resource Identifiers（URI）：Generic Syntax and Semantics」、RFC 2396、1998年8月。[jg645]
[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [jg646]
[43] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A.、Sink、E。、およびL. Stewart、「HTTP認証：基本認証とダイジェストアクセス認証"、RFC 2617、1999年6月。[jg646]
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy servers," Work in Progress. [jg647]
[44] Luotonen、A。、「Webプロキシサーバーを介したTCPベースのプロトコルのトンネリング」、Work in Progress。 [jg647]
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, March 1997.
[45] Palme、J.およびA. Hopmann、「HTML（MHTML）などの集約ドキュメントのMIME電子メールカプセル化」、RFC 2110、1997年3月。
[46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[46] Bradner、S.、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998.
[47] Masinter、L。、「ハイパーテキストコーヒーポットコントロールプロトコル（HTCPCP / 1.0）」、RFC 2324、1998年4月1日。
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[48] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part 5：Conformance Criteria and Examples」、RFC 2049、1996年11月。
[49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[49] Troost、R.、Dorner、S。、およびK. Moore、「インターネットメッセージでのプレゼンテーション情報の伝達：Content-Dispositionヘッダーフィールド」、RFC 2183、1997年8月。
18 Authors' Addresses
18著者のアドレス
Roy T. Fielding Information and Computer Science University of California, Irvine Irvine, CA 92697-3425, USA
ロイT.フィールディング情報およびコンピュータサイエンスカリフォルニア大学アーバインアーバイン、カリフォルニア州92697-3425、米国
Fax: +1 (949) 824-1715
EMail: fielding@ics.uci.edu
James Gettys World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
James Gettys World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge、MA 02139、USA
Fax: +1 (617) 258 8682
EMail: jg@w3.org
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, USA
ジェフリーC.モーグルウエスタンリサーチラボラトリーCompaq Computer Corporation 250 94 Avenue Palo Alto、California、94305、USA
EMail: mogul@wrl.dec.com
Henrik Frystyk Nielsen World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Henrik Frystyk Nielsen World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge、MA 02139、USA
Fax: +1 (617) 258 8682
EMail: frystyk@w3.org
Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94034, USA
Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto、CA 94034、USA
EMail: masinter@parc.xerox.com Paul J. Leach
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052, USA
EMail: paulle@microsoft.com
Tim Berners-Lee Director, World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Tim Berners-LeeワールドワイドウェブコンソーシアムMITコンピュータサイエンス研究所545 Technology Square Cambridge、MA 02139、USA
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
19 Appendices
19付録
In addition to defining the HTTP/1.1 protocol, this document serves as the specification for the Internet media type "message/http" and "application/http". The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed). The following is to be registered with IANA [17].
このドキュメントは、HTTP / 1.1プロトコルの定義に加えて、インターネットメディアタイプ「message / http」および「application / http」の仕様としても機能します。メッセージ/ httpタイプは、行の長さとエンコーディングに関するすべての「メッセージ」タイプのMIME制限に従う場合、単一のHTTP要求または応答メッセージを囲むために使用できます。 application / httpタイプは、1つ以上のHTTP要求または応答メッセージ（混合されていない）のパイプラインを囲むために使用できます。以下はIANA [17]に登録されます。
Media Type name: message Media subtype name: http Required parameters: none Optional parameters: version, msgtype version: The HTTP-Version number of the enclosed message (e.g., "1.1"). If not present, the version can be determined from the first line of the body. msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body. Encoding considerations: only "7bit", "8bit", or "binary" are permitted Security considerations: none
メディアタイプ名：メッセージメディアサブタイプ名：http必須パラメーター：なしオプションパラメーター：バージョン、msgtypeバージョン：囲まれたメッセージのHTTPバージョン番号（例：「1.1」）。存在しない場合、バージョンは本文の最初の行から判断できます。 msgtype：メッセージタイプ-「リクエスト」または「レスポンス」。存在しない場合、タイプは本文の最初の行から判別できます。エンコーディングに関する考慮事項：「7ビット」、「8ビット」、または「バイナリ」のみが許可されますセキュリティに関する考慮事項：なし
Media Type name: application Media subtype name: http Required parameters: none Optional parameters: version, msgtype version: The HTTP-Version number of the enclosed messages (e.g., "1.1"). If not present, the version can be determined from the first line of the body. msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body. Encoding considerations: HTTP messages enclosed by this type are in "binary" format; use of an appropriate Content-Transfer-Encoding is required when transmitted via E-mail. Security considerations: none
メディアタイプ名：アプリケーションメディアサブタイプ名：http必須パラメーター：なしオプションパラメーター：バージョン、msgtypeバージョン：囲まれたメッセージのHTTPバージョン番号（例：「1.1」）。存在しない場合、バージョンは本文の最初の行から判断できます。 msgtype：メッセージタイプ-「リクエスト」または「レスポンス」。存在しない場合、タイプは本文の最初の行から判別できます。エンコードに関する考慮事項：このタイプで囲まれたHTTPメッセージは「バイナリ」形式です。電子メールで送信する場合は、適切なContent-Transfer-Encodingを使用する必要があります。セキュリティに関する考慮事項：なし
When an HTTP 206 (Partial Content) response message includes the content of multiple ranges (a response to a request for multiple non-overlapping ranges), these are transmitted as a multipart message-body. The media type for this purpose is called "multipart/byteranges".
HTTP 206（Partial Content）応答メッセージに複数の範囲のコンテンツ（重複しない複数の範囲の要求に対する応答）が含まれている場合、これらはマルチパートメッセージ本文として送信されます。この目的のメディアタイプは、「multipart / byteranges」と呼ばれます。
The multipart/byteranges media type includes two or more parts, each with its own Content-Type and Content-Range fields. The required boundary parameter specifies the boundary string used to separate each body-part.
multipart / byterangesメディアタイプには2つ以上のパートが含まれ、それぞれに独自のContent-TypeフィールドとContent-Rangeフィールドがあります。必須の境界パラメータは、各ボディパーツを区切るために使用される境界文字列を指定します。
Media Type name: multipart Media subtype name: byteranges Required parameters: boundary Optional parameters: none Encoding considerations: only "7bit", "8bit", or "binary" are permitted Security considerations: none
メディアタイプ名：マルチパートメディアサブタイプ名：バイト範囲必須パラメーター：境界オプションパラメーター：なしエンコードに関する考慮事項：「7ビット」、「8ビット」、または「バイナリ」のみが許可されますセキュリティに関する考慮事項：なし
For example:
例えば：
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 500-999/8000
--THIS_STRING_SEPARATESコンテンツタイプ：application / pdfコンテンツ範囲：バイト500-999 / 8000
...the first range... --THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 7000-7999/8000
...最初の範囲... --THIS_STRING_SEPARATES Content-type：application / pdf Content-range：bytes 7000-7999 / 8000
...the second range --THIS_STRING_SEPARATES--
... 2番目の範囲--THIS_STRING_SEPARATES--
Notes:
ノート：
1) Additional CRLFs may precede the first boundary string in the entity.
1）追加のCRLFがエンティティの最初の境界文字列の前にある場合があります。
2) Although RFC 2046 [40] permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.
2）RFC 2046 [40]では境界文字列の引用が許可されていますが、一部の既存の実装では引用された境界文字列が正しく処理されません。
3) A number of browsers and servers were coded to an early draft of the byteranges specification to use a media type of multipart/x-byteranges, which is almost, but not quite compatible with the version documented in HTTP/1.1.
3）多くのブラウザーとサーバーがバイト範囲仕様の初期ドラフトにコーディングされ、HTTP / 1.1で文書化されているバージョンとほとんど互換性はありませんが、マルチパート/ xバイト範囲のメディアタイプを使用しました。
Although this document specifies the requirements for the generation of HTTP/1.1 messages, not all applications will be correct in their implementation. We therefore recommend that operational applications be tolerant of deviations whenever those deviations can be interpreted unambiguously.
このドキュメントではHTTP / 1.1メッセージを生成するための要件を指定していますが、すべてのアプリケーションがその実装において正しいとは限りません。したがって、運用アプリケーションでは、偏差を明確に解釈できる場合は常に、偏差を許容することをお勧めします。
Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required.
クライアントはStatus-Lineの解析に耐性があり、サーバーはRequest-Lineの解析に耐性があるべきです（SHOULD）。特に、SPが1つだけ必要な場合でも、フィールド間で任意の量のSPまたはHT文字を受け入れる必要があります（SHOULD）。
The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR.
メッセージヘッダーフィールドの行ターミネータは、シーケンスCRLFです。ただし、このようなヘッダーを解析する場合、アプリケーションは単一のLFを行末記号として認識し、先頭のCRを無視することをお勧めします。
The character set of an entity-body SHOULD be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1 and 3.4.1.
エンティティボディの文字セットは、そのボディ内で使用される文字コードの最小公分母としてラベル付けする必要があります。ただし、エンティティにラベルを付けない方が、US-ASCIIまたはISO-8859- 1。セクション3.7.1および3.4.1を参照してください。
Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:
日付の解析とエンコードに関する要件、および日付エンコードに関するその他の潜在的な問題に関する追加のルールは次のとおりです。
- HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve the "year 2000" problem).
- HTTP / 1.1クライアントとキャッシュは、50年以上先と思われるRFC-850の日付が実際には過去であると想定する必要があります（これにより、「2000年問題」の解決に役立ちます）。
- An HTTP/1.1 implementation MAY internally represent a parsed Expires date as earlier than the proper value, but MUST NOT internally represent a parsed Expires date as later than the proper value.
- HTTP / 1.1実装は、解析されたExpires日付を適切な値より前として内部的に表すことができますが、解析されたExpires日付を適切な値より後として内部的に表すことはできません。
- All expiration-related calculations MUST be done in GMT. The local time zone MUST NOT influence the calculation or comparison of an age or expiration time.
- すべての有効期限関連の計算はGMTで行う必要があります。ローカルタイムゾーンは、経過時間または有効期限の計算または比較に影響を与えてはなりません。
- If an HTTP header incorrectly carries a date value with a time zone other than GMT, it MUST be converted into GMT using the most conservative possible conversion.
- HTTPヘッダーがGMT以外のタイムゾーンの日付値を誤って運ぶ場合、最も保守的な変換を使用してGMTに変換する必要があります。
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 2045 discusses mail, and HTTP has a few features that are different from those described in RFC 2045. 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は、インターネットメール（RFC 822 [9]）および多目的インターネットメール拡張（MIME [7]）用に定義された構成の多くを使用して、エンティティをさまざまな表現で拡張可能なメカニズムで送信できるようにします。ただし、RFC 2045はメールについて説明しており、HTTPにはRFC 2045で説明されているものとは異なるいくつかの機能があります。これらの違いは、バイナリ接続でのパフォーマンスを最適化し、新しいメディアタイプをより自由に使用できるようにするために慎重に選択されました。比較が容易になり、一部の初期のHTTPサーバーとクライアントの慣行を認めることができます。
This appendix describes specific areas where HTTP differs from RFC 2045. Proxies and gateways to strict MIME environments SHOULD be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments to HTTP also need to be aware of the differences because some conversions might be required.
この付録では、HTTPがRFC 2045と異なる特定の領域について説明します。厳密なMIME環境へのプロキシとゲートウェイは、これらの違いを認識し、必要に応じて適切な変換を提供する必要があります。 MIME環境からHTTPへのプロキシとゲートウェイも、一部の変換が必要になる場合があるため、違いを認識する必要があります。
HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY include a single MIME-Version general-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 compliance with the MIME protocol (as defined in RFC 2045[7]). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME environments.
HTTPはMIME準拠のプロトコルではありません。ただし、HTTP / 1.1メッセージには、メッセージの作成に使用されたMIMEプロトコルのバージョンを示す単一のMIME-Version general-headerフィールドが含まれる場合があります。 MIME-Versionヘッダーフィールドの使用は、メッセージがMIMEプロトコル（RFC 2045 [7]で定義されている）に完全に準拠していることを示します。プロキシ/ゲートウェイは、HTTPメッセージを厳密なMIME環境にエクスポートする際に、可能な限り完全に準拠することを保証する責任があります。
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this document and not the MIME specification.
MIMEバージョン "1.0"は、HTTP / 1.1で使用されるデフォルトです。ただし、HTTP / 1.1メッセージの解析とセマンティクスは、MIME仕様ではなく、このドキュメントで定義されています。
RFC 2045 [7] requires that an Internet mail entity be converted to canonical form prior to being transferred, as described in section 4 of RFC 2049 [48]. Section 3.7.1 of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. RFC 2046 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 when a message is transmitted over HTTP.
RFC 2049 [48]のセクション4で説明されているように、RFC 2045 [7]では、インターネットメールエンティティを転送する前に正規形式に変換する必要があります。このドキュメントのセクション3.7.1は、HTTP経由で送信されるときに「テキスト」メディアタイプのサブタイプに許可されるフォームについて説明しています。 RFC 2046では、タイプが「テキスト」のコンテンツが改行をCRLFとして表すことを要求し、改行シーケンスの外でのCRまたはLFの使用を禁止しています。 HTTPでは、メッセージがHTTP経由で送信されるときに、CRLF、ベアCR、およびベアLFがテキストコンテンツ内の改行を示すことができます。
Where it is possible, a proxy or gateway from HTTP to a strict MIME environment SHOULD translate all line breaks within the text media types described in section 3.7.1 of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of a Content-Encoding and by the fact that HTTP allows the use of some character sets which do not use octets 13 and 10 to represent CR and LF, as is the case for some multi-byte character sets.
可能な場合、HTTPから完全MIME環境へのプロキシまたはゲートウェイは、このドキュメントのセクション3.7.1で説明されているテキストメディアタイプ内のすべての改行をRFC 2049の正規形式のCRLFに変換する必要があります（SHOULD）。ただし、これは、Content-Encodingの存在と、HTTPがオクテット13と10を使用せずにCRとLFを表すのに使用しない一部の文字セットを使用できるという事実によって複雑になる場合があることに注意してください。マルチバイト文字セット。
Implementors should note that 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 3.3.1) to simplify the process of date comparison. Proxies and gateways from other protocols SHOULD 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は、日付比較のプロセスを簡略化するために、日付フォーマットの制限されたセット（セクション3.3.1）を使用します。他のプロトコルからのプロキシとゲートウェイは、メッセージに存在するすべての日付ヘッダーフィールドがHTTP / 1.1形式のいずれかに準拠していることを確認し、必要に応じて日付を書き換える必要があります。
RFC 2045 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 MUST either change the value of the Content-Type header field or decode the entity-body 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 RFC 2045.)
RFC 2045には、HTTP / 1.1のContent-Encodingヘッダーフィールドに相当する概念は含まれていません。これはメディアタイプの修飾子として機能するため、HTTPからMIME準拠のプロトコルへのプロキシとゲートウェイは、メッセージを転送する前に、Content-Typeヘッダーフィールドの値を変更するか、エンティティボディをデコードする必要があります。 （インターネットメールのContent-Typeの一部の実験的アプリケーションでは、「-conversions = <content-coding>」のメディアタイプパラメーターを使用して、Content-Encodingと同等の機能を実行しています。ただし、このパラメーターはRFC 2045の一部ではありません。 ）
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client.
HTTPは、RFC 2045のContent-Transfer-Encoding（CTE）フィールドを使用しません。MIME準拠プロトコルからHTTPへのプロキシおよびゲートウェイは、配信する前に、非ID CTE（ "quoted-printable"または "base64"）エンコーディングを削除する必要がありますHTTPクライアントへの応答メッセージ。
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 SHOULD 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でデータにラベルを付ける必要があります（SHOULD）。そうすることで、宛先プロトコルを介した安全な転送の可能性が向上します。
HTTP/1.1 introduces the Transfer-Encoding header field (section 14.41). Proxies/gateways MUST remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
HTTP / 1.1では、Transfer-Encodingヘッダーフィールドが導入されています（セクション14.41）。プロキシ/ゲートウェイは、MIME準拠のプロトコルを介してメッセージを転送する前に、転送コーディングを削除する必要があります。
A process for decoding the "chunked" transfer-coding (section 3.6) can be represented in pseudo-code as:
「チャンク」転送コーディング（セクション3.6）をデコードするプロセスは、疑似コードで次のように表すことができます。
length := 0
read chunk-size, chunk-extension (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
HTTP implementations which share code with MHTML [45] 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 transports all message-bodies as payload (see section 3.7.2) and does not interpret the content or any MIME header lines that might be contained therein.
MHTML [45]実装とコードを共有するHTTP実装は、MIME行の長さの制限に注意する必要があります。 HTTPにはこの制限がないため、HTTPは長い行を折り返しません。 HTTPはすべてのメッセージ本文をペイロードとして転送し（セクション3.7.2を参照）、コンテンツやMIMEヘッダーを解釈しないため、HTTPによって転送されるMHTMLメッセージは、行の長さの制限、折りたたみ、正規化など、MHTMLのすべての規則に従います。その中に含まれる可能性のある行。
RFC 1945 and RFC 2068 document protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.1 applications. Implementors are advised to be aware of these features, but cannot rely upon their presence in, or interoperability with, other HTTP/1.1 applications. Some of these describe proposed experimental features, and some describe features that experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification.
RFC 1945およびRFC 2068には、一部の既存のHTTP実装で使用されているプロトコル要素が記載されていますが、ほとんどのHTTP / 1.1アプリケーション全体で一貫して正しくはありません。実装者はこれらの機能に注意することをお勧めしますが、他のHTTP / 1.1アプリケーションでの存在や相互運用性に依存することはできません。これらの一部は提案された実験的機能を説明し、一部は実験的配備が欠如していることをベースHTTP / 1.1仕様で現在対処されている機能を説明しています。
A number of other headers, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see RFC 2076 [37]).
SMTPやMIMEからのContent-DispositionやTitleなどの他の多くのヘッダーも実装されることがよくあります（RFC 2076 [37]を参照）。
The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename if the user requests that the content is saved to a file. This usage is derived from the definition of Content-Disposition in RFC 1806 [35].
Content-Disposition応答ヘッダーフィールドは、ユーザーがコンテンツをファイルに保存することを要求した場合に、オリジンサーバーがデフォルトのファイル名を提案する手段として提案されています。この使用法は、RFC 1806 [35]のContent-Dispositionの定義から派生しています。
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" ( token | quoted-string )
An example is
例は
Content-Disposition: attachment; filename="fname.ext"
The receiving user agent SHOULD NOT respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply to HTTP implementations at this time. The filename SHOULD be treated as a terminal component only.
受信ユーザーエージェントは、現時点でHTTP実装に適用されると考えられる唯一のパラメーターであるfilename-parmパラメーターに存在するディレクトリパス情報を尊重すべきではありません（SHOULD NOT）。ファイル名は端末コンポーネントとしてのみ扱われる必要があります（SHOULD）。
If this header is used in a response with the application/octet-stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog.
このヘッダーがapplication / octet-stream content-typeのレスポンスで使用される場合、暗黙の提案は、ユーザーエージェントがレスポンスを表示するのではなく、「save response as ...」ダイアログに直接入力することです。
See section 15.5 for Content-Disposition security issues.
Content-Dispositionのセキュリティ問題については、セクション15.5を参照してください。
It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification (1996), we would expect commercial HTTP/1.1 servers to:
以前のバージョンへの準拠を義務付けることは、プロトコル仕様の範囲を超えています。ただし、HTTP / 1.1は、以前のバージョンのサポートを容易にするために意図的に設計されました。この仕様を作成した時点（1996年）では、商用のHTTP / 1.1サーバーが次のことを期待していることに注意してください。
- recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1 requests;
- HTTP / 0.9、1.0、および1.1リクエストのリクエストラインのフォーマットを認識します。
- understand any valid request in the format of HTTP/0.9, 1.0, or 1.1;
- HTTP / 0.9、1.0、または1.1の形式で有効なリクエストを理解します。
- respond appropriately with a message in the same major version used by the client.
- クライアントが使用しているのと同じメジャーバージョンのメッセージで適切に応答します。
And we would expect HTTP/1.1 clients to:
また、HTTP / 1.1クライアントは次のことを期待します。
- recognize the format of the Status-Line for HTTP/1.0 and 1.1 responses;
- HTTP / 1.0および1.1応答のステータス行の形式を認識します。
- understand any valid response in the format of HTTP/0.9, 1.0, or 1.1.
- HTTP / 0.9、1.0、または1.1の形式で有効な応答を理解します。
For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described in section 19.7.1 of RFC 2068 [33].
HTTP / 1.0のほとんどの実装では、各接続は要求の前にクライアントによって確立され、応答の送信後にサーバーによって閉じられます。一部の実装では、RFC 2068 [33]のセクション19.7.1で説明されている永続的な接続のキープアライブバージョンを実装しています。
This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.
このセクションでは、バージョンHTTP / 1.0とHTTP / 1.1の主な違いを要約します。
19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses
19.6.1.1 マルチホームWebサーバーを簡素化し、IPアドレスを節約するための変更
The requirements that clients and servers support the Host request-header, report an error if the Host request-header (section 14.23) is missing from an HTTP/1.1 request, and accept absolute URIs (section 5.1.2) are among the most important changes defined by this specification.
クライアントとサーバーがホストリクエストヘッダーをサポートし、ホストリクエストヘッダー（セクション14.23）がHTTP / 1.1リクエストから欠落している場合にエラーを報告し、絶対URIを受け入れる（セクション5.1.2）が最も重要な要件です。この仕様で定義された変更。
Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism for distinguishing the intended server of a request than the IP address to which that request was directed. The changes outlined above will allow the Internet, once older HTTP clients are no longer common, to support multiple Web sites from a single IP address, greatly simplifying large operational Web servers, where allocation of many IP addresses to a single host has created serious problems. The Internet will also be able to recover the IP addresses that have been allocated for the sole purpose of allowing special-purpose domain names to be used in root-level HTTP URLs. Given the rate of growth of the Web, and the number of servers already deployed, it is extremely important that all implementations of HTTP (including updates to existing HTTP/1.0 applications) correctly implement these requirements:
古いHTTP / 1.0クライアントは、IPアドレスとサーバーの1対1の関係を想定していました。要求の対象となるサーバーを区別するための確立されたメカニズムは、その要求の送信先のIPアドレス以外にありませんでした。上記の変更により、古いHTTPクライアントが一般的でなくなると、インターネットは単一のIPアドレスから複数のWebサイトをサポートできるようになり、多数のIPアドレスを単一のホストに割り当てると深刻な問題が発生する大規模な運用Webサーバーが大幅に簡素化されます。 。また、インターネットは、ルートレベルのHTTP URLで特殊用途のドメイン名を使用できるようにするという唯一の目的で割り当てられたIPアドレスを回復することもできます。 Webの成長率、および既に展開されているサーバーの数を考えると、HTTPのすべての実装（既存のHTTP / 1.0アプリケーションへの更新を含む）が以下の要件を正しく実装することが非常に重要です。
- Both clients and servers MUST support the Host request-header.
- クライアントとサーバーの両方がホスト要求ヘッダーをサポートする必要があります。
- A client that sends an HTTP/1.1 request MUST send a Host header.
- HTTP / 1.1要求を送信するクライアントは、ホストヘッダーを送信する必要があります。
- Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header.
- HTTP / 1.1リクエストにHostリクエストヘッダーが含まれていない場合、サーバーは400（Bad Request）エラーを報告する必要があります。
- Servers MUST accept absolute URIs.
- サーバーは絶対URIを受け入れる必要があります。
Some clients and servers might wish to be compatible with some previous implementations of persistent connections in HTTP/1.0 clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0 experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify these problems. The problem was that some existing 1.0 clients may be sending Keep-Alive to a proxy server that doesn't understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients must be prevented from using Keep-Alive when talking to proxies.
一部のクライアントおよびサーバーは、HTTP / 1.0クライアントおよびサーバーでの以前の永続的接続の実装との互換性を望む場合があります。 HTTP / 1.0の永続的な接続は、デフォルトの動作ではないため、明示的にネゴシエートされます。持続的接続のHTTP / 1.0実験的実装は不完全であり、HTTP / 1.1の新しい機能はこれらの問題を修正するように設計されています。問題は、一部の既存の1.0クライアントが、接続を認識しないプロキシサーバーにキープアライブを送信し、誤って次のインバウンドサーバーに転送して、キープアライブ接続を確立してハングすることでした。応答のクローズを待機しているHTTP / 1.0プロキシ。その結果、HTTP / 1.0クライアントは、プロキシと通信するときにキープアライブを使用できないようにする必要があります。
However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable. Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce a new keyword (Connection: close) for declaring non-persistence. See section 14.10.
ただし、プロキシとの対話は永続的な接続の最も重要な使用法であるため、禁止は明らかに受け入れられません。したがって、永続的な接続が必要であることを示すために、Connectionを無視する古いプロキシと通信する場合でも安全に使用できる他のメカニズムが必要です。持続的接続は、HTTP / 1.1メッセージのデフォルトです。非永続性を宣言するための新しいキーワード（Connection：close）を導入します。セクション14.10を参照してください。
The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
永続的な接続の元のHTTP / 1.0形式（接続：キープアライブおよびキープアライブヘッダー）は、RFC 2068で文書化されています。[33]
This specification has been carefully audited to correct and disambiguate key word usage; RFC 2068 had many problems in respect to the conventions laid out in RFC 2119 [34].
この仕様は、キーワードの使用を修正および明確にするために慎重に監査されています。 RFC 2068には、RFC 2119 [34]で規定された規則に関して多くの問題がありました。
Clarified which error code should be used for inbound server failures (e.g. DNS failures). (Section 10.5.5).
受信サーバーの障害（DNS障害など）に使用するエラーコードを明確にしました。 （セクション10.5.5）。
CREATE had a race that required an Etag be sent when a resource is first created. (Section 10.2.2).
CREATEには、リソースが最初に作成されたときにEtagを送信する必要がある競合がありました。 （セクション10.2.2）。
Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML [45].
Content-Baseは仕様から削除されました。それは広く実装されておらず、堅牢な拡張メカニズムなしに導入する簡単で安全な方法はありません。また、MHTMLでも同様の方法で使用されていますが、同一ではありません。
Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are computed. (Sections 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
転送コーディングとメッセージの長さはすべて、チャンクエンコーディングが使用されるときに正確に修正する必要がある方法で相互作用します（自己区切りではない可能性がある転送エンコーディングを可能にするため）。メッセージの長さの計算方法を正確に示すことが重要でした。 （セクション3.6、4.4、7.2.2、13.5.2、14.13、14.16）
A content-coding of "identity" was introduced, to solve problems discovered in caching. (section 3.5)
キャッシングで発見された問題を解決するために、「アイデンティティ」のコンテンツコーディングが導入されました。 （セクション3.5）
Quality Values of zero should indicate that "I don't want something" to allow clients to refuse a representation. (Section 3.9)
品質値がゼロの場合、クライアントが表現を拒否できるように、「何かが欲しくない」ことを示します。 （セクション3.9）
The use and interpretation of HTTP version numbers has been clarified by RFC 2145. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 implementations (Section 3.1)
HTTPバージョン番号の使用と解釈はRFC 2145で明確になっています。HTTP/ 1.0実装で発見された問題に対処するために、プロキシがサポートする最高のプロトコルバージョンにリクエストをアップグレードする必要があります（セクション3.1）。
Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (Section 14.2)
文字セットワイルドカードは、受け入れヘッダーでの文字セット名の爆発を回避するために導入されています。 （セクション14.2）
A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections 13.4, 14.8, 14.9, 14.9.3)
HTTP / 1.1のCache-Controlモデルでケースが見落とされました。この不足しているケースを追加するためにs-maxageが導入されました。 （セクション13.4、14.8、14.9、14.9.3）
The Cache-Control: max-age directive was not properly defined for responses. (Section 14.9.3)
Cache-Control：max-ageディレクティブが応答に対して適切に定義されていませんでした。 （セクション14.9.3）
There are situations where a server (especially a proxy) does not know the full length of a response but is capable of serving a byterange request. We therefore need a mechanism to allow byteranges with a content-range not indicating the full length of the message. (Section 14.16)
サーバー（特にプロキシ）が応答の完全な長さを認識していないが、バイト範囲の要求を処理できる場合があります。したがって、メッセージの全長を示さないcontent-rangeを持つバイト範囲を許可するメカニズムが必要です。 （セクション14.16）
Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send needed headers in a 206 response, this problem can be avoided. (Section 10.2.7, 13.5.3, and 14.27)
すべてのメタデータが常に返された場合、範囲要求の応答は非常に冗長になります。サーバーが206応答で必要なヘッダーのみを送信できるようにすることで、この問題を回避できます。 （セクション10.2.7、13.5.3、および14.27）
Fix problem with unsatisfiable range requests; there are two cases: syntactic problems, and range doesn't exist in the document. The 416 status code was needed to resolve this ambiguity needed to indicate an error for a byte range request that falls outside of the actual contents of a document. (Section 10.4.17, 14.16)
満足できない範囲リクエストの問題を修正します。 2つのケースがあります。構文の問題と、範囲がドキュメントに存在しません。ドキュメントの実際のコンテンツの範囲外にあるバイト範囲リクエストのエラーを示すために必要なこのあいまいさを解決するために、416ステータスコードが必要でした。 （セクション10.4.17、14.16）
Rewrite of message transmission requirements to make it much harder for implementors to get it wrong, as the consequences of errors here can have significant impact on the Internet, and to deal with the following problems:
ここでのエラーの結果はインターネットに大きな影響を与える可能性があり、次の問題を処理するため、実装者が誤解するのをはるかに困難にするメッセージ送信要件の書き換え。
1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where this was incorrectly placing a requirement on the behavior of an implementation of a future version of HTTP/1.x
1. これがHTTP / 1.xの将来のバージョンの実装の動作に誤って要件を課していたコンテキストで、「HTTP / 1.1以降」を「HTTP / 1.1」に変更する
2. Made it clear that user-agents should retry requests, not "clients" in general.
2. 一般に「クライアント」ではなく、ユーザーエージェントがリクエストを再試行する必要があることを明確にしました。
3. Converted requirements for clients to ignore unexpected 100 (Continue) responses, and for proxies to forward 100 responses, into a general requirement for 1xx responses.
3. クライアントが予期しない100（続行）応答を無視するための要件と、プロキシが100応答を転送するための要件を、1xx応答の一般要件に変換しました。
4. Modified some TCP-specific language, to make it clearer that non-TCP transports are possible for HTTP.
4. HTTPで非TCPトランスポートが可能であることを明確にするために、一部のTCP固有の言語を変更しました。
5. Require that the origin server MUST NOT wait for the request body before it sends a required 100 (Continue) response.
5. オリジンサーバーが必要な100（Continue）応答を送信する前にリクエストボディを待機してはならないことを要求します。
6. Allow, rather than require, a server to omit 100 (Continue) if it has already seen some of the request body.
6. 要求本文の一部がすでに表示されている場合、サーバーが100（続行）を省略できるようにします。
7. Allow servers to defend against denial-of-service attacks and broken clients.
7. サーバーがサービス拒否攻撃や壊れたクライアントから防御できるようにします。
This change adds the Expect header and 417 status code. The message transmission requirements fixes are in sections 8.2, 10.4.18, 8.1.2.2, 13.11, and 14.20.
この変更により、Expectヘッダーと417ステータスコードが追加されます。メッセージ送信要件の修正は、セクション8.2、10.4.18、8.1.2.2、13.11、および14.20にあります。
Proxies should be able to add Content-Length when appropriate. (Section 13.5.2)
プロキシは、必要に応じてContent-Lengthを追加できる必要があります。 （セクション13.5.2）
Clean up confusion between 403 and 404 responses. (Section 10.4.4, 10.4.5, and 10.4.11)
403と404の応答の混乱を解消します。 （セクション10.4.4、10.4.5、および10.4.11）
Warnings could be cached incorrectly, or not updated appropriately. (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.
警告は誤ってキャッシュされるか、適切に更新されない可能性があります。 （セクション13.1.2、13.2.4、13.5.2、13.5.3、14.9.3、および14.46）警告は、PUTまたは他のメソッドがリクエストで必要とする場合があるため、一般的なヘッダーである必要もありました。
Transfer-coding had significant problems, particularly with interactions with chunked encoding. The solution is that transfer-codings become as full fledged as content-codings. This involves adding an IANA registry for transfer-codings (separate from content codings), a new header field (TE) and enabling trailer headers in the future. Transfer encoding is a major performance benefit, so it was worth fixing [39]. TE also solves another, obscure, downward interoperability problem that could have occurred due to interactions between authentication trailers, chunked encoding and HTTP/1.0 clients.(Section 3.6, 3.6.1, and 14.39)
転送コーディングには、特にチャンクエンコーディングとのやり取りで重大な問題がありました。解決策は、転送コーディングがコンテンツコーディングと同じくらい本格的なものになることです。これには、転送コーディング（コンテンツコーディングとは別）のIANAレジストリの追加、新しいヘッダーフィールド（TE）、および将来のトレーラーヘッダーの有効化が含まれます。転送エンコーディングはパフォーマンスの主要な利点であるため、修正する価値がありました[39]。 TEはまた、認証トレーラー、チャンクエンコーディング、HTTP / 1.0クライアント間の相互作用が原因で発生する可能性がある、別のあいまいな下位相互運用性の問題も解決します（セクション3.6、3.6.1、および14.39）。
The PATCH, LINK, UNLINK methods were defined but not commonly implemented in previous versions of this specification. See RFC 2068 [33].
PATCH、LINK、UNLINKメソッドは定義されていますが、この仕様の以前のバージョンでは一般的に実装されていませんでした。 RFC 2068 [33]を参照してください。
The Alternates, Content-Version, Derived-From, Link, URI, Public and Content-Base header fields were defined in previous versions of this specification, but not commonly implemented. See RFC 2068 [33].
Alternates、Content-Version、Derived-From、Link、URI、Public、およびContent-Baseヘッダーフィールドは、この仕様の以前のバージョンで定義されていましたが、一般的には実装されていませんでした。 RFC 2068 [33]を参照してください。
20 Index
20インデックス
Please see the PostScript version of this RFC for the INDEX.
INDEXについては、このRFCのPostScriptバージョンを参照してください。
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。 、ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。