Фрагмент URL-адреса и 302 перенаправления
https://stackoverflow.com/questions/2286402
-
21-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Хорошо известно, что фрагмент URL (часть после #) не отправляется на сервер.
Мне действительно интересно, однако, как работают фрагменты при перенаправлении сервера (через HTTP status 302 и Location: заголовок) задействован.
Мой вопрос действительно двоякий:
Если исходный URL-адрес содержал фрагмент (
/original.php#foo), и делается перенаправление на/new.php, просто ли теряется фрагментная часть исходного URL-адреса?Или это иногда применяется к новому URL-адресу?
Будет ли когда-нибудь новый URL-адрес/new.php#fooв данном случае?Независимо от исходного URL-адреса, если сервер перенаправляет на новый URL-адрес с фрагментом (
/new.php#foo), получит ли фрагмент "честь"?Или сервер действительно вообще не имеет права вмешиваться во фрагмент - и поэтому браузер проигнорирует его, просто перейдя к/new.php??
Решение
Обновление 2014-27 июня:
RFC 7231, Протокол передачи гипертекста (HTTP/1.1):Семантика и содержание, был опубликован в качестве ПРЕДЛАГАЕМОГО СТАНДАРТА.Из Журнал изменений:
Синтаксис поля заголовка Location был изменен, чтобы разрешить все Ссылки URI, включая относительные ссылки и фрагменты, наряду с некоторыми разъяснениями относительно того, когда использование фрагментов было бы нецелесообразно .(Раздел 7.1.2)
Важные моменты из Раздел 7.1.2.Расположение:
Если значение местоположения, указанное в ответе 3xx (перенаправление), не содержит компонента fragment, агент пользователя ДОЛЖЕН обработать перенаправление так, как если бы значение наследовало компонент fragment URI ссылка, используемая для генерации целевого запроса (т.Е. перенаправления наследует фрагмент исходной ссылки, если таковой имеется).
Например, Запрос GET, сгенерированный для ссылки на URI "http://www.example.org /~тим" может привести к 303 (См. Другое) ответ, содержащий поле заголовка:
Location: /People.html#timчто предполагает, что пользовательский агент перенаправляет на "http://www.example.org/People.html#tim"
Аналогично, запрос GET, сгенерированный для ссылки на URI "http://www.example.org/index.html#larry" может привести к 301 (перемещенному постоянно) ответу, содержащему поле заголовка:
Location: http://www.example.net/index.htmlчто предполагает, что пользовательский агент перенаправляет на "http://www.example.net/index.html#larry", сохраняя исходный идентификатор фрагмента.
Это должно четко ответить на ваши вопросы.
КОНЕЦ обновления
это открытая (не указанная) проблема с текущая спецификация HTTP.это рассматривается в 2 выпусках Рабочая группа IETF httpbis:
- #6: Фрагменты, разрешенные в Местоположении
- #43: Комбинация фрагментов / приоритет при перенаправлениях
#6 разрешает фрагменты в Location заголовок.в № 43 говорится следующее:
Я только что протестировал это с различными браузерами.
- Firefox и Safari используют фрагмент в заголовке location.
- Opera использует фрагмент из исходного URI, если он присутствует, в противном случае фрагмент из местоположения перенаправления
- IE (8) игнорирует фрагмент в URI местоположения, таким образом, будет использовать фрагмент из URI источника, когда он присутствует
Предложение:
"Примечание:поведение, когда необходимо объединить идентификаторы фрагмента из исходного URI и перенаправления, не определено;текущие пользовательские агенты действительно различаются в зависимости от того, какой фрагмент имеет приоритет ".
[...]
Похоже, что IE8 делает используйте идентификатор фрагмента из
Location(поведение, которое я видел, может быть ограничено localhost).Таким образом, мы, похоже, имеем согласованное поведение для Safari / IE / Firefox / Chrome (только что протестировано), поскольку используется фрагмент из заголовка Location, независимо от того, каким был исходный URI.
Поэтому я меняю свое предложение на документ это как и ожидалось, поведение.
это приводит к наиболее совместимому с браузером и надежному на будущее (поскольку эта проблема в конечном итоге будет стандартизирована) ответу на ваш вопрос:
A: фрагменты из исходных URL-адресов отбрасываются.
B: фрагменты из Location заголовки соблюдены.
Другие советы
Safari 5 и IE9 и ниже удаляют фрагмент исходного URI, если происходит перенаправление HTTP / 3xx.Если в заголовке Location в ответе указан фрагмент, он используется.
IE10+, Chrome 11+, Firefox 4+ и Opera будут "повторно подключать" исходный фрагмент URI после выполнения перенаправления 3xx.
Тестовая страница: http://www.webdbg.com/test/redir/fragment/.
Смотрите дальнейшее обсуждение этого вопроса на http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
Просто чтобы вы знали, здесь вы можете найти подходящую спецификацию.с помощью w3c определяя, как все должны вести себя: http://www.w3.org/TR/cuap#uri - пункт 4.1 - смотрите ниже:
Когда ресурс (URI1) перемещен, HTTP-перенаправление может указывать на его новое местоположение (URI2).
Если URI1 имеет идентификатор фрагмента #frag, то новой целью, к которой должен стремиться пользовательский агент , будет URI2#frag.Если URI2 уже имеет идентификатор фрагмента, то #frag добавлять не следует и новым целевым значением является URI2.
Неправильно:Большинство современных пользовательских агентов реализуют HTTP-перенаправление, но не делают этого добавляют идентификатор фрагмента к новому URI, что обычно сбивает пользователя с толку, потому что в конечном итоге он получает неправильный ресурс.
Ссылки:
Перенаправления HTTP описаны в разделе 10.3 протокола HTTP/1.1 спецификация [RFC2616].Требуемое поведение подробно описано в разделе "Обработка идентификаторов фрагментов в перенаправленных URL" [RURL]. Термин "Постоянный унифицированный указатель ресурсов (Persistent Uniform Resource Locator, PURL)" обозначает URL ( особый случай URI), который указывает на другой URL через HTTP перенаправление.Для получения дополнительной информации обратитесь к "Постоянному унифицированному ресурсу Локаторы" [PURL].Пример:
Предположим, что пользователь запрашивает ресурс по адресу http://www.w3.org/TR/WD-ruby/#changes и сервер перенаправляет пользовательский агент на http://www.w3.org/TR/ruby/.Прежде чем извлекать это последнее URI, браузер должен добавить к нему идентификатор фрагмента #changes: http://www.w3.org/TR/ruby/#changes.
