このページは Cloud Translation API によって翻訳されました。

Service Worker で範囲リクエストを処理する

部分レスポンスをリクエストされたときにサービスワーカーが何をすべきかを認識するようにします。

Jeff Posnick

一部の HTTP リクエストには Range: ヘッダーが含まれており、リソース全体の一部のみを返す必要があることを示しています。通常、音声または動画コンテンツのストリーミングに使用され、リモートファイル全体を一度にリクエストするのではなく、小さなチャンクのメディアをオンデマンドで読み込むことができます。

Service Worker は、ウェブアプリとネットワークの間に存在する JavaScript コードで、送信されるネットワークリクエストをインターセプトしてレスポンスを生成する可能性があります。

これまで、範囲リクエストとサービスワーカーはうまく連携していませんでした。サービスワーカーで望ましくない結果を回避するために、特別な手順を講じる必要がありました。幸い、この状況は変わりつつあります。正しい動作を示すブラウザでは、範囲リクエストはサービスワーカーを通過すると「正常に機能」します。

問題の詳細について教えてください

次の fetch イベントリスナーを使用するサービスワーカーについて考えてみましょう。このリスナーは、受信したすべてのリクエストをネットワークに渡します。

self.addEventListener('fetch', (event) => {
  // The Range: header will not pass through in
  // browsers that behave incorrectly.
  event.respondWith(fetch(event.request));
});

注: このような単純な fetch イベントリスナーは通常は使用しないでください。ここでは説明を目的として使用しています。

動作が正しくないブラウザでは、event.request に Range: ヘッダーが含まれている場合、そのヘッダーは自動的に破棄されます。リモートサーバーが受信したリクエストには Range: は含まれません。元のリクエストに Range: ヘッダーが存在する場合でも、サーバーは技術的には、200 ステータスコードとともに完全なレスポンス本文を返すことができるため、必ずしも「破損」するわけではありません。ただし、ブラウザの観点から厳密に必要な量よりも多くのデータが転送されることになります。

この動作を認識していたデベロッパーは、Range: ヘッダーの存在を明示的に確認し、存在する場合は event.respondWith() を呼び出さないことで、この問題を回避できました。これにより、サービスワーカーはレスポンス生成の絵から実質的に削除され、代わりに、範囲リクエストを保持する方法を知っているデフォルトのブラウザネットワーキングロジックが使用されます。

self.addEventListener('fetch', (event) => {
  // Return without calling event.respondWith()
  // if this is a range request.
  if (event.request.headers.has('range')) {
    return;
  }

  event.respondWith(fetch(event.request));
});

ただし、ほとんどのデベロッパーは、この必要性に気付いていなかったと推測されます。また、その理由も明確ではありませんでした。最終的に、この制限は、ブラウザが基盤となる仕様の変更に追いつく必要があったためでした。この仕様の変更により、この機能のサポートが追加されました。

修正内容

正しく動作するブラウザでは、event.request が fetch() に渡されたときに Range: ヘッダーが保持されます。つまり、最初の例のサービスワーカーコードでは、ブラウザによって設定された Range: ヘッダーをリモートサーバーが確認できるようになります。

self.addEventListener('fetch', (event) => {
  // The Range: header will pass through in browsers
  // that behave correctly.
  event.respondWith(fetch(event.request));
});

これで、サーバーは範囲リクエストを適切に処理し、206 ステータスコードで部分レスポンスを返すことができます。

どのブラウザが正しく動作しますか？

最新バージョンの Safari では、正しい機能が備わっています。Chrome と Edge（バージョン 87 以降）も正しく動作します。

2020 年 10 月現在、Firefox ではこの動作はまだ修正されていないため、サービスワーカーのコードを実運用環境にデプロイする際に、この動作を考慮する必要があります。

特定のブラウザでこの動作が修正されているかどうかを確認するには、ウェブプラットフォームテストダッシュボードの [ネットワークリクエストに範囲ヘッダーを含める] 行を確認するのが最適です。

範囲リクエストをキャッシュから提供する場合はどうなりますか？

Service Worker は、リクエストをネットワークに渡すだけでなく、さまざまなことができます。一般的なユースケースは、音声ファイルや動画ファイルなどのリソースをローカルキャッシュに追加することです。Service Worker は、そのキャッシュからリクエストを処理し、ネットワークを完全にバイパスできます。

Firefox を含むすべてのブラウザは、fetch ハンドラ内のリクエストの検査、Range: ヘッダーの存在の確認、キャッシュから取得した 206 レスポンスによるローカルでのリクエストの処理をサポートしています。ただし、Range: ヘッダーを適切に解析し、キャッシュに保存された完全なレスポンスの適切なセグメントのみを返すサービスワーカーコードは簡単ではありません。

幸い、デベロッパーがサポートを必要としている場合は、Workbox を利用できます。これは、一般的なサービスワーカーのユースケースを簡素化する一連のライブラリです。workbox-range-request module は、キャッシュから部分レスポンスを直接提供するのに必要なすべてのロジックを実装します。このユースケースの完全なレシピについては、Workbox のドキュメントをご覧ください。

この投稿のヒーロー画像は、Unsplash の Natalie Rhea Riggs によるものです。