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 重定向的行为是否更可靠吗？
I need to redirect the user from one page to another, but I need to maintain the original referer string. So, for example, if they start out on http://www.othersite.com/pageA.jsp, click a link that takes them to http://www.example.com/pageB.jsp, which then executes a 302 redirect to http://www.example.com/pageC.jsp, I need the referer string to contain http://www.othersite.com/pageA.jsp
Is this the normal behavior for a 302 redirect? Or would my original referer get dropped, in favor of http://www.example.com/pageB.jsp? That would not be desirable.
I don't know if it makes any difference, but I'm working in JSP, and I'm using response.sendRedirect() to execute the 302 redirect.
I should mention that I did an experiment with this, and it seems to have kept the original referer string (http://www.othersite.com/pageA.jsp) but I just wanted to make sure this was the normal default behavior, and not something weird on my end.
Although I'm currently using a 302 redirect, I could probably use a 301 redirect instead. Do you know if the behavior for 301 redirects is any more reliable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不知道 302，但我今天在一些浏览器上测试了 301，结果如下：
场景：用户单击指向domainA 的domainX 上的链接。域 A 执行 301 重定向到域 B。
referer登陆domainB时为：domainX（即使使用InPrivate浏览，甚至用户在新选项卡中打开链接）referer登陆domainB时为：domainX（甚至 当用户在新选项卡中打开链接时）当用户在新选项卡中打开链接时）referer是：domainX（即使用户在新选项卡中打开链接）referer是：domainX（除非用户在新选项卡中打开链接）referer登陆domainB时为：domainX（即使用户在新选项卡中打开链接）I don't know about the 302, but I tested the 301 on some browsers today, here the results:
SCENARIO: user clicks link on domainX that points to domainA. domainA does a 301 redirect to domainB.
refererwhen landing on domainB is: domainX (even when using InPrivate browsing and even when user opens link in new tab)refererwhen landing on domainB is: domainX (even when user opens link in new tab)refererwhen landing on domainB is: domainX (even when user opens link in new tab)refererwhen landing on domainB is: domainX (unless user opens links in new tab)refererwhen landing on domainB is: domainX (even when the user opens links in new tab)简短的回答是相关 RFC 2616 中未指定 http:// www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 用于 Referer 标头或 302 状态代码。
最好的选择是使用多个浏览器进行测试，看看是否存在一致的行为。
对于完整的腰带和大括号，请在重定向 URL 中对原始引荐来源网址进行编码，以便保证检索到它。
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.
Your best bet is to do a test with several browsers and see if there's a consensus behaviour.
For full belt and braces, encode the original referrer in the redirect URL so you can guarantee to retrieve it.
好问题。在这种情况下，referer 的发送完全取决于浏览器（因为浏览器被告知向新资源发出另一个请求）。
RFC 2616 对问题：
我不相信浏览器会发送正确的引荐来源网址。我打赌至少有一个发送的东西与其他的不同。
解决方法
如果可以，为什么不向您重定向到的 URL 添加
?override_referer=参数，并解析该值而不是 HTTP_REFERER。这样您就可以确保始终获得正确的结果，并且在安全性方面您不会损失任何东西：无论哪种方式，引用者都可以伪造。
Good question. In this case, the sending of the referer depends entirely on the browser (because the browser is told to make another request to the new resource).
RFC 2616 remains silent about the issue:
I wouldn't trust the browser to send the right referer along. I bet there is at least one that sends something different than the others.
Workaround
If you can, why not add a
?override_referer=<old_url>parameter to the URL you redirect to, and parse that value instead of HTTP_REFERER.That way you can be sure to always get the right result, and you're not losing anything in security: The referer can be faked either way.
我遇到了相反的问题：我希望引用者是“pageB”，但当前的浏览器都没有以这种方式进行...
所以我尝试在 pageB 上进行 HTML 重定向（而不是 301 或 302 重定向）：
结果令人惊讶：
希望这可以帮助
I had the oposite problem : I wanted that referer was "pageB" but none of curent browser procede this way...
So I tried with an HTML redirection on pageB (instead of 301 or 302 redirection) :
And result was surprising :
Hope this can help
迟到了，但今天 HTTP 重定向（通过 HTTP 标头或元 http-equiv）不会在 Referer 标头中发送重定向页面。
Javascript 重定向似乎在所有情况下都会在 Referer 标头中发送重定向页面。
我有以下场景：
如果用户已登录 Web 应用程序，访问登陆页面 A（例如来自搜索引擎或按点击付费活动，这构成了我们的大部分流量），则应将其自动重定向到Web 应用程序 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（或网络应用程序 B）
Late to the party, but today HTTP redirects (both via HTTP header or meta http-equiv) doesn't send the redirecting page in Referer header.
Javascript redirects seems to send the redirecting page in Referer header in all cases.
<script>window.location.href="..."</script>I had the following scenario:
If an user already logged into web app, visits the landing page A (coming for example from a search engine or pay-per-click campaign, that makes the majority of our traffic) it should be automatically redirected to the web app B. It's a CORS scenario but I control both domains.
I could have accomplished that by properly setting/reading cross-domain cookies (it works with HTTPS + Secure + SameSite cookie attributes) but it had some drawbacks when user logged out from the web app, or cleared browser cookies for just one of two domains, or session expired on the server.
So I came up with another solution: I implemented an endpoint "/redirectIfNotLogged" in my web app B. When someone visits landing page A, a HTTP redirect is performed to the endpoint above, on domain B. That endpoint reads the cookie and checks the session. If the user is already logged, it redirects to the dashboard of web app, otherwise it redirects back to the website. To avoid infinite redirection, I must know if we're caming from a redirect, operated by web app. We would redirect to the original URL. We wouldn't redirect to a different page on domain A or append a query string. So I check the HTTP Referer header. I discovered that redirects made via Javascript send Referer header, while HTTP redirects don't. The web app requires Javascript to work, so this isn't an issue.
Still experimenting if some antiviruses or firewalls (we use HTTPS everywhere so I don't care about cloud or enterprise AV/FW or anything it isn't installed on the local machine) strip away Referer header. In such cases, I just avoid infinite redirection choosing to display landing page A (or web app B)