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 registro de cambios :
La sintaxis del campo del encabezado Ubicación se ha cambiado para permitir todas las referencias de URI, incluidas las referencias y fragmentos relativos, junto con algunas aclaraciones sobre cuándo no sería apropiado el uso de fragmentos. (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 URI utilizada para generar el objetivo de solicitud (es decir, la redirección hereda el fragmento de la referencia original, si existe).
Por ejemplo, una solicitud GET generada para la referencia de URI " http://www.example.org/~tim " podría dar como resultado una respuesta 303 (Ver otra) que contiene 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 (movida permanentemente) que contiene el campo de encabezado:
Location: http://www.example.net/index.html
lo 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 de IETF :
# 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 tanto, usará 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 de hecho difieren en qué fragmento tiene prioridad".
[...]
Parece que IE8 hace uso de la idenfitier fragmento de Location(la vi comportamiento podría estar limitada a localhost).
Por lo tanto, parece que tenemos un comportamiento consistente para Safari / IE / Firefox / Chrome (recién probado), ya que el fragmento del encabezado Location se usa, sin importar cuál sea el URI original.
Por lo tanto, cambio mi propuesta para documentar eso como comportamiento esperado.
Esto lleva a la respuesta más compatible con el navegador y a prueba de futuro (porque este problema finalmente se estandarizará) responde a su pregunta:
R: los fragmentos de las URL originales se descartan.
B: se respetan los fragmentos del Locationencabezado.
