FetchEvent.respondWith()

Firefox 59 以降、サービスワーカーが FetchEvent.respondWith() に Response を提供すると、Response.url 値は最終的に解決された URL として、ネットワークリクエストに介入する際に伝搬されるようになりました。Response.url 値が空文字列の場合は、FetchEvent.request.url が最終的な URL として使用されます。

かつては FetchEvent.request.url がすべての場合に最終 URL として使われていました。与えられた Response.url は実際には無視されていました。

つまり、例えば、サービスワーカーがスタイルシートやワーカースクリプトに介入すると、与えられた Response.url が、サブリソースが読み込む相対的な @import や importScripts() の代わりに使われます (Firefox バグ 1222008)。

たいていのネットワークリクエストに対して、最終 URL を観測できないためこの変更は影響ありません。しかし、少しだけ関係する場合があります。

• fetch() が介入された場合、結果の Response.url で最終 URL を観測できます。
• ワーカースクリプトが介入された場合、最終 URL は self.location をセットするのに使われ、ワーカースクリプトの相対 URL の代わりのベース URL として使われます。
• スタイルシートが介入された場合、最終 URL は相対的な @import 読み込みの代わりのベース URL として使われます。

Window と iframe のナビゲーションリクエストはこの最終 URL を使わ「ない」ことに注意してください。HTML 仕様のナビゲーションのリダイレクトの処理方法では、Window.location のためにリクエスト URL を使います。これは、オフラインの時に、ユーザーに見える URL を変更することなくサイトが「代替の」ウェブページを提供できるということを意味します。

response

Response または Response に解決される Promise。それ以外の場合は、ネットワークエラーがフェッチ元に返されます。

なし (undefined)。

NetworkError DOMException

上記の「グローバルルール」にヒントがあるように、ネットワークエラーは FetchEvent.request.mode と Response.type の値の組み合わせで起動されます。

InvalidStateError DOMException

イベントが配信されていないか、respondWith() が既に呼び出されています。

この fetch イベントはキャッシュ API からのレスポンスを返そうとし、ない場合にはネットワークにフォールバックします。

addEventListener("fetch", (event) => {
  // 既定の動作を抑止し、リクエストを自分で処理します。
  event.respondWith(
    (async () => {
      // キャッシュからレスポンスを取得しようとします。
      const cachedResponse = await caches.match(event.request);
      // 見つかったらそれを返します。
      if (cachedResponse) return cachedResponse;
      // キャッシュ内に一致するものが見つからなかった場合は、ネットワークを使用します。
      return fetch(event.request);
    })(),
  );
});

• サービスワーカーの使用
• Is ServiceWorker ready?（英語）
• Promise
• フェッチ API