[解決済み】プリフライトCORSリクエストの導入の動機は何ですか？

質問

クロスオリジンリソース共有 は、Webページが別のドメインにXMLHttpRequestを行うことができるメカニズムです( ウィキペディア ).

ここ数日、CORSをいじっていて、すべての仕組みがかなり理解できたと思うんだ。

ですから、私の質問は、CORS/プリフライトの仕組みについてではなく、次のことについてです。 新しいリクエストタイプとしてプリフライトを導入した理由 . 私は、サーバAが、本当のリクエスト (RR) が受け入れられるかどうかを知るために、サーバBにプリフライト (PR) を送信する必要がある理由が見当たりません - Bが事前のPRなしにRRを受け入れる/拒否することは確かに可能でしょう。

かなり検索した結果 この作品 での情報です。 www.w3.org (7.1.5):

この仕様が存在する以前は、特定のユーザーエージェントから発信することができなかったクロスオリジンリクエストからリソースを保護するために プリフライトリクエストは、リソースがこの 仕様があります。

今までで一番理解しにくい文章だと思います。私の解釈では（「最善の推測」と呼ぶべきですが）、この仕様を知らないサーバーCからのリクエストからサーバーBを保護することだと思います。

どなたか、PR + RR が RR 単独よりうまく解決するシナリオを説明し、問題を示していただけませんか？

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

プリフライトの依頼の目的が分からず、しばらく迷っていましたが、これで分かったような気がします。

重要な洞察は、プリフライトリクエストは セキュリティ のことです。むしろ、それは ルールを変えない のことです。

プリフライト要求はセキュリティとは無関係であり、CORSを意識して現在開発されているアプリケーションには何の関係もない。むしろ、プリフライトメカニズムは、以下のように開発されたサーバーに利益をもたらします。 を使用せずに は、クライアントとサーバーが共に CORS を意識していることを確認するためのサニティ チェックとして機能します。CORS の開発者は、クロスドメイン DELETE リクエストなどを受け取ることがないという前提に依存しているサーバーが十分に存在すると考え、双方がオプトインできるようにプリフライ ト メカニズムを考案したのです。彼らは、単にクロスドメインの呼び出しを可能にするという代替案では、あまりにも多くの既存のアプリケーションを壊してしまうと考えたのです。

ここには3つのシナリオがあります。

1. もう開発されていない古いサーバーで、CORS以前に開発されたもの。これらのサーバーは、例えばクロスドメインのDELETEリクエストを受け取ることはないだろうと仮定している可能性があります。 このシナリオはプリフライト機構の主な受益者である。 しかし、CORS のある世界では、プリフライト メカニズムによって追加の「健全性チェック」が行われるため、ウェブの基本ルールが変更されても、クライアントとサーバーが壊れることはありません。

2. まだ開発中のサーバーで、古いコードを多く含み、クロスドメインの世界で正しく動作することを確認するために古いコードをすべて監査することが実行可能でない/望ましくない場合。このシナリオでは、サーバーが徐々に CORS にオプトインできるようにします。たとえば、「Now I'll allow this particular header"」、「Now I'll allow this particular HTTP verb"」、「Now I'll allow cookies/auth information to be sent"」などです。 このシナリオはプリフライトメカニズムの恩恵を受けています。

3. CORSを意識して書かれた新サーバー。標準的なセキュリティ手法によれば、サーバーは、そのリソースを保護するために 任意の サーバは、クライアントが悪意あることをしないとは信用できないのです。 このシナリオはプリフライト機構の恩恵を受けられない プリフライト機構は、リソースを適切に保護したサーバーに追加のセキュリティをもたらしません。