[解決済み] OPTIONSリクエストを送信する理由と、それを無効にする方法を教えてください。

質問

Web APIを構築しています。Chromeを使って私のAPIにPOSTやGETするときはいつも、本当のリクエストの前にOPTIONSリクエストが送信され、非常に迷惑していることに気づきました。現在、私はOPTIONSリクエストを無視するようにサーバーを設定しています。今、私の質問は、サーバーの負荷を2倍にするためにOPTIONSリクエストを送信するのは良いことでしょうか？ブラウザがOPTIONSリクエストを送るのを完全に止める方法はないのでしょうか？

解決方法は？

を編集 2018-09-13 : このレスポンスの最後に、この飛行前の要求とそれを回避する方法について、いくつかの注意事項を追加しました。

OPTIONS リクエストは、いわゆる pre-flight のリクエストは Cross-origin resource sharing (CORS) .

特定の状況で、異なるオリジンをまたいでリクエストをするときに必要なものです。

このプリフライトリクエストは、一部のブラウザが安全対策として行うもので、行われているリクエストがサーバーから信頼されていることを確認するためのものです。 つまり、サーバーはリクエストで送信されたメソッド、オリジン、ヘッダが安全に動作することを理解します。

サーバーは、クロスオリジンリクエストを行おうとするときは、これらのリクエストを無視せずに処理する必要があります。

良い資料がここにあります。 http://enable-cors.org/

これらを快適に処理する方法として、すべてのパスに対して OPTIONS メソッドを使用すると、サーバーはこのヘッダを含むレスポンスを送信します。

Access-Control-Allow-Origin: *

これは、サーバーがどのオリジンからのリクエストにも喜んで答えるということをブラウザに伝えるものです。

サーバーに CORS サポートを追加する方法の詳細については、次のフローチャートを参照してください。

http://www.html5rocks.com/static/images/cors_server_flowchart.png

を編集 2018-09-13

CORS OPTIONS のリクエストが発生するのは一部のケースに限られます。 MDNドキュメント :

リクエストによっては、CORSプリフライトが発生しないものもあります。この記事では、これらのリクエストを「単純なリクエスト」と呼びますが、Fetch 仕様（CORS を定義）ではこの用語は使用されていません。CORS プリフライトをトリガーしないリクエスト、いわゆる「単純なリクエスト」は、以下のすべての条件を満たすものです。

許可されたメソッドのみです。

• GET
• HEAD
• POST

ユーザーエージェントによって自動的に設定されるヘッダー（例えば、Connection、User-Agent、または「禁止されたヘッダー名」としてFetch仕様で定義された名前を持つ他のヘッダー）を除いて、手動で設定することが許可されている唯一のヘッダーは、Fetch仕様が「CORS-safelisted要求ヘッダー」であると定義しているもので、それは次のとおりである。

• 受け入れる
• 受け入れ言語
• コンテンツ言語
• Content-Type (ただし、以下の追加要件に注意)
• DPR
• ダウンリンク
• セーブデータ
• ビューポート幅
• 幅

Content-Typeヘッダーに許される値は以下の通りです。

• application/x-www-form-urlencoded です。
• multipart/form-data
• テキスト/プレーン

リクエストで使用されるXMLHttpRequestUploadオブジェクトにはイベントリスナーは登録されません。これらはXMLHttpRequest.uploadプロパティを使用してアクセスします。

リクエストにはReadableStreamオブジェクトは使用されていません。