从https页面转到http页面时是否发送了HTTP标头Referer？

Question

经过几次测试后，我开始得出这样的结论：浏览器在点击https页面的http页面时不会发送Referer HTTP标头。

有什么安全理由？是在标准的某个地方定义的吗？

Answer 1

HTTP RFC部分，15.1.3 Encoding Sensitive Information in URI's部分：

  

客户不应包含Referer   （非安全）HTTP中的头字段   如果推荐页面是请求   使用安全协议进行转移。

所以，这是预期/标准行为。

Answer 2

根据w3c document on referrer policy，实际上不再那么直截了当（2014年起）。

默认行为是，从HTTPS到HTTP时，浏览器不会发送引用者信息。但是，浏览器会在从HTTPS转为HTTPS时发送引荐来源。

此外，在HTML5中，有一个名为referrer的新元标记，如下所示：

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

New browsers have already implemented this。因此，浏览器是否会发送引荐来源，将在不久的将来取决于此元标记。如果此元标记未包含在页面的HTML中，则浏览器将使用默认行为。

以下是引荐来源元标记的内容属性的可能值：

• no-referrer：无论HTTP或HTTPS如何，都不会发送推荐人
• origin：只有origin（主）域将作为referrer
发送
• origin-when-crossorigin：相同的来源将发送完整的引荐来源网址，并且交叉来源将仅发送原始网址作为引荐来源
• no-referrer-when-downgrade：当页面上没有提供referrer元标记时，这是默认行为。
• unsafe-url：无论HTTP还是HTTPS
，都会始终发送引荐来源

此外，referrer元标记还有一些遗留属性值。这些不再推荐，但目前在许多网站中使用：

• never：与no-referrer相同
• 默认值：与no-referrer-when-downgrade相同
• 始终：与unsafe-url相同

我希望这些信息对2014年之后刚发现这篇文章的人有所帮助。

Answer 3

是，在standard：

中定义

  

客户不应包含Referer   （非安全）HTTP中的头字段   如果推荐页面是请求   使用安全协议转移

Answer 4

原因：有时SessionID是URL编码的。 HTTP页面可以具有跨站点脚本，从HTTPS通信中窃取会话。为了防止这种情况，引用者不会在HTTPS到HTTP转换上传输，因此URL编码的sessin ID不会被盗。