¿Pidió a Chrome que omita la caché local para XmlHttpRequest como es posible en Firefox?

Question

Como algunos de ustedes ya saben, hay algunos problemas de almacenamiento en caché en Firefox/Chrome para las solicitudes que se inician con el objeto XmlHttpRequest. Estos problemas significan que el navegador no sigue estrictamente las reglas y no va al servidor para el nuevo archivo XSLT (por ejemplo). La respuesta no tiene el encabezado Expires (por razones de rendimiento no podemos usarlo).

Firefox tiene un parámetro adicional en el "canal" de objeto XHR al que le pone el valor Components.interfaces.nsIRequest.LOAD_BYPASS_CACHE para ir al servidor de forma explícita.

¿Existe algo así para Chrome?

Permítanme detener inmediatamente a todos que recomendarían agregar la marca de tiempo como un valor de parámetro GET o entero aleatorio - No deseo que el servidor obtenga diferentes solicitudes de URL. Quiero que obtenga la URL original. La razón es que quiero evitar que el servidor reciba demasiadas solicitudes diferentes de archivos estáticos simples y envíe demasiados datos a los clientes cuando no los necesite.

Si tocas el archivo estático con el parámetro GET generado (como '? Forcenew = 12314') obtendría 200 respuestas cada primera vez y 304 para cada solicitud siguiente para ese valor de entero aleatorio. Deseo realizar solicitudes que siempre devolverán 304 si el archivo estático de destino es idéntico a la versión del cliente. Esto es por cierto cómo los navegadores web deberían funcionar de inmediato, pero los objetos XHR tienden a no ir al servidor en absoluto para preguntar si el archivo se modificó o no.

Answer 1

En mi proyecto principal en el trabajo tuve el mismo problema exacto. Mi solución fue no agregar cadenas aleatorias o marcas de tiempo a las solicitudes GET, sino agregar una cadena específica a las solicitudes GET.

Si tiene un número de revisión, p. revisión de subversión o de git/mer o lo que sea que esté usando, añada eso. Los archivos estáticos obtendrán 304 respuestas hasta el momento en que se publique una nueva revisión. Cuando se produce la nueva versión, se concede una única respuesta de 200 y vuelve a generar 304 respuestas felizmente. :-)

Esto tiene la ventaja añadida de ser independiente del navegador.

En caso de que tenga mala suerte y no tenga un número de revisión, cree una y auméntela cada vez que realice una publicación.

Answer 2

Debe buscar en Etags, los etags son claves que se pueden generar a partir del contenido del archivo, por lo tanto, una vez que el archivo en el servidor cambia, el sistema será un nuevo etag. Obviamente, este será un cambio en el lado del servicio, que es algo que tendrá que hacer dado que quiere un 200 y luego un 304 posterior. Chrome y FF deberían respetar estos etags, por lo que no debería tener que hacer ningún hack loco del lado del cliente.

Answer 3

Chrome ahora admite Cache-Control: max-age=0 solicitud encabezado HTTP. Se puede establecer que después de abrir un XMLHttpRequest ejemplo:

xhr.setRequestHeader("Cache-Control", "max-age=0"); 

Esto le indicará a Chrome para no utilizar la respuesta en caché sin revalidación.

Para obtener más información, marque The State of Browser Caching, Revisited por Mark Nottingham y RFC 7234 Hypertext Transfer Protocol (HTTP/1.1): Caching.