[解決済み] CORSプリフライトキャッシュをドメイン全体に適用する方法

質問

CORS を使用する REST アプリケーションを構築しています。すべての REST 呼び出しは異なっており、プリフライト OPTIONS 呼び出しを取得する際にかなりのオーバーヘッドがあることが分かっています。同じドメインへの後続の呼び出しがキャッシュされた応答を使用するように、プリフライト OPTIONS の結果をキャッシュして適用する方法はありますか？

どのように解決するのですか?

プリフライトはリクエストにのみ適用でき、ドメイン全体には適用できません。同じ質問をメーリングリストに持ち込んだところ、セキュリティ上の懸念がありました。以下はそのスレッド全体です。 http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0228.html

プリフライト要求の回数を制限したい場合、考慮すべき点がいくつかあります。まず、WebKit/Blink ベースのブラウザでは、プリフライト キャッシュの最大値が 10 分に設定されていることに注意してください。

https://github.com/WebKit/webkit/blob/master/Source/WebCore/loader/CrossOriginPreflightResultCache.cpp https://chromium.googlesource.com/chromium/blink/+/master/Source/core/loader/CrossOriginPreflightResultCache.cpp

(となっています（他のブラウザでもそうなのかはわかりません）。そのため、Access-Control-Max-Age ヘッダは常に設定する必要がありますが、最大値は 10 分です。

次に、PUT/DELETE リクエストのプリフライトを回避することは不可能であることに注意してください。そのため、API の更新/削除には、少なくとも 10 分ごとに 1 回のプリフライトが必要になります。

GET/POSTでは、カスタムヘッダは可能な限り避けてください。APIがJSONを返す場合、Content-Typeが'application/json'の場合もプリフライトをトリガーすることに注意してください。

もし、あなたのAPIがどれだけRESTfulであるかを曲げたいのであれば、さらにいくつかのことを試してみることができます。1 つは、「text/plain」のようなプリフライトを必要としない Content-Type を使用することです。カスタムヘッダは常にプリフライトを引き起こすので、もしカスタムヘッダがあるなら、それをクエリパラメータに移動させることができます。極端な話、JSON-RPC のようなプロトコルを使用して、すべてのリクエストを単一のエンドポイントに送信することもできます。

正直なところ、ブラウザのプリフライトキャッシュの上限は 10 分で、REST のリソース URL のため、プリフライトキャッシュはかなり役に立ちません。長い間実行されるアプリのコースでプリフライトを制限するためにできることはほとんどありません。CORS 仕様の作成者が将来的にこれに対処しようとすることを期待しています。