Skip to content

Latest commit

 

History

History
139 lines (79 loc) · 17.7 KB

index.md

File metadata and controls

139 lines (79 loc) · 17.7 KB
Raw
title slug l10n
HTTP 条件付きリクエスト
Web/HTTP/Conditional_requests
sourceCommit
fc577878fa29a23248fba29e14eb67beb54aaaa2

{{HTTPSidebar}}

HTTP には条件付きリクエストの概念があり、対象となるリソースと検証子の値とを比較することで、リクエストの結果や、成功か失敗かまでもが変化することがあります。このようなリクエストは、キャッシュの内容を検証して、無用な制御を避けたり、ダウンロードの再開の時などに文書の整合性を検証したり、サーバー上の文書をアップロードまたは変更するときに更新内容を失うことを避ける場合などに役立つことがあります。

原理

HTTP 条件付きリクエストは、特定のヘッダーの値に応じて異なる処理が行われるリクエストです。これらのヘッダーは前提条件を定義しており、リクエストの結果は前提条件に一致するか否かに応じて変わります。

リクエストで使用したメソッドや前提条件で使用したヘッダー一式によって、さまざまな動作が定義されています。

  • {{glossary("Safe/HTTP", "安全な")}}メソッド、例えば {{HTTPMethod("GET")}} などは、一般に文書を取得するメソッドであり、条件付きリクエストは関連する文書のみを返信するために利用することができます。これによって、帯域を節約します。
  • {{glossary("Safe/HTTP", "安全ではない")}}メソッド、例えば {{HTTPMethod("PUT")}} などは、一般に文書をアップロードするメソッドであり、条件付きリクエストは文書がサーバーに格納されているものと同じものに基づいたものである場合に限ってアップロードするようにするために利用することができます。

検証子

すべての条件ヘッダーは、サーバーに保存されているリソースが特定のバージョンに一致するか確認を試みます。このため、条件付きリクエストではリソースのバージョンを示す必要があります。リソース全体をバイト単位で比較することは不可能であり、常に望まれていることとは限らないので、リクエストはバージョンを記述する値を送信します。このような値は検証子と呼ばれ、二種類があります。

  • 文書が最後に変更された日時である last-modified の日時
  • エンティティタグまたは etag と呼ばれる、各バージョンを一意に識別する不透明な文字列。

同じリソースのバージョンの比較は少々複雑です。状況によって、二種類の確認方法があります。

  • 強い検証 (Strong validation) は、ダウンロードを再開するときなど、バイト単位の同一性が求められる場合に使用します。
  • 弱い検証 (Weak validation) は、ユーザーエージェントが二つのリソースが同じであることを確認することだけが必要である場合に使用します。これは広告の違いやフッターの日付の違いなど、小さな違いがある場合も含みます。

検証の種類と使用される検証子は独立しています。 {{HTTPHeader("Last-Modified")}} と {{HTTPHeader("ETag")}} はどちらの種類の検証もできますが、サーバー側の実装の複雑さは異なります。 HTTP は既定で強い検証を使用し、弱い検証を使用するときはそれを指定します。

強い検証

強い検証は、比較対象のリソースがバイト単位で同一であることを保証します。これは一部の条件ヘッダーで必須、また他のヘッダーでは既定の要件です。強い検証はとても厳密であり、サーバーレベルで保証することが困難である場合もありますが、時には性能を犠牲にしても、データが失われていないことを常に保証します。

{{HTTPHeader("Last-Modified")}} で強い検証のための一意な識別子を持つことは、とても困難です。多くの場合、リソースの MD5 ハッシュ（あるいはその派生物）を持つ {{HTTPHeader("ETag")}} を使用します。

弱い検証

弱い検証は、内容が等価であるなら二つのバージョンの文書が等しいと見なされるという点で、強い検証と異なります。例えばフッターの日付だけ、あるいは広告だけが異なる二つのページは、弱い検証では同一であるとみなされますが、強い検証では異なるものとみなされます。弱い検証を作り出す etag のシステムを構築することは、ページのさまざまな要素の重要性を知ることが伴うため複雑になるかもしれませんが、キャッシュの性能を最適化するためにとても役に立ちます。

条件ヘッダー

