negociación de contenido ignora cuando se utiliza el navegador botón Atrás

Question

Aquí está la situación:

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

/items

Esto se solicitó inicialmente directamente por el navegador web accediendo a ese camino. El navegador utiliza es estándar "Aceptar" de cabecera que incluye "text / html" y mi solicitud da cuenta y devuelve el contenido HTML de la lista de elementos.

En el 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". Una vez más, mi solicitud se da cuenta y JSON se devuelve correctamente a la solicitud, los datos se inserta en la página, y todo es feliz.

Aquí viene el problema : El usuario navega a otra página, y luego presiona el botón BACK. A continuación, se le pedirá que guardar un archivo. Esta resulta ser la JSON de datos de la lista de elementos.

Hasta ahora he confirmado que esto suceda, tanto en Google Chrome y Firefox 3.5.

Hay dos posibles tipos de respuestas aquí:

1. ¿Cómo puedo solucionar el problema. Es existe alguna combinación de magia encabezados Cache-Control, u otro vudú que hacen que el navegador para hacer lo correcto?

2. Si usted piensa que estoy haciendo algo muy mal aquí, ¿cómo debería ir ¿sobre esto? Estoy en busca de corrección, sino también tratando de no sacrificar flexibilidad.

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

Answer 1

  

¿Hay alguna combinación mágica de cabeceras Cache-Control, o de otro tipo de vudú que hacen que el navegador para hacer lo correcto aquí?

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

Vary: Accept

en su respuesta. El cabecera Vary también debe contener ningún otro cabeceras de petición que influir en la respuesta, así que por ejemplo si lo hace gzip / desinflado de compresión que tendría que incluir Accept-Encoding.

IE, por desgracia maneja muchos valores de Vary mal, rompiendo Cacheing por completo, lo que podría o no le importan.

  

Si usted piensa que estoy haciendo algo muy mal aquí, ¿cómo debería hacerlo?

No creo que la idea de servir contenidos diferentes para diferentes tipos al mismo URL es muy mal, pero estás metiendo más problemas de compatibilidad de lo que realmente necesita. Basándose en las cabeceras de trabajo a través de JSON no es realmente una gran idea en la práctica; que estaría mejor fuera de sólo tener una URL diferente, como /items/json o /items?format=json.

Answer 2

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

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

jQuery $. getJSON funciona sólo una vez para cada control. No llega al servidor de nuevo

El problema sólo parecía ocurrir con Chrome y Firefox. Safari estaba manejando el comportamiento posterior bien sin tener explícitamente para decirle que no caché.

Answer 3

vieja pregunta, pero para que alguien más vea esto, no hay nada malo con el uso del interrogador de la cabecera Accept.

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

http://code.google.com/p/chromium/ temas / detalle? id = 94369