redireccionamientos - redirect 301 htaccess

Fragmento URL y 302 redirecciones (3)

Es bien sabido que el fragmento de URL (la parte posterior al # ) no se envía al servidor.

Sin embargo, me pregunto cómo funcionan los fragmentos cuando un servidor redirige (mediante el estado HTTP 302 y la Location: encabezado).

Mi pregunta es realmente doble:

Si la URL original tenía un fragmento ( /original.php#foo ) y se redirige a /new.php , ¿la parte del fragmento de la URL original simplemente se pierde? ¿O a veces se aplica a la nueva URL?
¿La nueva URL será /new.php#foo en 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 ningún inconveniente en interferir con el fragmento, y el navegador, por lo tanto, lo ignorará simplemente yendo a /new.php ?

Para hacerte saber, aquí puedes encontrar las especificaciones adecuadas. por w3c definir cómo deberían comportarse todos: w3.org/TR/cuap#uri - cláusula 4.1 - ver a continuación:

Cuando un recurso (URI1) se ha movido, un redireccionamiento de 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 tratar de alcanzar sería URI2 # frag. Si URI2 ya tiene un identificador de fragmento, entonces #frag no se debe agregar 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, que generalmente confunde al usuario porque terminan con el recurso incorrecto.
Referencias
Los redireccionamientos 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 persistentes (PURL)" designa un URL (un caso especial de un URI) que apunta a otro a través de un redireccionamiento HTTP. Para obtener más información, consulte "Localizadores de recursos uniformes 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 buscar este último URI, el navegador debe anexar el identificador de fragmento #changes: http://www.w3.org/TR/ruby/#changes .

Safari 5 e IE9 y siguientes eliminan el fragmento del URI original si se produce una redirección HTTP / 3xx. Si el encabezado de ubicación en la respuesta especifica un fragmento, se usa.

IE10 +, Chrome 11+, Firefox 4+ y Opera "volverán a conectar" 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

Actualización 2014-junio-27 :

RFC 7231, Protocolo de transferencia de hipertexto (HTTP / 1.1): Semántica y contenido , se ha publicado como una NORMA PROPUESTA. Desde el Changelog :

La sintaxis del campo del encabezado de ubicación se ha modificado para permitir todas las referencias de URI, incluidas referencias y fragmentos relativos, 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 (Redirección) 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 objetivo de solicitud (es decir, la redirección hereda el fragmento de la referencia original, si hay alguno).
Por ejemplo, una solicitud GET generada para la referencia URI " http://www.example.org/~tim " podría dar como resultado una respuesta 303 (Ver Otro) que contenga el campo de encabezado:
Location: /People.html#tim
lo 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 dar como resultado una respuesta 301 (Movido permanentemente) que contiene el campo de encabezado:
Location: http://www.example.net/index.html
lo que sugiere que el agente de usuario redireccione a " http://www.example.net/index.html#larry ", conservando el identificador de fragmento original.

Esto debería responder claramente sus preguntas.

Actualizar END

este es un problema abierto (no especificado) con la especificación HTTP actual . se trata en 2 números del grupo de trabajo httpbis IETF :

# 6 permite fragmentos en el encabezado de la Location . # 43 dice esto:

Acabo de probar esto con varios navegadores.
Firefox y Safari usan el fragmento en el encabezado de ubicación.
Opera usa el fragmento del URI de origen, cuando está presente; de lo contrario, el fragmento de la ubicación de redirección
IE (8) ignora el fragmento en el URI de ubicación, por lo tanto usará el fragmento del URI de origen, cuando esté presente
Propuesta:
"Nota: el comportamiento cuando los identificadores de fragmentos del URI original y el redireccionamiento necesitan combinarse no está definido, los Agentes de usuario actuales difieren en qué fragmento tiene prioridad".
[...]
Parece que IE8 usa el fragmento idenfitier de 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 usa el fragmento del encabezado Location, sin importar el URI original.
Por lo tanto, cambio mi propuesta para documentar eso como comportamiento esperado.

esto lleva a la mayoría de los navegadores compatibles y a prueba de futuro (porque este problema finalmente se estandarizará) a su pregunta:

A: los fragmentos de las URL originales se descartan.

B: se respetan los fragmentos del encabezado de Location .