[要約] RFC 7232は、HTTP/1.1における条件付きリクエストに関する仕様を定めたものであり、キャッシュの効率化やネットワークの負荷軽減を目的としています。要約すると、リクエストやレスポンスに条件を付けることで、サーバー側が必要な情報のみを送信することができる仕組みです。
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7232 Adobe
Obsoletes: 2616 J. Reschke, Ed.
Category: Standards Track greenbytes
ISSN: 2070-1721 June 2014
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
ハイパーテキスト転送プロトコル（HTTP / 1.1）：条件付きリクエスト
Abstract
概要
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.
ハイパーテキスト転送プロトコル（HTTP）は、分散型の協調型ハイパーテキスト情報システム用のステートレスアプリケーションレベルプロトコルです。このドキュメントでは、HTTP / 1.1条件付きリクエストを定義します。これには、状態の変化を示すメタデータヘッダーフィールド、そのような状態の前提条件を作成するためのリクエストヘッダーフィールド、1つ以上の前提条件がfalseと評価されたときに条件付きリクエストへの応答を作成するためのルールが含まれます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7232.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7232で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conformance and Error Handling .............................4
1.2. Syntax Notation ............................................4
2. Validators ......................................................5
2.1. Weak versus Strong .........................................5
2.2. Last-Modified ..............................................7
2.2.1. Generation ..........................................7
2.2.2. Comparison ..........................................8
2.3. ETag .......................................................9
2.3.1. Generation .........................................10
2.3.2. Comparison .........................................10
2.3.3. Example: Entity-Tags Varying on
Content-Negotiated Resources .......................11
2.4. When to Use Entity-Tags and Last-Modified Dates ...........12
3. Precondition Header Fields .....................................13
3.1. If-Match ..................................................13
3.2. If-None-Match .............................................14
3.3. If-Modified-Since .........................................16
3.4. If-Unmodified-Since .......................................17
3.5. If-Range ..................................................18
4. Status Code Definitions ........................................18
4.1. 304 Not Modified ..........................................18
4.2. 412 Precondition Failed ...................................19
5. Evaluation .....................................................19
6. Precedence .....................................................20
7. IANA Considerations ............................................22
7.1. Status Code Registration ..................................22
7.2. Header Field Registration .................................22
8. Security Considerations ........................................22
9. Acknowledgments ................................................23
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................24
Appendix A. Changes from RFC 2616 .................................25
Appendix B. Imported ABNF .........................................25
Appendix C. Collected ABNF ........................................26
Index .............................................................27
Conditional requests are HTTP requests [RFC7231] that include one or more header fields indicating a precondition to be tested before applying the method semantics to the target resource. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax notation, and conformance criteria defined in [RFC7230].
条件付きリクエストは、メソッドのセマンティクスをターゲットリソースに適用する前にテストする前提条件を示す1つ以上のヘッダーフィールドを含むHTTPリクエスト[RFC7231]です。このドキュメントは、[RFC7230]で定義されているアーキテクチャ、構文表記、および適合基準の観点から、HTTP / 1.1条件付き要求メカニズムを定義しています。
Conditional GET requests are the most efficient mechanism for HTTP cache updates [RFC7234]. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: one client accidentally overwriting the work of another client that has been acting in parallel.
条件付きGETリクエストは、HTTPキャッシュ更新の最も効率的なメカニズムです[RFC7234]。また、PUTやDELETEなどの状態変更メソッドに条件を適用して、「失われた更新」の問題を防ぐことができます。あるクライアントが、並行して動作していた別のクライアントの作業を誤って上書きしてしまいます。
Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the state as observed in a previously obtained representation (one value in that set). A resource might have multiple current representations, each with its own observable state. The conditional request mechanisms assume that the mapping of requests to a "selected representation" (Section 3 of [RFC7231]) will be consistent over time if the server intends to take advantage of conditionals. Regardless, if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result when the precondition evaluates to false.
条件付きリクエストの前提条件は、ターゲットリソース全体の状態（現在の値セット）または以前に取得した表現で観察された状態（そのセット内の1つの値）に基づいています。リソースには複数の現在の表現があり、それぞれに独自の監視可能な状態があります。条件付きリクエストメカニズムでは、サーバーが条件付きの機能を利用しようとする場合、リクエストの「選択された表現」（[RFC7231]のセクション3）へのマッピングは、長期にわたって一貫していると想定しています。いずれにしても、マッピングに一貫性がなく、サーバーが適切な表現を選択できない場合、前提条件がfalseと評価されても害はありません。
The conditional request preconditions defined by this specification (Section 3) are evaluated when applicable to the recipient (Section 5) according to their order of precedence (Section 6).
この仕様（セクション3）で定義された条件付きリクエストの前提条件は、受信者（セクション5）に適用可能な場合、優先順位（セクション6）に従って評価されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].
エラー処理に関する適合基準と考慮事項は、[RFC7230]のセクション2.5で定義されています。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix B describes rules imported from other documents. Appendix C shows the collected grammar with all list operators expanded to standard ABNF notation.
この仕様では、[RFC7230]のセクション7で定義されているリスト拡張子付きの[RFC5234]の拡張バッカスナウア記法（ABNF）表記を使用して、「＃」演算子を使用したコンマ区切りリストのコンパクトな定義を可能にしています（ 「*」演算子が繰り返しを示す方法）。付録Bでは、他のドキュメントからインポートされたルールについて説明します。付録Cは、すべてのリスト演算子が標準のABNF表記に拡張された、収集された文法を示しています。
This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions: modification dates (Section 2.2) and opaque entity tags (Section 2.3). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed Authoring and Versioning (WebDAV, [RFC4918]), that are beyond the scope of this specification. A resource metadata value is referred to as a "validator" when it is used within a precondition.
この仕様は、リソースの状態を観察し、前提条件をテストするために一般的に使用される2つの形式のメタデータを定義します。変更日付（セクション2.2）と不透明なエンティティタグ（セクション2.3）です。リソースの状態を反映する追加のメタデータは、この仕様の範囲を超える、Web分散オーサリングやバージョン管理（WebDAV、[RFC4918]）などのHTTPのさまざまな拡張機能によって定義されています。リソースメタデータ値は、前提条件内で使用される場合、「バリデーター」と呼ばれます。
Validators come in two flavors: strong or weak. Weak validators are easy to generate but are far less useful for comparisons. Strong validators are ideal for comparisons but can be very difficult (and occasionally impossible) to generate efficiently. Rather than impose that all forms of resource adhere to the same strength of validator, HTTP exposes the type of validator in use and imposes restrictions on when weak validators can be used as preconditions.
バリデーターには、強いまたは弱いという2つのフレーバーがあります。弱いバリデーターは簡単に生成できますが、比較にはあまり役に立ちません。強力なバリデーターは比較には理想的ですが、効率的に生成することは非常に困難（場合によっては不可能）になる可能性があります。 HTTPは、すべての形式のリソースが同じバリデーターの強度に従うことを強制するのではなく、使用中のバリデーターのタイプを公開し、弱いバリデーターを前提条件として使用できる場合に制限を課します。
A "strong validator" is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the payload body of a 200 (OK) response to GET.
「強力なバリデーター」は、GETへの200（OK）応答のペイロード本体で監視可能な表現データに変更が発生するたびに値を変更する表現メタデータです。
A strong validator might change for reasons other than a change to the representation data, such as when a semantically significant part of the representation metadata is changed (e.g., Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate the stored responses held by remote caches and authoring tools.
強力なバリデーターは、表現メタデータの意味的に重要な部分（たとえば、Content-Type）が変更された場合など、表現データの変更以外の理由で変更される可能性がありますが、オリジンサーバーの最善の利益はリモートキャッシュおよびオーサリングツールによって保持されている格納された応答を無効にする必要がある場合は、値を変更します。
Cache entries might persist for arbitrarily long periods, regardless of expiration times. Thus, a cache might attempt to validate an entry using a validator that it obtained in the distant past. A strong validator is unique across all versions of all representations associated with a particular resource over time. However, there is no implication of uniqueness across representations of different resources (i.e., the same strong validator might be in use for representations of multiple resources at the same time and does not imply that those representations are equivalent).
キャッシュエントリは、有効期限に関係なく、任意の期間持続する場合があります。したがって、キャッシュは、それまでに取得したバリデーターを使用してエントリーを検証しようとする場合があります。強力なバリデーターは、特定のリソースに関連付けられたすべての表現のすべてのバージョンにわたって固有です。ただし、さまざまなリソースの表現全体の一意性の影響はありません（つまり、同じ強力なバリデーターが複数のリソースの表現に同時に使用されている可能性があり、それらの表現が同等であることを意味しません）。
There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations.
実際に使用されるさまざまな強力なバリデーターがあります。最良のものは厳密なリビジョン管理に基づいており、表現を変更するたびに、表現がGETにアクセスできるようになる前に、一意のノード名とリビジョン識別子が常に割り当てられます。応答ヘッダーフィールドが送信される前にデータが利用可能であり、検証要求が受信されるたびにダイジェストを再計算する必要がない場合も、表現データに適用される衝突耐性ハッシュ関数で十分です。ただし、リソースにメタデータのみが異なる別個の表現がある場合（たまたま同じデータ形式を共有するメディアタイプのコンテンツネゴシエーションなどで発生する可能性がある場合）、オリジンサーバーはこれらの表現を区別するためにバリデーターに追加情報を組み込む必要があります。
In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data. This weakness might be due to limitations in how the value is calculated, such as clock resolution, an inability to ensure uniqueness for all possible representations of the resource, or a desire of the resource owner to group representations by some self-determined set of equivalency rather than unique sequences of data. An origin server SHOULD change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation. In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.
対照的に、「弱いバリデーター」は表現メタデータであり、表現データが変更されるたびに変わるとは限りません。この弱点は、値の計算方法の制限（クロック分解能など）、リソースのすべての可能な表現の一意性を保証できないこと、またはリソース所有者が自己決定した同値のセットによって表現をグループ化したいという欲求による可能性があります。データの一意のシーケンスではなく。オリジンサーバーは、以前の表現が現在の表現の代用として受け入れられないと見なした場合はいつでも、弱いエンティティタグを変更する必要があります。言い換えれば、弱いエンティティタグは、元のサーバーが古い応答を無効にするためにキャッシュを必要とするときはいつでも変更する必要があります。
For example, the representation of a weather report that changes in content every second, based on dynamic measurements, might be grouped into sets of equivalent representations (from the origin server's perspective) with the same weak validator in order to allow cached representations to be valid for a reasonable period of time (perhaps adjusted dynamically based on server load or weather quality). Likewise, a representation's modification time, if defined with only one-second resolution, might be a weak validator if it is possible for the representation to be modified twice during a single second and retrieved between those modifications.
たとえば、動的測定に基づいてコンテンツが毎秒変化する天気予報の表現は、キャッシュされた表現を有効にするために、同じ弱いバリデーターを使用して（起点サーバーの観点から）同等の表現のセットにグループ化できます。妥当な期間（おそらく、サーバーの負荷や気象の質に基づいて動的に調整されます）。同様に、1秒の解像度で定義された表現の変更時間は、表現が1秒間に2回変更され、それらの変更の間に取得される可能性がある場合、弱いバリデーターになる可能性があります。
Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data. For example, if the origin server sends the same validator for a representation with a gzip content coding applied as it does for a representation with no content coding, then that validator is weak. However, two simultaneous representations might share the same strong validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data.
同様に、特定のリソースの2つ以上の表現が同時に共有している場合、それらの表現が同じ表現データを持たない限り、バリデーターは脆弱です。たとえば、オリジンサーバーが、コンテンツコーディングのない表現の場合と同じように、gzipコンテンツコーディングが適用された表現に対して同じバリデーターを送信する場合、そのバリデーターは脆弱です。ただし、2つの異なるメディアタイプが同じ表現データで使用できる場合など、2つの同時表現が表現のメタデータのみが異なる場合、同じ強力なバリデーターを共有する可能性があります。
Strong validators are usable for all conditional requests, including cache validation, partial content ranges, and "lost update" avoidance. Weak validators are only usable when the client does not require exact equality with previously obtained representation data, such as when validating a cache entry or limiting a web traversal to recent changes.
強力なバリデーターは、キャッシュの検証、部分的なコンテンツの範囲、および「失われた更新」の回避を含む、すべての条件付きリクエストに使用できます。弱いバリデーターは、キャッシュエントリを検証したり、Webトラバーサルを最近の変更に制限したりする場合など、クライアントが以前に取得した表現データとの正確な同等性を必要としない場合にのみ使用できます。
The "Last-Modified" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request.
応答の "Last-Modified"ヘッダーフィールドは、要求の処理の終了時に決定された、選択された表現が最後に変更されたとオリジンサーバーが信じる日時を示すタイムスタンプを提供します。
Last-Modified = HTTP-date
Last-Modified = HTTP-date
An example of its use is
その使用例は
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
An origin server SHOULD send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined, since its use in conditional requests and evaluating cache freshness ([RFC7234]) results in a substantial reduction of HTTP traffic on the Internet and can be a significant factor in improving service scalability and reliability.
オリジンサーバーは、条件付きリクエストでの使用とキャッシュの新しさの評価（[RFC7234]）の結果、インターネットは、サービスのスケーラビリティと信頼性を向上させる上で重要な要素となります。
A representation is typically the sum of many parts behind the resource interface. The last-modified time would usually be the most recent time that any of those parts were changed. How that value is determined for any given resource is an implementation detail beyond the scope of this specification. What matters to HTTP is how recipients of the Last-Modified header field can use its value to make conditional requests and test the validity of locally cached responses.
表現は通常、リソースインターフェイスの背後にある多くの部分の合計です。最終変更時刻は通常、これらのパーツのいずれかが変更された最新の時刻です。特定のリソースについてその値を決定する方法は、この仕様の範囲を超える実装の詳細です。 HTTPで重要なのは、Last-Modifiedヘッダーフィールドの受信者がその値を使用して条件付き要求を作成し、ローカルにキャッシュされた応答の有効性をテストする方法です。
An origin server SHOULD obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date field value for its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially if the representation changes near the time that the response is generated.
オリジンサーバーは、その応答の日付フィールド値を生成する時刻にできるだけ近い表現のLast-Modified値を取得する必要があります（SHOULD）。これにより、受信者は、特に応答が生成された時間の近くで表現が変化した場合に、表現の変更時間を正確に評価できます。
An origin server with a clock MUST NOT send a Last-Modified date that is later than the server's time of message origination (Date). If the last modification time is derived from implementation-specific metadata that evaluates to some time in the future, according to the origin server's clock, then the origin server MUST replace that value with the message origination date. This prevents a future modification date from having an adverse impact on cache validation.
クロックのあるオリジンサーバーは、サーバーのメッセージの発生時刻（日付）より後の最終変更日を送信してはなりません（MUST NOT）。最終変更時刻が、起点サーバーのクロックに従って、将来のある時点で評価される実装固有のメタデータから導出される場合、起点サーバーはその値をメッセージの起点日で置き換えなければなりません（MUST）。これにより、将来の変更日がキャッシュの検証に悪影響を及ぼすのを防ぎます。
An origin server without a clock MUST NOT assign Last-Modified values to a response unless these values were associated with the resource by some other system or user with a reliable clock.
クロックのないオリジンサーバーは、Last-Modified値を他のシステムまたは信頼できるクロックを持つユーザーによってリソースに関連付けられていない限り、応答に値を割り当ててはなりません（MUST NOT）。
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時間は、リクエストでバリデーターとして使用された場合、次のルールを使用して、それが強いと推定できない限り、暗黙的に弱くなります。
o The validator is being compared by an origin server to the actual current validator for the representation and,
o バリデーターは、オリジンサーバーによって、表現の実際の現在のバリデーターと比較されます。
o That origin server reliably knows that the associated representation did not change twice during the second covered by the presented validator.
o その起点サーバーは、関連する表現が、提示されたバリデーターによってカバーされる2番目の間に2回変更されなかったことを確実に認識しています。
or
または
o The validator is about to be used by a client in an If-Modified-Since, If-Unmodified-Since, or If-Range header field, because the client has a cache entry for the associated representation, and
o クライアントに関連付けられた表現のキャッシュエントリがあるため、バリデーターはクライアントがIf-Modified-Since、If-Unmodified-Since、またはIf-Rangeヘッダーフィールドで使用しようとしています。
o That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
o そのキャッシュエントリには、元のサーバーが元の応答を送信した時刻を示す日付値が含まれています。
o The presented Last-Modified time is at least 60 seconds before the Date value.
o 提示されるLast-Modified時間は、Date値の少なくとも60秒前です。
or
または
o The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation, and
o バリデーターは、中間キャッシュによって、表現のキャッシュエントリーに保存されているバリデーターと比較されます。
o That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
o そのキャッシュエントリには、元のサーバーが元の応答を送信した時刻を示す日付値が含まれています。
o The presented Last-Modified time is at least 60 seconds before the Date value.
o 提示される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）。
The "ETag" header field in a response provides the current entity-tag for the selected representation, as determined at the conclusion of handling the request. An entity-tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
応答の「ETag」ヘッダーフィールドは、要求の処理の終了時に決定された、選択された表現の現在のエンティティタグを提供します。エンティティタグは、同じリソースの複数の表現を区別するための不透明なバリデータであり、それらの複数の表現が時間の経過に伴うリソースの状態の変化によるものか、コンテンツネゴシエーションによって複数の表現が同時に有効になるか、またはその両方であるかは関係ありません。エンティティタグは、不透明の引用符付き文字列で構成され、弱点インジケータが前に付いている可能性があります。
ETag = entity-tag
ETag =エンティティタグ
entity-tag = [ weak ] opaque-tag
weak = %x57.2F ; "W/", case-sensitive
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text
Note: Previously, opaque-tag was defined to be a quoted-string ([RFC2616], Section 3.11); thus, some recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity tags.
注：以前は、不透明タグは引用文字列として定義されていました（[RFC2616]、セクション3.11）。したがって、一部の受信者はエスケープ解除のバックスラッシュを実行する場合があります。したがって、サーバーはエンティティタグ内のバックスラッシュ文字を回避する必要があります。
An entity-tag can be more reliable for validation than a modification date in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, or where modification dates are not consistently maintained.
エンティティータグは、HTTP日付値の1秒の解決では不十分な場合、または変更日が一貫して維持されない場合、変更日を保存するのに不便な状況では、変更日よりも検証の信頼性が高くなる可能性があります。
Examples:
例：
ETag: "xyzzy" ETag: W/"xyzzy" ETag: ""
ETag： "xyzzy" ETag：W / "xyzzy" ETag： ""
An entity-tag can be either a weak or strong validator, with strong being the default. If an origin server provides an entity-tag for a representation and the generation of that entity-tag does not satisfy all of the characteristics of a strong validator (Section 2.1), then the origin server MUST mark the entity-tag as weak by prefixing its opaque value with "W/" (case-sensitive).
entity-tagは、デフォルトのstrongを使用して、弱いまたは強いバリデーターにすることができます。オリジンサーバーが表現にエンティティタグを提供し、そのエンティティタグの生成が強力なバリデーターのすべての特性を満たさない場合（セクション2.1）、オリジンサーバーはエンティティタグにプレフィックスを付けて弱いものとしてマークしなければなりません（MUST）。 「W /」（大文字と小文字を区別）付きの不透明な値。
The principle behind entity-tags is that only the service author knows the implementation of a resource well enough to select the most accurate and efficient validation mechanism for that resource, and that any such mechanism can be mapped to a simple sequence of octets for easy comparison. Since the value is opaque, there is no need for the client to be aware of how each entity-tag is constructed.
エンティティタグの背後にある原則は、リソースの実装を知っているのはサービスの作成者だけであり、そのリソースに対して最も正確で効率的な検証メカニズムを選択できること、そしてそのようなメカニズムは単純なオクテットのシーケンスにマッピングして簡単に比較できることです。 。値は不透明であるため、クライアントが各エンティティタグの構成方法を認識する必要はありません。
For example, a resource that has implementation-specific versioning applied to all changes might use an internal revision number, perhaps combined with a variance identifier for content negotiation, to accurately differentiate between representations. Other implementations might use a collision-resistant hash of representation content, a combination of various file attributes, or a modification timestamp that has sub-second resolution.
たとえば、実装固有のバージョン管理がすべての変更に適用されているリソースは、内部リビジョン番号を使用し、コンテンツネゴシエーションの差異識別子と組み合わせて、表現を正確に区別できます。他の実装では、表現コンテンツの衝突に強いハッシュ、さまざまなファイル属性の組み合わせ、または1秒未満の解像度を持つ変更タイムスタンプを使用する場合があります。
An origin server SHOULD send an ETag for any selected representation for which detection of changes can be reasonably and consistently determined, since the entity-tag's use in conditional requests and evaluating cache freshness ([RFC7234]) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability and reliability.
条件付きリクエストでのエンティティタグの使用とキャッシュの鮮度の評価（[RFC7234]）により、HTTPネットワークが大幅に削減される可能性があるため、オリジンサーバーは、変更の検出を合理的かつ一貫して決定できる任意の選択された表現のETagを送信する必要があります（SHOULD）。トラフィックは、サービスのスケーラビリティと信頼性を向上させる上で重要な要素となります。
There are two entity-tag comparison functions, depending on whether or not the comparison context allows the use of weak validators:
比較コンテキストが弱いバリデーターの使用を許可するかどうかに応じて、2つのエンティティタグ比較関数があります。
o Strong comparison: two entity-tags are equivalent if both are not weak and their opaque-tags match character-by-character.
o 強力な比較：2つのエンティティタグは、両方が弱くなく、それらの不透明タグが文字ごとに一致する場合、同等です。
o Weak comparison: two entity-tags are equivalent if their opaque-tags match character-by-character, regardless of either or both being tagged as "weak".
o 弱い比較：どちらかまたは両方が「弱い」としてタグ付けされているかどうかに関係なく、不透明タグが文字ごとに一致する場合、2つのエンティティタグは同等です。
The example below shows the results for a set of entity-tag pairs and both the weak and strong comparison function results:
以下の例は、エンティティタグペアのセットの結果と、弱い比較関数と強い比較関数の両方の結果を示しています。
+--------+--------+-------------------+-----------------+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+--------+--------+-------------------+-----------------+
| W/"1" | W/"1" | no match | match |
| W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match |
| "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+
Consider a resource that is subject to content negotiation (Section 3.4 of [RFC7231]), and where the representations sent in response to a GET request vary based on the Accept-Encoding request header field (Section 5.3.4 of [RFC7231]):
コンテンツネゴシエーションの対象となるリソースを検討し（[RFC7231]のセクション3.4）、GETリクエストへの応答として送信される表現がAccept-Encodingリクエストヘッダーフィールドに基づいて変化する場合（[RFC7231]のセクション5.3.4）：
>> Request:
>>リクエスト：
GET /index HTTP/1.1 Host: www.example.com Accept-Encoding: gzip
GET / index HTTP / 1.1ホスト：www.example.com Accept-Encoding：gzip
In this case, the response might or might not use the gzip content coding. If it does not, the response might look like:
この場合、応答はgzipコンテンツコーディングを使用する場合と使用しない場合があります。そうでない場合、応答は次のようになります。
>> Response:
>>応答：
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-a"
Content-Length: 70
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! Hello World! Hello World! Hello World! Hello World!
"こんにちは世界" "こんにちは世界" "こんにちは世界" "こんにちは世界" "こんにちは世界"
An alternative representation that does use gzip content coding would be:
gzipコンテンツコーディングを使用する代替表現は次のようになります。
>> Response:
>>応答：
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
ETag: "123-b"
Content-Length: 43
Vary: Accept-Encoding
Content-Type: text/plain
Content-Encoding: gzip
...binary data...
...バイナリデータ...
Note: Content codings are a property of the representation data, so a strong entity-tag for a content-encoded representation has to be distinct from the entity tag of an unencoded representation to prevent potential conflicts during cache updates and range requests. In contrast, transfer codings (Section 4 of [RFC7230]) apply only during message transfer and do not result in distinct entity-tags.
注：コンテンツコーディングは表現データのプロパティであるため、コンテンツのエンコードされた表現の強力なエンティティタグは、エンコードされていない表現のエンティティタグとは区別して、キャッシュの更新や範囲のリクエスト中に競合が発生しないようにする必要があります。対照的に、転送コーディング（[RFC7230]のセクション4）はメッセージ転送中にのみ適用され、個別のエンティティタグにはなりません。
In 200 (OK) responses to GET or HEAD, an origin server:
元のサーバーであるGETまたはHEADに対する200（OK）応答：
o SHOULD send an entity-tag validator unless it is not feasible to generate one.
o エンティティタグバリデーターを生成することが不可能な場合を除き、それを送信する必要があります（SHOULD）。
o 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.
o パフォーマンスの考慮により弱いエンティティタグの使用がサポートされている場合、または強いエンティティタグを送信できない場合は、強いエンティティタグの代わりに弱いエンティティタグを送信できます。
o SHOULD send a Last-Modified value if it is feasible to send one.
o 送信可能な場合は、Last-Modified値を送信する必要があります（SHOULD）。
In other words, the preferred behavior for an origin server is to send both a strong entity-tag and a Last-Modified value in successful responses to a retrieval request.
つまり、オリジンサーバーの推奨動作は、取得リクエストへの正常な応答で強力なエンティティタグとLast-Modified値の両方を送信することです。
A client:
クライアント：
o MUST send that entity-tag in any cache validation request (using If-Match or If-None-Match) if an entity-tag has been provided by the origin server.
o エンティティタグがオリジンサーバーから提供されている場合は、キャッシュ検証リクエスト（If-MatchまたはIf-None-Matchを使用）でそのエンティティタグを送信する必要があります。
o SHOULD send the Last-Modified value in non-subrange cache validation requests (using If-Modified-Since) if only a Last-Modified value has been provided by the origin server.
o オリジンサーバーからLast-Modified値のみが提供されている場合は、サブレンジ以外のキャッシュ検証リクエストでLast-Modified値を送信する必要があります（If-Modified-Sinceを使用）。
o MAY send the Last-Modified value in subrange cache validation requests (using If-Unmodified-Since) if only a Last-Modified value has been provided by an HTTP/1.0 origin server. The user agent SHOULD provide a way to disable this, in case of difficulty.
o Last-Modified値のみがHTTP / 1.0オリジンサーバーから提供されている場合は、Last-Modified値をサブレンジキャッシュ検証リクエスト（If-Unmodified-Sinceを使用）で送信できます（MAY）。ユーザーエージェントは、問題が発生した場合にこれを無効にする方法を提供する必要があります（SHOULD）。
o SHOULD send both validators in cache validation requests if both an entity-tag and a Last-Modified value have been provided by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
o エンティティタグとLast-Modified値の両方がオリジンサーバーから提供されている場合、キャッシュ検証リクエストで両方のバリデータを送信する必要があります（SHOULD）。これにより、HTTP / 1.0キャッシュとHTTP / 1.1キャッシュの両方が適切に応答できるようになります。
This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests. Section 5 defines when the preconditions are applied. Section 6 defines the order of evaluation when more than one precondition is present.
このセクションでは、リクエストに前提条件を適用するためのHTTP / 1.1ヘッダーフィールドの構文とセマンティクスを定義します。セクション5は、前提条件がいつ適用されるかを定義します。セクション6では、複数の前提条件が存在する場合の評価の順序を定義します。
The "If-Match" header field makes the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is "*", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value.
「If-Match」ヘッダーフィールドは、フィールド値が「*」の場合、ターゲットリソースの現在の表現を少なくとも1つ持つか、またはfield-valueで提供されるエンティティタグのリストのメンバーと一致するエンティティタグがあります。
An origin server MUST use the strong comparison function when comparing entity-tags for If-Match (Section 2.3.2), since the client intends this precondition to prevent the method from being applied if there have been any changes to the representation data.
クライアントは、表現データに変更があった場合にメソッドが適用されないようにするために、クライアントがこの前提条件を意図しているため、If-Match（セクション2.3.2）のエンティティタグを比較するときに、強力な比較関数を使用する必要があります。
If-Match = "*" / 1#entity-tag
Examples:
例：
If-Match: "xyzzy" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: *
If-Match： "xyzzy" If-Match： "xyzzy"、 "r2d2xxxx"、 "c3piozzzz" If-Match：*
If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to prevent the "lost update" problem). It can also be used with safe methods to abort a request if the selected representation does not match one already stored (or partially stored) from a prior request.
if-Matchは、複数のユーザーエージェントが同じリソース上で並行して動作している可能性がある場合の偶発的な上書きを防ぐために（つまり、「更新の喪失」の問題を防ぐため）、状態変更メソッド（POST、PUT、DELETEなど）で最もよく使用されます。 。また、選択した表現が前の要求から既に格納されている（または部分的に格納されている）表現と一致しない場合に、要求を中止する安全なメソッドと共に使用することもできます。
An origin server that receives an If-Match header field MUST evaluate the condition prior to performing the method (Section 5). If the field-value is "*", the condition is false if the origin server does not have a current representation for the target resource. If the field-value is a list of entity-tags, the condition is false if none of the listed tags match the entity-tag of the selected representation.
If-Matchヘッダーフィールドを受信するオリジンサーバーは、メソッドを実行する前に条件を評価する必要があります（セクション5）。フィールド値が「*」の場合、オリジンサーバーにターゲットリソースの現在の表現がないと、条件はfalseになります。フィールド値がエンティティタグのリストである場合、リストされたタグのいずれも選択した表現のエンティティタグと一致しない場合、条件はfalseです。
An origin server MUST NOT perform the requested method if a received If-Match condition evaluates to false; instead, the origin server MUST respond with either a) the 412 (Precondition Failed) status code or b) one of the 2xx (Successful) status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other user agent). In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent.
受信したIf-Match条件がfalseと評価された場合、オリジンサーバーは要求されたメソッドを実行してはなりません（MUST NOT）。代わりに、オリジンサーバーは、a）412（Precondition Failed）ステータスコードまたはb）2xx（Successful）ステータスコードのいずれかで応答する必要があります。ターゲットリソースの現在の状態に反映されます（つまり、ユーザーエージェントによって要求された変更は既に成功していますが、おそらく以前の応答が失われたか、互換性のある変更が他の何らかの変更によって行われたため、ユーザーエージェントはそれを認識しない場合がありますユーザーエージェント）。後者の場合、オリジンサーバーは、リクエストが同じユーザーエージェントによって行われた直前の変更の複製であることを確認できない限り、レスポンスでバリデーターヘッダーフィールドを送信してはなりません（MUST NOT）。
The If-Match header field can be ignored by caches and intermediaries because it is not applicable to a stored response.
If-Matchヘッダーフィールドは、格納された応答には適用されないため、キャッシュおよび中間者によって無視されます。
The "If-None-Match" header field makes the request method conditional on a recipient cache or origin server either not having any current representation of the target resource, when the field-value is "*", or having a selected representation with an entity-tag that does not match any of those listed in the field-value.
「If-None-Match」ヘッダーフィールドは、フィールド値が「*」の場合、ターゲットリソースの現在の表現を持たないか、選択された表現を持つfield-valueにリストされているものと一致しないエンティティタグ。
A recipient MUST use the weak comparison function when comparing entity-tags for If-None-Match (Section 2.3.2), since weak entity-tags can be used for cache validation even if there have been changes to the representation data.
受信者は、If-None-Match（セクション2.3.2）のエンティティタグを比較するときに、弱い比較関数を使用する必要があります。これは、表現データに変更があった場合でも、弱いエンティティタグをキャッシュの検証に使用できるためです。
If-None-Match = "*" / 1#entity-tag
Examples:
例：
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *
If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information with a minimum amount of transaction overhead. When a client desires to update one or more stored responses that have entity-tags, the client SHOULD generate an If-None-Match header field containing a list of those entity-tags when making a GET request; this allows recipient servers to send a 304 (Not Modified) response to indicate when one of those stored responses matches the selected representation.
If-None-Matchは主に条件付きGETリクエストで使用され、最小限のトランザクションオーバーヘッドでキャッシュされた情報を効率的に更新できるようにします。クライアントがエンティティタグを持つ1つ以上の保存された応答を更新することを望む場合、クライアントはGETリクエストを行うときにそれらのエンティティタグのリストを含むIf-None-Matchヘッダーフィールドを生成する必要があります。これにより、受信者サーバーは304（Not Modified）応答を送信して、保存された応答の1つが選択された表現と一致することを示すことができます。
If-None-Match can also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation (Section 4.2.1 of [RFC7231]). This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation for the target resource.
If-None-Matchを値 "*"と共に使用して、クライアントがリソースに現在の表現がないと信じているときに、安全でないリクエストメソッド（PUTなど）がターゲットリソースの既存の表現を誤って変更するのを防ぐこともできます。 （[RFC7231]のセクション4.2.1）。これは、複数のクライアントがターゲットリソースの初期表現を作成しようとした場合に発生する可能性のある「失われた更新」問題のバリエーションです。
An origin server that receives an If-None-Match header field MUST evaluate the condition prior to performing the method (Section 5). If the field-value is "*", the condition is false if the origin server has a current representation for the target resource. If the field-value is a list of entity-tags, the condition is false if one of the listed tags match the entity-tag of the selected representation.
If-None-Matchヘッダーフィールドを受信するオリジンサーバーは、メソッドを実行する前に条件を評価する必要があります（セクション5）。 field-valueが "*"の場合、オリジンサーバーにターゲットリソースの現在の表現がある場合、条件はfalseです。 field-valueがエンティティタグのリストである場合、リストされたタグの1つが選択した表現のエンティティタグと一致すると、条件はfalseになります。
An origin server MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond with either a) the 304 (Not Modified) status code if the request method is GET or HEAD or b) the 412 (Precondition Failed) status code for all other request methods.
オリジンサーバーは、条件がfalseと評価された場合、要求されたメソッドを実行してはなりません（MUST NOT）。代わりに、オリジンサーバーは、a）リクエストメソッドがGETまたはHEADの場合は304（Not Modified）ステータスコード、b）その他のすべてのリクエストメソッドの場合は412（Precondition Failed）ステータスコードのいずれかで応答する必要があります。
Requirements on cache handling of a received If-None-Match header field are defined in Section 4.3.2 of [RFC7234].
受信したIf-None-Matchヘッダーフィールドのキャッシュ処理に関する要件は、[RFC7234]のセクション4.3.2で定義されています。
The "If-Modified-Since" header field makes a GET or HEAD request method conditional on the selected representation's modification date being more recent than the date provided in the field-value. Transfer of the selected representation's data is avoided if that data has not changed.
「If-Modified-Since」ヘッダーフィールドは、選択された表現の変更日付がフィールド値で提供された日付よりも新しいことを条件として、GETまたはHEADリクエストメソッドを作成します。選択した表現のデータが変更されていない場合、そのデータの転送は回避されます。
If-Modified-Since = HTTP-date
If-Modified-Since = HTTP-date
An example of the field is:
フィールドの例は次のとおりです。
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Modified-Since if the request contains an If-None-Match header field; the condition in If-None-Match is considered to be a more accurate replacement for the condition in If-Modified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement If-None-Match.
リクエストにIf-None-Matchヘッダーフィールドが含まれている場合、受信者はIf-Modified-Sinceを無視する必要があります。 If-None-Matchの条件は、If-Modified-Sinceの条件のより正確な置き換えと見なされ、2つは、If-None-Matchを実装していない可能性のある古い仲介者と相互運用するためにのみ結合されます。
A recipient MUST ignore the If-Modified-Since header field if the received field-value is not a valid HTTP-date, or if the request method is neither GET nor HEAD.
受信したフィールド値が有効なHTTP日付でない場合、または要求メソッドがGETでもHEADでもない場合、受信者はIf-Modified-Sinceヘッダーフィールドを無視する必要があります。
A recipient MUST interpret an If-Modified-Since field-value's timestamp in terms of the origin server's clock.
受信者は、起点サーバーのクロックの観点から、If-Modified-Sinceフィールド値のタイムスタンプを解釈する必要があります。
If-Modified-Since is typically used for two distinct purposes: 1) to allow efficient updates of a cached representation that does not have an entity-tag and 2) to limit the scope of a web traversal to resources that have recently changed.
If-Modified-Sinceは通常、2つの異なる目的で使用されます。1）エンティティタグを持たないキャッシュされた表現を効率的に更新できるようにすることと、2）Webトラバーサルの範囲を最近変更されたリソースに制限することです。
When used for cache updates, a cache will typically use the value of the cached message's Last-Modified field to generate the field value of If-Modified-Since. This behavior is most interoperable for cases where clocks are poorly synchronized or when the server has chosen to only honor exact timestamp matches (due to a problem with Last-Modified dates that appear to go "back in time" when the origin server's clock is corrected or a representation is restored from an archived backup). However, caches occasionally generate the field value based on other data, such as the Date header field of the cached message or the local clock time that the message was received, particularly when the cached message does not contain a Last-Modified field.
キャッシュの更新に使用される場合、キャッシュは通常、キャッシュされたメッセージのLast-Modifiedフィールドの値を使用して、If-Modified-Sinceのフィールド値を生成します。この動作は、クロックが十分に同期されていない場合、またはサーバーがタイムスタンプの正確な一致のみを優先することを選択した場合に最も相互運用可能です（元のサーバーのクロックが修正されたときに「過去に遡る」ように見えるLast-Modified日付の問題が原因です）または、表現がアーカイブされたバックアップから復元されます）。ただし、特にキャッシュされたメッセージにLast-Modifiedフィールドが含まれていない場合、キャッシュは、キャッシュされたメッセージのDateヘッダーフィールドやメッセージが受信されたローカルクロック時間など、他のデータに基づいてフィールド値を生成することがあります。
When used for limiting the scope of retrieval to a recent time window, a user agent will generate an If-Modified-Since field value based on either its own local clock or a Date header field received from the server in a prior response. Origin servers that choose an exact timestamp match based on the selected representation's Last-Modified field will not be able to help the user agent limit its data transfers to only those changed during the specified window.
検索の範囲を最近の時間枠に制限するために使用される場合、ユーザーエージェントは、独自のローカルクロックまたは以前の応答でサーバーから受信した日付ヘッダーフィールドに基づいて、If-Modified-Sinceフィールド値を生成します。選択された表現のLast-Modifiedフィールドに基づいて正確なタイムスタンプの一致を選択するオリジンサーバーは、ユーザーエージェントがデータ転送を指定されたウィンドウ中に変更されたもののみに制限することを支援できません。
An origin server that receives an If-Modified-Since header field SHOULD evaluate the condition prior to performing the method (Section 5). The origin server SHOULD NOT perform the requested method if the selected representation's last modification date is earlier than or equal to the date provided in the field-value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response.
If-Modified-Sinceヘッダーフィールドを受信するオリジンサーバーは、メソッドを実行する前に条件を評価する必要があります（セクション5）。オリジンサーバーは、選択された表現の最終変更日付がフィールド値で提供された日付以前の場合、要求されたメソッドを実行してはなりません。代わりに、オリジンサーバーは、以前にキャッシュされた応答の識別または更新に役立つメタデータのみを含めて、304（Not Modified）応答を生成する必要があります（SHOULD）。
Requirements on cache handling of a received If-Modified-Since header field are defined in Section 4.3.2 of [RFC7234].
受信したIf-Modified-Sinceヘッダーフィールドのキャッシュ処理に関する要件は、[RFC7234]のセクション4.3.2で定義されています。
The "If-Unmodified-Since" header field makes the request method conditional on the selected representation's last modification date being earlier than or equal to the date provided in the field-value. This field accomplishes the same purpose as If-Match for cases where the user agent does not have an entity-tag for the representation.
「If-Unmodified-Since」ヘッダーフィールドは、選択された表現の最終変更日がfield-valueで指定された日付より前か等しいことを条件として、リクエストメソッドを作成します。このフィールドは、ユーザーエージェントが表現のエンティティタグを持たない場合のIf-Matchと同じ目的を果たします。
If-Unmodified-Since = HTTP-date
If-Unmodified-Since = HTTP-date
An example of the field is:
フィールドの例は次のとおりです。
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Unmodified-Since if the request contains an If-Match header field; the condition in If-Match is considered to be a more accurate replacement for the condition in If-Unmodified-Since, and the two are only combined for the sake of interoperating with older intermediaries that might not implement If-Match.
リクエストにIf-Matchヘッダーフィールドが含まれている場合、受信者はIf-Unmodified-Sinceを無視する必要があります。 If-Matchの条件は、If-Unmodified-Sinceの条件のより正確な置き換えと見なされ、2つは、If-Matchを実装しない可能性のある古い仲介者と相互運用するためにのみ結合されます。
A recipient MUST ignore the If-Unmodified-Since header field if the received field-value is not a valid HTTP-date.
受信したフィールド値が有効なHTTP日付でない場合、受信者はIf-Unmodified-Sinceヘッダーフィールドを無視する必要があります。
A recipient MUST interpret an If-Unmodified-Since field-value's timestamp in terms of the origin server's clock.
受信者は、起点サーバーのクロックに関して、If-Unmodified-Sinceフィールド値のタイムスタンプを解釈する必要があります。
If-Unmodified-Since is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on a resource that does not supply entity-tags with its representations (i.e., to prevent the "lost update" problem). It can also be used with safe methods to abort a request if the selected representation does not match one already stored (or partially stored) from a prior request.
If-Unmodified-Sinceは、多くの場合、状態を変更するメソッド（POST、PUT、DELETEなど）で使用され、エンティティタグとその表現を提供しないリソースで複数のユーザーエージェントが並行して動作している場合に、誤って上書きされるのを防ぎます（つまり、「更新が失われる」問題を防ぐためです）。また、選択した表現が前の要求から既に格納されている（または部分的に格納されている）表現と一致しない場合に、要求を中止する安全なメソッドと共に使用することもできます。
An origin server that receives an If-Unmodified-Since header field MUST evaluate the condition prior to performing the method (Section 5). The origin server MUST NOT perform the requested method if the selected representation's last modification date is more recent than the date provided in the field-value; instead the origin server MUST respond with either a) the 412 (Precondition Failed) status code or b) one of the 2xx (Successful) status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of that because the prior response message was lost or a compatible change was made by some other user agent). In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent.
If-Unmodified-Sinceヘッダーフィールドを受信するオリジンサーバーは、メソッドを実行する前に条件を評価する必要があります（セクション5）。オリジンサーバーは、選択された表現の最終変更日付がフィールド値で提供された日付よりも新しい場合、要求されたメソッドを実行してはなりません（MUST NOT）。代わりに、オリジンサーバーは、a）412（Precondition Failed）ステータスコード、またはb）2xx（Successful）ステータスコードのいずれかで応答する必要があります。ターゲットリソースの現在の状態（つまり、ユーザーエージェントによって要求された変更はすでに成功していますが、前の応答メッセージが失われたか、互換性のある変更が他のユーザーエージェントによって行われたため、ユーザーエージェントはそのことに気付かない場合があります）。後者の場合、オリジンサーバーは、リクエストが同じユーザーエージェントによって行われた直前の変更の複製であることを確認できない限り、レスポンスでバリデーターヘッダーフィールドを送信してはなりません（MUST NOT）。
The If-Unmodified-Since header field can be ignored by caches and intermediaries because it is not applicable to a stored response.
If-Unmodified-Sinceヘッダーフィールドは、格納された応答には適用されないため、キャッシュおよび仲介者によって無視されます。
The "If-Range" header field provides a special conditional request mechanism that is similar to the If-Match and If-Unmodified-Since header fields but that instructs the recipient to ignore the Range header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a 412 (Precondition Failed) response. If-Range is defined in Section 3.2 of [RFC7233].
「If-Range」ヘッダーフィールドは、If-MatchおよびIf-Unmodified-Sinceヘッダーフィールドと同様の特別な条件付きリクエストメカニズムを提供しますが、バリデーターが一致しない場合、結果としてRangeヘッダーフィールドを無視するように受信者に指示します。 412（Precondition Failed）応答ではなく、新しく選択された表現の転送。 If-Rangeは[RFC7233]のセクション3.2で定義されています。
The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false. In other words, there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored representation as if it were the payload of a 200 (OK) response.
304（Not Modified）ステータスコードは、条件付きのGETまたはHEADリクエストが受信され、条件がfalseと評価されたという事実がなければ200（OK）応答を返すことを示しています。つまり、リクエストは条件付きのリクエストを作成したクライアントがすでに有効な表現を持っていることをリクエストが示しているため、サーバーがターゲットリソースの表現を転送する必要はありません。したがって、サーバーはクライアントをリダイレクトして、格納されている表現を200（OK）応答のペイロードであるかのように利用します。
The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.
304応答を生成するサーバーは、同じ要求に対する200（OK）応答で送信されるヘッダーフィールド（Cache-Control、Content-Location、Date、ETag、Expires、およびVary）のいずれかを生成する必要があります。
Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender SHOULD NOT generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., Last-Modified might be useful if the response does not have an ETag field).
304応答の目的は、受信者がすでに1つ以上のキャッシュされた表現を持っている場合の情報転送を最小限に抑えることであるため、キャッシュの更新をガイドする目的でメタデータが存在しない限り、送信者は上記のフィールド以外の表現メタデータを生成してはなりません（SHOULD NOT）。 Last-Modifiedは、応答にETagフィールドがない場合に役立つことがあります。
Requirements on a cache that receives a 304 response are defined in Section 4.3.4 of [RFC7234]. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional GET to a shared proxy, then the proxy SHOULD forward the 304 response to that client.
304応答を受信するキャッシュの要件は、[RFC7234]のセクション4.3.4で定義されています。条件付き要求が発信クライアント、たとえば独自のキャッシュを持つユーザーエージェントが条件付きGETを共有プロキシに送信することで発生した場合、プロキシは304応答をそのクライアントに転送する必要があります（SHOULD）。
A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.
304応答にメッセージ本文を含めることはできません。ヘッダーフィールドの後の最初の空行で常に終了します。
The 412 (Precondition Failed) status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the server. This response code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state.
412（Precondition Failed）ステータスコードは、サーバーでテストしたときに、リクエストヘッダーフィールドで指定された1つ以上の条件がfalseと評価されたことを示します。この応答コードにより、クライアントは現在のリソースの状態（現在の表現とメタデータ）に前提条件を設定できるため、ターゲットリソースが予期しない状態の場合にリクエストメソッドが適用されないようにします。
Except when excluded below, a recipient cache or origin server MUST evaluate received request preconditions after it has successfully performed its normal request checks and just before it would perform the action associated with the request method. A server MUST ignore all received preconditions if its response to the same request without those conditions would have been a status code other than a 2xx (Successful) or 412 (Precondition Failed). In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests.
以下で除外する場合を除き、受信者キャッシュまたはオリジンサーバーは、通常のリクエストチェックが正常に実行された後、リクエストメソッドに関連付けられたアクションを実行する直前に、受信したリクエストの前提条件を評価する必要があります。サーバーは、それらの条件なしの同じ要求への応答が2xx（成功）または412（前提条件失敗）以外のステータスコードである場合、受信したすべての前提条件を無視する必要があります。つまり、リダイレクトと失敗は、条件付きリクエストの前提条件の評価よりも優先されます。
A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource MUST NOT evaluate the conditional request header fields defined by this specification, and it MUST forward them if the request is forwarded, since the generating client intends that they be evaluated by a server that can provide a current representation. Likewise, a server MUST ignore the conditional request header fields defined by this specification when received with a request method that does not involve the selection or modification of a selected representation, such as CONNECT, OPTIONS, or TRACE.
ターゲットリソースのオリジンサーバーではなく、ターゲットリソース上のリクエストのキャッシュとして機能できないサーバーは、この仕様で定義されている条件付きリクエストヘッダーフィールドを評価してはならず、リクエストが転送される場合は転送する必要があります。生成クライアントは、現在の表現を提供できるサーバーによって評価されることを意図しています。同様に、サーバーは、CONNECT、OPTIONS、またはTRACEなどの選択された表現の選択または変更を含まない要求メソッドで受信された場合、この仕様で定義された条件付き要求ヘッダーフィールドを無視する必要があります。
Conditional request header fields that are defined by extensions to HTTP might place conditions on all recipients, on the state of the target resource in general, or on a group of resources. For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field ([RFC4918], Section 10.4).
HTTPの拡張機能によって定義された条件付き要求ヘッダーフィールドは、すべての受信者、ターゲットリソースの一般的な状態、またはリソースのグループに条件を設定する場合があります。たとえば、WebDAVの「If」ヘッダーフィールドは、受信者がそのフィールドを理解して実装している場合、ロックなど、複数のリソースのさまざまな側面を条件としてリクエストを行うことができます（[RFC4918]、セクション10.4）。
Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent with those of GET), there is no point in sending a conditional HEAD because a successful response is around the same size as a 304 (Not Modified) response and more useful than a 412 (Precondition Failed) response.
条件付きリクエストヘッダーフィールドはHEADメソッドで使用可能として定義されていますが（HEADのセマンティクスをGETのセマンティクスと一致させるため）、成功したレスポンスは304（Not Modified）とほぼ同じサイズであるため、条件付きHEADを送信しても意味がありません。 ）レスポンスであり、412（Precondition Failed）レスポンスよりも有用です。
When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes important. In practice, the fields defined in this document are consistently implemented in a single, logical order, since "lost update" preconditions have more strict requirements than cache validation, a validated cache is more efficient than a partial response, and entity tags are presumed to be more accurate than date validators.
リクエストに複数の条件付きリクエストヘッダーフィールドが存在する場合、フィールドが評価される順序が重要になります。実際には、このドキュメントで定義されているフィールドは、単一の論理的な順序で一貫して実装されます。「失われた更新」の前提条件には、キャッシュの検証よりも厳しい要件があるため、検証されたキャッシュは部分的な応答よりも効率的であり、エンティティタグは日付バリデーターよりも正確である。
A recipient cache or origin server MUST evaluate the request preconditions defined by this specification in the following order:
受信者キャッシュまたはオリジンサーバーは、この仕様で定義されているリクエストの前提条件を次の順序で評価する必要があります。
1. When recipient is the origin server and If-Match is present, evaluate the If-Match precondition:
1. 受信者が起点サーバーであり、If-Matchが存在する場合、If-Match前提条件を評価します。
* if true, continue to step 3
* trueの場合、手順3に進みます
* if false, respond 412 (Precondition Failed) unless it can be determined that the state-changing request has already succeeded (see Section 3.1)
* falseの場合は、状態変更要求が既に成功したと判断できない場合（セクション3.1を参照）を除き、412（前提条件の失敗）を返します。
2. When recipient is the origin server, If-Match is not present, and If-Unmodified-Since is present, evaluate the If-Unmodified-Since precondition:
2. 受信者が起点サーバーであり、If-Matchが存在せず、If-Unmodified-Sinceが存在する場合、If-Unmodified-Since前提条件を評価します。
* if true, continue to step 3
* trueの場合、手順3に進みます
* if false, respond 412 (Precondition Failed) unless it can be determined that the state-changing request has already succeeded (see Section 3.4)
* falseの場合は、状態変更要求がすでに成功したと判断できない場合（セクション3.4を参照）を除き、412（前提条件の失敗）を返します。
3. When If-None-Match is present, evaluate the If-None-Match precondition:
3. If-None-Matchが存在する場合、If-None-Match前提条件を評価します。
* if true, continue to step 5
* trueの場合、ステップ5に進みます。
* if false for GET/HEAD, respond 304 (Not Modified)
* GET / HEADがfalseの場合、304（未変更）を応答します
* if false for other methods, respond 412 (Precondition Failed)
* 他のメソッドでfalseの場合は、412（前提条件の失敗）を応答します
4. When the method is GET or HEAD, If-None-Match is not present, and If-Modified-Since is present, evaluate the If-Modified-Since precondition:
4. メソッドがGETまたはHEADであり、If-None-Matchが存在せず、If-Modified-Sinceが存在する場合は、If-Modified-Since前提条件を評価します。
* if true, continue to step 5
* trueの場合、ステップ5に進みます。
* if false, respond 304 (Not Modified)
* falseの場合、304（未変更）を応答します
5. When the method is GET and both Range and If-Range are present, evaluate the If-Range precondition:
5. メソッドがGETで、RangeとIf-Rangeの両方が存在する場合は、If-Range前提条件を評価します。
* if the validator matches and the Range specification is applicable to the selected representation, respond 206 (Partial Content) [RFC7233]
* バリデーターが一致し、範囲の指定が選択した表現に適用できる場合は、206（部分的なコンテンツ）[RFC7233]を応答します
6. Otherwise,
6. さもないと、
* all conditions are met, so perform the requested action and respond according to its success or failure.
* すべての条件が満たされているため、要求されたアクションを実行し、その成功または失敗に応じて応答します。
Any extension to HTTP/1.1 that defines additional conditional request header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice.
追加の条件付きリクエストヘッダーフィールドを定義するHTTP / 1.1の拡張は、このドキュメントで定義されているフィールドと実際に見つかる可能性のある他の条件に関連して、そのようなフィールドを評価する順序に関する独自の期待を定義する必要があります。
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at <http://www.iana.org/assignments/http-status-codes> has been updated with the registrations below:
<http://www.iana.org/assignments/http-status-codes>にある「ハイパーテキスト転送プロトコル（HTTP）ステータスコードレジストリ」は、以下の登録で更新されています。
+-------+---------------------+-------------+
| Value | Description | Reference |
+-------+---------------------+-------------+
| 304 | Not Modified | Section 4.1 |
| 412 | Precondition Failed | Section 4.2 |
+-------+---------------------+-------------+
HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.
HTTPヘッダーフィールドは、<http://www.iana.org/assignments/message-headers/>で管理されている「メッセージヘッダー」レジストリ内に登録されます。
This document defines the following HTTP header fields, so their associated registry entries have been updated according to the permanent registrations below (see [BCP90]):
このドキュメントでは、次のHTTPヘッダーフィールドを定義しているため、関連するレジストリエントリは、以下の永続的な登録に従って更新されています（[BCP90]を参照）。
+---------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+---------------------+----------+----------+-------------+
| ETag | http | standard | Section 2.3 |
| If-Match | http | standard | Section 3.1 |
| If-Modified-Since | http | standard | Section 3.3 |
| If-None-Match | http | standard | Section 3.2 |
| If-Unmodified-Since | http | standard | Section 3.4 |
| Last-Modified | http | standard | Section 2.2 |
+---------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
変更管理者は、「IETF（iesg@ietf.org）-Internet Engineering Task Force」です。
This section is meant to inform developers, information providers, and users of known security concerns specific to the HTTP conditional request mechanisms. More general security considerations are addressed in HTTP "Message Syntax and Routing" [RFC7230] and "Semantics and Content" [RFC7231].
このセクションは、HTTP条件付き要求メカニズムに固有の既知のセキュリティ問題を開発者、情報プロバイダー、およびユーザーに通知することを目的としています。セキュリティに関するより一般的な考慮事項は、HTTPの「メッセージの構文とルーティング」[RFC7230]および「セマンティクスとコンテンツ」[RFC7231]で対処されています。
The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious changes, or detect man-in-the-middle attacks. At best, they enable more efficient cache updates and optimistic concurrent writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response that is no more harmful than an HTTP exchange without conditional requests.
この仕様で定義されているバリデーターは、表現の有効性を保証したり、悪意のある変更から保護したり、中間者攻撃を検出したりすることを意図していません。せいぜい、すべての参加者が適切に動作しているときに、より効率的なキャッシュ更新と楽観的な同時書き込みが可能になります。最悪の場合、条件は失敗し、クライアントは条件付き要求のないHTTP交換と同じくらい害のない応答を受け取ります。
An entity-tag can be abused in ways that create privacy risks. For example, a site might deliberately construct a semantically invalid entity-tag that is unique to the user or user agent, send it in a cacheable response with a long freshness time, and then read that entity-tag in later conditional requests as a means of re-identifying that user or user agent. Such an identifying tag would become a persistent identifier for as long as the user agent retained the original cache entry. User agents that cache representations ought to ensure that the cache is cleared or replaced whenever the user performs privacy-maintaining actions, such as clearing stored cookies or changing to a private browsing mode.
エンティティタグは、プライバシーリスクを引き起こす方法で悪用される可能性があります。たとえば、サイトはユーザーまたはユーザーエージェントに固有の意味的に無効なエンティティタグを意図的に作成し、それをキャッシュ可能な応答で長い更新時間で送信し、手段として後の条件付きリクエストでそのエンティティタグを読み取ります。そのユーザーまたはユーザーエージェントを再識別します。このような識別タグは、ユーザーエージェントが元のキャッシュエントリを保持している限り、永続的な識別子になります。表現をキャッシュするユーザーエージェントは、ユーザーが保存されたCookieのクリアやプライベートブラウジングモードへの変更などのプライバシーを維持するアクションを実行するたびに、キャッシュがクリアまたは置き換えられるようにする必要があります。
See Section 10 of [RFC7230].
[RFC7230]のセクション10をご覧ください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、2014年6月。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、2014年6月。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.
[RFC7233] Fielding、R。、編、Lafon、Y。、編、およびJ. Reschke、編、「Hypertext Transfer Protocol（HTTP / 1.1）：Range Requests」、RFC 7233、2014年6月。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、June 2014。
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[BCP90] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918] Dusseault、L.、Ed。、「Web Distributed Authoring and Versioning（WebDAV）のHTTP拡張機能」、RFC 4918、2007年6月。
The definition of validator weakness has been expanded and clarified. (Section 2.1)
バリデータの弱点の定義が拡張され、明確になりました。 （セクション2.1）
Weak entity-tags are now allowed in all requests except range requests. (Sections 2.1 and 3.2)
弱いエンティティタグが範囲リクエストを除くすべてのリクエストで許可されるようになりました。 （セクション2.1および3.2）
The ETag header field ABNF has been changed to not use quoted-string, thus avoiding escaping issues. (Section 2.3)
ETagヘッダーフィールドABNFがquoted-stringを使用しないように変更され、エスケープの問題を回避しています。 （セクション2.3）
ETag is defined to provide an entity tag for the selected representation, thereby clarifying what it applies to in various situations (such as a PUT response). (Section 2.3)
ETagは、選択された表現のエンティティタグを提供するために定義され、それにより、さまざまな状況（PUT応答など）に適用されるものを明確にします。 （セクション2.3）
The precedence for evaluation of conditional requests has been defined. (Section 6)
条件付きリクエストの評価の優先順位が定義されました。 （セクション6）
The following core rules are included by reference, as defined in Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).
[RFC5234]の付録B.1で定義されている次のコアルールが参照として含まれています：ALPHA（文字）、CR（キャリッジリターン）、CRLF（CR LF）、CTL（コントロール）、DIGIT（10進数0-9） 、DQUOTE（二重引用符）、HEXDIG（16進数の0-9 / AF / af）、LF（ラインフィード）、OCTET（データの任意の8ビットシーケンス）、SP（スペース）、およびVCHAR（目に見えるUS-ASCII文字） ）。
The rules below are defined in [RFC7230]:
以下のルールは[RFC7230]で定義されています：
OWS = <OWS, see [RFC7230], Section 3.2.3>
obs-text = <obs-text, see [RFC7230], Section 3.2.6>
The rules below are defined in other parts:
以下のルールは他の部分で定義されています：
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
In the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230].
以下の収集されたABNFでは、リストルールが[RFC7230]のセクション1.2に従って拡張されています。
ETag = entity-tag
ETag =エンティティタグ
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) )
If-Modified-Since = HTTP-date
If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) )
If-Unmodified-Since = HTTP-date
Last-Modified = HTTP-date
Last-Modified = HTTP-date
OWS = <OWS, see [RFC7230], Section 3.2.3>
entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text
obs-text = <obs-text, see [RFC7230], Section 3.2.6>
opaque-tag = DQUOTE *etagc DQUOTE
weak = %x57.2F ; W/
Index
索引
3 304 Not Modified (status code) 19
3 304未変更（ステータスコード）19
4 412 Precondition Failed (status code) 18
4 412前提条件の失敗（ステータスコード）18
E ETag header field 9
E ETagヘッダーフィールド9
G Grammar entity-tag 9 ETag 9 etagc 9 If-Match 13 If-Modified-Since 15 If-None-Match 14 If-Unmodified-Since 17 Last-Modified 7 opaque-tag 9 weak 9
G文法エンティティタグ9 ETag 9 etagc 9 If-Match 13 If-Modified-Since 15 If-None-Match 14 If-Unmodified-Since 17 Last-Modified 7不透明タグ9弱い9
I If-Match header field 13 If-Modified-Since header field 16 If-None-Match header field 14 If-Unmodified-Since header field 17
I If-Matchヘッダーフィールド13 If-Modified-Sinceヘッダーフィールド16 If-None-Matchヘッダーフィールド14 If-Unmodified-Sinceヘッダーフィールド17
L Last-Modified header field 7
L Last-Modifiedヘッダーフィールド7
M metadata 5
Mメタデータ5
S selected representation 4
S選択表現4
V validator 5 strong 5 weak 5
Vバリデーター5強い5弱い5
Authors' Addresses
著者のアドレス
Roy T. Fielding (editor) Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA
ロイT.フィールディング（編集者）Adobe Systems Incorporated 345 Park Ave San Jose、CA 95110 USA
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F. Reschke（編集者）greenbytes GmbH Hafenweg 16 Muenster、NW 48155ドイツ
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/