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

经过几次testing，我开始得出结论：浏览器不会发送Referer HTTP标头，只要点击https页面上的http页面即可。

这是什么安全原因？ 是在标准的某个地方定义的？

Answer 1

HTTP RFC规定，在第15.1.3节中对URI中的敏感信息进行编码 ：

如果引用页面是通过安全协议传输的，那么客户端不应该在（非安全）HTTP请求中包含Referer头域。

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

Answer 2

其实这并不是那么直截了当（从2014年起），根据W3C有关引荐政策的文件 。

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

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

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

新的浏览器已经实现了这一点 。 所以不pipe浏览器是否会发送引用，都会在不久的将来依赖于这个meta标签。 如果这个元标记不包含在页面的HTML中，那么浏览器将使用默认的行为。

以下是referrer元标记的内容属性的可能值：

• 无引荐：无论HTTP或HTTPS，引荐都不会被发送
• 起源：只有原始（主）域将作为引荐者发送
• 起源时，跨越：相同的来源将发送完整的引荐url和交叉来源将只发送原始url作为引用
• no-referrer-when-downgrade：这是在页面上未提供引用链接元标记时的默认行为。
• unsafe-url：无论使用HTTP还是HTTPS，都将始终发送引荐来源

此外，还有一些引用者元标记的遗留属性值。 这些不再推荐，但现在在许多网站使用：

• 从来没有：没有引荐
• 默认：与降级时不使用引用者相同
• 总是：与不安全的url相同

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

Answer 3

是的，在标准中定义：

如果引用页面使用安全协议传输，则客户端不应在（非安全）HTTP请求中包含Referer头域

Answer 4

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