条件ヘッダーと呼ばれるいくつかの HTTP ヘッダーが、条件付きリクエストをもたらします。

  • {{HTTPHeader("If-Match")}}
    • : 遠方のリソースの {{HTTPHeader("ETag")}} と、このヘッダーに載せた etag が等しければ成功します。強い検証を行います。
  • {{HTTPHeader("If-None-Match")}}
    • : 遠方のリソースの {{HTTPHeader("ETag")}} と、このヘッダーに載せたそれぞれの etag が異なっていれば成功します。弱い検証を行います。
  • {{HTTPHeader("If-Modified-Since")}}
    • : 遠方のリソースの {{HTTPHeader("Last-Modified")}} の日時が、このヘッダーで指定した日時より新しければ成功します。
  • {{HTTPHeader("If-Unmodified-Since")}}
    • : 遠方のリソースの {{HTTPHeader("Last-Modified")}} の日時が、このヘッダーで指定した日時以前であれば成功します。
  • {{HTTPHeader("If-Range")}}
    • : {{HTTPHeader("If-Match")}} や {{HTTPHeader("If-Unmodified-Since")}} に似ていますが、 etag または日時をひとつしか持つことができません。条件が失敗すると範囲指定リクエストも失敗して、 {{HTTPStatus("206")}} Partial Content レスポンスの代わりに {{HTTPStatus("200")}} OK でリソース全体を送信します。

使用例

キャッシュの更新

条件付きリクエストのもっとも一般的な使用例は、キャッシュの更新です。キャッシュが空である、あるいはキャッシュを使用しない状態では {{HTTPStatus("200")}} OK ステータスと共に、要求したリソースが送信されます。

キャッシュが空のときに発行されたリクエストは、 リソースをダウンロードするきっかけとなり、 両方の検証子の値がヘッダーとして送信されます。その後、キャッシュが満たされます。

リソースと共に、ヘッダーで検証子を送信します。この例では {{HTTPHeader("Last-Modified")}} と {{HTTPHeader("ETag")}} の両方を送信していますが、どちらか一方しか使用しません。これらの検証子はリソースと共に (すべてのヘッダーのように) キャッシュへ保存され、キャッシュが陳腐化したときに条件付きリクエストを作成するために使用します。

キャッシュが陳腐化していなければ、条件付きリクエストは行いません。しかしキャッシュが陳腐化すると主に {{HTTPHeader("Cache-Control")}} ヘッダーに制御されて、クライアントはキャッシュされた値を直接使用せず、{{HTTPHeader("If-Modified-Since")}} または {{HTTPHeader("If-None-Match")}} ヘッダーに検証子の値を指定した条件付きリクエストを発行します。

リソースが変更されていなければ、サーバーは {{HTTPStatus("304")}} Not Modified レスポンスを返します。これはキャッシュを再び新鮮な状態にして、クライアントはキャッシュされたリソースを使用します。これはリソースをいくらか消費するレスポンスとリクエストのやり取りが発生しますが、通信網でリソース全体を再度転送するよりも効率的です。

キャッシュが古くなっている状態では、条件付きのリクエストが送信されます。サーバーは、リソースが変更されたかどうかを判断し、このケースのように、同じものであるため再度送信しないことを決定することができます。

リソースが変更された場合、サーバーは新しいバージョンのリソースを含む {{HTTPStatus("200", "200 OK")}} レスポンスを返します（リクエストが条件付きでなかったかのように）。 クライアントはこの新しいリソースを使用します（そしてキャッシュします）。

リソースが変更された場合には、リクエストが条件付きでなかったかのように送り返されます。

サーバー側で検証子を設定することをを除いて、この仕組みは透過的です。どのブラウザーもウェブ開発者が特別な作業を行うことなく、キャッシュを管理してこのような条件付きリクエストを送信します。

部分ダウンロードの整合性

ファイルの部分ダウンロードは、以前の操作を再開することが可能な HTTP の機能であり、すでに取得済みの情報を保持することによって帯域や時間を節約します。

ダウンロードが停止し、コンテンツの一部しか取得できていない状態です。

部分ダウンロードをサポートするサーバーは、{{HTTPHeader("Accept-Ranges")}} ヘッダーを送信してそのことを知らせます。このヘッダーが送信されると、クライアントは {{HTTPHeader("Ranges")}} ヘッダーで欠落している範囲を送信することで、ダウンロードを再開できます。

クライアントは、自分が必要とする範囲を示し、部分的に取得したリクエストの検証子を前提条件としてチェックすることで、リクエストを再開します。

この原理はシンプルですが、潜在的な問題がひとつあります。2 回のダウンロードの間にリソースが変更されると、取得した範囲が 2 つの異なるバージョンのリソースに対応してしまい、最終的な文書が壊れてしまうでしょう。

これを防ぐため、条件付きリクエストを使用します。範囲についてこれを行うための方法が 2 つあります。より柔軟な方法は {{HTTPHeader("If-Modified-Since")}} と {{HTTPHeader("If-Match")}} を使用することであり、前提条件に合わない場合はサーバーがエラーを返します。すると、クライアントはダウンロードを始めから再実行します。

部分的にダウンロードされたリソースが変更された場合、前提条件が満たされず、リソースを完全にダウンロードし直さなければなりません。

この方法でも動作しますが、文書が変更されると余分なレスポンスやリクエストの交換が発生します。これはパフォーマンスを低下させますので HTTP には、この問題を避けるために特化した追加ヘッダーである {{HTTPHeader("If-Range")}} があります。

