[109] [DFN[[CODE(HTTP)@en[[[Origin:]]]]]] [[ヘッダー]]は、 当該[[要求]]を行う [[fetch]] の実行元の[RUBYB[[[起源]]]@en[origin]]を表すものです。 * 仕様書 [REFS[ - [49] [CITE[[[Fetch Standard]]]] -- [290] '''[CITE@en-US[Fetch Standard]] ([TIME[2014-06-30 12:53:29 +09:00]] 版) ''' -- [306] [CITE@en-US[Fetch Standard]] ([TIME[2014-06-30 12:53:29 +09:00]] 版) -- [307] [CITE@en-US[Fetch Standard]] ([TIME[2014-06-30 12:53:29 +09:00]] 版) - [125] [CITE@en-US-x-hixie[HTML Standard]] ([TIME[2012-02-22 20:11:59 +09:00]] 版) - [302] [CITE@en-US[Fetch Standard]] ([TIME[2014-06-30 12:53:29 +09:00]] 版) ]REFS] * 構文 [299] [[欄値]]は、 [[起源]]または [CODE[[[null]]]] です [SRC[>>290]]。 [300] [[起源]]は、[[URL scheme]]、[CODE(URI)[://]]、[[ホスト]]、 [CODE[[[:]]]]、[[ポート]]で構成され ([CODE[[[:]]]] 以降は省略可能) [SRC[>>290]]、 [[起源]]の[[ASCII直列化]]を表します。 [301] [CODE[[[null]]]] は、[[三項組]]で表されない[[起源]]を表します。 [[小文字]]でなければなりません。 [FIG(railroad)[ = | == = === [[URL scheme]] === [CODE(URI)[://]] === [[ホスト]] === ? ==== [CODE[[[:]]]] ==== [[ポート]] == [CODE(URI)[[[null]]]] ]FIG] [113] [[利用者エージェント]]は任意の[[要求]]に [CODE(HTTP)@en[[[Origin:]]]] 欄を含めて[['''構いません''']]。 [SRC[>>21]] [114] 一つの[[要求]]に複数の [CODE(HTTP)@en[[[Origin:]]]] 欄を含めては[['''なりません''']]。 [SRC[>>21]] ;; [115] 複数含まれている場合に[[鯖]]がどう解釈するべきかは規定されていません。 * [CODE(HTTP)[null]] [117] 値 [CODE(HTTP)[[[null]]]] は[[3項組]]で表せない[[起源]]である時に使われます。 ;; [116] [[RFC 6454]] は、「[RUBYB[[[プライバシー]]重視]@en[privacy-sensitive]]」な文脈では値 [DFN[[CODE(HTTP)[[[null]]]]]] を送信しなければ[['''ならない''']] [SRC[>>21]] としていました。 具体的に何が「[[プライバシー]]重視」な文脈かは [CODE(HTTP)@en[[[Origin:]]]] 欄の仕様としては決めていませんが、 [[応用]]ごとに決めることもできます [SRC[>>21]]。 * 空文字列 [142] [[HTML]] の定義に従えば[[起源]]の[[ASCII直列化]]が[[空文字列]]になることもありますが、 その場合 [CODE(HTTP)@EN[[[Origin:]]]] の値をどうするべきかは不明確です。 [196] >>195 によれば [[Firefox]] では[[空文字列]]が [CODE[[[null]]]] の変わりに使われることになっています。 古い仕様ではそうだったのかもしれません。 [REFS[ - [195] [CITE@en[HTTP access control - MDN]] ([TIME[2012-02-29 23:20:44 +09:00]] 版) ]REFS] * 文脈 [50] [[Webブラウザー]]の [[fetch]] アルゴリズムは、 送信する[[HTTP要求]]の多くに、 [[HTTPヘッダー]] [CODE[Origin:]] を付与します。 [51] [DFN[[RUBYB[要求[CODE[Origin]]ヘッダーの追加][append a request `[CODE[Origin]]` header]]]]は、 [VAR[要求]]について、 次のようにします。 [SRC[>>49]] [FIG(steps)[ = [53] [VAR[直列化起源]]を、 [VAR[要求]]について[[要求起源を直列化]]した結果に設定します。 = [54] [VAR[要求]]の[F[response tainting]]が[CODE[cors]]か、 [VAR[要求]]の[F[モード][要求モード]]が [CODE[websocket]] の場合、 == [55] [VAR[要求]]の[F[ヘッダーリスト]]に、 [CODE[Origin]]/[VAR[直列化起源]]を[[末尾に追加]]します。 = [56] それ以外の場合で、 [VAR[要求]]の[F[メソッド][要求メソッド]]が [CODE[GET]] でも [CODE[HEAD]] でも''ない''場合、 == [58] [VAR[要求]]の[F[参照元ポリシー]]により、 [FIG(switch)[ : [CODE[no-referrer]] : [VAR[直列化起源]]を、 [CODE[null]] に設定します。 : [CODE[no-referrer-when-downgrade]], [CODE[strict-origin]], [CODE[strict-origin-when-cross-origin]]: [FIG(steps)[ = [59] [VAR[要求]]の[F[起源]]が[[項組起源]]で、 [VAR[要求]]の[F[起源]]の[F[scheme][URL scheme]]が [CODE[https]] で、 [VAR[要求]]の[F[現在URL]]の[F[scheme][URL scheme]]が [CODE[https]] で''ない''場合、 == [60] [VAR[直列化起源]]を、 [CODE[null]] に設定します。 ]FIG] : [CODE[same-origin]] : [FIG(steps)[ = [61] [VAR[要求]]の[F[起源]]が[VAR[要求]]の[F[現在URL]]の[F[起源]]と[[同じ起源]]で''ない''場合、 == [62] [VAR[直列化起源]]を、 [CODE[null]] に設定します。 ]FIG] ]FIG] == [57] [VAR[要求]]の[F[ヘッダーリスト]]に、 [CODE[Origin]]/[VAR[直列化起源]]を[[末尾に追加]]します。 ]FIG] ;; [297] 互換性の問題からすべての[[要求]]には含まれません [SRC[>>290]]。 ;; [42] [[プロキシ]]に接続するための [CODE[CONNECT]] には含まれません。 [298] [[Webブラウザー]]など[[同一起源ポリシー]]で管理された[[クライアント]]からの[[要求]]には [CODE(HTTP)@en[[[Origin:]]]] [[ヘッダー]]が含まれますが、 それ以外の[[要求]]には普通は [CODE(HTTP)@en[[[Origin:]]]] [[ヘッダー]]は含まれません。 [HISTORY[ [296] [[要求メソッド]]が [CODE[GET]] でも [CODE[HEAD]] でも''ない''[[要求]]や、 [[WebSocket接続の確立]]の[[要求]]、 [[CORS]] を使った他の[[起源]]への[[要求]]に含まれます [SRC[>>290]]。 [HISTORY[ [308] [[fetch]] において、[DFN[[RUBYB[[[[CODE[Origin]]ヘッダー省略フラグ]]]@en[omit-[CODE(HTTP)[Origin]]0header flag]]]]が未設定の時、 [[HTTP要求]]に [CODE(HTTP)@en[[[Origin:]]]] [[ヘッダー]]が設定されます [SRC[>>307]]。 ;; [28] 初期値は未設定です [SRC[>>306]]。 ]HISTORY] ]HISTORY] * 処理 ** CSRF 対策 [37] [[サーバー]]は、 [[CSRF]] 対策のためにこの[[ヘッダー]]を使うことができます。 [38] [CODE(HTTP)@en[Origin:]] [[ヘッダー]]の値が[[サーバー]]の想定する[[起源]]でなければ、 不当な[[起源]]からの[[要求]]であり、 [[CSRF]] 攻撃のおそれがありますから、 [[要求]]を拒否することとできます。 ** CORS [36] [[サーバー]]は、 [[CORS]] のためにこの[[ヘッダー]]を使うことができます。 [HISTORY[ [119] [[RFC 6454]] では[[鯖]]による解釈の方法は特に規定されていませんでした。 ]HISTORY] [214] [[CORS]] では別[[起源]]への[[要求]]に対する[[鯖]] ([[資源]]) での処理モデルが規定されており、 その中で [CODE(HTTP)@en[[[Origin:]]]] の処理方法も規定されています。 [CODE(HTTP)@en[[[Origin:]]]] に関する部分だけを抜き出すと、次の通りです。 - [215] [CODE(HTTP)@en[[[Origin:]]]] 欄がなければ、 [[CORS]] 処理モデルの適用範囲''外''です。 [SRC[>>213]] - [216] [CODE(HTTP)@en[[[Origin:]]]] 欄の値は、 -- [218] [[cross-origin request]]/[[actual request]] では [CODE(char)[[[U+0020]]]] [CODE(charname)@en[[[SPACE]]]] で分割し、得られたそれぞれの値が[[大文字・小文字不区別]]で想定している[[起源]]と一致するかを判定します。 [SRC[>>213]] -- [220] [[preflight request]] では値を直接[[大文字・小文字不区別]]で想定している[[起源]]と一致するかを判定します。 ([[preflight request]] は[[リダイレクト]]に対応していないので、常に値が1つと想定しています。) [SRC[>>213, >>221]] -- [219] なお、ここでいう想定している[[起源]]は有限のリストである必要はありません。 - [217] [[応答]]の [CODE(HTTP)@en[[[Access-Control-Allow-Origin:]]]] 欄には [CODE(HTTP)@en[[[Origin:]]]] 欄の値をそのまま使うことができます。 [SRC[>>213]] ** DNS による攻撃 [210] [[鯖]]側では [CODE(HTTP)@en[[[Origin:]]]] が[[要求]]元として適切な[[起源]]かどうかチェックすることになりますが、 [CODE(HTTP)@en[[[Host:]]]] をチェックしておかないと攻撃者が不正な[[ドメイン名]]を当該[[鯖]]に結びつけることで意図せぬ[[要求]]を受理させることができるとされています。 [EG[ [211] 例えば [CODE[corp.example]] と [CODE[corp.invalid]] があるとします。 [CODE[corp.example]] が [CODE[corp.example]] に [[cross-origin request]] を行い、 [CODE(HTTP)@en[[[Origin:]] corp.example]] と送ります。この時 [CODE[corp.invalid]] または[[ネットワーク]]が不正にこの[[要求]]を [CODE[corp.example]] に送りつけさせることができます。すると [CODE[corp.example]] は自身からの[[要求]]を (意図せず) 受け取ることになります。 [CODE[corp.example]] 側で [CODE(HTTP)@en[[[Host:]]]] をチェックすれば、[[利用者エージェント]]が本当は [CODE[corp.invalid]] に宛てて送ろうとしていたことを認識でき、 不適切な[[要求]]として処理できます。 ([[cross-origin request]] には [[HTTPS]] のような安全な接続を使うとより安全になります。) [SRC[>>212 4.]] ]EG] * 歴史 [22] 例によって [[W3C]] や [[IETF]] で政治的なごたごたに巻き込まれて必要以上に長くかかっています。 [[RFC]] になるよりずっと先に [[Webブラウザー]]で実装が進みました。 [1] [CITE[Cross-Site Request Forgery]] ([TIME[2008-07-11 00:28:05 +09:00]] 版) [2] [CITE[Origin Header for CSRF Mitigation]] ([TIME[2008-11-30 15:01:02 +09:00]] 版) [3] [[HTML5]] の[[ナビゲーション]]の[[算法]]に組み込まれたみたいです。。。 [4] [CITE@en[(X)HTML5 Tracking]] ([TIME[2009-01-15 07:15:24 +09:00]] 版) [5] [CITE@en[ACTION-96: Origin removal]] ([[Henri Sivonen]] 著, [TIME[2009-01-19 08:33:27 +09:00]] 版) ** IETF [6] [CITE@en[draft-abarth-origin-00 - The HTTP Origin Header]] ([TIME[2009-01-22 10:33:27 +09:00]] 版) [7] [CITE@en[(X)HTML5 Tracking]] ([TIME[2009-09-29 23:36:58 +09:00]] 版) [8] [CITE[IRC logs: freenode / #whatwg / 20090821]] ([TIME[2009-10-12 19:18:16 +09:00]] 版) [9] [CITE@en[Security/Origin - MozillaWiki]] ([TIME[2009-10-09 22:03:56 +09:00]] 版) [20] [CITE@en[The HTTP Sec-From Header]] draft-abarth-origin-01 の頃は [DFN[[CODE(HTTP)@en[[[Sec-From:]]]]]] という名前が提案されていました。 [10] [CITE[IRC logs: freenode / #whatwg / 20090929]] ([TIME[2009-12-02 08:29:55 +09:00]] 版) [11] [CITE[IRC logs: freenode / #whatwg / 20091002]] ([TIME[2009-12-04 00:35:25 +09:00]] 版) [12] [CITE[IRC logs: freenode / #whatwg / 20091204]] ([TIME[2009-12-27 16:46:13 +09:00]] 版) [13] [CITE@en[Security/Origin - MozillaWiki]] ([TIME[2010-10-06 06:03:55 +09:00]] 版) [14] [CITE[IRC logs: freenode / #whatwg / 20101109]] ( ([TIME[2010-11-18 23:22:34 +09:00]] 版)) [15] [CITE[drafts/origin.xml at master from abarth's ietf-websec - GitHub]] ( ([TIME[2011-02-13 13:01:41 +09:00]] 版)) [16] [CITE[IRC logs: freenode / #whatwg / 20110815]] ( ([TIME[2011-08-27 15:22:54 +09:00]] 版)) [17] [CITE[IRC logs: freenode / #whatwg / 20111022]] ( ([TIME[2011-10-23 18:08:47 +09:00]] 版)) [REFS[ - [21] '''[CITE@en[RFC 6454 - The Web Origin Concept]] ([TIME[2011-12-12 09:13:37 +09:00]] 版) ''' ]REFS] [107] [CODE(HTTP)@en[[[Origin:]]]] 欄の構文は次のように定義されていました [SRC[>>21]]。 [FIG[ [PRE(ABNF code)[ origin = "Origin:" [[OWS]] origin-list-or-null [[OWS]] origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list origin-list = serialized-origin *( SP serialized-origin ) serialized-origin = [[scheme]] "://" [[host]] [ ":" [[port]] ] ; <[[scheme]]>, <[[host]]>, <[[port]]> from [[RFC 3986]] ]PRE] ]FIG] [108] [[RFC 6454]] は、 [CODE(char)[[[SP]]]] 区切りのリストで複数の値を指定できるとしていました [SRC[>>21]]。 [110] [[要求]]がなされるまでに複数の[[起源]]が関わっている場合、 それをすべて列挙して[['''構わない''']] [SRC[>>21]] とされていました。 [EG[ [111] 例えば[[リダイレクト]]が発生した時、大元の[[起源]]と[[リダイレクト]]を行った[[起源]]を列挙して構いません。 ]EG] [112] しかし列挙の順序や[[鯖]]による解釈の方法については特に規定されていませんでした。 [118] 隣接する[[起源]]が[RUBYB[同じ]@en[identical]]であっては[['''なりません''']]。 そうなってしまう場合は片方だけ送信しなければ[['''なりません''']]。 [SRC[>>21]] [191] [[fetch]] (>>126) の定義においては[[リダイレクト]]の際に複数の値を [CODE(HTTP)@en[[[Origin:]]]] を入れることは認められていません。ただし明示的に禁じられているわけではなく、 自然に読むと複数にはならないというだけなので、実際には禁止する意図は無いかもしれません。 [222] [[CORS]] (>>213) でも[[鯖]]側の処理モデルにおいて、 [[リダイレクト]]の時に複数の値が指定され得ることに言及はされているのですが、 [[利用者エージェント]]側の処理モデル上はそうなる場合が記述されていません。 [126] [[fetch]] 操作においては、[[起源]]が呼び出し元により明示された場合、 それを [CODE(HTTP)@en[[[Origin:]]]] に使います。そうでない場合は「[[プライバシー]]重視」 な文脈として扱います。 [SRC[>>125]] [190] [[HTML]] や [[XHR]] の仕様上定義されたあらゆる [[HTTP]] [[要求]]は [[fetch]] 操作経由で発行されるので、従ってこれを実装している[[Webブラウザー]]からのあらゆる [[HTTP]] [[要求]]は何らかの [CODE(HTTP)@en[[[Origin:]]]] 欄を送出し得ることになります。 しかしよく読むといつ [CODE(HTTP)@en[[[Origin:]]]] 欄を送出するべきかは [[RFC]] も [[HTML]] も [[XHR]] も規定していません。明示的な[[起源]]の指定無しに [[fetch]] が呼び出された時は [[null]] を送信しなければならない (>>126 + >>116) ということになっていますが、 これも無条件に送信することを強制する意図があるのかは怪しいです。 [193] 実際の [[Webブラウザー]]は[[フォーム]]の[[提出]]や [[XHR]] などで [CODE(HTTP)@en[[[Origin:]]]] を送出しますが、通常の[[文書]]の [[navigation]] などでは送出しないものもあります。 [18] [CITE@en[Web Applications 1.0 r6941 Drop old origin definitions that no longer matter.]] ( ([TIME[2012-01-31 09:48:00 +09:00]] 版)) [19] [CITE[Widget Access Request Policy]] ( ([TIME[2012-02-04 04:00:27 +09:00]] 版)) [192] [CITE[Origin Header Proposal]] ( ([TIME[2011-12-28 22:11:55 +09:00]] 版)) [194] [CITE[446344 – Implement Origin header CSRF mitigation]] ( ([TIME[2012-02-29 23:10:51 +09:00]] 版)) [197] [CITE[Chromium Blog: Security in Depth: New Security Features]] ( ([TIME[2012-02-29 23:04:56 +09:00]] 版)) [198] [CITE[Scheme/Host/Port: RFC 6454 and RFC 6455]] ( ([TIME[2012-02-16 12:42:54 +09:00]] 版)) [199] [CITE[javascript - Force Safari to include Origin header in jQuery GET request - Stack Overflow]] ( ([TIME[2012-02-29 23:34:42 +09:00]] 版)) [204] [CITE@en-us[AJAX - Introducing Cross-domain Request (XDR)]] ( ([TIME[2012-02-29 23:41:40 +09:00]] 版)) [295] [[CORS]] における [CODE(HTTP)@en[[[Origin:]]]] [[ヘッダー]]の利用については、 [[CORS]] 仕様書に規定がありました。 [REFS[ - [213] [CITE@en-US[Cross-Origin Resource Sharing]] ([TIME[2012-03-03 09:26:46 +09:00]] 版) - [221] [CITE@en-US[Cross-Origin Resource Sharing]] ([TIME[2012-03-03 09:39:38 +09:00]] 版) - [212] [CITE@en-US[Cross-Origin Resource Sharing]] ([TIME[2012-03-03 07:13:53 +09:00]] 版) ]REFS] [303] [[著者]]が直接 [CODE(HTTP)@en[[[Origin:]]]] を指定することは、 [[XHR]] で禁じられていました [SRC[>>123]]。 ;; [304] 現在では [[Fetch Standard]] で禁じられています [SRC[>>302]]。 [REFS[ - [123] [CITE@en-US[XMLHttpRequest]] ([TIME[2012-02-28 13:24:26 +09:00]] 版) ]REFS] ** WHATWG [291] [[IETF]] の [[RFC 6454]] の [CODE(HTTP)@en[[[Origin:]]]] の定義は実際の [[Webブラウザー]]の実装と異なっていましたが、 [[IETF]] では手続き上改訂が難しい状況でした。 [292] [[Anne]] は、 [[WHATWG]] [[Fetch Standard]] において [[RFC 6454]] を参照しつつもより正確な定義を含めました [SRC[>>290]]。 [293] 2014年6月には [[URL Standard]] に [[URL]] の[[起源]]が追加され、 [[HTML Standard]]、[[URL Standard]]、[[Fetch Standard]] の3つの文書によって事実上 [[RFC 6454]] は廃止されました [SRC[>>310, >>311]]。 [REFS[ - [311] [CITE[Define URL's origin · c65766a · whatwg/url]] ([TIME[2014-07-01 04:50:13 +09:00]] 版) - [310] [CITE[Fix origin xref mess; obsolete ORIGIN · d94f125 · whatwg/fetch]] ([TIME[2014-07-01 04:49:04 +09:00]] 版) ]REFS] ;; [294] 詳しくは[[起源]]の歴史の項を参照してください。 * 実装 [205] [CODE(HTTP)@en[[[Origin:]]]] はまだ十分 [[interoperable]] に実装されていません。 別の[[起源]]への [[XHR]]+[[CORS]] [[POST]] では [[Chrome]] も [[Firefox]] も [CODE(HTTP)@en[[[Origin:]]]] を送りますし、 [[XDR]] では [[IE]] も送りますが、[[フォーム]]の [[POST]] で送るのは [[WebKit]] だけです。 また、同じ[[起源]]の時に送るのも [[Chrome]] だけです。 [TIME[2012-03-01T14:14:48.300Z]] [289] [[Chrome]] は [[POST]] したページを再読み込みした時に [CODE(HTTP)@en[[[Origin:]]]] を送らない(?)ようです。 [TIME[2014-04-25T11:19:32.000Z]] * 関連 [124] [CODE(HTTP)@en[[[Origin:]]]] を [CODE(DOMi)@en[[[XMLHttpRequest]]]] などで[[著者]]が指定することはできません [SRC[>>123, >>302]]。 [305] [CODE(HTTP)@en[[[Origin:]]]] が指定された [[HTTP要求]]を、 [[CORS要求]]といいます [SRC[>>306]]。 [309] [CITE@en[RFC 6454 - The Web Origin Concept]] ( ([TIME[2014-06-22 05:12:22 +09:00]] 版)) [312] ( ([TIME[2011-07-16 05:29:36 +09:00]] 版)) [23] [[Chrome]] 40 になって、 [CODE(HTML)@en[[[]]]] で [CODE(HTTP)@en[[[never]]]] や [CODE(HTTP)@en[[[origin-when-crossorigin]]]] を指定すると [CODE(HTTP)@en[[[Origin:]] [[null]]]] が送られるようになったみたいです。 [TIME[2015-01-29T10:01:03.00Z]] [24] [CITE@en[Web Applications 1.0 r4011 Synchronise with the latest Origin spec rules and semantics.]] ([TIME[2009-09-29 08:51:00 +09:00]] 版) [25] [CITE@en[Web Applications 1.0 r2525 CSRF mitigation -- add Origin header to all non-GET requests.]] ([TIME[2008-12-02 20:26:00 +09:00]] 版) [27] [CITE@en[Fix #91: rename force-Origin-header flag to omit-Origin; unset it whe… · whatwg/fetch@dfb8bff]] ([TIME[2015-09-08 15:06:31 +09:00]] 版) [29] [CITE@en[force-Origin-header flag set for no-cors requests · Issue #91 · whatwg/fetch]] ([TIME[2015-09-08 15:10:59 +09:00]] 版) [30] [CITE@en[Align with Fetch: force-Origin-header flag is now omit-Origin-header … · whatwg/xhr@bb19040]] ([TIME[2015-09-08 15:13:25 +09:00]] 版) [31] [CITE@en[remove force-origin flag · w3c/beacon@5f1a2e7]] ([TIME[2015-12-16 12:35:23 +09:00]] 版) [32] [CITE@en[Re: ''''''[''''''referrer'''''']'''''' Should referrer policy change value of the Origin header?]] ([[Mike West]] 著, [TIME[2016-02-02 15:45:42 +09:00]] 版) [33] [CITE@en[Should we send an Origin header for no-cors fetches? · Issue #225 · whatwg/fetch]] ( ([TIME[2016-05-17 13:12:19 +09:00]])) [34] [CITE@en[Consider setting omit-Origin-header-flag for same origin requests · Issue #31 · whatwg/xhr]] ( ([TIME[2016-05-17 13:13:53 +09:00]])) [35] [CITE@en[1272302 – navigator.sendBeacon doesn't set Origin header for same-origin request]] ( ([TIME[2016-05-17 13:14:45 +09:00]])) [39] [CITE@en[Remove request's omit-Origin-header flag]] ([[annevk]]著, [TIME[2016-12-09 16:37:16 +09:00]]) [40] [CITE@en[Fetch: remove omit-Origin-header flag]] ([[annevk]]著, [TIME[2016-12-08 03:56:35 +09:00]]) [41] [CITE@en[Properly set the Origin header for WebSocket requests]] ([[nox]]著, [TIME[2017-03-27 20:35:48 +09:00]]) [26] [CITE@en[IETF HTML5 Meeting March 2009 - W3C Wiki]] ([TIME[2018-04-21 13:28:11 +09:00]]) [43] [CITE@en[Fix Origin header and "no-cors" redirects behavior]] ([[annevk]]著, [TIME[2018-05-28 18:17:18 +09:00]]) [44] [CITE@en["no-cors" POST and 307/308 redirects · Issue #593 · whatwg/fetch]] ([TIME[2018-06-01 01:01:17 +09:00]]) [45] [CITE@en[Avoid using the CORS flag to reset request's origin in redirects by annevk · Pull Request #594 · whatwg/fetch]] ([TIME[2018-06-01 01:01:59 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [46] [CITE@en[Does Cloudflare support Cross-origin resource sharing (CORS)? – Cloudflare Support]] ([TIME[2018-10-01 17:30:07 +09:00]]) ]FIGCAPTION] > The Cloudflare CDN identifies cache items based on the Host Header + Origin Header +  Path and Query, which supports different objects using the same host header, but different origin headers ]FIG] [47] [CITE@en[Editorial: use %s ABNF notation]] ([[annevk]]著, [TIME[2018-12-12 20:25:58 +09:00]]) [48] [CITE@en[Make the Origin header honor Referrer Policy (outside of CORS)]] ([[JuniorHsu]]著, [TIME[2019-06-27 18:38:15 +09:00]]) [52] [CITE@en[Make the Origin header honor Referrer Policy (outside of CORS)]] ([[JuniorHsu]]著, [TIME[2019-06-27 18:38:15 +09:00]]) [63] [CITE@en[Let Origin header honor referrer policy for non CORS request by JuniorHsu · Pull Request #908 · whatwg/fetch]] ([TIME[2020-07-13 14:45:16 +09:00]]) [64] [CITE@en[Editorial: remove the CORS flag]] ([[annevk]], [TIME[2019-11-11 19:02:42 +09:00]], [TIME[2021-03-16T07:19:17.000Z]]) [65] [CITE@en[Remove the CORS flag by annevk · Pull Request #960 · whatwg/fetch]] ([TIME[2021-03-16T07:24:35.000Z]])