Каковы последствия использования заголовков относительного расположения?

17

Согласно спецификации , заголовки Location, используемые в перенаправлении, требуют имя сервера

HTTP/1.1 301 Moved Permanently
...
Location: http://example.com/foo/baz/bar

Однако в 2012 году большинство веб-браузеров распознают относительный путь и перенаправляют вас на новое место, используя исходное имя сервера.

HTTP/1.1 301 Moved Permanently
...
Location: /foo/baz/bar

Есть ли какие-либо негативные / неожиданные последствия использования относительных URL в заголовках Location? Меня особенно беспокоит то, как Google / поисковые системы будут интерпретировать это, но если есть что-то еще, о чем я не думаю, я бы хотел услышать это.

— Алан Сторм
источник

Не могли бы вы привести точную цифру, из которой вы получаете это требование? Не сложно, я просто не сразу это вижу и не хочу читать весь RFC, чтобы найти его. Кроме того, вы цитируете спецификацию HTTP 1.0, но в своих примерах используете заголовки HTTP 1.1 . (Который может или не может изменить разрешенный контент.)

— Su '

Раздел 10.11. tools.ietf.org/html/rfc1945#page-44 Насколько мне известно, в спецификации 1.1 нет ничего, что "исправляет" это.

— Алан Сторм

15

В соответствии с текущей версией стандарта HTTP / 1.1, RFC 2616, значение Locationзаголовка должно быть абсолютным URI .

Однако в проекте стандарта, подготовленном Рабочей группой HTTPbis для последующей замены RFC 2616, он был изменен, чтобы разрешить также относительные URI, по- видимому, потому что :

«Определение заголовка Location [в RFC 2616] отличается по-разному в том, как, по крайней мере, веб-браузеры должны взаимодействовать с ними для взаимодействия с контентом в Интернете».

На практике AFAIK почти все основные браузеры и поисковые системы понимают и принимают перенаправления HTTP на относительные URL-адреса. Однако до тех пор, пока однажды черновик HTTPbis не станет официальным стандартом и получит широкое распространение, всегда будут какие-то новые или непонятные пользовательские агенты, которые реализуют текущий стандарт письма и принимают только абсолютные URL-адреса. Таким образом, сейчас безопаснее всего использовать абсолютные URL-адреса в Locationзаголовках, как это предусмотрено законом Постеля :

«Будь консервативным в том, что ты посылаешь, либеральным в том, что ты принимаешь».

— Илмари Каронен
источник

3

RFC 2616 теперь устарел на 7231, что разрешает относительные URL в заголовках Location. Поэтому пользовательские агенты, реализующие стандарт к письму, теперь будут принимать относительные URL-адреса

— ZoFreX

6

Раздел 14.30 RFC HTTP 1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 существенно не отличается. Я не знаю, что вы увидите какие-то реальные практические ограничения для этого.

Единственный раз, когда я видел даже предупреждение об этой проблеме, это когда я использовал для тестирования в Lynx, и местоположение не было абсолютным, оно предупреждает вас «Значение местоположения не абсолютное» - но если я правильно помню, оно все равно отпустит вас на новое место. Я только что протестировал Lynx 2.8.7 и похоже, что он больше этого не делает, хотя это может быть проблемой конфигурации.

Теперь вы говорите:

Меня особенно беспокоит то, как Google / поисковые системы будут интерпретировать это, но если есть что-то еще, о чем я не думаю, я бы хотел услышать это.

Я считаю, что это требует проверки. Я бы настроил URL, поместил бы его в xml sitemap вашего сайта и сделал бы этот URL-адрес перенаправлением, как вы описываете. Я думаю, что нужно проверить это с помощью Google Webmaster Tools и посмотреть, есть ли негативные последствия.

— artlung
источник