CORS を利用する REST アプリケーションを構築しています。すべての REST 呼び出しは異なり、プリフライト OPTIONS 呼び出しを取得する際にかなりのオーバーヘッドがあることがわかりました。同じドメインへの後続の呼び出しがキャッシュされた応答を使用するように、プリフライト OPTIONS の結果をキャッシュして適用する方法はありますか?
28839 次
3 に答える
111
プリフライトは、ドメイン全体ではなく、リクエストにのみ適用できます。同じ質問をメーリング リストに投稿しましたが、セキュリティ上の懸念がありました。スレッド全体は次のとおりです: 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 を返す場合、'application/json' の Content-Type もプリフライトをトリガーすることに注意してください。
API の "RESTful" 性を曲げる気がある場合は、他にもいくつか試してみることができます。1 つは、'text/plain' のように、プリフライトを必要としない Content-Type を使用することです。カスタム ヘッダーは常にプリフライトをトリガーするため、カスタム ヘッダーがある場合は、それらをクエリ パラメーターに移動できます。最終的には、すべてのリクエストが単一のエンドポイントに対して行われる JSON-RPC のようなプロトコルを使用できます。
正直なところ、ブラウザのプリフライト キャッシュの制限は 10 分であり、REST のリソース URL により、プリフライト キャッシュはほとんど役に立ちません。長時間実行されるアプリの過程でプリフライトを制限するためにできることはほとんどありません。CORS 仕様の作成者が将来これに対処しようとすることを期待しています。
于 2012-08-18T20:25:17.083 に答える