可能な範囲で確認してみました。pjaxがHTMLを取得する際の挙動が、Service Worker側でHTMLの取得と判定されないことが原因かと見受けられます。
こちらでは動作確認していませんが、先に解決策を示しますと、次のようなコードで対処できるのではと存じます。
js
1$(document).on('pjax:beforeSend', function(event, xhr, settings) {
2 xhr.setRequestHeader('Accept', 'text/html');
3});
参考: Append Data to PJAX Request
以下、参考までに、詳細な原因究明です。
まず、Service Workerのコードから、キャッシュから読むかダウンロードするかどうかを判定している箇所を抜き出してみます。
js
1 //For HTML requests, look for file in network, then cache if network fails.
2 if (event.request.headers.get('Accept').indexOf('text/html') != -1) {
3 event.respondWith(fetch(event.request).then(fetchFromNetwork, fallback));
4 return;
5 }
6
7 //For non-HTML requests, look for file in cache, then network if no cache exists.
8 event.respondWith(
9 caches.match(event.request).then(function(cached) {
10 return cached || fetch(event.request).then(fetchFromNetwork, fallback);
11 })
12)
こちらによると、
- For HTML requests: HTTPリクエストの
Accept
ヘッダの値がtext/html
であれば、まずネットワークからダウンロードし、失敗した場合はキャッシュから読み込む
- For non-HTML requests:
Accept
ヘッダがtext/html
でなければ、キャッシュに保存されていればそれを読み込み、なければネットワークからダウンロード
といったロジックになっています。
一方、pjaxでは、遷移先のHTMLをXMLHttpRequestでダウンロードするように実装されていますが、XMLHttpRequestではAccept
ヘッダのデフォルト値が*/*
となっています。よって、Service Worker側で「For non-HTML requests」として扱われてしまい、キャッシュに保存されていればそこから読み込む、といった動作が選択されてしまいます。
以上が、今回の現象の原因と考えられます。よって、解決策は、pjaxがXMLHttpRequestでHTMLをダウンロードする際に、Accept
ヘッダの値をtext/html
とするよう設定すること、となります。