2023/07/19 時点の英語版に同期

files/ja/web/http/conditional_requests/index.md

@@ -1,6 +1,8 @@
 ---
 title: HTTP 条件付きリクエスト
 slug: Web/HTTP/Conditional_requests
+l10n:
+  sourceCommit: fc577878fa29a23248fba29e14eb67beb54aaaa2
 ---
 
 {{HTTPSidebar}}
@@ -13,8 +15,8 @@ HTTP 条件付きリクエストは、特定のヘッダーの値に応じて異
 
 リクエストで使用したメソッドや前提条件で使用したヘッダー一式によって、さまざまな動作が定義されています。
 
-- {{HTTPMethod("GET")}} などの{{glossary("safe", "安全な")}}メソッドは、一般に文書を取得するメソッドであり、条件付きリクエストは関連する文書のみを返信するために利用することができます。これによって、帯域を節約します。
-- {{HTTPMethod("PUT")}} などの{{glossary("safe", "安全ではない")}}メソッドは、一般に文書をアップロードするメソッドであり、条件付きリクエストは文書がサーバーに格納されているものと同じものに基づいたものである場合に限ってアップロードするようにするために利用することができます。
+- {{glossary("Safe/HTTP", "安全な")}}メソッド、例えば {{HTTPMethod("GET")}} などは、一般に文書を取得するメソッドであり、条件付きリクエストは関連する文書のみを返信するために利用することができます。これによって、帯域を節約します。
+- {{glossary("Safe/HTTP", "安全ではない")}}メソッド、例えば {{HTTPMethod("PUT")}} などは、一般に文書をアップロードするメソッドであり、条件付きリクエストは文書がサーバーに格納されているものと同じものに基づいたものである場合に限ってアップロードするようにするために利用することができます。
 
 ## 検証子
 
@@ -34,7 +36,7 @@ HTTP 条件付きリクエストは、特定のヘッダーの値に応じて異
 
 強い検証は、比較対象のリソースがバイト単位で同一であることを保証します。これは一部の条件ヘッダーで必須、また他のヘッダーでは既定の要件です。強い検証はとても厳密であり、サーバーレベルで保証することが困難である場合もありますが、時には性能を犠牲にしても、データが失われていないことを常に保証します。
 
-{{HTTPHeader("Last-Modified")}} で強い検証のための一意な識別子を持つことは、とても困難です。多くの場合、リソースの MD5 ハッシュ (あるいはその派生物) を持つ {{HTTPHeader("ETag")}} を使用します。
+{{HTTPHeader("Last-Modified")}} で強い検証のための一意な識別子を持つことは、とても困難です。多くの場合、リソースの MD5 ハッシュ（あるいはその派生物）を持つ {{HTTPHeader("ETag")}} を使用します。
 
 ### 弱い検証
 
@@ -45,13 +47,13 @@ HTTP 条件付きリクエストは、特定のヘッダーの値に応じて異
 条件ヘッダーと呼ばれるいくつかの HTTP ヘッダーが、条件付きリクエストをもたらします。
 
 - {{HTTPHeader("If-Match")}}
-  - : 遠方のリソースの {{HTTPHeader("ETag")}} と、このヘッダーに載せた etag が等しければ成功します。既定では etag に接頭辞 `'W/'` がついていない限り、強い検証を行います。
+  - : 遠方のリソースの {{HTTPHeader("ETag")}} と、このヘッダーに載せた etag が等しければ成功します。強い検証を行います。
 - {{HTTPHeader("If-None-Match")}}
-  - : 遠方のリソースの {{HTTPHeader("ETag")}} と、このヘッダーに載せたそれぞれの etag が異なっていれば成功します。既定では etag に接頭辞 `'W/'` がついていない限り、強い検証を行います。
+  - : 遠方のリソースの {{HTTPHeader("ETag")}} と、このヘッダーに載せたそれぞれの etag が異なっていれば成功します。弱い検証を行います。
 - {{HTTPHeader("If-Modified-Since")}}
   - : 遠方のリソースの {{HTTPHeader("Last-Modified")}} の日時が、このヘッダーで指定した日時より新しければ成功します。
 - {{HTTPHeader("If-Unmodified-Since")}}
-  - : 遠方のリソースの {{HTTPHeader("Last-Modified")}} の日時が、このヘッダーで指定した日時より過去または同一であれば成功します。
+  - : 遠方のリソースの {{HTTPHeader("Last-Modified")}} の日時が、このヘッダーで指定した日時以前であれば成功します。
 - {{HTTPHeader("If-Range")}}
   - : {{HTTPHeader("If-Match")}} や {{HTTPHeader("If-Unmodified-Since")}} に似ていますが、 etag または日時をひとつしか持つことができません。条件が失敗すると範囲指定リクエストも失敗して、 {{HTTPStatus("206")}} `Partial Content` レスポンスの代わりに {{HTTPStatus("200")}} `OK` でリソース全体を送信します。
 
@@ -65,13 +67,14 @@ HTTP 条件付きリクエストは、特定のヘッダーの値に応じて異
 
 リソースと共に、ヘッダーで検証子を送信します。この例では {{HTTPHeader("Last-Modified")}} と {{HTTPHeader("ETag")}} の両方を送信していますが、どちらか一方しか使用しません。これらの検証子はリソースと共に (すべてのヘッダーのように) キャッシュへ保存され、キャッシュが陳腐化したときに条件付きリクエストを作成するために使用します。
 
