URL-хэш сохраняется между перенаправлениями - PullRequest
33 голосов
/ 12 марта 2011

По какой-то причине браузеры, отличные от IE, похоже, сохраняют хэш URL-адреса (если присутствует) при отправке перенаправления на стороне сервера (с использованием заголовка Location).Пример:

// a simple redirect using Response.Redirect("http://www.yahoo.com");
Text.aspx

Если я захожу:

Test.aspx#foo

В Firefox / Chrome меня принимают:

http://www.yahoo.com#foo

Может кто-нибудь объяснить, почему это происходит?Я пробовал это с различными перенаправлениями на стороне сервера на разных платформах (все это приводит к заголовку Location, хотя), и это всегда, кажется, происходит.Я не вижу его нигде в спецификации HTTP, но на самом деле это проблема самих браузеров.Хэш URL (как и ожидалось) никогда не отправляется на сервер, поэтому перенаправление сервера не загрязняется им, браузеры по какой-то причине просто сохраняют его.

Есть идеи?

Ответы [ 3 ]

73 голосов
/ 12 марта 2011

Я полагаю, что это правильное поведение. Коды состояния 302 и 307 указывают, что ресурс находится в другом месте. #bookmark - местоположение внутри ресурса.

Как только ресурс (html-документ) найден, браузер должен найти #bookmark в документе.

Аналогия такова: вы хотите найти что-то в книге в главе 57, поэтому вы идете в библиотеку за книгой. Но на полке есть записка о том, что книга переехала, сейчас она находится в другом здании. Итак, вы идете на новое место. Вы все еще хотите главу 57 - не имеет значения, где вы получили книгу.

24 голосов
/ 12 марта 2011

Это аспект, который не охватывался предыдущими спецификациями HTTP, но был учтен в более поздней разработке HTTP :

Если сервер возвращает код ответа 300 («множественный выбор»), 301 («перемещен навсегда»), 302 («временно перемещен») или 303 («см. другие»), и если сервер также возвращает один или несколько URI, где можно найти ресурс, тогда клиентСЛЕДУЕТ обрабатывать новые URI так, как если бы в конце был добавлен идентификатор фрагмента исходного URI.

Исключение составляют случаи, когда возвращенный URI уже имеет идентификатор фрагмента.В этом случае исходный идентификатор фрагмента НЕ ДОЛЖЕН быть добавлен к нему.

Таким образом, фрагмент исходного URI также следует использовать для URI перенаправления, если он также не содержит фрагмент.

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

@ Julian Reschke или @ Марк Ноттингем вероятно, знает больше / лучше об этом.

2 голосов
/ 12 марта 2011

Из того, что я обнаружил, неясно, каким должно быть точное поведение. У многих людей есть проблемы с этим, некоторые хотят сохранить закладку через перенаправление, некоторые хотят от нее избавиться.

Разные браузеры обрабатывают это по-разному, поэтому на практике бесполезно полагаться на любое поведение.

Это определенно проблема браузера. Браузер никогда не отправляет часть URL-адреса с закладками на сервер, поэтому сервер ничего не может сделать, чтобы выяснить, есть ли закладка или нет, и ничего, что можно было бы с этим сделать надежно.

...