リファラ

Referer: ヘッダー (HTTP)

[115] リファラー (referrer) は、 fetch の発生元の URL です。

[111] Referer:は、 HTTP などで使われる頭欄で、リンク先の資源を取り寄せる時に、 その参照元を示すために使います。

仕様書

呼称

[42] Referer は referrer の typo だけど、もはや直しようがない。

[45] HTTP 以外は正しく referrer と呼んでいたりする。

[132] Referrer を採用しているもの:

[133] Referer を採用しているもの:

意味

[134] Referer: ヘッダーは、 対象URLの取得元である資源URL利用者エージェントが指定するものです >>65

[135] 対象URLを得たのが URL を持たないものからである場合 (例えばキーボードからの入力やからの選択である場合) には、 Referer: を含めないか、 about:blank を指定するかのいずれかとしなければなりません >>65

[81] 実際に about:blank を送る利用者エージェントが現存するのかは不明です。

構文

[82] Referer: ヘッダーの値は、 RFC 3986 absolute-URI または partial-URI とされています。ただし、 素片識別子userinfo を使ってはなりません>>65

  1. |
    1. 絶対URL
    2. 部分URL

[186] Webブラウザーは必ず絶対URLとします。 部分URLとする実装があるのかは不明です。 受信者が部分URLを正しく扱えない虞がありますから、 クライアント絶対URL生成するべきです。


[136] URL URL から参照元として使う URL を得るには、 Strip url for use as a referrer >>60、 すなわち次のようにします。入力として起源のみフラグを持ちます。

  1. [137] URLno-referrer なら、
    1. [138] no-referrer を返し、ここで停止します。
  2. [92] URLscheme局所schemeなら、
    1. [94] no-referrer を返し、ここで停止します。
  3. [95] URL利用者名を、空文字列に設定します。
  4. [96] URL合言葉を、 null に設定します。
  5. [97] URL素片を、 null に設定します。
  6. [98] 起源のみフラグが設定されていれば、
    1. [99] URLpath を、 null に設定します。
    2. [140] URLquery を、 null に設定します。
  7. [93] URL を返します。

[139] 他にも、 file: URLブラウザー拡張URL scheme などを no-referrer とする必要があるかもしれません。

[187] 起源のみかどうか、あるいは no-referrer が使われるかどうかは、 参照元ポリシーにより決まります。

要求の参照元の決定

[149] 要求は、参照元 (referrer) を持ちます >>105。 その値は、 no-referrerclientURL のいずれかで、既定値は client です >>105

[150] HTTP は、参照元ページが保安プロトコルで受信したものの場合に、 利用者エージェント非保安 HTTP要求Referer: ヘッダーを送信してはならない >>65 と規定していました。これは現在も原則として維持されていますが、 著者の明示的な指定により上書きできるようになっています。

[85] main fetch における要求参照元の決定は、次のようにします >>107

  1. [151] 要求参照元ポリシー空文字列で、 要求クライアントnullないなら、
    1. [152] 要求参照元ポリシーを、要求クライアント参照元ポリシーに設定します。
  2. [153] 要求参照元ポリシー空文字列なら、
    1. [154] 要求参照元ポリシーを、 no-referrer-when-downgrade に設定します。
  3. [155] 要求参照元no-referrer 以外なら、
    1. [156] 要求参照元を、 要求determine request's referrer を適用した結果に設定します。

[157] 要求について Determine request’s Referrer は、次のようにします >>3

  1. [158] 設定群を、要求クライアントに設定します。
  2. [159] 文書を、 null に設定します。
  3. [160] 要求参照元URL なら、
    1. [161] 参照元源を、要求参照元に設定します。
  4. [162] それ以外で、要求参照元clientなら、
    1. [163] 設定群大域オブジェクトWindow なら、
      1. [164] 文書を、設定群有責閲覧文脈文書に設定します。
      2. [213] 文書起源不透明起源なら、
        1. [214] no-referrer を返し、ここで停止します。
      3. [215] 文書iframe srcdoc文書である間、繰り返し、
        1. [216] 文書を、文書閲覧文脈閲覧文脈包含子節点文書に設定します。
      4. [217] 参照元源を、文書URLに設定します。
    2. [165] それ以外なら、
      1. [218] 参照元源を、設定群作成URLに設定します。
  5. [177] 参照元URLを、参照元源Strip url for use as a referrer を適用した結果に設定します。
  6. [178] 参照元起源を、参照元源Strip url for use as a referrer を適用した結果に設定します。このとき起源のみフラグをに設定します。
  7. [224] 参照元URL直列化した結果の長さ4096 より大きい場合、
    1. [225] 参照元URL を、 参照元起源に設定します。
  8. [226] 情報漏洩を最小化すべく何らかの基準に則り参照元URL参照元起源を変更して構いません

    [227] URL起源にまで縮めたり、 ホストを変更したり、 空文字列に置き換えたりして構いません。

  9. [179] 方針を、要求参照元ポリシーに設定します。
  10. [180] downgrade を、
    ... のすべてを満たすかどうかに設定します。
  11. [166] 交差起源要求を、要求交差起源要求かどうかに設定します。
  12. [188] 次の表に従って値を返します。
    policy
    方針
    same-origin
    交差起源要求
    cross-origin
    交差起源要求かつ非downgrade
    downgrade
    交差起源要求かつdowngrade
    policy
    no-referrer
    same-origin
    no-referrer
    cross-origin
    no-referrer
    downgrade
    no-referrer
    policy
    origin
    same-origin
    参照元起源
    cross-origin
    参照元起源
    downgrade
    参照元起源
    policy
    strict-origin
    same-origin
    参照元起源
    cross-origin
    参照元起源
    downgrade
    no-referrer
    policy
    unsafe-url
    same-origin
    参照元URL
    cross-origin
    参照元URL
    downgrade
    参照元URL
    policy
    no-referrer-when-downgrade
    cross-origin
    参照元URL
    same-origin
    参照元URL
    downgrade
    no-referrer
    policy
    same-origin
    same-origin
    参照元URL
    cross-origin
    no-referrer
    downgrade
    no-referrer
    policy
    origin-when-cross-origin
    cross-origin
    参照元起源
    same-origin
    参照元URL
    downgrade
    参照元URL
    policy
    strict-origin-when-cross-origin
    cross-origin
    参照元起源
    same-origin
    参照元URL
    downgrade
    no-referrer

