Jakie są konsekwencje korzystania z względnych nagłówków lokalizacji?

17

Zgodnie ze specyfikacją nagłówki lokalizacji używane w przekierowaniu wymagają nazwy serwera

HTTP/1.1 301 Moved Permanently
...
Location: http://example.com/foo/baz/bar

Jednak w 2012 r. Większość przeglądarek internetowych rozpozna ścieżkę względną i przekieruje do nowej lokalizacji przy użyciu oryginalnej nazwy serwera

HTTP/1.1 301 Moved Permanently
...
Location: /foo/baz/bar

Czy są jakieś negatywne / zaskakujące konsekwencje korzystania z względnych adresów URL w nagłówkach lokalizacji? Moją szczególną troską jest to, jak Google / wyszukiwarki to zinterpretują, ale jeśli jest coś jeszcze, nie myślę o tym, chciałbym to usłyszeć.

— Alan Storm
źródło

Czy możesz podać dokładny fragment, od którego otrzymujesz to wymaganie? Nie jest to wyzwanie, po prostu nie widzę go od razu i nie mam ochoty czytać całego RFC, aby go znaleźć. Cytujesz także specyfikację HTTP 1.0, ale w swoich przykładach używasz nagłówków HTTP 1.1 . (Które mogą, ale nie muszą, zmieniać dozwoloną treść).

— Su

Sekcja 10.11. tools.ietf.org/html/rfc1945#page-44 O ile wiem, w specyfikacji 1.1 nic nie „naprawia” tego.

— Alan Storm

15

Zgodnie z bieżącą wersją standardu HTTP / 1.1, RFC 2616, wartością Locationnagłówka musi być bezwzględny identyfikator URI .

Jednak w projekcie standardu przygotowanym przez grupę roboczą HTTPbis, aby ostatecznie zastąpić RFC 2616, zmieniono to, aby umożliwić również względne identyfikatory URI, najwyraźniej dlatego , że :

„Definicja nagłówka lokalizacji [w RFC 2616] różni się na różne sposoby, w jaki przynajmniej przeglądarki internetowe muszą sobie z nimi radzić, aby współpracować z treściami w Internecie”

W praktyce AFAIK prawie wszystkie główne przeglądarki i wyszukiwarki rozumieją i akceptują przekierowania HTTP na względne adresy URL. Jednak dopóki projekt HTTPbis pewnego dnia nie stanie się oficjalnym standardem i nie zostanie powszechnie przyjęty, zawsze będą pojawiać się nowe lub niejasne programy klienckie, które implementują obecny standard do listu i akceptują tylko bezwzględne adresy URL. Dlatego bezpiecznym rozwiązaniem jest na razie używanie bezwzględnych adresów URL w Locationnagłówkach, zgodnie z prawem Postela :

„Bądź konserwatywny w tym, co wysyłasz, liberalny w tym, co akceptujesz”.

— Ilmari Karonen
źródło

3

RFC 2616 jest teraz przestarzały przez 7231, który zezwala na względne adresy URL w nagłówkach lokalizacji.

— Programy klienckie

6

Sekcja 14.30 HTTP 1.1 RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 nie różni się znacząco. Nie wiem, czy zobaczysz jakieś praktyczne ograniczenia.

Tylko raz zobaczyłem ostrzeżenie o tym problemie, kiedy testowałem w Lynxie, a lokalizacja nie była bezwzględna, ostrzegłoby cię: „Wartość lokalizacji nie jest bezwzględna” - ale jeśli dobrze pamiętam, nadal pozwoli ci odejść do nowej lokalizacji. Właśnie przetestowałem Lynx 2.8.7 i wygląda na to, że już tego nie robi, choć może to być problem z konfiguracją.

Teraz mówisz:

Moją szczególną troską jest to, jak Google / wyszukiwarki to zinterpretują, ale jeśli jest coś jeszcze, nie myślę o tym, chciałbym to usłyszeć.

Uważam, że uzasadnia to test. Ustawiłbym adres URL, umieściłem go w mapie witryny xml Twojej witryny i chciałbym , aby ten adres URL był przekierowaniem, jak opisano. Myślę, że należy to sprawdzić za pomocą Narzędzi Google dla webmasterów i sprawdzić, czy występują negatywne konsekwencje.

— artlung
źródło