Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。Policy(日本語では同一生成元ポリシー)が適用されます。HTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。アクセス元が悪意あるWebサイトならともかく、データの連携をする相手として信頼関係ができているWebサイトにまで制限をかけてしまうと不便ですので、データのアクセスを許可できるWebサイトに対してはOriginを越えたアクセスを可能にするための仕組みとして、CORSがあります。HTTP(S)でのアクセスを許可したい場合を例として述べます。APIでのGETやPOSTを許可したい場合は、次のようにします。APIの場合はオプションによってCORSを使うことを宣言します。'cors'}).then(onLoadFunc);一方、Webサーバ側では、Originを越えたアクセスを許可することをブラウザに明示的に知らせるために、HTTPレスポンスヘッダに適切な情報を付加する必要があります。ブラウザからサーバに送られるHTTPリクエストヘッダには、Originを越えるアクセスの場合はOriginというフィールドが含まれます。https://trustedsite.comといった内容を追加すれば、ブラウザ側でアクセスが許可されるようになります。このようなシンプルな例に限り、どのWebサイトにもOriginを越えるアクセスを許可することをワイルドカードで指定することが可能です(サブドメイン等の部分指定はできません)。*Cookieも許可したい場合HTTP(S)通信時にCookieの送受信も許可したい場合は、ブラウザとサーバの両方で、もう少々細工が必要となります。ブラウザのJavaScriptでは次のようにします。この例以降では、Access-Control-Allow-Originにおいてワイルドカード指定が許可されなくなりますので、注意が必要です。'include'}).then(onLoadFunc);これに対し、サーバ側ではHTTPレスポンスヘッダに次のような内容を追加します。requestとしてOPTIONSリクエストを行うことが定められています。この場合、サーバ側ではGETやPOSTに加えてOPTIONSでも同様のCORS対応が必要になりますので、注意が必要です。text/plain以外の内容が指定されている。requestには、次のようなHTTPリクエストヘッダが含まれます。requestに対するレスポンスとしては、例えば、少なくとも次のような要領で、Originを越えるアクセスとして許可するHTTPリクエストのメソッドを指定する必要があります。ブラウザ側でX-MyRequestとX-MyOptionというヘッダを追加したとします。requestがブラウザからサーバに送られます。X-MyRequest,X-MyOptionサーバ側では、これらのリクエストヘッダに示されているメソッドとヘッダを許可するかどうかを判断して、レスポンスヘッダを返します。Access-Control-Allow-Methodsで指定されたメソッドと、Access-Control-Allow-Headersで指定されたヘッダが、この後ブラウザが実際に送るHTTPリクエストに許可されます。(該当するヘッダはpreflightと実際のリクエストの両方で必要になります。good-resultのような独自レスポンスヘッダをブラウザに返そうとしている場合、ブラウザがこれらのレスポンスヘッダの内容を取得しようとすると、セキュアではないヘッダにアクセスしようとしたものとみなされて、アクセスが許可されないようになっています。Pragmaとなっているようです。)このような独自レスポンスヘッダへのアクセスをブラウザに許可するには、許可したいレスポンスヘッダをAccess-Control-Expose-Headersで指定します。requestには、サーバ側からブラウザにキャッシュさせる有効期限を指定することが出来ます。requestがこの後の同じURLに対するHTTPリクエストにも適用されるようになります。864000Access-Control-Max-Ageには有効期限を秒単位で指定します。864,000(秒))となっています。Sharing)](https://fetch.spec.whatwg.org/#http-cors-protocol)**を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。Policy](http://www.rfc-editor.org/info/rfc6454)**(日本語では同一生成元ポリシー)が適用されます。HTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。アクセス元が悪意あるWebサイトならともかく、データの連携をする相手として信頼関係ができているWebサイトにまで制限をかけてしまうと不便ですので、**データのアクセスを許可できるWebサイトに対してはOriginを越えたアクセスを可能にするための仕組み**として、CORSがあります。HTTP(S)でのアクセスを許可したい場合を例として述べます。APIでのGETやPOSTを許可したい場合は、次のようにします。APIの場合はオプションによってCORSを使うことを宣言します。'cors'}).then(onLoadFunc);```一方、Webサーバ側では、Originを越えたアクセスを許可することをブラウザに明示的に知らせるために、HTTPレスポンスヘッダに適切な情報を付加する必要があります。ブラウザからサーバに送られるHTTPリクエストヘッダには、Originを越えるアクセスの場合は`Origin`というフィールドが含まれます。https://trustedsite.com```といった内容を追加すれば、ブラウザ側でアクセスが許可されるようになります。このようなシンプルな例に限り、どのWebサイトにもOriginを越えるアクセスを許可することをワイルドカードで指定することが可能です(サブドメイン等の部分指定はできません)。Cookieも許可したい場合HTTP(S)通信時にCookieの送受信も許可したい場合は、ブラウザとサーバの両方で、もう少々細工が必要となります。ブラウザのJavaScriptでは次のようにします。この例以降では、`Access-Control-Allow-Origin`においてワイルドカード指定が許可されなくなりますので、注意が必要です。'include'}).then(onLoadFunc);```これに対し、サーバ側ではHTTPレスポンスヘッダに次のような内容を追加します。request**として**OPTIONS**リクエストを行うことが定められています。この場合、サーバ側ではGETやPOSTに加えてOPTIONSでも同様のCORS対応が必要になりますので、注意が必要です。text/plain以外の内容が指定されている。requestには、次のようなHTTPリクエストヘッダが含まれます。requestに対するレスポンスとしては、例えば、少なくとも次のような要領で、Originを越えるアクセスとして許可するHTTPリクエストのメソッドを指定する必要があります。ブラウザ側でX-MyRequestとX-MyOptionというヘッダを追加したとします。requestがブラウザからサーバに送られます。X-MyRequest,X-MyOption```サーバ側では、これらのリクエストヘッダに示されているメソッドとヘッダを許可するかどうかを判断して、レスポンスヘッダを返します。Access-Control-Allow-Methodsで指定されたメソッドと、Access-Control-Allow-Headersで指定されたヘッダが、この後ブラウザが実際に送るHTTPリクエストに許可されます。(該当するヘッダはpreflightと実際のリクエストの両方で必要になります。good-result```のような独自レスポンスヘッダをブラウザに返そうとしている場合、ブラウザがこれらのレスポンスヘッダの内容を取得しようとすると、セキュアではないヘッダにアクセスしようとしたものとみなされて、アクセスが許可されないようになっています。Pragmaとなっているようです。)このような独自レスポンスヘッダへのアクセスをブラウザに許可するには、許可したいレスポンスヘッダをAccess-Control-Expose-Headersで指定します。requestには、サーバ側からブラウザにキャッシュさせる有効期限を指定することが出来ます。requestがこの後の同じURLに対するHTTPリクエストにも適用されるようになります。864000```Access-Control-Max-Ageには有効期限を秒単位で指定します。864,000(秒))となっています。送信いただいたご意見への返信は行っておりません。お問い合わせください。