リファラーがHTTPSからHTTPに渡される場合があります…方法は？

理論的には、ブラウザはリファラー情報をHTTPSからHTTPサイトに渡しません。そして私の経験では、これは常に真実でした。しかし、私はちょうど例外を見つけたので、なぜそれが機能するのかを理解したいと思います。

https://www.google.ca/で「リファラーとは」を検索します。
例：https : //www.google.ca/search ? q=what+is+my+referer

リファラーを表示するサイトがいくつかあります。彼らは、そうすべきではないときにすべて「働く」ように見えます。たとえば、www.whatismyreferer.comをクリックします。私は得る：

 Your referer:
 https://www.google.ca/

まれに、結果として「リファラーなし」が表示されることがあります。戻ってリンクをもう一度クリックすると、次回は「機能」します。

これは起こらないはずです。www.whatismyreferer.comは、非HTTPSサイトです。refererヘッダーは渡されるべきではありませんが、渡されます。

ここで何が起こっていますか？また、HTTPSサイトからリンク先のHTTPサイトに同じことを行うにはどうすればよいですか？

<meta>Googleが使用している新しいヘッダーが原因のようです。

 <meta name="referrer" content="origin">

仕様：https : //w3c.github.io/webappsec-referrer-policy/

現在、いくつかのブラウザでのみ完全にサポートされているため、完全なソリューションではありませんが、確かに開始です！

これは標準の動作です。

https://tools.ietf.org/html/rfc2616#section-15.1.3は言う

参照ページがセキュアなプロトコルで転送された場合、クライアントは（非セキュアな）HTTPリクエストにRefererヘッダーフィールドを含めるべきではありません。

クライアントがそれをしている場合、それは標準に違反しています。

繰り返しになりますが、Googleは標準であり、何でもできます:-)

これは、Googleページのjavascriptが実行していることのようです。noscriptが有効になっているFirefoxでは表示されず、javascriptを無効にするとWindows上のChromeで表示されなくなります。私はそれ以上深く掘り下げていないので、具体的には何がわかりません。

<meta> ラベルの属性名には新しいリファラールールがあります。リファラーは、このドキュメントから送信されたリクエストに添付されたHTTPリファラーHTTPヘッダーのコンテンツを制御します。

詳細については、RFC Referrer Policyをご覧ください。

リンクをクリックすると、https：//www.google ....からhttp://www.google ...にリダイレクトされ、その後www.whatismyreferer.comにリダイレクトされるためです。

そして、あなたが言ったように、httpウェブサイト間でリファラーが送信されます。

Firefox拡張機能で確認できます