我不知道302，但我今天在一些浏览器上测试了301，这里的结果：

• • 场景**：用户单击domainX上指向domainA的链接。domainA执行301重定向到domainB。
• IE8 referer在domainB上登陆时为：domainX（即使使用InPrivate浏览和用户在新选项卡中打开链接时）
• Safari4referer在domainB上登陆时为：domainX（即使用户在新选项卡中打开链接）
• FF3.6.10referer在domainB上登陆时为：domainX（即使用户在新选项卡中打开链接）
• Chrome5referer在domainB上登陆时为：domainX（除非用户在新选项卡中打开链接）
• Chrome26referer在domainB上登陆时为：domainX（即使用户在新选项卡中打开链接）

Short answer is it's not specified in the relevant RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 either for the Referer header or the 302 status code.
你最好的办法是用几个浏览器做一个测试，看看是否有一个一致的行为。
对于完整的腰带和大括号，在重定向URL中编码原始引用，以便您可以保证检索它。

问得好。在这种情况下，referer的发送完全取决于浏览器（因为浏览器被告知向新资源发出另一个请求）。

RFC 2616对该问题保持沉默：

请求的资源暂时驻留在不同的URI下。由于重定向有时可能会被更改，客户端应该继续使用请求URI来处理将来的请求。只有在Cache-Control或Expires头域指示时，此响应才是可缓存的。
我不相信浏览器会发送正确的推荐沿着，我打赌至少有一个推荐人发送的东西与其他推荐人不同。

解决方法

如果可以，为什么不向重定向到的URL添加一个?override_referer=<old_url>参数，并解析该值而不是HTTP_REFERER。
这样，您就可以确保始终获得正确的结果，并且不会在安全性方面损失任何东西：推荐人可以用任何一种方式伪造。

我遇到了相反的问题：我希望推荐者是“pageB”，但目前的浏览器都没有这样的程序...
所以我尝试在pageB上使用HTML重定向（而不是301或302重定向）：

<meta http-equiv="refresh" content="0; url=pageC.jsp" />

结果令人吃惊：

• 引用页面为带有Chrome的页面B
• FireFox和IE的引用为空！

希望这能有所帮助

晚到党，但今天HTTP重定向（通过HTTP头或元http-equiv）不发送重定向页面在引用头。
Javascript重定向似乎在所有情况下都在Referer标头中发送重定向页面。<script>window.location.href="..."</script>
我有以下场景：

• 域A上的登录页面;
• 域B上Web应用程序

如果用户已经登录到Web应用程序，访问登录页面A（例如，来自搜索引擎或按点击付费营销活动，这构成了我们的大部分流量），它应该自动重定向到Web应用程序B。这是一个CORS场景，但我控制两个域。
我本可以通过正确设置/读取跨域cookie来实现这一点（它与HTTPS + Secure + SameSite cookie属性一起工作），但当用户从Web应用程序注销时，或仅清除两个域中的一个域的浏览器cookie时，或服务器上的会话过期时，它会有一些缺点。
于是我想出了另一个办法：我在我的Web应用B中实现了一个端点"/redirectIfNotLogged "。当有人访问登录页面A时，会执行HTTP重定向到域B上的端点。该端点读取cookie并检查会话。如果用户已经登录，则会重定向到Web应用的 Jmeter 板，否则会重定向回网站。为了避免无限重定向，我必须知道我们是否从重定向而来。我们将重定向到原始URL。我们不会重定向到域A上的其他页面或附加查询字符串。因此我检查了HTTP Referer标头。我发现通过Javascript进行的重定向会发送Referer标头，而HTTP重定向不会。Web应用需要Javascript才能工作，因此这不是问题。
仍在试验是否有一些防病毒或防火墙（我们到处都使用HTTPS，所以我不关心云或企业AV/FW或任何它没有安装在本地机器上的东西）剥离Referer头。在这种情况下，我只是避免无限重定向选择显示着陆页面A（或Web应用B）