web-dev-qa-db-ja.com

応答が404の場合、Service Workerを使用してクロスドメインリソースをキャッシュする方法は？

w3：

6.2クロスオリジンリソースとCORS¶
アプリケーションは、CDNまたは他のオリジンからのアイテムをキャッシュする傾向があります。 <script>, <img>, <video>および<link>要素を使用して、それらの多くを直接要求することができます。この種のランタイムコラボレーションがオフラインで壊れた場合、それは非常に制限されます。同様に、適切なCORSヘッダーが設定されている場合、さまざまな種類のオフオリジンリソースをXHRすることができます。

ServiceWorkersは、キャッシュがオフオリジンアイテムをフェッチしてキャッシュできるようにすることでこれを可能にします。ただし、いくつかの制限が適用されます。まず、type属性が「basic」に設定されたResponseオブジェクトとしてキャッシュで管理される同一生成元リソースとは異なり、格納されるオブジェクトは、type属性が「opaque」に設定されたResponseオブジェクトです。 「不透明」と入力された応答は、「基本」と入力された応答よりも表現力の低いAPIを提供します。本文とヘッダーを読み取ったり設定したりすることはできません。また、コンテンツの他の多くの側面を検査することもできません。これらは、「基本」と入力された応答と同じ方法でevent.respondWith（r）メソッドに渡すことができますが、プログラムで意味のある方法で作成することはできません。これらの制限は、プラットフォームのセキュリティ不変条件を維持するために必要です。キャッシュにそれらを保存できるようにすると、ほとんどの場合、アプリケーションは再設計を回避できます。

CORSヘッダーを次のように設定しました：

Access-Control-Allow-Origin:https://xxx.xx.x.com
Access-Control-Allow-Credentials:true

しかし、それでも「不透明な」応答が返され、コードが200であることを確認できません。これらの失敗した応答をキャッシュすると、問題が発生します。

たとえば、ネットワークのチャムによってクロスドメインリソースに404が発生し、それをキャッシュすると、ネットワークの問題が修正された場合でも、常にこの404キャッシュ応答を使用します。同一生成元リソースにはこの問題はありません。

javascriptcachingcross-domainservice-worker
9
abu

modeのRequest（伝えられるところでは） デフォルトは_"no-cors"_ 。 （fetch()で使用される暗黙的に作成されたRequestがCORS対応のResponseになる状況を見たと思うので、「疑わしい」と言います。）

したがって、サーバーがCORSをサポートしていることがわかっている場合は、CORSにオプトインすることを明示する必要があります。

_var corsRequest = new Request(url, {mode: 'cors'});
fetch(corsRequest).then(response => ...); // response won't be opaque.
_

適切に構成されたリモートサーバーが与えられると、CORS対応のRequestは、 Response of _"cors"_ を持つtypeになります。 _"opaque"_ Responseとは異なり、_"cors"_ Responseは、基になるstatus、bodyなどを公開します。

9
Jeff Posnick

残念ながら、それを検出する方法はありません。

セキュリティ上の理由から、明示的に許可されていません： https://github.com/whatwg/fetch/issues/14 。

0
Marco