[解決済み】AngularJS がクロスオリジンリソースに対して OPTIONS HTTP リクエストを実行する場合

質問

AngularJSをクロスオリジンリソースと通信するように設定しようとしています。テンプレートファイルを配信しているアセットホストは別のドメインにあり、したがってAngularが実行するXHRリクエストはクロスドメインでなければなりません。この作業を行うために、HTTPリクエストに適切なCORSヘッダーをサーバーに追加しましたが、うまくいかないようです。問題は、ブラウザ（クローム）でHTTPリクエストを検査すると、アセットファイルに送信されたリクエストがOPTIONSリクエストであることです（GETリクエストであるべきです）。

これはAngularJSのバグなのか、それとも何か設定が必要なのか、よくわかりません。私が理解したところでは、XHRラッパーはOPTIONS HTTPリクエストを行うことができないので、ブラウザはGETリクエストを実行する前に、最初にアセットをダウンロードすることが"allow"であるかどうかを判断しようとしているように見えます。この場合、CORSヘッダーを設定する必要があります（Access-Control-Allow-Origin: http://asset.host... .）もアセットホストと同じように設定するのですか？

解決方法は？

OPTIONSリクエストは決してAngularJSのバグではなく、Cross-Origin Resource Sharing標準がブラウザに命じている動作方法です。このドキュメントを参照してください。 https://developer.mozilla.org/en-US/docs/HTTP_access_control とあり、「概要」の項にこうあります。

Cross-Origin Resource Sharing規格は、新しいHTTP ヘッダを使用することで、サーバーは、そのヘッダを使用することができるオリジンのセットを記述することができます。 ウェブブラウザを使用してその情報を読み取ることが許可されています。さらに ユーザーデータに副作用を与える可能性のあるHTTPリクエストメソッド（特に 特に、GET以外のHTTPメソッドや、POSTを使用する場合。 特定のMIMEタイプ）。この仕様では、ブラウザに次のことを義務付けています。 リクエストのプリフライトを行い、サーバーからサポートされているメソッドを呼び出す。 をHTTP OPTIONSリクエストヘッダで送信し、その後、HTTP OPTIONSリクエストヘッダが承認された時点で サーバーは、実際のリクエストを実際のHTTPリクエスト メソッドを使用します。 また、サーバーはクライアントに対して、quot;credentials" (クッキーと HTTP 認証データを含む) を一緒に送信すべきかどうかをクライアントに通知することもできます。 リクエストに対応します。

すべてのWWWサーバーに対応する汎用的な解決策を提供することは非常に困難です。なぜなら、サーバー自体やサポートしようとするHTTP動詞によって設定が異なるからです。この素晴らしい記事( http://www.html5rocks.com/en/tutorials/cors/ には、サーバーが送信する必要のある正確なヘッダについて、より詳細な説明があります。