Hash de URL persiste entre redirecciones

Por alguna razón, los navegadores que no son IE persisten en un hash URL (si está presente) cuando se envía un redireccionamiento del lado del servidor (usando el encabezado Location). Ejemplo:

// a simple redirect using Response.Redirect("http://www.yahoo.com"); Text.aspx 

Si visito:

 Test.aspx#foo 

En Firefox / Chrome, me llevan a:

 http://www.yahoo.com#foo 

¿Alguien puede explicar por qué sucede esto? He intentado esto con varios redireccionamientos del lado del servidor en diferentes plataformas también (todo lo cual resulta en el encabezado de la ubicación, sin embargo) y esto siempre parece suceder. No lo veo en ninguna parte de la especificación HTTP, pero realmente parece ser un problema con los navegadores mismos. El hash de URL (como se esperaba) nunca se envía al servidor, por lo que la redirección del servidor no está contaminada, los navegadores simplemente lo siguen persistiendo por algún motivo.

¿Algunas ideas?

Sugiero que este es el comportamiento correcto. Los códigos de estado 302 y 307 indican que el recurso se encuentra en otro lugar. #bookmark es una ubicación dentro del recurso.

Una vez que se ha localizado el recurso (documento html), el navegador debe ubicar el #bookmark dentro del documento.

La analogía es esta: quieres buscar algo en un libro en el capítulo 57, entonces vas a la biblioteca para obtener el libro. Pero hay una nota en el estante que dice que el libro se ha movido, ahora está en el otro edificio. Entonces vas a la nueva ubicación. Todavía quieres el capítulo 57: es irrelevante dónde obtuviste el libro.

Este es un aspecto que no estaba cubierto por las especificaciones HTTP anteriores, pero se ha abordado en el desarrollo posterior de HTTP :

Si el servidor devuelve un código de respuesta de 300 (“opción múltiple”), 301 (“movido permanentemente”), 302 (“movido temporalmente”) o 303 (“vea otro”), y si el servidor también devuelve uno o más URI donde se puede encontrar el recurso, entonces el cliente DEBERÍA tratar los nuevos URI como si el identificador de fragmento del URI original se añadiera al final.

La excepción es cuando un URI devuelto ya tiene un identificador de fragmento. En ese caso, el identificador de fragmento original NO DEBE agregarse a él.

Por lo tanto, el fragmento del URI original también debe usarse para el URI de redirección a menos que también contenga un fragmento.

Aunque este fue solo un borrador que expiró en 2000, parece que el comportamiento descrito anteriormente es el comportamiento estándar de facto entre los navegadores web de hoy en día.

@Julian Reschke o @Mark Nottingham probablemente saben más / mejor sobre esto.

Por lo que he encontrado, no parece claro cuál debería ser el comportamiento exacto. Hay muchas personas que tienen problemas con esto, algunos quieren mantener el marcador a través del redireccionamiento, algunos quieren deshacerse de él.

Los diferentes navegadores manejan esto de manera diferente, por lo que en la práctica no es útil confiar en ninguno de los comportamientos.

Definitivamente es un problema del navegador. El navegador nunca envía la parte de marcador de la URL al servidor, por lo que no hay nada que el servidor pueda hacer para averiguar si hay un marcador o no, y no se puede hacer nada al respecto de manera confiable.

    Intereting Posts