Чи буде переадресація 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 переспрямування є більш надійною?

Коротка відповідь - це не зазначено у відповідному 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при посадці на доменB - це: domainX (навіть при використанні перегляду InPrivate і навіть коли користувач відкриває посилання в новій вкладці)
• Safari4 refererпри посадці на доменB - це: domainX (навіть коли користувач відкриває посилання в новій вкладці)
• FF3.6.10 referer при посадці на доменB - це: domainX (навіть коли користувач відкриває посилання в новій вкладці)
• Chrome5 refererпри посадці на доменB - це: domainX ( якщо користувач не відкриває посилання в новій вкладці)
• Chrome26 refererпри посадці на доменB - це: доменХ (навіть коли користувач відкриває посилання в новій вкладці)

Гарне питання. У цьому випадку надсилання реферала повністю залежить від браузера (оскільки браузеру пропонується зробити ще один запит на новий ресурс).

RFC 2616 мовчить про проблему:

Запитаний ресурс тимчасово знаходиться під іншим URI. Оскільки перенаправлення іноді може бути змінено, клієнт ПОВИНЕН продовжувати використовувати Request-URI для майбутніх запитів. Цю відповідь можна кешувати, лише якщо вказано поле заголовка Cache-Control або Expires.

Я б не довіряв браузеру, щоб він надіслав потрібного реферала. Б'юся об заклад, є принаймні один, який надсилає щось інше, ніж інші.

Вирішення проблем

Якщо можете, чому б не додати a ?override_referer=<old_url> параметр до URL-адреси, на яку ви переспрямовуєте, та проаналізувати це значення замість HTTP_REFERER.

Таким чином, ви можете бути впевнені, що завжди отримуєте правильний результат, і ви нічого не втрачаєте в безпеці: реферера можна підробити в будь-якому випадку.

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

Тож я спробував із переспрямуванням HTML на сторінці B (замість переспрямування 301 або 302):

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

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

• Referer - це сторінка B з Chrome
• Referer ПОПУСТИЙ з FireFox та IE!

Сподіваюся, це може допомогти