¿Cuáles son las consecuencias de usar encabezados de ubicación relativa?

17

Según la especificación , los encabezados de ubicación utilizados en una redirección requieren un nombre de servidor

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

Sin embargo, en 2012, la mayoría de los navegadores web reconocerán una ruta relativa y lo redirigirán a la nueva ubicación utilizando el nombre del servidor original

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

¿Existen consecuencias negativas / sorprendentes al usar las URL relativas en los encabezados de ubicación? Mi preocupación particular es cómo Google / motores de búsqueda interpretarán esto, pero si hay algo más en lo que no estoy pensando, me encantaría escucharlo.

— Alan Storm
fuente

¿Podría citar la parte exacta de la que obtiene ese requisito? No es un desafío, simplemente no lo veo de inmediato y no tengo ganas de leer un RFC completo para encontrarlo. Además, está citando la especificación HTTP 1.0 pero está usando encabezados HTTP 1.1 en sus ejemplos. (Lo que puede o no cambiar el contenido permitido.)

— Su

La sección 10.11. tools.ietf.org/html/rfc1945#page-44 Tampoco hay nada, que yo sepa, en la especificación 1.1 que "corrige" esto.

— Alan Storm

15

Según la versión actual del estándar HTTP / 1.1, RFC 2616, el valor del Locationencabezado debe ser un URI absoluto .

Sin embargo, en el borrador del estándar preparado por el Grupo de Trabajo HTTPbis para eventualmente reemplazar RFC 2616, esto también se ha cambiado para permitir URIs relativos, aparentemente porque :

"La definición del encabezado de ubicación [en RFC 2616] difiere en varias formas de cómo al menos los navegadores web deben lidiar con ellos para interactuar con el contenido en la Web"

En la práctica, AFAIK casi todos los principales navegadores y motores de búsqueda entienden y aceptan los redireccionamientos HTTP a las URL relativas. Sin embargo, hasta que el borrador de HTTPbis algún día se convierta en el estándar oficial y sea ampliamente adoptado, siempre habrá algunos agentes de usuario nuevos u oscuros que implementarán el estándar actual al pie de la letra y solo aceptarán URL absolutas. Por lo tanto, lo más seguro , por ahora, es usar solo URL absolutas en los Locationencabezados, como sugiere la ley de Postel :

"Sea conservador en lo que envía, liberal en lo que acepta".

— Ilmari Karonen
fuente

3

RFC 2616 ahora ha quedado obsoleto por 7231, lo que permite URL relativas en los encabezados de ubicación. Por lo tanto, los agentes de usuario que implementen el estándar al pie de la letra aceptarán las URL relativas ahora

— ZoFreX

6

La sección 14.30 del HTTP 1.1 RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 no es significativamente diferente. No sé si verá limitaciones prácticas reales para esto.

La única vez que he visto una advertencia sobre este problema es cuando solía hacer una prueba en Lynx y la ubicación no era absoluta, le advertiría "El valor de la ubicación no es absoluto", pero si recuerdo bien, todavía lo dejaría ir. a la nueva ubicación. Acabo de probar Lynx 2.8.7 y parece que ya no lo hace, aunque eso puede ser un problema de configuración.

Ahora tu dices:

Mi preocupación particular es cómo Google / motores de búsqueda interpretarán esto, pero si hay algo más en lo que no estoy pensando, me encantaría escucharlo.

Creo que esto justifica una prueba. Configuraría una url, la pondría en el mapa del sitio xml de su sitio , y esa URL sería una redirección como usted describe. Creo que lo que hay que hacer es verificarlo con las Herramientas para webmasters de Google y ver si hay consecuencias negativas.

— artlung
fuente