302重定向是否会维护引用字符串？

我需要将用户从一个页面重定向到另一个页面，但是我需要维护原始的引用字符串。因此，例如，如果它们从 http://www.othersite.com/pageA.jsp开始，单击一个将它们带到 http://www.example.com/pageB.jsp的链接，然后执行到 http://www.example.com/pageC.jsp的302重定向，我需要引用字符串来包含 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重定向的行为是否更可靠吗？

82255 次浏览
小开

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:

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

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.

小开
最佳答案

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.

小开

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.

  • IE8 referer when landing on domainB is: domainX (even when using InPrivate browsing and even when user opens link in new tab)
  • Safari4 referer when landing on domainB is: domainX (even when user opens link in new tab)
  • FF3.6.10 referer when landing on domainB is: domainX (even when user opens link in new tab)
  • Chrome5 referer when landing on domainB is: domainX (unless user opens links in new tab)
  • Chrome26 referer when landing on domainB is: domainX (even when the user opens links in new tab)
小开

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) :

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

And result was surprising :

  • Referer is pageB with Chrome
  • Referer is EMPTY with FireFox & IE !

Hope this can help

小开

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:

  • landing page on domain A;
  • web app on domain B.

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)


提交答案