2009-09-23 25 views
6

Esta es la situación:negociación contenido ignorado cuando se utiliza el navegador botón Atrás

Tengo una aplicación web que la respuesta a una solicitud de una lista de recursos, le dicen:

/items 

Este es un principio solicitado directamente por el navegador web navegando a esa ruta. El navegador usa su encabezado estándar "Aceptar" que incluye "texto/html" y mi aplicación lo nota y devuelve el contenido HTML para la lista de elementos.

Dentro del HTML devuelto es un poco de Javascript (jQuery), que a su vez hace una petición AJAX para recuperar los datos reales:

/items 

Sólo que esta vez, el "Aceptar" de cabecera se establece explícitamente en "application/json ". De nuevo, mi aplicación lo nota y JSON se devuelve correctamente a la solicitud, los datos se insertan en la página y todo está satisfecho.

Aquí viene el problema: El usuario navega a otra página y luego presiona el botón ATRÁS. Luego se les pide que guarden un archivo. Esto resulta ser el JSON datos de la lista de elementos.

Hasta ahora he confirmado que esto sucederá tanto en Google Chrome como en Firefox 3.5.

Hay dos posibles tipos de respuestas aquí:

  1. ¿Cómo puedo solucionar el problema. ¿Hay alguna combinación mágica de encabezados de control de caché, u otro vudú que haga que el navegador haga lo correcto aquí?

  2. Si cree que estoy haciendo algo horriblemente mal aquí, ¿cómo debo ir al acerca de esto? Estoy buscando la corrección, pero también estoy tratando de no sacrificar flexibilidad.

Si ayuda, la aplicación es una aplicación web JAX-RS, utilizando Restlet 2.0m4. Puedo proporcionar encabezados de solicitud/respuesta de muestra si es útil, pero creo que el problema es completamente reproducible.

+0

botón "Volver" es el mal. –

+0

Esto parece un problema futuro que voy a tener después de descubrir (http://stackoverflow.com/questions/5250923). Tengo curiosidad, ¿terminaste apegándote a esta solución o finalmente la abandonaste para diferentes URL? La limpieza de la única URL RESTful para diferentes representaciones del mismo recurso es ciertamente ideal. – mckamey

Respuesta

6

¿Hay alguna combinación mágica de encabezados de control de caché u otro vudú que haga que el navegador haga lo correcto aquí?

Si va a servir diferentes respuestas a diferentes Accept: cabeceras, debe incluir el encabezado:

Vary: Accept 

en su respuesta. El encabezado Vary también debe contener cualquier otro encabezado de solicitud que influya en la respuesta, por lo que, por ejemplo, si realiza la compresión gzip/deflate, deberá incluir Aceptar codificación.

IE, lamentablemente maneja muchos valores de Vary mal, rompiendo la caché por completo, lo que podría o no ser importante para usted.

Si crees que estoy haciendo algo terriblemente malo aquí, ¿cómo debo hacerlo?

No creo que la idea de servir contenido diferente para diferentes tipos en la misma URL sea terriblemente incorrecta, pero te estás permitiendo más problemas de compatibilidad de los que realmente necesitas. Depender de los encabezados que trabajan a través de JSON no es realmente una gran idea en la práctica; Sería mejor que solo tuviera una URL diferente, como /items/json o /items?format=json.

+0

Servir un recurso diferente en la misma URL es incorrecto; servir a diferentes representaciones del mismo recurso es lo que se supone que HTTP debe hacer. ¿Desea verlo en XML, JSON, HTML legible con formato agradable o texto sin formato? Siempre es lo mismo, pero con su elección de formatos. Desafortunadamente, algunos navegadores rompen esto y tienes que usar un truco como en la respuesta. Si su servicio ofrece tanto "application/json" como "text/html", Internet Explorer buscará la versión JSON debido a su encabezado Accept retorcido. –

1

Sé que esta pregunta es viejo, pero por si acaso alguien más se encuentra con esto:

que estaba teniendo el mismo problema con una aplicación Rails usando jQuery, y lo arreglé diciendo al navegador que no almacenar en caché el respuesta JSON con la solución dada aquí a una pregunta diferente:

jQuery $.getJSON works only once for each control. Doesn't reach the server again

el problema sólo parecía ocurrir con Chrome y Firefox. Safari manejaba bien el comportamiento de la espalda sin tener que decirle explícitamente que no caché.

+0

Esta respuesta funcionó para mí, si configuras la opción "caché" en tu solicitud de jQuery.ajax() a "falso" puedes responder y funcionará como se esperaba –

0

Pregunta anterior, pero para cualquier otra persona que vea esto, no hay nada de malo en el uso del encabezado Accept por parte del autor de la pregunta.

Este es un error confirmado en Chrome. (Anteriormente también en Firefox pero desde fijo.)

http://code.google.com/p/chromium/issues/detail?id=94369

Cuestiones relacionadas