-キャッシュが陳腐化していなければ、条件付きリクエストは行いません。しかしキャッシュが陳腐化すると主に {{HTTPHeader("Cache-Control")}} ヘッダーに制御されて、クライアントはキャッシュされた値を直接使用せず、{{HTTPHeader("If-Modified-Since")}} または {{HTTPHeader("If-Match")}} ヘッダーに検証子の値を指定した*条件付きリクエスト*を発行します。
+キャッシュが陳腐化していなければ、条件付きリクエストは行いません。しかしキャッシュが陳腐化すると主に {{HTTPHeader("Cache-Control")}} ヘッダーに制御されて、クライアントはキャッシュされた値を直接使用せず、{{HTTPHeader("If-Modified-Since")}} または {{HTTPHeader("If-None-Match")}} ヘッダーに検証子の値を指定した*条件付きリクエスト*を発行します。
 
 リソースが変更されていなければ、サーバーは {{HTTPStatus("304")}} `Not Modified` レスポンスを返します。これはキャッシュを再び新鮮な状態にして、クライアントはキャッシュされたリソースを使用します。これはリソースをいくらか消費するレスポンスとリクエストのやり取りが発生しますが、通信網でリソース全体を再度転送するよりも効率的です。
 
 ![キャッシュが古くなっている状態では、条件付きのリクエストが送信されます。サーバーは、リソースが変更されたかどうかを判断し、このケースのように、同じものであるため再度送信しないことを決定することができます。](httpcache2.png)
 
-リソースが変更された場合は、サーバーは条件付きではないリクエストと同様に {{HTTPStatus("200")}} `OK` レスポンスで新しいバージョンのリソースを送信します。そして、クライアントは新しいリソースを使用します (また、それをキャッシュします)。
+リソースが変更された場合、サーバーは新しいバージョンのリソースを含む {{HTTPStatus("200", "200 OK")}} レスポンスを返します（リクエストが条件付きでなかったかのように）。
+クライアントはこの新しいリソースを使用します（そしてキャッシュします）。
 
 ![リソースが変更された場合には、リクエストが条件付きでなかったかのように送り返されます。](httpcache3.png)
 
@@ -97,7 +100,7 @@ HTTP 条件付きリクエストは、特定のヘッダーの値に応じて異
 
 ![If-Range ヘッダーを使用すると、リソースが変更されている場合、サーバは直接完全なリソースを送り返すことができ、 412 エラーを送信してクライアントが再度ダウンロードを開始するのを待つ必要がありません。](httpresume4.png)
 
-この解決策はより効率的ですが、柔軟性が若干劣ります (条件で etag をひとつしか使用できません)。ただし、これ以上の柔軟性はほとんど必要ありません。
+この解決策はより効率的ですが、柔軟性が若干劣ります（条件で etag をひとつしか使用できません）。ただし、これ以上の柔軟性はほとんど必要ありません。
 
 ### 楽観的ロックで更新が失われる問題を避ける
 
@@ -113,7 +116,7 @@ HTTP 条件付きリクエストは、特定のヘッダーの値に応じて異
 
 2 つのクライアントの片方を困らせることなく、この問題に対処する方法はありません。しかし、更新が失われたりや競合状態になったりすることは避けるべきです。予測可能な結果や、クライアントが変更点を却下されたときに通知を受けることを望みます。
 
-条件付きリクエストで、_楽観的ロックアルゴリズム_ (ほとんどの wiki やソース管理システムで使用されています) を実装できます。この考え方ではすべてのクライアントに、リソースの複製の取得を許可してローカルで変更することを許可します。そして、最初のクライアントが更新内容を送信することを許可して成功させて、以降の古いバージョンになったリソースに基づく更新は拒否します。
+条件付きリクエストで、_楽観的ロックアルゴリズム_ （ほとんどの wiki やソース管理システムで使用されています）を実装できます。この考え方ではすべてのクライアントに、リソースの複製の取得を許可してローカルで変更することを許可します。そして、最初のクライアントが更新内容を送信することを許可して成功させて、以降の古いバージョンになったリソースに基づく更新は拒否します。
 
 ![条件付きリクエストにより、楽観的なロックを実装することができます。](httplock3.png)
 
@@ -125,7 +128,7 @@ HTTP 条件付きリクエストは、特定のヘッダーの値に応じて異
 
 ![通常のアップロードと同様に、リソースの最初のアップロードには競合状態が発生します。 If-None-Match で防ぐことができます。](httpfirst.png)
 
-`If-None-Match` は HTTP/1.1 (およびそれ以降) に準拠するサーバーのみで動作します。サーバーが対応しているかが不明である場合は、始めに確認用の {{HTTPMethod("HEAD")}} リクエストをリソースに対して発行しなければなりません。
+`If-None-Match` は HTTP/1.1 （およびそれ以降）に準拠するサーバーのみで動作します。サーバーが対応しているかが不明である場合は、始めに確認用の {{HTTPMethod("HEAD")}} リクエストをリソースに対して発行しなければなりません。
 
 ## まとめ