Yahoo! JAPANのサービスが2016年4月から2017年3月にかけて常時SSLに移行するそうです。
Yahoo! JAPANサービスは常時SSL（AOSSL）に対応します - Yahoo! JAPAN
この影響で「リファラ‥‥ もう来ないのかな‥‥」という声がチラホラと聞こえました。実際にYahooのページでも以下のような説明をされています。
今後、Yahoo! JAPAN（HTTPS）から外部サイト（HTTP）にページ遷移する場合、原則、HTTP Referer（リファラ）は送出されなくなります（※1）。 そのため、HTTP Refererを利用してYahoo! JAPANからサイトへの流入量を計測することはできなくなりますので、ご注意ください。
これを読むと、「え、リファラが取れなくなるの？ 原則ってことは例外で取れるときはあるの？」なんて疑問が湧いてきますよね。
いい機会なのでリファラーについて整理してみます。間違いがあればTwitterなどで突っ込んでくださいませ。
そもそもリファラとは
そもそもリファラとは？ まずはWikipediaをみてみます。
HTTPヘッダの1つで、インターネット上の1つのウェブページまたはリソースから見て、それにリンクしているウェブページやリソースのアドレスを指す。リファラを参照することで、どこからそのページに要求が来たのかを知ることができる。
ざっくりどこからリンクがクリックされたかがわかるという仕組みがリファラです。
例えば、このINTERNET Watchの記事のリンクをクリックして、Yahooのページに移動します。
するとYahooのページではリファラとしてINTERNET Watchの記事URLであるhttp://internet.watch.impress.co.jp/docs/news/20160405_751611.htmlが取得できます。
ChromeのデベロッパーツールNetworkタブなどを使うと確認できますね。
HTTPSからHTTPには（基本）リファラは送られない
RFCには「HTTPSのようにセキュアなプロトコルからHTTPプロトコルに移動するときはリファラを送らないようにしましょう」という仕様があります。
RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
利用者のプライバシー保護の観点から考えると納得の仕様ですね。
各ブラウザはこの仕様に準拠しているため、冒頭のYahoo! JAPANのサービスが常時SSL化されるとリファラが取れなくなるかも‥‥！ という話になるわけです。
リファラと標準化
現在W3Cにおいてリファラの標準化が推進されています。ワーキングドラフトの状態ですが、以下のページから確認することが可能です。
W3Cによってリファラをどのようにして送るのか？ というポリシーが5パターン定義されています。
None
リファラを送らないというNone。
Origin Only
オリジン情報のみを送る。
※ オリジンというのはHTTPSとかのプロトコル、ドメイン、ポートによって成り立っているけれど、ここではhttps://www.google.co.jp のようにプロトコルとドメイン情報のみ送られてくると捉えておけば実務上困らないと思います。
詳細はMDNをご参照
Origin When Cross-Origin
リンク先が別オリジンの場合はオリジンのみを送り、同一オリジンの場合はURL全体(パラメータを除く)が送られます。
None When Downgrade
HTTPSからHTTPのように安全性が落ちる場合はリファラを送らない。同一の安全性の場合はオリジンのみ送る。
Unsafe URL
同一オリジンだろうが違うオリジンだろうがURL全体(パラメータを除く)を送る。HTTPSからHTTPに対しても同様の動作をするため利用には非常に注意が必要。
meta referrerとは
ブラウザの既定ではリファラポリシーがNone When Downgradeになっています。これをページオーナーが変更できる仕組みが「meta referrer」です。文字通りmetaタグでリファラポリシーを決定できるという仕組み。
実例としてGoogle検索をみてみます。HTTPSのGoogle検索からHTTPに移動するとブラウザ既定の動作ではリファラは送られないはずです。しかし実際にはリファラにオリジンの情報が入っています。
これはGoogle検索側で<meta content="origin" id="mref" name="referrer">というメタタグが指定されているためです。
meta referrerで指定できるリファラポリシーは基本的にW3Cでさだめられているリファラポリシに準拠しています。
- no-referrer (None)
- origin
- no-referrer-when-downgrade
- origin-when-crossorigin
- unsafe-URL
参考：
注：上記ページはUnsafe URLまわりの情報が日本語だと不十分 (2016/04/13現在)
meta referrerには古い仕様がある
meta referrerですが、一度仕様がかわっているんです。以前は上記の5パターンではなく、never、always、origin、defaultの4パターンでした。
検索して調べていると、古い仕様の情報に出会うことがあるので注意が必要です。
ブラウザによって実装はまちまち
HTMLの歴史は断片化の歴史。meta referrerでもブラウザによって実装がまちまちです‥‥
ざっくり2016/04/13現在の状況をまとめると、IEだめ。Chrome（Android含む）、FirefoxはOK。Edge、Safari、iOS Safariは古い仕様で実装。
うん、キレイな断片化 ('A`)
Can I use... Support tables for HTML5, CSS3, etc
今後はどうなるのか
なんの根拠もないんですが、今後はSSLなサービス・メディアはmeta referrerでoriginを指定するんじゃないのかなって思います。セキュリティに配慮をする必要は当然ありながらも自サービス・メディアのパワーをきちんと外部につたえる手段としてリファラは非常に優れた仕組みです。
SSLのYahooサーチでもmeta referrerでoriginが指定されています。なので冒頭で取り上げたYahoo! JAPANの各種サービスが常時SSLになったとしても、オリジンなリファラは送られてくるでしょう (無根拠
(個人的には、常時SSLはリファラよりも暗号化によるペアレンタルコントロールの難しさなどのほうに興味があるんですが‥‥ それは別のお話)
ま、万が一リファラが取れなくなっても、検索キーワードと同じで粛々と状況を受けいれるしかないのですがね :P