[115] リファラーは、 fetch の発生元の URL です。
[111] Referer:
欄は、 HTTP
などで使われる頭欄で、リンク先の資源を取り寄せる時に、
その参照元を示すために使います。
[42] Referer は referrer の typo だけど、もはや直しようがない。
[134] Referer:
ヘッダーは、
対象URLの取得元である資源の URL を利用者エージェントが指定するものです
>>65。
[135] 対象URLを得たのが URL を持たないものからである場合
(例えばキーボードからの入力や栞からの選択である場合) には、
Referer:
を含めないか、
about:blank
を指定するかのいずれかとしなければなりません
>>65。
[82] Referer:
ヘッダーの値は、
RFC 3986 absolute-URI
または
partial-URI
とされています。ただし、
素片識別子と userinfo を使ってはなりません。 >>65
[186] Webブラウザーは必ず絶対URLとします。 部分URLとする実装があるのかは不明です。 受信者が部分URLを正しく扱えない虞がありますから、 クライアントは絶対URLを生成するべきです。
[136] URL URL から参照元として使う URL を得るには、 Strip url for use as a referrer >>60、 すなわち次のようにします。入力として起源のみフラグを持ちます。
[187] 起源のみかどうか、あるいは no-referrer
が使われるかどうかは、
参照元ポリシーにより決まります。
[149] 要求は、参照元を持ちます >>105。
その値は、 no-referrer
、client
、
URL のいずれかで、既定値は client
です >>105。
[150] HTTP は、参照元ページが保安プロトコルで受信したものの場合に、
利用者エージェントが非保安 HTTP要求で
Referer:
ヘッダーを送信してはならない
>>65 と規定していました。これは現在も原則として維持されていますが、
著者の明示的な指定により上書きできるようになっています。
[85] main fetch における要求の参照元の決定は、次のようにします >>107。
[157] 要求について Determine request’s Referrer は、次のようにします >>3。
[228] 令和元(2019)年の改訂で、利用者エージェントはプライバシー保護のための任意の改変を加えて良いとの規定が追加されました。 状況に応じたWebブラウザー依存の特例的な措置が現に行われている (または行われようとしている) のを追認するものですが、 明確な範囲と挙動を仕様書に記述せず任意の措置を認めてしまっており、 仕様書のアルゴリズムの空文化を招いてしまいました。 仕様書解釈論的には任意の挙動が適合することになって、 規定の意味をなしません。
[76] Referer
URI として報告例のある scheme は、
http
https
news
about
file
webster
xxxx
こんなものかな。 gopher
とか ftp
とかもあってもよさそうだけど、確認されていますか?
[84] 普通の一般目的利用者エージェントは、 data:
や
file:
の URL は Referer:
で送りません。 >>65
[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] 特に昔のロボットなんかは、
その身元を表す文書がある URI
を Referer:
欄で送ってくることがありました。
身元を表明するという意味ではよい心がけですが、 本来の使い方からそれており好ましいことではありません。 幸い最近はそういうのは減っているようです。
[147] なつみかんなんかは設定項目がわざわざあって、 アンテナの結果表示 URI を指定するようにと指導されていました。 リンクを広義に解釈すれば必ずしも間違いとも言い切れませんが、 なんだかなあという気はしました。
[148] なお、身元申告には本来 From:
欄を使うのがよいとされています。
実際、最近のロボットは From:
欄に連絡先メイル・アドレスを入れてきます。
但し、 From:
欄の中身はあくまでメイル・アドレスでして、
参照して欲しい URI 参照を入れることは残念ながらできません。
ですから、身元申告文書の URI 参照を入れる標準の頭欄で最も適切なのは
User-Agent:
欄です。 (しかし、単なる文字列の一部でしかないので機械処理ができない諸刃の剣。素人は User-Agent:
欄に入れるときには注釈にしないといけないことにも注意されたし。)
[141] 利用者エージェントは要求に Referer:
ヘッダーを指定することができます。
[75] しかしこのヘッダーは必須ではありません。対象URL
が利用者の直接入力など他の資源以外に由来する場合や、
利用者の設定や著者の指定により Referer:
ヘッダーを送信しないことになっている場合は、
このヘッダーは送信されません。
[219] WebSocket接続の確立では、参照元ポリシーに関わらず、 Referer:
は使われません。
[unknown origin]
Referer:
で送りつけてくることがあるそうです。[80] Referer: <!--#exec cmd="ls"-->
のようなものが送られてくることがあります。
Referer
を記録していて、
その結果が HTML ファイルに出力されて、
そのファイルで SSI が有効になっているのに、
HTML 化時の逃避が行われていない、
なんていう一昔前にあちこちで起こっていそうな光景
(今はしらん。) を想像しているのでしょうね。
ls だからよいもの、 Apache
が root
で動いている上に 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)")
[127] IE で、特定の条件でリンクを辿っていないのに閲覧した無関係の URI が送られることがある。
[57] 同じような Referer 漏れに見える、 2種類の現象があります。
[4] 古い NetscapeNavigator でも起こったようです。
MosaicView/2.0009 Win32 NEC/9
という太古(1996)の Mosaic variant は、リンクをたどっていないにもかかわらず直前の URI を送ります。しかもそれが file: URI でもお構いなく。[56] >>22 Mosaic Netscape 0.9 もそんなもんです。 古い時代は今とは違った privacy 感覚でしたから。。。
location.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)
[74] 外行きの要求の Referer:
ヘッダーをすべて除去する中間器もあることが知られています。
しかしそれによって Referer:
ヘッダーによる CSRF
対策を鯖が行えなくなりますから、より利用者を危険に晒すことになりかねません。 >>65
[86] 中間器や利用者エージェントが情報漏洩を防止したいときは、 内部ドメイン名をペンネームに置き換えたり、 path や query を削除したりするなどの変更に留めるべきです。 >>65
[87] 中間器は、 Referer:
ヘッダーの値の
URL scheme や host が要求対象と同じ時は、これを編集したり、
削除したりするべきではありません >>65。
[170] ジョブは、
参照元を持ちます。
値は URL または null
です。 >>169
[1] Referer: 欄の値により、接続制御することがあります。 例えば画像資源において、 Referer: 値が自分のサーバー内を指すものと思われないときには資源を渡さないという方法は良く使われます。
しかしこの方法は Referer を返さない利用者エージェントに対しては正しく動作しない可能性が強いですし、そうでなくても World Wide Web の最大の特徴の一つであるハイパーリンクに対して著しく不利益を与えるものです。
ですから、 Referer による接続制限は、それによる影響を十分に理解した上で、どうしても必要な場合においてのみ行うように、慎重に検討する必要があります。また、その場合においても Referer を返さない利用者エージェントに対して不利益がないように十分考慮しなければならないでしょう。 (Referer を返す UA でご利用下さい、はそれだけで既に不利益です。)
[2] なお、 Referer は HTTP において必須の欄ではありません。プライバシーの観点から値を与えない実装も数多く存在します。
[66] Referer 情報は鯖側で様々な用途に利用できますが、仕様書 (RFC 2616) にも言及がある代表的な使用例の一つが逆リンク一覧の作成です。
Referer 情報を見ることにより、 ある資源に関する言及の所在をその資源の著者が容易に発見できます。
[67] Referer 情報は閲覧者が直前に何を見ていたかの情報であり、 ともすればプライバシーの問題にもなりかねません。 RFC 2616 は利用者エージェントに、利用者が referer 情報を送信するかどうかを選択できることを求めています。 Referer 情報を逆リンクなどの形で公表されたとしても、 閲覧者がそれを著者に抗議したり、 不快感を示したりするのはお門違いです。
[11] Referer: 欄に値を入れて送る場合には、例えば次の場面があり得ます。
[16] どういう時に Referer URI を送るかは、実装依存です。 (サーバー側は何らの仮定もするべきではありません。) ただ常識的に考えて、 Referer を送る場合は >>12 は必須でしょう。
[63]
フレームとしてのリンク (frame
) は実際に UA
によって Referer:
を送ったり送らなかったりするようです。
(名無しさん [sage] 2005-02-03 23:22:24 +00:00)
[17] 利用者のプライバシーを考えつつも、分析目的の Referer 情報をサーバーに提供するために、例えば次のような実装が考えられます。
https:
な世界から http:
な世界に移るときに Referer が送られるのを気にする人もいます。多分本質的には気になることではないと思うのですが、安全なはずの世界の側のへたれ実装が、 https:
だからといって合言葉に準じるものを URI に含めていたりしたら問題ですね。まあそんな設計者が悪いんですが。ftp:
の場合でもその他の場合でも、 URI の最初の方に利用者名や合言葉を含めることができますが、安全性と個人情報保護の観点から、必ず削除するように注意した方がよいと思われます。file:
同様に送らないようにする、とかの UA の実装ごとの調整も必要でしょう。[220] 内部名が使われているURLを非内部名のサーバーに送ってほしくないですが、 そのような制限はなく、送られてしまいます。
[114] HTML - Referrer を制御する - Qiita ( ( 版)) http://qiita.com/wakaba@github/items/707d72f97f2862cd8000
[83] Referer:
によって要求の文脈や閲覧の履歴を晒すことによってプライバシー上の問題が生じるかもしれません。
例えば URL にはアカウント名など個人情報が含まれるかもしれませんし、
防火壁内などの秘密の資源の URL かもしれません。 >>65
[103] 利用者エージェントは、 Referer:
ヘッダーを送信しないオプションを利用者に提供して構いません
>>102。
[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] 文書は、参照元を持ちます。 既定値は、空文字列です。 >>91
[209] navigate は、作成した文書の参照元を、
元の要求の参照元の値に設定します。それが no-referrer
だった場合には、空文字列のままとします。
[210] 閲覧文脈の作成は、作成した文書の参照元を、 作成子閲覧文脈の文書の番地に設定します。
[28] Document
インターフェイスの
referrer
IDL属性は、
文脈オブジェクトの参照元を返さなければなりません >>205。
[109] ncsa-mosaic/CHANGES at master · alandipert/ncsa-mosaic ( ( 版)) https://github.com/alandipert/ncsa-mosaic/blob/master/CHANGES#L20
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.)ThisThe 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 fieldmust notMUST 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 giventhe field value is apartialrelative URI, itshouldSHOULD be interpreted relative to the Request-URI. The URImust notMUST 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 の変更点。
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 Refererfield may{2616} header might indicate a private document's URI whose publication would be inappropriate.
Referer
頭は、読解パターンを学習することや、 逆リンクを描くことを可能にします。これは非常に有用でありますが、 利用者の詳細がReferer
に含まれる情報から分離されていなければ、 その力は濫用され得ます。個人情報が削除されるとしても、Referer
頭は公表が不適切である私的な文書の URI を示しているかもしれません。
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
欄を送るかどうかを利用者が選択できるようにすることを強く推奨します。 例えば、ブラウザ・クライアントでは、公開で閲覧するか匿名で閲覧するかの切替器を用意して、Referer
やFrom
の情報の送信を有効にするか無効にするか指定するようにできます。
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
頭欄を含めるべきではありません。
See [H14.37]. The URL refers to that of the presentation description, typically retrieved via 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.referrer
は DOM0 で導入されました。
[207] W3C は DOM1 HTML、SVG、MathML でこれを標準化しましたが、
なぜか Document
ではなく、各言語ごとの子インターフェイスのメンバーとしていました。
[208] リンクを辿ってきたのではないような場合には、
HTML と SVG では空文字列に、 MathML では null
になると規定していました。
[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
[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 でそれやったら残ったことがあった。残らないこともあった。変だなあ
[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
[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
Referrer-Policy:
も参照。[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 とするか:
HTML の a
や
img
のような単純なリンクが単純に存在する場合は Referer
となるべき URI 参照は自明 (その文書実体の URI 参照) ですが、
取込みや輸入が複雑に絡むと何を送るべきかわからなくなることがあります。
例:
img
src
に 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
about:blank
を送る利用者エージェントが現存するのかは不明です。