URL-адрес хеша сохраняется между переадресацией

По какой-то причине браузеры не-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-адресов (как и ожидалось) никогда не отправляется на сервер, поэтому перенаправление сервера не загрязняется им, браузеры по какой-то причине просто сохраняют его.

Любые идеи?

Ответ 1

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

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

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

Ответ 2

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

Если сервер возвращает код ответа 300 ( "множественный выбор" ), 301 ( "постоянно перемещается" ), 302 ( "временно перемещается" ) или 303 ( "см. другое" ), и если сервер также возвращает один или несколько URI, где ресурс можно найти, тогда клиент ДОЛЖЕН обрабатывать новые URI как если в конце был добавлен идентификатор фрагмента исходного URI.

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

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

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

@Julian Reschke или @Mark Nottingham, вероятно, знают больше/лучше об этом.

Ответ 3

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

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

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