Quais são as consequências para o uso de cabeçalhos de local relativo?

17

De acordo com a especificação , os cabeçalhos de localização usados em um redirecionamento requerem um nome de servidor

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

No entanto, em 2012, a maioria dos navegadores reconhecerá um caminho relativo e o redirecionará para o novo local usando o nome do servidor original

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

Há consequências negativas / surpreendentes para o uso dos URLs relativos nos cabeçalhos do local? Minha preocupação particular é como o Google / mecanismos de pesquisa interpretará isso, mas se houver mais alguma coisa em que eu não esteja pensando, adoraria ouvi-lo.

— Alan Storm
fonte

Você poderia citar exatamente o que você está obtendo desse requisito? Não é um desafio, simplesmente não o vejo imediatamente e não sinto vontade de ler uma RFC inteira para encontrá-la. Além disso, você está citando a especificação HTTP 1.0, mas usando cabeçalhos HTTP 1.1 em seus exemplos. (O que pode ou não alterar o conteúdo permitido.)

— '

A seção 10.11. tools.ietf.org/html/rfc1945#page-44 Também não há nada, até onde sei, na especificação 1.1 que "conserte" isso.

— Alan Storm

15

De acordo com a versão atual do padrão HTTP / 1.1, RFC 2616, o valor do Locationcabeçalho deve ser um URI absoluto .

No entanto, no rascunho do padrão preparado pelo HTTPbis Working Group para substituir o RFC 2616, isso foi alterado para permitir URIs relativos também, aparentemente porque :

"A definição do cabeçalho Location [na RFC 2616] difere de várias maneiras de como pelo menos os navegadores da Web precisam lidar com eles para interoperar com o conteúdo da Web"

Na prática, o AFAIK praticamente todos os principais navegadores e mecanismos de pesquisa entendem e aceitam redirecionamentos HTTP para URLs relativos. No entanto, até que o rascunho do HTTPbis um dia se torne o padrão oficial e seja amplamente adotado, sempre haverá alguns agentes de usuário novos ou obscuros que implementam o padrão atual à letra e aceitam apenas URLs absolutos. Portanto, o mais seguro a se fazer, por enquanto, é usar apenas URLs absolutas nos Locationcabeçalhos, conforme sugerido pela lei de Postel :

"Seja conservador no que envia, liberal no que aceita."

— Ilmari Karonen
fonte

3

O RFC 2616 agora foi obsoleto pelo 7231, que permite URLs relativos nos cabeçalhos de localização. Usuário agentes de aplicação da norma ao pé da letra, portanto, aceitar URLs relativos agora

— ZoFreX

6

A seção 14.30 da RFC HTTP 1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 não é significativamente diferente. Não sei se você verá limitações práticas reais para isso.

A única vez em que vi um aviso sobre esse problema foi quando eu testava no Lynx e o local não era absoluto, o alertaria "O valor do local não é absoluto" - mas, se bem me lembro, ainda o deixaria ir para o novo local. Acabei de testar o Lynx 2.8.7 e parece que não faz mais isso, embora isso possa ser um problema de configuração.

Agora você diz:

Minha preocupação particular é como o Google / mecanismos de pesquisa interpretará isso, mas se houver mais alguma coisa em que eu não esteja pensando, adoraria ouvi-lo.

Eu acredito que isso merece um teste. Eu configurava um URL, o colocava no sitemap xml do seu site e fazia com que esse URL fosse um redirecionamento, como você descreve. Acho que o melhor é verificar as Ferramentas do Google para webmasters e verificar se há consequências negativas.

— artlung
fonte