5

これをもう少しよく理解したいと思います。現在使用しているメンタルモデルは、次のように機能します。

  1. foo.comでホストされているJSは、bar.comでホストされているリソースにアクセスしたいと考えています。これは、bar.comがこのリクエストを歓迎していることを示すことができない限り、ブラウザがユーザーを公開することを好むようなものではありません。
  2. したがって、foo.comJSは基本的にリクエストを2つに分割します。まず、XMLHttpRequestオブジェクトを介して適切な種類（GET、POSTなど）のデータレスリクエストを送信します。bar.comのサーバーは、Access-Control-Allow-Originヘッダーが含まれる場合と含まれない場合がある、基本的にすべての要求に通常応答するものを返します。（編集：これは誤解でした-以下のapsillersによる優れたコメントを参照してください）
  3. ブラウザがそのようなヘッダーを取得した場合、ブラウザはそれをスキャンしてOrigin（この場合はfoo.com）を探します。存在する場合は、送信を要求された実際の要求の送信に進みます。そうでなければ、それは拒否します。（編集：これも完全に正しくありませんでした）

このモデルが正しければ、ブラウザがこの予備リクエストでOriginヘッダーを送信する理由について混乱しています。一致のチェックはクライアント側で行われませんか？このヘッダーを送信すると何が達成されますか？

4

1 に答える 1

3

これがCORSの仕組みです。基本的には握手で、「はい」と言ってくれます。第三者に連絡しないと可能かどうかわかりません。

以下は、 MDN記事のPreflighted_requestsセクションの一部です。

単純なリクエスト（上記で説明）とは異なり、「プリフライト」リクエストは、実際のリクエストを安全に送信できるかどうかを判断するために、最初にHTTPOPTIONSリクエストヘッダーを他のドメインのリソースに送信します。クロスサイトリクエストは、ユーザーデータに影響を与える可能性があるため、このようにプリフライトされます。特に、次の場合、リクエストはプリフライトされます。

GETまたはPOST以外のメソッドを使用します。また、POSTを使用してapplication / x-www-form-urlencoded、multipart / form-data、text / plain以外のContent-Typeでリクエストデータを送信する場合、たとえば、POSTリクエストがXMLペイロードをサーバーに送信する場合application/xmlまたはtext/xmlを使用すると、リクエストがプリフライトされます。リクエストにカスタムヘッダーを設定します（たとえば、リクエストはX-PINGOTHERなどのヘッダーを使用します）

于 2012-11-19T18:37:54.360 に答える