どうやら、私はその意味を完全に誤解していたようです。私は次のようなことを考えました:
- クライアントは、origin
http://siteAからJavaScript コード MyCode.js をダウンロードします。 - MyCode.js のレスポンス ヘッダーにはAccess-Control-Allow-Origin: が
http://siteB含まれています。これは、MyCode.js がサイト B へのクロスオリジン参照を許可されていることを意味すると考えました。 - クライアントは MyCode.js の一部の機能をトリガーし、次に にリクエストを送信します。これは、
http://siteBクロスオリジン リクエストであるにもかかわらず、問題ないはずです。
まあ、私は間違っています。これは全く機能しません。だから、私は読んだクロスオリジンリソース共有そして読もうとしたW3C 勧告におけるクロスオリジン リソース共有。
確かなことが 1 つあります。このヘッダーをどのように使用すればよいのか、まだ理解できていません。
サイト A とサイト B の両方を完全に制御できます。このヘッダーを使用して、サイト A からダウンロードした JavaScript コードがサイト B のリソースにアクセスできるようにするにはどうすればよいでしょうか?
PS: 利用したくないJSONP。
ベストアンサー1
Access-Control-Allow-OriginはCORS (クロスオリジンリソース共有) ヘッダー。
サイトAがサイトBからコンテンツを取得しようとすると、サイトBはAccess-Control-Allow-Originレスポンスヘッダーを送信して、このページのコンテンツが特定のオリジンからアクセス可能であることをブラウザに伝えます。（オリジンとは、ドメイン、スキーム、ポート番号デフォルトでは、サイトBのページは他の起源からはアクセスできない; Access-Control-Allow-Originヘッダーを使用すると、特定のリクエスト元によるクロスオリジン アクセスが可能になります。
サイト B がサイト A にアクセスできるようにする各リソース/ページに対して、サイト B はレスポンス ヘッダーを使用してページを提供する必要があります。
Access-Control-Allow-Origin: http://siteA.com
最新のブラウザは、クロスドメイン リクエストを完全にブロックしません。サイト A がサイト B からページをリクエストすると、ブラウザは実際にネットワーク レベルでリクエストされたページを取得し、レスポンス ヘッダーにサイト A が許可されたリクエスト元ドメインとしてリストされているかどうかを確認します。サイト B がサイト A がこのページにアクセスできることを示していない場合、ブラウザはXMLHttpRequestのerrorイベントをトリガーし、リクエスト元の JavaScript コードへのレスポンス データを拒否します。
単純ではないリクエスト
ネットワークレベルで何が起こるかは、上で説明したよりも少し複雑です。リクエストが「単純ではない」リクエストブラウザはまず、データなしの「プリフライト」OPTIONS リクエストを送信し、サーバーがリクエストを受け入れるかどうかを確認します。次のいずれか (または両方) を使用する場合、リクエストは単純ではありません。
- GET または POST 以外の HTTP 動詞 (例: PUT、DELETE)。
- 単純でないリクエスト ヘッダー。単純なリクエスト ヘッダーは次のとおりです。
Accept;Accept-Language;Content-Language;Content-Typeapplication/x-www-form-urlencoded(これは、その値が、multipart/form-data、または の場合にのみ単純ですtext/plain)。
サーバーが、非単純な動詞および/または非単純なヘッダーに一致する適切な応答ヘッダー (Access-Control-Allow-Headers非単純なヘッダーの場合、Access-Control-Allow-Methods非単純な動詞の場合) を使用して OPTIONS プリフライトに応答した場合、ブラウザーは実際のリクエストを送信します。
サイト A が の PUT リクエストを という/somePage単純でないContent-Type値で送信すると仮定するとapplication/json、ブラウザはまずプリフライト リクエストを送信します。
OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type
およびAccess-Control-Request-MethodはAccess-Control-Request-Headersブラウザによって自動的に追加されるので、追加する必要はありません。この OPTIONS プリフライトは、成功した応答ヘッダーを取得します。
Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type
実際のリクエストを送信するとき (プリフライトが完了した後) の動作は、単純なリクエストの処理方法と同じです。つまり、プリフライトが成功した非単純なリクエストは、単純なリクエストと同じように扱われます (つまり、サーバーはAccess-Control-Allow-Origin実際の応答のために再度送信する必要があります)。
ブラウザは実際のリクエストを送信します:
PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json
{ "myRequestContent": "JSON is so great" }
そして、サーバーはAccess-Control-Allow-Origin単純なリクエストの場合と同じように を返します。
Access-Control-Allow-Origin: http://siteA.com
見るCORS 経由の XMLHttpRequest を理解する単純ではないリクエストに関する詳細情報については、こちらをご覧ください。