質問

どうやら、私はその意味を完全に誤解しているようです。私はこのようなことを考えました。

1. クライアントがJavascriptコードMyCode.jsを以下の場所からダウンロードします。 http://siteA - 原点 .
2. MyCode.jsのレスポンスヘッダには Access-Control-Allow-Origin。 http://siteB というのは、MyCode.jsがBというサイトをクロスオリジンで参照することを許可しているという意味だと思ったのですが。
3. クライアントがMyCode.jsのいくつかの機能をトリガーし、その機能から http://siteB クロスオリジンリクエストであるにもかかわらず、問題ないはずです。

さて、私は間違っています。全くこのように動作しません。そこで、私は クロスオリジンリソース共有 を読み取ろうとしたところ w3c勧告のクロスオリジンリソース共有について

ひとつだけ確かなことは、このヘッダーをどう使えばいいのか、私にはまだわからないということです。

私はサイトAとサイトBの両方を完全に管理しています。サイトAからダウンロードしたjavascriptコードを、このヘッダーを使用してサイトBのリソースにアクセスできるようにするにはどうすればよいでしょうか？

追伸

JSONPを活用したいとは思わない。

どのように解決するのですか？

Access-Control-Allow-Origin は CORS (Cross-Origin Resource Sharing)ヘッダー .

サイトAがサイトBからコンテンツを取得しようとするとき、サイト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 's error イベントに参加し、リクエストしている JavaScript コードにレスポンスデータを拒否します。

シンプルでないリクエスト

ネットワークレベルで起こることは わずかに は、上記で説明したよりも複雑です。もしリクエストが シンプルでないリクエスト の場合、ブラウザはまずデータなしの "preflight" OPTIONS リクエストを送信し、サーバーがそのリクエストを受け入れるかどうかを確認します。リクエストは、以下のいずれか(または両方)のときに非シンプルになります。

• GETまたはPOST以外のHTTP動詞を使用する場合（例：PUT、DELETE）。
• 単純でないリクエストヘッダを使用すること。単純なリクエストヘッダはこれだけです。
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (これは、その値が application/x-www-form-urlencoded , multipart/form-data または text/plain )

OPTIONSプリフライトに対して、サーバーが適切なレスポンスヘッダで応答した場合( Access-Control-Allow-Headers 単純でないヘッダの場合 Access-Control-Allow-Methods の場合)、非単純動詞および/または非単純ヘッダにマッチするものがあれば、ブラウザは実際のリクエストを送信します。

仮にサイトAが /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 を理解する には、単純でないリクエストに関するもう少し詳しい情報があります。