在什么情况下 HTTP referer 会被截断答案

【问题标题】：In what cases HTTP referer will be truncated在什么情况下 HTTP referer 会被截断
【发布时间】：2017-12-14 03:29:20
【问题描述】：

我正在尝试了解 HTTP 引用标头的行为。我注意到有时引用是完整的（完整的 URL，包括路径和查询字符串），但大多数情况下它只包括域。

例如“https://www.google.com/”而不是“https://www.google.com/search?q=http+referer+truncated&oq=http+referer+truncated&aqs=chrome..69i57.6485j0j1&sourceid=chrome&ie=UTF-8#q=http+referer+is+not+full”

是否有任何关于何时裁判和何时被截断以及何时被截断的规则？

【问题讨论】：

从未见过截断的，除非请求来自/。您在什么情况下观察到这种情况？
我刚刚用示例编辑了问题
我知道 HTTP 引荐来源网址会被截断的唯一情况是，如果您使用的是数据包分析器或类似的东西。内部显示限制可能小于实际大小。
@UlugToprak，试一试。在 google 上搜索您想要的任何内容，单击其中一个结果并查看 HTTP 请求引用。
顺便说一句，使用 Bing 我确实看到了完整的 URL

标签： http http-referer referrer-policy

【解决方案1】：

HTTP 引用标头由浏览器根据所需标准使用Referrer Policy 创建，尽管大多数浏览器使用通用标准，但浏览器处理服务器指令的方式存在一些差异，主要是移动网络浏览器那些与 WWWC 在这个问题上的建议不能很好地配合的。

那么为什么需要不同的 HTTP 引用标头呢？要理解这一点，我们需要先看看这些标头的用途。最简单形式的主要目的是“将信息从原始页面传送到新页面”。

我们在网络上看到“信息”这个词的任何地方都附有一个信息安全概念，HTTP 标头也不例外。根据header携带的信息类型，服务器可以指定需要使用的referrer策略类型。以下是 W3 的推荐人策略列表

enum ReferrerPolicy { "", "no-referrer", "no-referrer-when-downgrade", "same-origin", "origin", "strict-origin", "origin-when-cross-origin", "strict-origin-when-cross-origin", "unsafe-url" };

上面包含的推荐人政策链接中提供了有关每一项的详细信息。

举个例子；使用谷歌搜索“黄页”。在这种情况下

来源：https://www.google.ie

推荐人：https://www.google.ie/

第一个结果的链接是

https://www.google.ie/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiA26TfiHSGDFHKFAKHQXoCWUQFggoMBB&url=https%3A%2F%2Fwww.goldenpages.ie%2F&usg=AFQjCNGTG-tsBSFHgMkXw_GuvOcLEOD2hg

虽然实际网址是https://www.goldenpages.ie/

当我们实际点击链接时，referrer 变为

Referer:https://www.goldenpages.ie/ 并且推荐人策略是

Referrer Policy:no-referrer-when-downgrade

这意味着如果我们从当前页面点击另一个链接，我们将不会看到与我们在 google 搜索结果页面的 URL 中看到的类似的所有其他参数。

证明是这样的；单击当前页面中的任何链接并观察引荐来源标头根据策略类型的变化（如果您使用开发人员工具并检查网络活动，可以在相关的 js 文件中找到）

当我点击“列出您的业务”链接时，推荐人保持为

https://www.goldenpages.ie/list-your-business/

并且没有传递其他参数

所以只是整理一下这个混乱的解释；生成的 URL 取决于针对 Referrer 策略设置的规则，可能是没有参数的简单基本规则，也可能是很长的 URL，其中包含与用户和导航来源相关的大量信息。

注意：URL 无法正常工作，我把一些字母弄乱了。

【讨论】：

【解决方案2】：

截至 2020 年 11 月的更新详情...

许多浏览器在发出跨域请求时已开始默认使用更严格的引荐来源网址策略 (strict-origin-when-cross-origin)，而不是旧的默认 (no-referrer-when-downgrade)。这通常会导致 URL 被截断，但有时也意味着根本不会设置引荐来源网址 (no-referrer)。

以下是一篇关于此的好文章的摘录： https://plausible.io/blog/referrer-policy

Chrome 使用的是版本 85 中的 strict-origin-when-cross-origin。如果在同一个域中，Strict-origin-when-cross-origin 是发送完整路径的位置，但如果转到另一个域，则仅发送域本身。以前它使用no-referrer-when-downgrade。

Firefox 默认使用no-referrer-when-downgrade。除非请求从 HTTPS 发送到 HTTP，否则它始终传递完整路径。 Firefox 在隐私浏览选项卡和已知跟踪器中使用strict-origin-when-cross-origin。

Edge 正在使用no-referrer-when-downgrade。和火狐一样。

Safari 正在使用strict-origin-when-cross-origin。与 Chrome 相同。

Brave 正在使用 no-referrer，其中完全删除了引用标头。即使对于同源请求，它也从不共享完整的 URL，您甚至看不到跨域请求的域名。

【讨论】：

【解决方案3】：

有Referrer-Policy 标头和referrer 元标记。

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

他们似乎做着完全相同的工作（如@Ulug 的回答中所述）。如果两者都存在我不知道浏览器如何决定选择哪个，我只是删除了 HTML 来解决我的问题。

【讨论】：