前提：
サイト ( http://example.com ) がクロスオリジン リクエストを作成しようとすると、ブラウザはクロスオリジン サーバー ( http://other-server.com ) にヘッダー付きのHTTP リクエストを送信しますOrigin: http://example.com。http://other-server.comのサーバーがhttp://example.comを有効なオリジンとして承認した場合、サーバーは 1) エラーなしで応答し、かつ 2) 応答ヘッダーを次のように設定します。Access-control-allow-origin: http://example.com
Access-control-allow-origin私の質問は、応答にヘッダーを設定する必要があるのはなぜですか? サーバー ( http://other-server.com ) がクロスオリジン要求を許可していることをエラーなしで応答しませんか?
この追加の確認応答層により、サーバーは CORS をサポートする方法について多くの柔軟性を得ることができます。例えば：
1）Access-Control-Allow-Originヘッダーを設定するとき、サーバーには多くの選択肢があります。値を使用して*すべてのクライアントを許可することも、オリジンの実際の値 (例: ) を使用してクライアントの範囲を制限することもできますhttp://example.com。サーバーが CORS をサポートしているが、すべてのオリジンに対してサポートしているわけではない場合、サーバーはエラーなしで応答できますが、Access-Control-Allow-Originが に設定される可能性がありますhttp://notyourorigin.com。
Access-Control-Allow-Methods2) CORS では、およびAccess-Control-Allow-Headersプリフライト レスポンス ヘッダーを介してさらに柔軟に対応できます。これらのヘッダーは、単純なバイナリの成功/エラー HTTP ステータスを超えて、サーバーでサポートされているものとサポートされていないものに関するより微妙な情報を提供します。
上記の例が指摘しているように、コンテキストのないエラー応答は、ユーザーを非常に混乱させる可能性があります。CORS リクエストを行ったときにエラー応答しか返されない場合、そのリクエストが失敗した理由がわかりません。リクエストの仕方が間違っていませんか？サーバーは CORS をまったくサポートしていますか? これは、付随する情報がないと把握するのが非常に難しい場合があります。Access-Control-*CORS リクエストを効果的にデバッグできるように、ユーザーにより多くのコンテキストを提供します。