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

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

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

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

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

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

其实这并不是那么直截了当(从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这篇文章的人有所帮助。

是的,在标准中定义:

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

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