Fragmento de URL y redirecciones 302
Es bien sabido que el fragmento de URL (la parte después de #) no se envía al servidor.
Sin embargo, me pregunto cómo funcionan los fragmentos cuando se Location:trata de una redirección del servidor (a través del estado HTTP 302 y el encabezado).
Mi pregunta es realmente doble:
Si la URL original tenía un fragmento (
/original.php#foo) y se realiza una redirección a/new.php, ¿simplemente se pierde la parte del fragmento de la URL original? ¿O a veces se aplica a la nueva URL?
¿La nueva URL alguna vez estará/new.php#fooen este caso?Independientemente de la URL original, si el servidor redirige a una nueva URL con un fragmento (
/new.php#foo), ¿se "honrará" el fragmento? ¿O el servidor realmente no tiene por qué interferir con el fragmento y, por lo tanto, el navegador lo ignorará simplemente yendo a/new.php??
Actualización 2022-09-22 :
RFC 9110/STD 97 HTTP Semantics (que deja obsoleto a 7231 (y otros)) se publicó como ESTÁNDAR DE INTERNET en junio de 2022. La redacción de la Sección 10.2.2 Ubicación recién numerada permanece igual que antes/a continuación.
Actualización 27 de junio de 2014 :
RFC 7231, Protocolo de transferencia de hipertexto (HTTP/1.1): Semántica y contenido , se ha publicado como ESTÁNDAR PROPUESTO. Del registro de cambios :
La sintaxis del campo del encabezado Ubicación se ha cambiado para permitir todas las referencias de URI, incluidas las referencias relativas y los fragmentos, junto con algunas aclaraciones sobre cuándo el uso de fragmentos no sería apropiado. (Sección 7.1.2)
Los puntos importantes de la Sección 7.1.2. Ubicación :
Si el valor de Ubicación proporcionado en una respuesta 3xx (Redireccionamiento) no tiene un componente de fragmento, un agente de usuario DEBE procesar la redirección como si el valor heredara el componente de fragmento de la referencia de URI utilizada para generar el destino de la solicitud (es decir, la redirección hereda fragmento de la referencia original, si la hubiere).
Por ejemplo, una solicitud GET generada para la referencia de URI "http://www.example.org/~tim" podría generar una respuesta 303 (Ver otros) que contenga el campo de encabezado:
Location: /People.html#timlo que sugiere que el agente de usuario redirija a "http://www.example.org/People.html#tim"
Del mismo modo, una solicitud GET generada para la referencia de URI "http://www.example.org/index.html#larry" podría generar una respuesta 301 (Movida permanentemente) que contenga el campo de encabezado:
Location: http://www.example.net/index.htmllo que sugiere que el agente de usuario redirija a "http://www.example.net/index.html#larry", conservando el identificador de fragmento original.
Esto debería responder claramente a sus preguntas.
Actualizar FIN
Este es un problema abierto (no especificado) con la especificación HTTP actual . se aborda en 2 números del grupo de trabajo httpbis del IETF :
- #6: Fragmentos permitidos en la ubicación
- #43: Combinación/precedencia de fragmentos durante las redirecciones
#6 permite fragmentos en el Locationencabezado. #43 dice esto:
Acabo de probar esto con varios navegadores.
- Firefox y Safari usan el fragmento en el encabezado de ubicación.
- Opera utiliza el fragmento del URI de origen, cuando está presente; de lo contrario, el fragmento de la ubicación de redireccionamiento
- IE (8) ignora el fragmento en el URI de ubicación, por lo que utilizará el fragmento del URI de origen, cuando esté presente.
Propuesta:
"Nota: el comportamiento cuando los identificadores de fragmentos del URI original y la redirección deben combinarse no está definido; los agentes de usuario actuales difieren en cuanto a qué fragmento tiene prioridad".
[...]
Parece que IE8 usa el identificador de fragmento
Location(el comportamiento que vi podría estar limitado a localhost).
Por lo tanto, parece que tenemos un comportamiento consistente para Safari/IE/Firefox/Chrome (recién probado), en el sentido de que se utiliza el fragmento del encabezado Ubicación, sin importar cuál sea el URI original.
Por lo tanto, cambio mi propuesta para documentarlo como comportamiento esperado.
esto conduce a la respuesta más compatible con el navegador y preparada para el futuro (porque este problema eventualmente se estandarizará) a su pregunta:
R: los fragmentos de las URL originales se descartan.
B:Location se respetan los fragmentos del encabezado.
Safari 5 e IE9 y versiones inferiores eliminan el fragmento del URI original si se produce una redirección HTTP/3xx. Si el encabezado Ubicación de la respuesta especifica un fragmento, se utiliza.
IE10+, Chrome 11+, Firefox 4+ y Opera "volverán a adjuntar" el fragmento del URI original después de seguir una redirección 3xx.
Página de prueba: http://www.webdbg.com/test/redir/fragment/ .
Consulte más información sobre este tema en http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx
Sólo para que lo sepas, aquí puedes encontrar las especificaciones adecuadas. por w3c definiendo cómo deben comportarse todos: http://www.w3.org/TR/cuap#uri - cláusula 4.1 - ver a continuación:
Cuando un recurso (URI1) se ha movido, una redirección HTTP puede indicar su nueva ubicación (URI2).
Si URI1 tiene un identificador de fragmento #frag, entonces el nuevo objetivo que el agente de usuario debería intentar alcanzar sería URI2#frag. Si URI2 ya tiene un identificador de fragmento, entonces no se debe agregar #frag y el nuevo destino es URI2.
Incorrecto: la mayoría de los agentes de usuario actuales implementan redireccionamientos HTTP pero no agregan el identificador de fragmento al nuevo URI, lo que generalmente confunde al usuario porque termina con el recurso incorrecto.
Referencias:
Las redirecciones HTTP se describen en la sección 10.3 de la especificación HTTP/1.1 [RFC2616]. El comportamiento requerido se describe en detalle en "Manejo de identificadores de fragmentos en URL redirigidas" [RURL]. El término "Localizador uniforme de recursos persistente (PURL)" designa una URL (un caso especial de URI) que apunta a otra a través de una redirección HTTP. Para obtener más información, consulte "Localizadores uniformes de recursos persistentes" [PURL]. Ejemplo:
Supongamos que un usuario solicita el recurso en http://www.w3.org/TR/WD-ruby/#changes y el servidor redirige al agente de usuario a http://www.w3.org/TR/ruby/ . Antes de recuperar ese último URI, el navegador debe agregarle el identificador de fragmento #changes: http://www.w3.org/TR/ruby/#changes .
