サービスワーカー/ fetch（）でHTTP 304を認識

Question

サービスワーカーを構築し、常にキャッシュからのデータで応答し、バックグラウンドでサーバーに要求を送信します。サーバーがHTTP 304 - not modifiedで応答する場合、サーバーがHTTP 200と応答すると、データが変更され、新しいファイルがキャッシュに入れられ、ユーザーに通知されてページの更新が求められます。

私はnot-modified-since/last-modifiedヘッダーを使用して、クライアントが最新のバージョンを取得していることを確認します。 fetch()を介して要求が送信されると、HTTPキャッシュがネットワークに渡されます。また、HTTPキャッシュがクライアントに到着したときにHTTPキャッシュが渡されます。問題は、応答がステータスが304で、HTTPキャッシュがキャッシュされたバージョンのサービスワーカーに応答し、ステータスが200（fetch specification - HTTP-network-or-cache-fetchに記載されている）に変更された場合に発生します。サービスワーカーでは、200応答が最初にサーバーによって送信された（ユーザーが更新する必要がある）か、キャッシュによって送信されたか、サーバーが最初に304（最新のもの）で応答したかどうかを調べることはできませんバージョンは既にロードされています）。

if-modified-sinceヘッダが設定され、サーバが見つけるためにチャンスを持っていないされていないことを意味し、no-cacheに設定されますが、要求がサーバーに送信されたときに、これはまた、HTTPキャッシュをバイパスすることができますcache-mode flagがありますクライアントのバージョンです。また、このフラグは、今夜は夜間にはFirefoxでのみサポートされています。

サーバーが200と応答すると、x-was-modifiedのようなカスタムHTTPヘッダーを設定することをお勧めします。このカスタムヘッダーはサービスワーカーでアクセスすることができ、リソースが更新されたかどうかを確認するために使用できます。たとえHTTPキャッシュが200のステータスを304に置き換えたとしてもです。

これは正当な解決策ですか？回避策ですか？この問題を解決するための提案されたアプローチはありますか？

サービスワーカーキャッシュを実装するときにHTTPキャッシュを処理するHTTPヘッダーに依存する必要がありますか？あるいは、カスタムx-if-modified-since/x-last-modifiedヘッダーを使用し、indexedDBを使用してクライアントに情報を保存し、それを各要求に追加する必要がありますか？

fetch()は、最新のバージョンがキャッシュにある場合、200のコードを304に置き換えるのはなぜですか？

Answer 1

何かが変更されたかどうかを判断するために、ステータスコード（304対200）に頼ることはできません。コードの他の部分が同じリソースを要求し、ブラウザのキャッシュを更新するとどうなりますか？

代わりに、応答のLast-ModifiedヘッダーをIf-Modified-Sinceで送信したもの、または最後に見たものをLast-Modifiedで比較してください。値が一致しない場合、何かが変更されています。

さらに精度を上げるには（データが1秒間に何回か変更される可能性がある場合）、Last-Modifiedの代わりにETagを使用することを検討してください。

、キャッシュ内の最新バージョンがある場合は、なぜfetch()でも200で304コードを置き換えるのでしょうか？

通常、人々はどこから来たのかに関わらず、新鮮なコンテンツを取得したいと考えているからです。 304レスポンスは、独自のHTTPキャッシュを実装する人にとって興味深いだけです。