Czy przekierowanie 302 zachowa ciąg referencyjny?

Muszę przekierować użytkownika z jednej strony na drugą, ale muszę zachować oryginalny ciąg referencyjny. Na przykład, jeśli zaczynają na http://www.othersite.com/pageA.jsp , kliknij łącze, które prowadzi ich do http://www.example.com/pageB.jsp , a następnie wykonuje 302 przekierowanie do http://www.example.com/pageC.jsp , potrzebuję, aby zawierał ciąg referencyjnyhttp://www.othersite.com/pageA.jsp

Czy jest to normalne zachowanie w przypadku przekierowania 302? A może mój pierwotny referendarz zostałby usunięty na korzyść http://www.example.com/pageB.jsp? To nie byłoby pożądane.

Nie wiem, czy to robi jakąkolwiek różnicę, ale pracuję w JSP i używam response.sendRedirect()do wykonania przekierowania 302.

Powinienem wspomnieć, że przeprowadziłem z tym eksperyment i wydaje się, że zachowałem oryginalny ciąg referencyjny ( http://www.othersite.com/pageA.jsp), ale chciałem się tylko upewnić, że jest to normalne domyślne zachowanie, a nie coś dziwnego z mojej strony.

Chociaż obecnie używam przekierowania 302, prawdopodobnie mógłbym zamiast tego użyć przekierowania 301. Czy wiesz, czy zachowanie przekierowań 301 jest bardziej niezawodne?

Krótka odpowiedź brzmi: nie podano jej w odpowiednim dokumencie RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 ani w nagłówku Referer, ani w kodzie stanu 302.

Najlepszym rozwiązaniem jest wykonanie testu z kilkoma przeglądarkami i sprawdzenie, czy istnieje konsensus.

W przypadku pełnego paska i szelek zakoduj oryginalny odsyłacz w adresie URL przekierowania, aby zagwarantować jego odzyskanie.

Nie wiem o 302, ale testowałem 301 na niektórych przeglądarkach dzisiaj, oto wyniki:

SCENARIUSZ : użytkownik klika link w domenieX, który wskazuje na domenęA. domena A wykonuje przekierowanie 301 do domeny B.

• IE8 refererpodczas lądowania na domenie B to: domainX (nawet podczas przeglądania InPrivate, a nawet gdy użytkownik otworzy link w nowej karcie)
• Safari4 refererpodczas lądowania na domenie B to: domenaX (nawet gdy użytkownik otworzy link w nowej karcie)
• FF3.6.10 referer podczas lądowania na domenie B to: domenaX (nawet jeśli użytkownik otworzy link w nowej karcie)
• Chrome5 refererpo wylądowaniu na domenie B to: domenaX ( chyba że użytkownik otworzy linki w nowej karcie)
• Chrome26 refererpodczas lądowania na domenie B to: domenaX (nawet jeśli użytkownik otworzy linki w nowej karcie)

Dobre pytanie. W takim przypadku wysłanie osoby odsyłającej zależy całkowicie od przeglądarki (ponieważ przeglądarka jest proszona o wysłanie kolejnego żądania do nowego zasobu).

RFC 2616 milczy na temat problemu:

Żądany zasób znajduje się tymczasowo pod innym identyfikatorem URI. Ponieważ przekierowanie może być czasami zmieniane, klient POWINIEN nadal używać identyfikatora URI żądania dla przyszłych żądań. Ta odpowiedź może być buforowana tylko wtedy, gdy jest to wskazane w polu nagłówka Cache-Control lub Expires.

Nie ufałbym przeglądarce, że wyśle ​​ze sobą właściwego recenzenta. Założę się, że jest przynajmniej jeden, który wysyła coś innego niż inne.

Obejście problemu

Jeśli możesz, dlaczego nie dodać ?override_referer=<old_url>parametru do adresu URL, do którego przekierowujesz, i przeanalizować tę wartość zamiast HTTP_REFERER.

W ten sposób możesz mieć pewność, że zawsze uzyskasz właściwy wynik i nic nie stracisz na bezpieczeństwie: sędzia może zostać sfałszowany.

Miałem inny problem: chciałem, żeby recenzentem była „stronaB”, ale żadna z obecnych przeglądarek nie działa w ten sposób ...

Próbowałem więc z przekierowaniem HTML na stronie B (zamiast przekierowania 301 lub 302):

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

Wynik był zaskakujący:

• Odsyłacz to strona B w Chrome
• Referer jest PUSTY z FireFox i IE!

Mam nadzieję, że to pomoże