Фрагмент URL и 302 перенаправления

хорошо известно, что фрагмент URL (часть после #) не отправляется на сервер.

мне интересно, как работают фрагменты при перенаправлении сервера (через HTTP status 302 и Location: заголовок) участвует.

мой вопрос действительно в два раза:

  1. если исходный URL имел фрагмент (/original.php#foo), и перенаправление производится на /new.php, фрагментная часть исходного URL-адреса просто теряется? Или это иногда получается применяется к новому URL-адресу?
    будет ли новый URL когда-нибудь /new.php#foo в этом случае?

  2. независимо от исходного URL, если сервер перенаправляет на новый URL с фрагментом (/new.php#foo), будет ли фрагмент получить "честь"? Или у сервера действительно нет никакого бизнеса, мешающего фрагменту вообще - и будет ли браузер поэтому игнорировать его, просто перейдя к /new.php??

3 115
redirect http-redirect fragment-identifier

3 ответа:

Обновление 2014-Jun-27:

RFC 7231, протокол передачи гипертекста (HTTP / 1.1): семантика и содержание, был опубликован в качестве предлагаемого стандарта. Из список изменений:

синтаксис поля заголовка Location был изменен, чтобы разрешить все Ссылки URI, включая относительные ссылки и фрагменты, вдоль с некоторыми уточнениями относительно того, когда использование фрагментов не будет соответствующий. (Раздел 7.1.2)

важные моменты из 7.1.2. Расположение:

если значение местоположения, указанное в ответе 3xx (перенаправление), делает не иметь компонент фрагмента, агент пользователя должен обрабатывать перенаправление, как если бы значение наследует компонент фрагмента URI ссылка, используемая для создания целевого объекта запроса (т. е. перенаправления наследует фрагмент исходной ссылки, если таковой имеется).

например, a Получить запрос, сгенерированный для ссылки URI "http://www.example.org/~tim " может привести к 303 (см. Другое) ответ, содержащий поле заголовка:

Location: /People.html#tim

что свидетельствует о том, что агент пользователя перенаправление "http://www.example.org/People.html#tim"

кроме того, сделать запрос, созданный для 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 позволяет фрагменты в Location заголовок. #43 пишет это:

Я только что проверил это с различными браузерами.

  • Firefox и Safari используют фрагмент в заголовке location.
  • Opera использует фрагмент из исходного URI, когда присутствует, в противном случае фрагмент из места перенаправления
  • IE (8) игнорирует фрагмент в местоположении URI, таким образом будет использовать фрагмент из исходного URI, когда присутствует
111

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

36

просто чтобы вы знали, здесь вы можете найти правильную спецификацию. по 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]. Этот термин "хронический унифицированный указатель ресурса (изнаночные)" определяет URL-адрес (а частный случай URI), который указывает на другой через HTTP перенаправлять. Дополнительные сведения см. В разделе " постоянный единый ресурс Локаторы" [изнаночной]. Пример:

предположим, что пользователь запрашивает ресурс в http://www.w3.org/TR/WD-ruby/#changes и сервер перенаправляет агент пользователя для http://www.w3.org/TR/ruby/. Перед извлечение последнего URI, браузер должен добавить идентификатор фрагмента #изменения к нему: http://www.w3.org/TR/ruby/#changes.

8