URL-fragment и 302 перенаправления

Хорошо известно, что fragment URL (часть после # ) не отправляется на сервер.

Я действительно удивляюсь, как работают fragmentы при перенаправлении сервера (через HTTP-статус 302 и Location: заголовок).

Мой вопрос действительно двоякий:

Если исходный URL-адрес имеет fragment ( /original.php#foo ), а redirect выполняется в /new.php , часть fragmentа исходного URL-адреса просто теряется? Или иногда он применяется к новому URL-адресу?
Будет ли в этом случае новый URL-адрес /new.php#foo ?
Независимо от исходного URL-адреса, если сервер перенаправляет на новый URL-адрес с fragmentом ( /new.php#foo ), будет ли fragment получать «честь»? Или на самом деле сервер вообще не вмешивается в этот fragment – и поэтому браузер игнорирует его, просто перейдя в /new.php ?

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

RFC 7231, протокол передачи гипертекста (HTTP / 1.1): семантика и контент , опубликован как ПРЕДЛАГАЕМЫЙ СТАНДАРТ. Из списка изменений :

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

Важные моменты из раздела 7.1.2. Откуда :

Если значение местоположения, указанное в ответе 3xx (redirect), не имеет компонента fragmentа, пользовательский агент ДОЛЖЕН обрабатывать redirect, как если бы это значение наследовало компонент fragmentа ссылки на URI, используемый для генерации цели запроса (т. Е. Перенаправление наследует fragment исходной ссылки, если таковой имеется).

Например, запрос GET, сгенерированный для ссылки URI « http://www.example.org/~tim », может привести к ответу 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 », сохраняя исходный идентификатор fragmentа.

Это должно четко ответить на ваши вопросы.

Обновить END

это открытая (не указанная) проблема с текущей спецификацией HTTP . он рассматривается в двух выпусках рабочей группы IETF httpbis :

# 6: Разрешены fragmentы в местоположении
# 43: Комбинация fragmentов / приоритет во время перенаправления

# 6 позволяет fragmentы в заголовке Location . # 43 говорит следующее:

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

Firefox и Safari используют fragment в заголовке местоположения.

Opera использует fragment из исходного URI, если присутствует, в противном случае fragment из места перенаправления

IE (8) игнорирует fragment в URI местоположения, поэтому будет использовать fragment из исходного URI, если он присутствует

Предложение:

«Примечание: поведение, когда идентификаторы fragmentов из исходного URI и перенаправления должны быть объединены, не определено, а текущие пользовательские агенты действительно отличаются от того, какой fragment имеет приоритет».

[…]

Похоже, что IE8 использует идентификатор idenfitier из Location (поведение, которое я видел, может быть ограничено локальным хостом).

Таким образом, у нас, похоже, есть последовательное поведение для Safari / IE / Firefox / Chrome (только что протестировано), поскольку используется fragment из заголовка Location, независимо от того, что изначально был URI.

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

это приводит к наиболее совместимому с браузером и будущему доказательству (поскольку эта проблема в конечном итоге будет стандартизирована) ответит на ваш вопрос:

A: fragmentы исходных URL-адресов отбрасываются.

B: fragmentы из заголовка Location соблюдены.

Safari 5 и IE9 и ниже удаляют исходный fragment URI, если происходит redirect HTTP / 3xx. Если заголовок Location в ответ указывает fragment, он используется.

IE10 +, Chrome 11+, Firefox 4+ и Opera будут «повторно прикреплять» исходный fragment 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) перемещен, redirect HTTP может указывать на его новое местоположение (URI2).

Если URI1 имеет идентификатор fragmentа #frag, то новая цель, которую должен пытаться достичь пользовательский агент, будет URI2 # frag. Если URI2 уже имеет идентификатор fragmentа, то #frag не следует добавлять, а новой целью является URI2.

Неправильно. Большинство современных агентов-пользователей реализуют HTTP-перенаправления, но не добавляют идентификатор fragmentа к новому URI, что обычно путает пользователя, потому что в конечном итоге они попадают в неправильный ресурс.

Рекомендации:

Переадресации HTTP описаны в разделе 10.3 спецификации HTTP / 1.1 [RFC2616]. Необходимое поведение подробно описано в разделе «Обработка идентификаторов fragmentов в перенаправленных URL» [RURL]. Термин «Постоянный унифицированный указатель ресурсов (PURL)» обозначает URL-адрес (частный случай URI), который указывает на другой через redirect HTTP. Для получения дополнительной информации см. Раздел «Устойчивые унифицированные указатели ресурсов» [PURL]. Пример:

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