web-dev-qa-db-ja.com

ブラウザはいつOriginヘッダーを送信しますか？ブラウザはいつOriginをnullに設定しますか？

this Bugzilla thread （および also ）からわかるように、Firefoxは常にPOSTリクエストでOriginヘッダーを送信しません。- RFC は、特定の未定義の「プライバシーに敏感な」コンテキストでは送信されるべきではないと述べています。Mozillaはそれらのコンテキストを定義しています here 。

これらがFirefoxがOriginヘッダーを送信しない唯一の状況であるかどうかを知りたいのですが。私が知る限り、クロスオリジンPOSTリクエストでは送信しません（ChromeおよびInternet Explorerはそうします））が、私はできますドキュメンテーションでそれを確認します。それは私が欠けているどこかに列挙されていますか？

httpfirefoxcorscross-domainfetch-api
14
P Jones

仕様が必要とする限り、上記の質問はいくつかの回答に分割する必要があります：

  • ブラウザがOriginヘッダーを送信する必要がある場合
  • ブラウザが内部でOriginをnullとしてシリアル化される値に設定する必要がある場合

これについて（仕様とは異なる）Firefoxに必要なものが列挙されているとは思えません。しかし、spec要件を列挙する限り、ここでは、詳細を2つに分けて示します。

ブラウザがOriginヘッダーを送信する必要がある場合

質問に対する答えブラウザーがOriginヘッダーを送信する必要があるのはいつですか？は次のとおりです：Originヘッダーは、Fetch仕様で定義されているリクエストに対してのみ送信されます- CORSリクエスト ：

CORSリクエストは、Originヘッダーを含むHTTPリクエストです。 OriginヘッダーもメソッドがGETでもHEADでもないすべてのリクエストに含まれているため、CORSプロトコルに参加しているとは確実に識別できません。

Fetch仕様の実際のステートメント は、メソッドがOriginでもGETでもないすべてのリクエストに対してHEADヘッダーを送信するようブラウザーに要求します：

CORSフラグが設定されているか、httpRequestのメソッドがGETでもHEADでもない場合、 Origin /httpRequestのOriginをhttpRequestのヘッダーリストにシリアル化してUTF-8でエンコードして追加します。

そのため、ブラウザはallOriginリクエストに対してPOSTを送信する必要があります。これには、同じ起源のPOSTs（Fetchの定義により）実際には「CORSリクエスト」です（たとえそれらが同じ起源であっても）。

注：上記は、2016-12の仕様に加えられた 変更により、Fetch仕様が現在どのように要件を定義するかを説明しています-09 。それまでは、要件は異なりました。

  • 以前は、同じ起源のPOSTに対してOriginは送信されませんでした
  • 以前はOriginはクロスオリジンに送信されませんでしたPOST <form>から（CORSなしで）

そのため、質問で説明されているFirefoxの動作は、仕様以前に必要なものに準拠していますが、仕様現在必要なものには準拠していないと思います。

ブラウザーがOriginヘッダーを送信する必要がある他のケースは、「CORSフラグ」を設定してリクエストが作成された場合で、HTTP（S）リクエストは exceptリクエストモードがnavigate、websocket、same-Origin、またはno-corsの場合 。

XHRalwaysは、モードをcorsに設定します。ただし、Fetch APIでは、これらのリクエストモードは、fetch(…)メソッドのinit-object引数のmodeフィールドで設定できるものです。

fetch("http://example.com", { mode: 'no-cors' }) // no Origin will be sent

それに加えて、 a crossorigin属性 （aka“ CORS設定属性）を含む要素の場合、HTML仕様ではブラウザで設定する必要がありますcorsへの要求モード（およびOriginヘッダーを送信するため）。

それ以外の場合、リクエストを開始するURLを持つ属性を持つ要素（<script src>、スタイルシート、画像、メディア要素）の場合、リクエストのモードはデフォルトでno-corsになり、Originヘッダーは送信されません。

以上が、ブラウザーがOriginヘッダーを送信する条件の詳細です。

答えの次の部分は、Origin値がいつnullに設定されるかについてです。

ブラウザがOriginをnullとしてシリアル化される値に設定する必要がある場合

ブラウザーがOriginヘッダーを送信する必要がある場合の要件とは別に、ブラウザーがOriginをnullに設定する必要がある場合の要件は次の仕様で定義されています。

HTML仕様では opaque Origin という用語を使用しており、次のように述べています。

シリアライゼーションなしで再作成できる内部値（ASCII Originのシリアライゼーションごとに「null」としてシリアライズされます）。意味のある操作は等価性のテストのみです。

つまり、HTML仕様で不透明なOriginと記述されているところならどこでも、それをnullに変換できます。

次の場合、HTML仕様では、ブラウザに不透明なOriginまたは一意のOriginを設定する必要があります。

  1. クロスオリジン画像（クロスオリジンimg要素を含む）
  2. クロスオリジンメディアデータ（クロスオリジンvideoおよびaudio要素を含む）
  3. data: URLから生成された任意のドキュメント
  4. Any iframe with the sandbox attribute that does not include the value allow-same-Origin
  5. createDocument()などを使用してプログラムで作成されたドキュメント
  6. 作成者の閲覧コンテキストがないドキュメント
  7. ネットワークエラーである応答
  8. ターゲットのソースからのタイプのナビゲーション要求に対するナビゲーション応答は、コンテンツセキュリティポリシーによってブロックされますか？アルゴリズムは、ナビゲーション応答で実行されるとBlockedを返します

Fetch仕様では、ブラウザにOriginを「グローバルに一意の識別子」（基本的には「不透明なOrigin」と同じ意味であり、基本的にはnull…を意味する）に設定する必要があります。

  1. 起点間のリダイレクト

次の場合、URL仕様ではブラウザに不透明なOriginを設定する必要があります。

  1. blob: URLの場合
  2. file: URLの場合
  3. スキームがhttp、https、ftp、ws、wss、またはGopher 。

ただし、ブラウザが内部的に不透明なOrigin（基本的にはnull）を設定したからといって、必ずしもブラウザがOriginヘッダーを送信するわけではないことを理解することが重要です。したがって、ブラウザがOriginヘッダーを送信する必要がある場合の詳細については、この回答の最初の部分を参照してください。

33
sideshowbarker