無効なCORSリクエストに対する予想される応答は何ですか？
CORS仕様では、サーバーが無効なCORSリクエストにどのように応答するかについては言及されていません。たとえば、リクエストのオリジンが無効な場合、 CORS仕様の状態 ：「この一連のステップを終了します。リクエストはこの仕様の範囲外です。」無効なメソッドやヘッダーを要求するなど、他のエラーケースにも同様の言語があります。
CORSエラーの場合、期待される応答はどうなりますか？サーバーが異なれば、必要な動作も異なる可能性があることを理解しています。しかし、サーバーの所有者が気にしない場合に受け入れられる可能性のある標準的な応答を探しています。
はい、私は自分の質問に答えていることに気づきましたが、とにかくここに行きます。私はこれについていくつかの調査を行いましたが、行動は2つの陣営に分類されるようです。
1）CORSリクエストが無効な場合はエラーを返します。これは Java CORSフィルター プロジェクトがたどるルートです。このライブラリは
- 仕様に準拠していないリクエストに対する400の不正なリクエスト
- 403無効なオリジンまたはヘッダーは禁止されています。
- 405メソッドは無効なメソッドを許可しません
2）応答でCORSヘッダーを返し、ブラウザにアクセスの詳細を分類させます。これははるかに一般的なアプローチのようで、によって使用されます。 Amazon S3、SoundCloud、FourSquare、SpotifyのAPI（後者の2つのAPIは、単純なCORSリクエストのみをサポートすることでメリットがあります）。この場合、サーバーはエラーチェックを行わず、サポートされているオリジン、メソッド、ヘッダーのCORSヘッダーを返すだけです。ブラウザーは引き続き要求を行いますが、CORS応答ヘッダーがユーザーの要求と一致しない場合、ブラウザーはユーザーからの応答を保留します。
これらの方法にはそれぞれ長所と短所があります。方法1はCORS仕様により厳密に調整されていますが、ユーザーに有用なデバッグ情報を提供していません。
メソッド＃2は、サポートされているメソッドとヘッダーが何であるかについてのより多くの洞察を提供します。サーバーはリクエストヘッダーに関係なく同じレスポンスヘッダーを返すため、実装も簡単です。ただし、これには、ブラウザがユーザーからの応答をブロックする場合でも、サーバー側で実際に要求を実行するという犠牲が伴います。これは、POST、PUT、DELETEなどの副作用のあるメソッドには望ましくない場合があり、CORSを認証メカニズムとして使用してはならないという事実を浮き彫りにします。
（上記の私の調査は決して網羅的ではないことに注意してください。多くのAPIの実際の動作を確認するのは困難でした。なぜなら、APIは認証を必要とするか、サポートされていないメソッドなどの他のエラーのために別のレベルでリクエストをブロックしたからです。）
モンスールの答えに付け加えたいだけです。 お互いに動作があります（現在S3で使用されている動作）：
リクエストのオリジンと一致する場合にのみCORSレスポンスヘッダーを送信します。それ以外の場合は、CORSヘッダーをまったく送信せず、ブラウザまたは他のクライアントに自分で決定させます。
少なくともこれは私にとってそれがどのように機能するかです。
また、Javaに関しては、403を送信するのが一般的です。そのJavaリンクはかなり古いですが、JavaのデファクトスタンダードであるSpringのアプローチは同じです。私のリファレンスを参照してください- ここ 。
エラーの性質によって異なると思いますが、403（リクエストが必要な基準を満たしていない場合）や404（メソッドが利用できない場合）などの4xxエラーが発生することが予想されます。