Будет ли 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.

Я должен упомянуть, что я провел эксперимент с этим, и, похоже, он сохранил исходную строку referer ( http://www.othersite.com/pageA.jsp), но я просто хотел убедиться, что это нормальное поведение по умолчанию, а не что-то странное с моей стороны.

Хотя в настоящее время я использую перенаправление 302, я, вероятно, мог бы использовать вместо него перенаправление 301. Знаете ли вы, является ли поведение 301 редиректа более надежным?

Короткий ответ: он не указан в соответствующем RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 ни для заголовка Referer, ни для кода состояния 302.

Лучше всего провести тест с несколькими браузерами и посмотреть, есть ли согласованное поведение.

Для полного пояса и фигурных скобок закодируйте исходный реферер в URL-адресе перенаправления, чтобы вы могли гарантировать его получение.

Не знаю, как насчет 302, но сегодня я тестировал 301 в некоторых браузерах, вот результаты:

СЦЕНАРИЙ : пользователь нажимает ссылку на domainX, которая указывает на domainA. domainA выполняет 301 редирект на domainB.

• IE8 refererпри переходе на domainB: domainX (даже при использовании просмотра InPrivate и даже когда пользователь открывает ссылку в новой вкладке)
• Safari4 refererпри переходе на domainB: domainX (даже когда пользователь открывает ссылку в новой вкладке)
• FF3.6.10 refererпри переходе на domainB: domainX (даже когда пользователь открывает ссылку в новой вкладке)
• Chrome5 refererпри переходе на domainB: domainX ( если пользователь не открывает ссылки в новой вкладке)
• Chrome26 refererпри переходе на domainB: domainX (даже когда пользователь открывает ссылки в новой вкладке)

Хороший вопрос. В этом случае отправка реферера полностью зависит от браузера (потому что браузеру говорят сделать еще один запрос к новому ресурсу).

RFC 2616 ничего не говорит об этой проблеме:

Запрошенный ресурс временно находится под другим URI. Так как перенаправление может быть изменено при случае, клиент ДОЛЖЕН продолжать использовать Request-URI для будущих запросов. Этот ответ кэшируется только в том случае, если он указан полем заголовка Cache-Control или Expires.

Я бы не стал доверять браузеру, чтобы он отправил правильного реферера. Бьюсь об заклад, есть по крайней мере один, который отправляет что-то отличное от других.

Обходной путь

Если можете, почему бы не добавить ?override_referer=<old_url>параметр к URL-адресу, на который вы перенаправляете, и не проанализировать это значение вместо HTTP_REFERER.

Таким образом, вы можете быть уверены, что всегда получите правильный результат и ничего не потеряете в безопасности: реферер может быть подделан в любом случае.

У меня была противоположная проблема: я хотел, чтобы референт был "pageB", но ни один из текущих браузеров не работал таким образом ...

Итак, я попытался использовать перенаправление HTML на странице B (вместо перенаправления 301 или 302):

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

И результат был удивительным:

• Referer - pageB с Chrome
• Referer ПУСТО с FireFox и IE!

Надеюсь, это поможет