[228] 令和元(2019)年の改訂で、利用者エージェントはプライバシー保護のための任意の改変を加えて良いとの規定が追加されました。 状況に応じたWebブラウザー依存の特例的な措置が現に行われている (または行われようとしている) のを追認するものですが、 明確な範囲と挙動を仕様書に記述せず任意の措置を認めてしまっており、 仕様書アルゴリズムの空文化を招いてしまいました。 仕様書解釈論的には任意の挙動が適合することになって、 規定の意味をなしません。

Referer: 欄の中身

[76] Referer URI として報告例のある scheme は、

http
HTTP
https
HTTP over SSL/TLS
news
Usenet (news://foo.example/)
about
about:blank (一時の Classic Mozilla の不具合らしい。)
file
Local file
webster
Webster://Internal/StatusPage
xxxx
串による書き換え

こんなものかな。 gopher とか ftp とかもあってもよさそうだけど、確認されていますか?

[84] 普通の一般目的利用者エージェントは、 data:file:URLReferer: で送りません。 >>65

相対 URI

[144] >>82 によればこの欄の値は相対 URI でも良いみたいですが、 そういうのは見たことがないですね。 絶対 URI にした方がいい気がします。

[142] SuikaWiki の Referer plugin も相対 URI には実は対応していなかった気が。

[143] 一部の版の IE や一部の検索円陣索引付け器が相対 URI で Referer: を送ってくるそうです。

[54] それから、一部の腐った索引付け器は www.example.com/ のような相対 URI もどきを送りつけるそうです。

素片識別子

[145] Bug 179400 - URI fragment present in HTTP Referer http://bugzilla.mozilla.org/show_bug.cgi?id=179400

Mozilla では、最近 (2002年末) まで Referer URI に素片識別子もつけて送ってしまうという不具合がありました。 (HTTP RFC ははっきり禁止しています >>82。)

多分他にも素片識別子を送る UA は少なくないと想像されます。

ロボットの身元申告

[146] 特に昔のロボットなんかは、 その身元を表す文書がある URIReferer: 欄で送ってくることがありました。

身元を表明するという意味ではよい心がけですが、 本来の使い方からそれており好ましいことではありません。 幸い最近はそういうのは減っているようです。

[147] なつみかんなんかは設定項目がわざわざあって、 アンテナの結果表示 URI を指定するようにと指導されていました。 リンクを広義に解釈すれば必ずしも間違いとも言い切れませんが、 なんだかなあという気はしました。

[148] なお、身元申告には本来 From: 欄を使うのがよいとされています。 実際、最近のロボットは From: 欄に連絡先メイル・アドレスを入れてきます。 但し、 From: 欄の中身はあくまでメイル・アドレスでして、 参照して欲しい URI 参照を入れることは残念ながらできません。

ですから、身元申告文書の URI 参照を入れる標準の頭欄で最も適切なのは User-Agent: 欄です。 (しかし、単なる文字列の一部でしかないので機械処理ができない諸刃の剣。素人は User-Agent: 欄に入れるときには注釈にしないといけないことにも注意されたし。)

文脈

[141] 利用者エージェント要求Referer: ヘッダーを指定することができます。

[75] しかしこのヘッダーは必須ではありません。対象URL利用者の直接入力など他の資源以外に由来する場合や、 利用者の設定や著者の指定により Referer: ヘッダーを送信しないことになっている場合は、 このヘッダーは送信されません。

[219] WebSocket接続の確立では、参照元ポリシーに関わらず、 Referer: は使われません。

変な Referer

[80] Referer: <!--#exec cmd="ls"--> のようなものが送られてくることがあります。 Referer を記録していて、 その結果が HTML ファイルに出力されて、 そのファイルSSI が有効になっているのに、 HTML 化時の逃避が行われていない、 なんていう一昔前にあちこちで起こっていそうな光景 (今はしらん。) を想像しているのでしょうね。

ls だからよいもの、 Apacheroot で動いている上に rm -fr / だった日には(w

(名無しさん [sage] 2005-06-03 11:40:21 +00:00)

[5] 栞から辿った場合に、 "Referer: bookmarks" をつける UA があるみたいです。 (User-Agent:欄の値: "Mozilla/4.7 [ja] (Macintosh; U; PPC)")

  • [55] 最近の Mozillaいつからかしりませんが栞の項目の設定画面で、その栞を挟んだ URI を参照するときに使われる Referer の値が設定できるみたいです。

Referer 漏れ

[127] IE で、特定の条件でリンクを辿っていないのに閲覧した無関係の URI が送られることがある。

[57] 同じような Referer 漏れに見える、 2種類の現象があります。

  • Referer は送られない様に設計されているはずなのに、なぜか条件が揃うと送られてしまう — 90年代後半に幾つかのブラウザで見つかったバグ。
  • 何も考えてないので、よく考えれば (あるいは現在の価値観からすれば) 送らないで欲しいのだけど、 そのブラウザの仕様上「正しく」 送られてしまう — 90年代中頃までに幾つかのブラウザに見られた状況。

[4] 古い NetscapeNavigator でも起こったようです。

[56] >>22 Mosaic Netscape 0.9 もそんなもんです。 古い時代は今とは違った privacy 感覚でしたから。。。

  • [24] 2002-12-13 (金) 18:39 >>10: どっかの糞 UA または privacy を謳う串の類が、適当にそこのサーバーのルートを Referer として送ってくるんじゃないか? だれか検証してみてくれ。
  • [41] >>127- の Referer 漏れとちょっと趣が異なりますが、 JavaScriptlocation.href を使って飛んだ場合に、 UA によっては Referer が送られます。普通は問題ないのですが、この JavaScript が Bookmarklet だった場合で、例えば利用者に入力を求めてその入力に従って移動するようなものであったら、全く関係ない URI が Referer として送られてしまうことになります。 (Mozilla とかでなります。送られるのは javascript: ではなくて既に表示されている URI なんですね)

[68] スラッシュドット ジャパン | EZwebブラウザに不正なReferer送出を行う不具合 http://slashdot.jp/security/05/12/09/1021257.shtml (名無しさん 2005-12-10 03:12:19 +00:00)

[69] JP Vendor Status Notes http://jvn.jp/jp/JVN%2315243167/index.html (名無しさん 2005-12-10 03:19:09 +00:00)

参考

処理

[189] Referer: ヘッダーは、例えば次のような用途に使うことができます >>65

[74] 外行きの要求Referer: ヘッダーをすべて除去する中間器もあることが知られています。 しかしそれによって Referer: ヘッダーによる CSRF 対策をが行えなくなりますから、より利用者を危険に晒すことになりかねません。 >>65

[86] 中間器利用者エージェントが情報漏洩を防止したいときは、 内部ドメイン名ペンネーム (pseudonym) に置き換えたり、 pathquery を削除したりするなどの変更に留めるべき (ought to) です。 >>65

[87] 中間器は、 Referer: ヘッダーの値の URL schemehost要求対象と同じ時は、これを編集したり、 削除したりするべきではありません >>65


[170] ジョブは、 参照元 (referrer) を持ちます。 値は URL または null です。 >>169

Referer による接続制御

[1] Referer: 欄の値により、接続制御することがあります。 例えば画像資源において、 Referer: 値が自分のサーバー内を指すものと思われないときには資源を渡さないという方法は良く使われます。

しかしこの方法は Referer を返さない利用者エージェントに対しては正しく動作しない可能性が強いですし、そうでなくても World Wide Web の最大の特徴の一つであるハイパーリンクに対して著しく不利益を与えるものです。

ですから、 Referer による接続制限は、それによる影響を十分に理解した上で、どうしても必要な場合においてのみ行うように、慎重に検討する必要があります。また、その場合においても Referer を返さない利用者エージェントに対して不利益がないように十分考慮しなければならないでしょう。 (Referer を返す UA でご利用下さい、はそれだけで既に不利益です。)

[2] なお、 Referer は HTTP において必須の欄ではありません。プライバシーの観点から値を与えない実装も数多く存在します。

Referer による逆リンク作成

[66] Referer 情報は鯖側で様々な用途に利用できますが、仕様書 (RFC 2616) にも言及がある代表的な使用例の一つが逆リンク一覧の作成です。

Referer 情報を見ることにより、 ある資源に関する言及の所在をその資源著者が容易に発見できます。

[67] Referer 情報は閲覧者が直前に何を見ていたかの情報であり、 ともすればプライバシーの問題にもなりかねません。 RFC 2616利用者エージェントに、利用者が referer 情報を送信するかどうかを選択できることを求めています。 Referer 情報を逆リンクなどの形で公表されたとしても、 閲覧者がそれを著者に抗議したり、 不快感を示したりするのはお門違いです。

いつ Referer を送るか

[11] Referer: 欄に値を入れて送る場合には、例えば次の場面があり得ます。

[16] どういう時に Referer URI を送るかは、実装依存です。 (サーバー側は何らの仮定もするべきではありません。) ただ常識的に考えて、 Referer を送る場合は >>12 は必須でしょう。

[63] フレームとしてのリンク (frame) は実際に UA によって Referer: を送ったり送らなかったりするようです。 (名無しさん [sage] 2005-02-03 23:22:24 +00:00)

どういうときに Referer を送らないか

[17] 利用者のプライバシーを考えつつも、分析目的の Referer 情報をサーバーに提供するために、例えば次のような実装が考えられます。

  • [18] 同じサーバーの URI なら送信する。
  • [19] 特定の{サーバー|種類(scheme)}の URI なら送信{する|しない}。

  • [20] 例えば検索円陣の URI は送信しないで欲しい、 のような利用者の要望に応えられる実装が望ましいでしょう。
  • [34] 2002-12-17 (火) 15:01 Name_Not_Found: >>32 のように、 FQDN 以外を参照する URI は送信するべきではないでしょう。 Private などの特殊-IPv4-address, 特殊IPv6アドレスも同様。
  • [46] https: な世界から http: な世界に移るときに Referer が送られるのを気にする人もいます。多分本質的には気になることではないと思うのですが、安全なはずの世界の側のへたれ実装が、 https: だからといって合言葉に準じるものを URI に含めていたりしたら問題ですね。まあそんな設計者が悪いんですが。
  • [47] それとか、素の HTTP であっても、認証が使われている世界から使われていない世界、あるいは違う realm な世界に行く時にも注意が必要です。もちろんこっちの場合も、合言葉やそれに準じるものを URI に使ったりするほうが悪いんですが。それに制限領域だからといって URI がばれると困るような設計はどうかと思うんですが。だけど現実問題、やっぱり >>46 もこれも気にした方がいいのかもなあ。
  • [48] また、 HTTP でも ftp: の場合でもその他の場合でも、 URI の最初の方に利用者名や合言葉を含めることができますが、安全性と個人情報保護の観点から、必ず削除するように注意した方がよいと思われます。
  • [49] MUA にブラウザ部品を流用している UA とかでは、内部的に使っているメッセージの URI とかが流用してしまわないように注意するべきです。
    • でもニュースの記事なんかなら、別にメッセージIDの URI が送られても構わない気がします。
    • 多くの実装の形態で言うところのフォルダとかの区分ごとに利用者が指定できるのが一番いいでしょうか。
    • その指定に関わらず spam と判定されているメッセージの場合は絶対に送らないとか、細かい設定が出来るとなお良いですね。
  • [50] 付属文書系URI とかなら file: 同様に送らないようにする、とかの UA の実装ごとの調整も必要でしょう。
    • scheme を利用者又は追加モジュールが容易に追加できる形態の UA だったら、 default では送らないことにしておいて、 特に指定 (モジュールの定義で指定でも、利用者が指定でも、 なんでもいい。) した時にだけ送るようにするのがいいかも。
  • [58] >>19,>>50 ブラウザにとって未知の scheme は、とりあえず送らないを既定にしておく方が色々安全でしょうね。

[220] 内部名が使われているURLを非内部名サーバーに送ってほしくないですが、 そのような制限はなく、送られてしまいます。

著者による Referrer 送信の制御

[114] HTML - Referrer を制御する - Qiita ( ( 版)) http://qiita.com/wakaba@github/items/707d72f97f2862cd8000

利用者の設定

[83] Referer: によって要求の文脈や閲覧の履歴を晒すことによってプライバシー上の問題が生じるかもしれません。 例えば URL にはアカウント名など個人情報が含まれるかもしれませんし、 防火壁内などの秘密の資源URL かもしれません。 >>65

[103] 利用者エージェントは、 Referer: ヘッダーを送信しないオプションを利用者に提供して構いません >>102

[104] しかしサーバーReferer: ヘッダーによってアクセス制御を行っていることがありますから、 まったく Referer: ヘッダーを送らないクライアントWeb互換ではありません。

Proxy などによる削除

[197] Referer は privacy に関わる情報であることから、 これを削除する機能を持ったがあります。 (本来は情報を送る UA 側で利用者が制御できるのがあるべき姿でしょうが、 そうでない UA が実際には多いですから。)

[198] しかし、ただ削除するだけなら何ら問題はないのですが、削除して代わりに "Blocked by Proxy-name" のような文字列を挿入するものがあります。 これは規格違反であることは明らかですから、串作者はこうした文字列を入れてはなりません。利用者もそのような製品はできるだけ使わず、 代替製品があればそちらを使用することが望ましいでしょう。

挿入されるいかれた文字列の例:

[201] xxxx:++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ のように、伏字にして送ってくる糞 privacy 保護ソフトウェアがあります。

参考:

Blocked by ... (www.example.com) てなのもあるそうです。

[52] Blocked by Norton

こんなところでまでわざわざ自己主張しなくたってねぇ。

Document インターフェイス referrer 属性

[204] 文書は、参照元 (the document's referrer) を持ちます。 既定値は、空文字列です。 >>91

[209] navigate は、作成した文書参照元を、 元の要求参照元の値に設定します。それが no-referrer だった場合には、空文字列のままとします。

[210] 閲覧文脈の作成は、作成した文書参照元を、 作成子閲覧文脈文書の番地に設定します。

[28] Document インターフェイスreferrer IDL属性は、 文脈オブジェクト参照元を返さなければなりません >>205

[1237] こちらは referer ではなく referrer です。

歴史

[109] ncsa-mosaic/CHANGES at master · alandipert/ncsa-mosaic ( ( 版)) https://github.com/alandipert/ncsa-mosaic/blob/master/CHANGES#L20

HTTP

[88] RFC 1945 (HTTP/1.0) 10.13; RFC 2068 (HTTP/1.1) 14.37; RFC 2616 (HTTP/1.1) 14.36 Referer

The Referer [sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained. (the "referrer", although the header field is misspelled.) This The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field must not MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.

Referer [おっと!] 要求頭欄によりクライアントはサーバーの益がために Request-URI を得た資源のアドレス (URI) (「referrer」。 頭欄は綴りが間違っていますが。) を指定することが出来ます。 Referer 要求頭によりサーバーは興味, 記録, キャッシュ最適化その他の目的で資源への逆リンクの一覧を生成出来ます。 維持管理で廃止された又は綴りの間違ったリンクを追跡することも出来ます。 Referer 欄は Request-URI が URI を持たない資源, 例えば利用者の鍵盤からの入力から得たものである時には送ってはいけません

  • Referer = "Referer" ":" ( absoluteURI | relativeURI )

Example:

  • Referer: http://www.w3.org/hypertext/DataSources/Overview.html

If a partial URI is given the field value is a partial relative URI, it should SHOULD be interpreted relative to the Request-URI. The URI must not MUST NOT include a fragment. {2616} See section 15.1.3 for security considerations.

欄値が相対 URI の場合、これは Request-URI (要求 URI) との関係であると解釈されるべきものです。 URI は素片 (fragment) を含んでいてはなりません。安全性についての第15.1.3節も参照して下さい。

{1945,2068} Note: Because the source of a link may be private information or may reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information.

注: この部分は RFC 2616 では 5.1.3 に移動しました。

注: 注記のない修正は、 RFC 1945 → RFC 2068 の変更点。

[77] RFC 1945 (HTTP/1.0) 12.4; RFC 2068 (HTTP/1.1) 15.4; RFC 2616 (HTTP/1.1) 15.1.2 (抜粋)

The Referer field {2616} header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can be abused if user details are not separated from the information contained in the Referer. Even when the personal information has been removed, the Referer field may {2616} header might indicate a private document's URI whose publication would be inappropriate.

Referer 頭は、読解パターンを学習することや、 逆リンクを描くことを可能にします。これは非常に有用でありますが、 利用者の詳細が Referer に含まれる情報から分離されていなければ、 その力は濫用され得ます。個人情報が削除されるとしても、 Referer 頭は公表が不適切である私的な文書の URI を示しているかもしれません。

[79] RFC 2616 (HTTP/1.1) 15.1.3 (抜粋)

Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information.

リンクの始点が私的な情報であったり、本来私的な情報源を晒すことになったりするかもしれませんから、 Referer 欄を送るかどうかを利用者が選択できるようにすることを強く推奨します。 例えば、ブラウザ・クライアントでは、公開で閲覧するか匿名で閲覧するかの切替器を用意して、 RefererFrom の情報の送信を有効にするか無効にするか指定するようにできます。

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

クライアントは、参照している頁が安全なプロトコルで転送されたものであれば、 (安全でない) HTTP 要求で Referer 頭欄を含めるべきではありません

[192] RTSP/1.0 (RFC 2326 12.30 Referer)

See [H14.37]. The URL refers to that of the presentation description, typically retrieved via HTTP.

[H14.37] 参照。 URL は、 (典型的には HTTP を介して取り出した) 表現記述のものを参照します。

[116] Re: History of device independence, User-Agent header? ( (Sean B. Palmer 著, 版)) http://lists.w3.org/Archives/Public/public-webhistory/2014Jul/0002.html

document.referrer

[206] document.referrerDOM0 で導入されました。

[207] W3CDOM1 HTMLSVGMathML でこれを標準化しましたが、 なぜか Document ではなく、各言語ごとの子インターフェイスメンバーとしていました。

[208] リンクを辿ってきたのではないような場合には、 HTML と SVG では空文字列に、 MathML では null になると規定していました。

[29]

[1240] Document Object Model for MathML ( ( 版)) http://www.w3.org/TR/2001/REC-MathML2-20010221/appendixd.html#dom_Document

[1241] Document Object Model for MathML ( ( 版)) http://www.w3.org/Math/DOM/mathml2/appendixd.html#dom_Document

00年代の実装

[78] Mozilla では、 View->Page Info->General->Referring URL に Referer として送られた URI が出ます。

[193] Apache の log では、既定では、 "http://www.example.com/" のように記録されますが、 Referer: 欄自体が送られてこなかったときには "-" になります。 空 (または空白だけ) の Referer: 欄が送られてきたときには、 "" になります。 Referer: - が送られてきたら、 "-" になりました。

[53] Referer リクエストヘッダの除去 http://www.st.ryukoku.ac.jp/~kjm/security/memo/referer.html

[194] 2002-11-04 (月) 13:45 Name_Not_Found InternetExplorer で現時点で Referer をつけない方法はありません。代わりに >>197 のような串を使うのが良いでしょう。

[195] >>194 少々面倒ですが、リンクを (マウス) 引っ張っ (ドラッグし) て、「アドレス」欄などに落と (ドロップ) したら Referer は送られません。

この方法はMozilla でも、タブの上に drag & drop とかすれば使えます。普段は Referer を送るけど、特定の場合には送らないというのに便利。

[196] 2002-12-25 11:53 >>195: でも Mozilla 1.2.1 でそれやったら残ったことがあった。残らないこともあった。変だなあ

HTML5

[129] (X)HTML5 Tracking ( 版) http://html5.org/tools/web-apps-tracker?from=4328&to=4329

[103] HTML5 Revision Tracker ( 版) http://html5.org/tools/web-apps-tracker?from=4726&to=4727

[104] HTML5 Revision Tracker ( 版) http://html5.org/tools/web-apps-tracker?from=4726&to=4727

[130] Request Headers in the HTTP protocol ( ( 版)) http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z14

[106] 141641 – disabling cross-site HTTPS referrers breaks sites [was: when leaving https, should send host+port as referrer instead of no referer] ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=141641

[131] Web Applications 1.0 r7341 Attempt to actually define what Referer headers are used for a whole host of things that were poorly defined. Also: cleanup of a bunch of editorial mistakes I found from past such attempts. Mark every fetch algorithm use for sanity in the future. Block data:, javascript:, and about:blank referrers. Note: This relies on not-yet-done changes to CORS and XHR. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7340&to=7341

[108] IRC logs: freenode / #whatwg / 20120912 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20120912

[120] Web Applications 1.0 r8791 Make appcache requests have no referrer, since it's not clear what referrer to use. ( ( 版)) https://html5.org/r/8791

<meta name=referrer>

[1238] [whatwg] <meta name="referrer"> ( ( 版)) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-October/033617.html

[1239] Meta referrer - WHATWG Wiki ( ( 版)) http://wiki.whatwg.org/wiki/Meta_referrer

CSP

[1246] Bug 61576 – Consider adding "scrub-referrer" directive to CSP ( ( 版)) https://bugs.webkit.org/show_bug.cgi?id=61576

[1247] Content Security Policy 1.1 ( 版) https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#referrer

[1248] restrict-referrer-leakage.txt on Ticket #127 – Attachment – tahoe-lafs ( ( 版)) https://tahoe-lafs.org/trac/tahoe-lafs/attachment/ticket/127/restrict-referrer-leakage.txt

[1249] Privacy/Features/Shortened HTTP Referer header - MozillaWiki ( ( 版)) https://wiki.mozilla.org/Privacy/Features/Shortened_HTTP_Referer_header

[1250] Protecting Privacy with Referrers ( ( 版)) http://www.facebook.com/notes/facebook-engineering/protecting-privacy-with-referrers/392382738919

[1251] [whatwg] Feedback on Meta referrer ( (Adam Barth 著, 版)) http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0243.html

[1252] ISSUE-39: Discuss CSP relevant use cases for possibly including Meta Referrer as a CSP directive - Web Application Security Working Group Tracker ( ( 版)) http://www.w3.org/2011/webappsec/track/issues/39

[1253] scrub-referrer directive? ( (Adam Barth 著, 版)) http://lists.w3.org/Archives/Public/public-web-security/2011May/0001.html

[1254] Issue 309551 - chromium - CSP 1.1: Implement 'referrer' directive. - An open-source project to help move the web forward. - Google Project Hosting ( ( 版)) https://code.google.com/p/chromium/issues/detail?id=309551

[1255] Bug 25973 – CORS preflight referrer header. ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=25973

[1256] Put in Referrer Policy hook link · d5fc282 · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/d5fc28228d0842680e3a33a8c1a7d215315d13ef

[117] [REFERRER] Where does "Determine request’s Referrer" get its URL from? ( (Ian Hickson 著, 版)) http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0101.html

[118] Referrer Policy ( ( 版)) http://www.w3.org/TR/2014/WD-referrer-policy-20140807/

[119] CSP2: Delegate definition of 'referrer' to Referrer Policy. · d5483ae · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/d5483ae3cb199798cdd44d5c85c2482e7f992501

[121] REFERRER: Ignore empty strings. · 58d5d78 · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/58d5d7841d31f8e16fdde63da56cc9b08efadf13

[122] REFERRER: Ignore case when evaluating tokens. · 0a26369 · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/0a263697170b88524c0be685a54f16711a6a0e14

[123] REFERRER: Be a bit more specific about case-insensitivity. · a30ed4e · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/a30ed4e5cded7f42bd5f5dfc65a194587f54ccd6

[8] Referrer attribute · Issue #409 · w3c/webappsec ( 版) https://github.com/w3c/webappsec/issues/409

[21] Referrer and cross-origin CSS · Issue #413 · w3c/webappsec ( 版) https://github.com/w3c/webappsec/issues/413

[40] Referrer-Policy: も参照。

URL 規定の整理

[1242] Web Applications 1.0 r7710 Integrate with URL standard. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7709&to=7710

[1243] Web Applications 1.0 r7762 I totally broke document.referrer a few weeks ago. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7761&to=7762

[1244] [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-July/040031.html

[1245] [whatwg] Question about document.referrer (and document.URL, document.location.href) when IDN domains are in use ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-September/040748.html

[124] Web Applications 1.0 r8848 fix a mess I made with 'referrer source' recently ( ( 版)) https://html5.org/r/8848

[125] Web Applications 1.0 r8853 Drop the 'responsible document' concept. This also changes the referrer to use when launching a nested worker to be the URL of the outer worker instead of the URL of the outer Document, which made no sense really. ( ( 版)) https://html5.org/r/8853

[6] Fix the order of CSP, HSTS, Mixed Content, and Referrer https://www.w3.o... · b8c2c49 · whatwg/fetch ( 版) https://github.com/whatwg/fetch/commit/b8c2c4964c233cd3616042c04e2c14e0ff25485d

[25] Integrate Fetch into HTML · whatwg/html@7c5555a ( 版) https://github.com/whatwg/html/commit/7c5555a16f2920c02244c10756bb2f1a11e87a22

[26] Never send a referrer with hyperlink auditing pings · whatwg/html@faec3a5 ( 版) https://github.com/whatwg/html/commit/faec3a50ea181f322ab9819975e285ced34a0308

[27] Use USVString for document.domain/referrer/cookie · whatwg/html@8170d82 ( 版) https://github.com/whatwg/html/commit/8170d82a2fc93c8ff7981c54aa4ccafd54204552

メモ

[62] ここのように頁の名前にRefererが入っていると referer spamer を引き寄せることができるようですね(w (名無しさん 2005-01-31 08:26:42 +00:00)

[64] どのURI参照を Referer とするか: HTMLaimg のような単純なリンクが単純に存在する場合は Referer となるべき URI 参照は自明 (その文書実体の URI 参照) ですが、 取込み輸入が複雑に絡むと何を送るべきかわからなくなることがあります。

例:

(名無しさん)

[126] 各々の書式の処理モデルにおいて、参照を解釈した結果溶け込んでしまった部分は区別せずに (区別できずに) 参照元の一部であったかのように扱い、参照を解釈しても元々の区別が保存され続ける場合には外部から取込んだ部分の元の URI 参照を保存しておくのが、 実装的には一番楽な方法であると思われます。

しかし、前述のように、動的に作られる参照は非直感的なことがあり得るなど、 問題が無いわけではありません。 ある URI 参照が何を意味しているのかという根本的な問題にも関係してきます。

[100] 高木浩光@自宅の日記 - Refererを誤送信するブラウザが最近も存在する, 栃木県警の無断リンク禁止規定の復活はシステム不具合による事故 (高木浩光 著, 版) http://takagi-hiromitsu.jp/diary/20070707.html#p01

[101] リファラ実験 - referrer test ( 版) http://www.teria.com/~koseki/memo/referrer/

[7] アクセス解析データを掻き乱すリファラ偽装スパムへの対策|Web制作 W3G ( 版) https://w3g.jp/blog/block_referer-spam-bots

[62] この WikiPage の referer 記録、これまた香ばしいのがたくさんきてますねぇ。 他の一般の WikiPage にはあまりないようですけど、 こういう referer spam ってまさか手動でやってるのでしょうか。 (Referer の頁もなぜか多いです。) 暇な人もいるものですねぇ。 (名無しさん 2004-11-06 01:07:14 +00:00)

[202] Fix referrer. Inline source origin and referrer source. https://www.w3.o... · 1898f6f · whatwg/xhr ( ( 版)) https://github.com/whatwg/xhr/commit/1898f6f8981e8f926dc42392c07137eeedf7094b

[203] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#page-14

[89] The Platform for Privacy Preferences 1.0 (P3P1.0) Specification ( ( 版)) http://www.w3.org/TR/P3P/#safezone

[90] The Platform for Privacy Preferences 1.0 (P3P1.0) Specification ( ( 版)) http://www.w3.org/TR/P3P/#other_http_info

[211] Define the document's referrer in terms of Fetch ( (annevk著, )) https://github.com/whatwg/html/commit/148dcd7d8214433b80de92b19d27cc5de128f849

[212] Fix referrer calculation to not refer to "API referrer source" (#58) (domenic著, ) https://github.com/w3c/webappsec-referrer-policy/commit/2d78da2dba8f7ca75c5a0aef8db4ceeae59e0074

[167] Omit Referer header when referrer is "no-referrer" (annevk著, ) https://github.com/whatwg/fetch/commit/7feaed2cc1d4ac97ea6a3f47ab6aa50e7377e161

[168] Fix use of "active document" in determining referrer (#63) (estark37著, ) https://github.com/w3c/webappsec-referrer-policy/commit/301ed67dc160c8d0ca8e72e7e5b076088cf611b1

[171] remove referrer resource (#52) (siusin著, ) https://github.com/w3c/beacon/commit/af4b8c29c4530bf1d0d1890e85863908ae9c53e6

[172] remove referrer resource by siusin · Pull Request #52 · w3c/beacon () https://github.com/w3c/beacon/pull/52

[173] Remove referrer source definition + HTML5.2 dep · Issue #51 · w3c/beacon () https://github.com/w3c/beacon/issues/51

[174] Clean up the Dependencies section - fix #47 by siusin · Pull Request #50 · w3c/beacon () https://github.com/w3c/beacon/pull/50#discussion_r132872213

[175] Remove registerContentHandler() and several friends (annevk著, ) https://github.com/whatwg/html/commit/b143dbc2d16f3473fcadee377d838070718549d3

[176] WebSocket handshake has no referrer (annevk著, ) https://github.com/whatwg/fetch/commit/60db35ed0d18c6636f002da91593bfa5ee58494e

[181] WebSocket handshake has no referrer by annevk · Pull Request #632 · whatwg/fetch () https://github.com/whatwg/fetch/pull/632

[185] WebSocket connections don't appear to send referrers · Issue #630 · whatwg/fetch () https://github.com/whatwg/fetch/issues/630

[221] Editorial: replace UTF-8 encode with isomorphic encode (annevk著, ) https://github.com/whatwg/fetch/commit/ffbaefb5c4f68b9d619e9db6491fd665a30a2ffb

[222] Editorial: replace UTF-8 encode with isomorphic encode by annevk · Pull Request #742 · whatwg/fetch () https://github.com/whatwg/fetch/pull/742

[223] Use "isomorphic decode" explicitly for Refresh headers · Issue #3924 · whatwg/html () https://github.com/whatwg/html/issues/3924

[178] Codify user agent flexibility with regard to referrer values. by mikewest · Pull Request #127 · w3c/webappsec-referrer-policy · GitHub () https://github.com/w3c/webappsec-referrer-policy/pull/127

[177] Codify user agent flexibility with regard to referrer values. (@johnwilander著, ) https://github.com/w3c/webappsec-referrer-policy/commit/31577f26f47d81bf390ca4f04f217468d742fcf1

[174] fixup note (mikewest著, ) https://github.com/w3c/webappsec-referrer-policy/commit/3e2666dad02e61269b8efdff6a83029c35c173f8

[175] Codify user agent flexibility with regard to referrer values. by mikewest · Pull Request #127 · w3c/webappsec-referrer-policy · GitHub () https://github.com/w3c/webappsec-referrer-policy/pull/127

[229] Limit referer header's value to 4k. (mikewest, , ) https://github.com/w3c/webappsec-referrer-policy/commit/ee6cf252c5fb996178945829b3f6d3c18669d920

[230] Limit the length of the Referer header · Issue #903 · whatwg/fetch () https://github.com/whatwg/fetch/issues/903

[231] Limit `referer` header's value to 4k. by mikewest · Pull Request #122 · w3c/webappsec-referrer-policy () https://github.com/w3c/webappsec-referrer-policy/pull/122

[232] fixup serialize (mikewest, , ) https://github.com/w3c/webappsec-referrer-policy/commit/a71e33564bacf501e870f3070d08b8cb292dbac9

[233] 最速インターフェース研究会 :: IEはwindow.openでリファラを送らない () http://la.ma.la/blog/diary_200608191751.htm