302 重定向会维护引用字符串吗？
我需要将用户从一个页面重定向到另一个页面，但我需要维护原始的引用字符串。因此，例如，如果他们从 http://www.othersite.com/pageA.jsp 开始，点击将他们带到 http://www.example.com/pageB.jsp 的链接，然后执行 302 重定向到 http://www.example.com/pageC.jsp，我需要引用字符串包含 http://www.othersite.com/pageA.jsp
这是 302 重定向的正常行为吗？或者我的原始推荐人会被删除，转而支持 http://www.example.com/pageB.jsp？那是不可取的。
我不知道这是否有任何区别，但我正在使用 JSP，并且我正在使用 response.sendRedirect() 来执行 302 重定向。
我应该提到我对此做了一个实验，它似乎保留了原始的引用字符串（http://www.othersite.com/pageA.jsp），但我只是想确保这是正常的默认行为，而不是我的奇怪行为。
虽然我目前正在使用 302 重定向，但我可能会改用 301 重定向。您知道 301 重定向的行为是否更可靠？
我不知道302，但我今天在一些浏览器上测试了301，结果如下：
场景：用户单击 domainX 上指向 domainA 的链接。 domainA 执行 301 重定向到 domainB。
登陆 domainB 时的 IE8 引用是：domainX（即使使用 InPrivate 浏览，甚至当用户在新选项卡中打开链接时）
登陆 domainB 时的 Safari4 引用是：domainX（即使用户在新选项卡中打开链接）
FF3.6.10 登陆 domainB 时的 referer 是：domainX（即使用户在新标签页中打开链接）
登陆 domainB 时的 Chrome5 referer 是：domainX（除非用户在新标签页中打开链接）
登陆 domainB 时的 Chrome26 referer 是：domainX（即使用户在新标签页中打开链接）
简短的回答是在相关的 RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 中没有为 Referer 标头或 302 状态代码指定。
您最好的选择是使用多个浏览器进行测试，看看是否存在共识行为。
对于完整的腰带和大括号，请在重定向 URL 中对原始引荐来源网址进行编码，以便您可以保证检索到它。
好问题。在这种情况下，referer 的发送完全取决于浏览器（因为浏览器被告知要向新资源发出另一个请求）。
RFC 2616 对此问题保持沉默：
请求的资源临时驻留在不同的 URI 下。由于重定向有时可能会改变，客户端应该继续使用 Request-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 的 pageB
在 FireFox 和 IE 中，Referer 为空！
希望这可以帮助
迟到了，但今天 HTTP 重定向（通过 HTTP 标头或元 http-equiv）不会在 Referer 标头中发送重定向页面。
在所有情况下，Javascript 重定向似乎都会在 Referer 标头中发送重定向页面。 <script>window.location.href="..."</script>
我有以下情况：
域 A 的登陆页面；
域 B 上的 Web 应用程序。
如果用户已经登录到网络应用程序，访问登录页面 A（例如来自搜索引擎或按点击付费的广告系列，这构成了我们的大部分流量）它应该自动重定向到网络应用程序 B。它是一个 CORS 场景，但我控制了两个域。
我可以通过正确设置/读取跨域 cookie 来实现这一点（它适用于 HTTPS + Secure + SameSite cookie 属性），但是当用户从 Web 应用程序注销或仅清除两个域之一的浏览器 cookie 时，它有一些缺点，或服务器上的会话已过期。
所以我想出了另一个解决方案：我在我的 Web 应用程序 B 中实现了一个端点“/redirectIfNotLogged”。当有人访问登录页面 A 时，HTTP 重定向将执行到域 B 上的上述端点。该端点读取 cookie 并检查会议。如果用户已经登录，它会重定向到 Web 应用程序的仪表板，否则它会重定向回网站。为了避免无限重定向，我必须知道我们是否来自由网络应用程序操作的重定向。我们将重定向到原始 URL。我们不会重定向到域 A 上的不同页面或附加查询字符串。所以我检查了 HTTP Referer 标头。我发现通过 Javascript 进行的重定向会发送 Referer 标头，而 HTTP 重定向不会。 Web 应用程序需要 Javascript 才能工作，所以这不是问题。
仍在试验是否某些防病毒软件或防火墙（我们在任何地方都使用 HTTPS，所以我不关心云或企业 AV/FW 或任何未安装在本地计算机上的东西）剥离 Referer 标头。在这种情况下，我只是避免无限重定向，选择显示登录页面 A（或 Web 应用程序 B）
关注公众号
不定期副业成功案例分享