If-Range ヘッダーを使用すると、リソースが変更されている場合、サーバは直接完全なリソースを送り返すことができ、 412 エラーを送信してクライアントが再度ダウンロードを開始するのを待つ必要がありません。

この解決策はより効率的ですが、柔軟性が若干劣ります（条件で etag をひとつしか使用できません）。ただし、これ以上の柔軟性はほとんど必要ありません。

楽観的ロックで更新が失われる問題を避ける

リモートの文書の更新は、ウェブアプリケーションで一般的な操作です。これはファイルシステムやソース管理アプリケーションではごく一般的ですが、リモートにリソースを保存できるようにするにはこのような仕組みが必要です。同様に、wiki のような一般的なウェブサイトや他の CMS でも必要です。

{{HTTPMethod("PUT")}} を使用して、この機能を実装できます。クライアントは始めに元のファイルを読み込んで、変更した後にサーバーへ送信します。

PUT によるファイルの更新は、並行処理ない場合はとても簡単です。

残念ながら、並行処理を考慮すると若干の間違いが出てきます。あるクライアントがリソースの新たな複製をローカルで変更している間に、第二のクライアントが同じリソースを取得して、クライアント側で同じことを行えます。これにより、とても不幸なことが発生します。両者がリソースを引き渡すと、最初のクライアントが渡した変更点が次に渡されたものによって破棄されて、第二のクライアントは新たな変更点に気づきません。誰が勝ち取ったかの結果は他者には伝わりませんが、どのクライアントの変更点が反映されるかは引き渡す速度によって変わります。またその速度はクライアントやサーバーのパフォーマンス、さらにはクライアント側で人間が文書を編集するパフォーマンスに依存します。勝ち取る者は、その時々で変わります。これは競合状態であり、検出やデバッグが難しい不確かな動作をもたらします。

複数のクライアントが同じリソースを並行して更新していると、競合状態に陥ってしまいます。問題ですね。

2 つのクライアントの片方を困らせることなく、この問題に対処する方法はありません。しかし、更新が失われたりや競合状態になったりすることは避けるべきです。予測可能な結果や、クライアントが変更点を却下されたときに通知を受けることを望みます。

条件付きリクエストで、楽観的ロックアルゴリズム （ほとんどの wiki やソース管理システムで使用されています）を実装できます。この考え方ではすべてのクライアントに、リソースの複製の取得を許可してローカルで変更することを許可します。そして、最初のクライアントが更新内容を送信することを許可して成功させて、以降の古いバージョンになったリソースに基づく更新は拒否します。

条件付きリクエストにより、楽観的なロックを実装することができます。

これは {{HTTPHeader("If-Match")}} および {{HTTPHeader("If-Unmodified-Since")}} ヘッダーを使用して実装します。etag が元のファイルと一致しない、あるいはファイルが取得したときから変更されている場合は、変更点が {{HTTPStatus("412")}} Precondition Failed エラーで拒否されます。このエラーへの対処はクライアント次第であり、今度は最新のバージョンで再び実行するよう人間に通知する、あるいは diff を表示して変更点を維持するかを人間が選択できるように支援します。

リソースの最初のアップロードに対処する

リソースの最初のアップロードは、前述の状況の特別なケースです。リソースの更新と同様に、2 つのクライアントが同時 (あるいはほぼ同時) にアップロードしようとする競合状態を仮定します。これを防ぐために条件付きリクエストを使用できます。すべての etag を表す特別な値 '*' を持つ {{HTTPHeader("If-None-Match")}} を追加することで、それより前のリクエストが存在しない場合に限り、リクエストが成功します。

通常のアップロードと同様に、リソースの最初のアップロードには競合状態が発生します。 If-None-Match で防ぐことができます。

If-None-Match は HTTP/1.1 （およびそれ以降）に準拠するサーバーのみで動作します。サーバーが対応しているかが不明である場合は、始めに確認用の {{HTTPMethod("HEAD")}} リクエストをリソースに対して発行しなければなりません。

まとめ

条件付きリクエストは HTTP の重要な機能であり、効率的で複雑なアプリケーションの構築を可能にします。キャッシュやダウンロードの再開について、ウェブマスターに求められる作業はサーバーを適切に設定することだけです (一部の環境では正しい etag を設定することが難しいかもしれません)。また、ブラウザーが適切な条件付きリクエストを実行しますので、ウェブ開発者に求められる作業はありません

一方、ロックの仕組みでは、ウェブ開発者が適切なヘッダーを伴ってリクエストを発行しなければなりません。ウェブマスターはほとんどの場合、それらの確認をアプリケーションに頼ることができるでしょう。

どちらにせよ、条件付きリクエストはウェブの重要な機能であることは明らかです。