Подтвердить что ты не робот

Будет ли перенаправление 302 поддерживать строку-референт?

Мне нужно перенаправить пользователя с одной страницы на другую, но мне нужно сохранить исходную строку реферирования. Так, например, если они начинаются с http://www.othersite.com/pageA.jsp, щелкните ссылку, которая приведет их к http://www.mysite.com/pageB.jsp, который затем выполняет перенаправление 302 на http://www.mysite.com/pageC.jsp, мне нужна строка-референт, чтобы содержать "http://www.othersite.com/pageA.jsp "

Это нормальное поведение для перенаправления 302? Или мой первоначальный референт будет сброшен в пользу "http://www.mysite.com/pageB.jsp "? Это было бы нежелательно.

Я не знаю, имеет ли значение какое-либо значение, но я работаю в JSP, и я использую response.sendRedirect() для выполнения перенаправления 302.

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

Благодарим вас за помощь.

ИЗМЕНИТЬ ДОБАВИТЬ:

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

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

СКЭНАРИО: пользователь нажимает ссылку на domainX, указывающую на domainA. domainA переадресовывает 301 домену.

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

Ответ 3

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

RFC 2616 продолжает молчать об этой проблеме:

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

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

Обход

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

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

Ответ 4

У меня была проблема с oposite: я хотел, чтобы этот референт был "pageB", но ни один из методов curent browser таким образом...

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

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

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

  • Referer - страница с Chrome
  • Референт EMPTY с FireFox и IE!

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