不透明な応答 は Fetch API の一部として定義され、 CORS がそうでない場合にリモートOriginに対して行われたリクエストの結果を表します有効。
JavaScriptからもページ上のリソースとしても、不透明な応答をどのように使用できるかについて、実際的な制限と「落とし穴」は何ですか?
不透明な応答のヘッダー/ボディへのアクセス
不透明な応答に関する最も簡単な制限は、 Response
などのheaders
クラスのほとんどの プロパティ から意味のある情報を取得できないこと、またはBody
を構成するさまざまな メソッド を呼び出せないことです json()
や text()
のようなインターフェイス。これは、不透明な応答のブラックボックスの性質と一致しています。
不透明な応答をページ上のリソースとして使用する
ブラウザが非CORSクロスオリジンリソースの使用を許可する場合はいつでも、不透明な応答をWebページ上のリソースとして使用できます。以下は、 Mozilla Developer Networkのドキュメント から変更された、非CORSクロスオリジンリソース、したがって不透明な応答が有効な要素のサブセットです。
<script>
<link rel="stylesheet">
<img>
、<video>
、および<audio>
<object>
および<embed>
<iframe>
不透明な応答がnot有効である注目すべき使用例は、 フォントリソース です。
一般に、ページ上の特定の種類のリソースとして不透明な応答を使用できるかどうかを判断するには、関連する仕様を確認します。たとえば、HTML仕様の では、 以外のクロスオリジン(不透明)応答を<script>
要素に使用できることを説明していますが、エラー情報の漏洩を防ぐための制限があります。
不透明な応答とキャッシュストレージAPI
開発者 が不透明な応答で に遭遇する可能性のある「落とし穴」には、 Cache Storage API でそれらを使用することが含まれます。 2つの背景情報が関連しています。
status
プロパティは、元の要求が成功したか失敗したかに関係なく、 常に常に0
に設定されます。add()
/ addAll()
メソッドは、いずれかの要求からの応答に 2XX範囲 以外のステータスコードがある場合、両方とも拒否します。これらの2つの点から、add()
/addAll()
呼び出しの一部として実行された要求が不透明な応答になった場合、キャッシュへの追加に失敗することになります。
この問題を回避するには、明示的にfetch()
を実行してから、不透明な応答で put()
メソッドを呼び出します。そうすることで、キャッシュしている応答がサーバーから返されたエラーである可能性があるというリスクに効果的にオプトインします。
const request = new Request('https://third-party-no-cors.com/', {mode: 'no-cors'});
// Assume `cache` is an open instance of the Cache class.
fetch(request).then(response => cache.put(request, response));
不透明なレスポンスとnavigator.storage API
クロスドメイン情報の漏洩を避けるために、ストレージクォータ制限の計算に使用される不透明な応答のサイズに追加された重要なパディングがあり(つまり、QuotaExceeded
例外がスローされるかどうか)、 navigator.storage
API によって報告されます。
このパディングの詳細はブラウザごとに異なりますが、Google Chromeの場合、これは単一のキャッシュされた不透明な応答がストレージ全体の使用に寄与するminimumサイズがおよそ であることを意味します7メガバイト 。キャッシュする不透明な応答の数を決定するときは、不透明なリソースの実際のサイズに基づいて予想されるよりもはるかに早くストレージクォータの制限を簡単に超えてしまう可能性があるため、これに留意する必要があります。