Evitar el almacenamiento en caché del navegador del resultado de la llamada AJAX de jQuery

Lo siguiente evitará que todas las solicitudes AJAX futuras se almacenen en caché, independientemente del método jQuery que utilice ($.conseguir, $.ajax, etc.)

$.ajaxSetup({ cache: false });

JQuery $.get() almacenará en caché los resultados. En lugar de

$.get("myurl", myCallback)

Deberías usar $.ajax, que le permitirá desactivar el almacenamiento en caché:

$.ajax({url: "myurl", success: myCallback, cache: false});

Otra forma es no proporcionar encabezados de caché desde serverside en el código que genera la respuesta a la llamada ajax:

response.setHeader( "Pragma", "no-cache" );
response.setHeader( "Cache-Control", "no-cache" );
response.setDateHeader( "Expires", 0 );

Todas las respuestas aquí dejan una huella en la URL solicitada que se mostrará en los registros de acceso del servidor.

Necesitaba una solución basada en encabezado sin efectos secundarios y descubrí que se puede lograr configurando los encabezados mencionados en ¿Cómo controlar el almacenamiento en caché de páginas web, en todos los navegadores?.

Los resultados, trabajando para Chrome al menos, sería

$.ajax({
   url: url, 
   headers: {
     'Cache-Control': 'no-cache, no-store, must-revalidate', 
     'Pragma': 'no-cache', 
     'Expires': '0'
   }
});

Personalmente siento que el método de cadena de consulta es más confiable que intentar establecer encabezados en el servidor - no hay garantía de que un proxy o navegador no solo lo almacene en caché de todos modos (algunos navegadores son peores que otros - sin nombrar nombres).

Normalmente uso Math.random() pero no veo nada malo en usar la fecha (no deberías hacer solicitudes AJAX lo suficientemente rápido como para obtener el mismo valor dos veces).

Siguiendo la documentación: http://api.jquery.com/jquery.ajax /

Puede usar la propiedad cache con:

$.ajax({
    method: "GET",
    url: "/Home/AddProduct?",
    data: { param1: value1, param2: value2},
    cache: false,
    success: function (result) {
        // TODO
    }
});

La verdadera pregunta es por qué necesita que esto no se almacene en caché. Si no se debe almacenar en caché porque cambia todo el tiempo, el servidor debe especificar que no se almacene en caché el recurso. Si solo cambia a veces (porque uno de los recursos de los que depende puede cambiar), y si el código del cliente tiene una forma de saberlo, puede agregar un parámetro ficticio a la url que se calcula a partir de algún hash o fecha de última modificación de esos recursos (eso es lo que hacemos en Microsoft Ajax script resources para que puedan se almacenará en caché para siempre, pero las nuevas versiones todavía se pueden servir a medida que aparecen). Si el cliente no puede saber de los cambios, la forma correcta debería ser que el servidor maneje las solicitudes de HEAD correctamente y le diga al cliente si debe usar la versión en caché o no. Me parece que agregar un parámetro aleatorio o decirle al cliente que nunca almacene caché es incorrecto porque la capacidad de almacenamiento en caché es una propiedad del recurso del servidor, por lo que debe decidirse del lado del servidor. Otra pregunta a hacerse es si este recurso realmente ser servido a través de GET o debe ir a través de POST? Esa es una cuestión de semántica, pero también tiene implicaciones de seguridad (hay ataques que funcionan solo si el servidor permite GET). La publicación no se almacenará en caché.

Tal vez deberías mirar $.ajax() en su lugar (si está utilizando jQuery, que parece). Echa un vistazo a: http://docs.jquery.com/Ajax/jQuery.ajax#options y la opción "cache".

Otro enfoque sería observar cómo se almacenan en caché las cosas en el lado del servidor.

Por supuesto, las técnicas de "ruptura de caché" harán el trabajo, pero esto no sucedería en primer lugar si el servidor le indicara al cliente que la respuesta no debe almacenarse en caché. En algunos casos es beneficioso almacenar en caché las respuestas, a veces no. Deje que el servidor decida la duración correcta de los datos. Es posible que desee cambiarlo más tarde. Mucho más fácil de hacer desde el servidor que desde muchos lugares diferentes en su código de interfaz de usuario.

Por supuesto, esto no ayuda si no tienes control sobre servidor.

Qué tal usar una solicitud POST en lugar de una GET...? (Que deberías de todos modos...)

Una pequeña adición a las excelentes respuestas dadas: Si se está ejecutando con una solución de copia de seguridad no ajax para usuarios sin javascript, tendrá que corregir esas cabeceras del lado del servidor de todos modos. Esto no es imposible, aunque entiendo a los que lo abandonan;)

Estoy seguro de que hay otra pregunta en LO que le dará el conjunto completo de encabezados que son apropiados. No estoy totalmente convencido miceus respuesta cubre todas las bases 100%.

Para aquellos de ustedes que utilizan la opción cache de $.ajaxSetup() en mobile Safari, parece que es posible que tenga que usar una marca de tiempo para las publicaciones, ya que mobile Safari también almacena en caché. De acuerdo con la documentación sobre $.ajax() (a la que se le dirige desde $.ajaxSetup()):

Establecer caché en false solo funcionará correctamente con peticiones HEAD y GET. Funciona añadiendo "_ = {timestamp} " a los parámetros GET. El parámetro no es necesario para otros tipos de solicitudes, excepto en IE8 cuando se realiza un POST a una URL que ya ha sido solicitada por un GET.

Así que configurar esa opción por sí sola no te ayudará en el caso que mencioné anteriormente.

Básicamente solo agrega cache:false; en el ajax donde crees que el contenido cambiará a medida que avance el progreso. Y el lugar donde el contenido no cambiará allí u puede omitir esto. De esta manera u obtendrá la nueva respuesta cada vez

Caché Ajax De Internet Explorer: ¿Qué Vas A Hacer Al Respecto? sugiere tres enfoques:

1. Agregue un token de caché a la cadena de consulta, como ?date=[timestamp]. En jQuery y YUI puedes decirles que lo hagan automáticamente.
2. Usa POST en lugar de GET
3. Enviar un encabezado de respuesta HTTP que prohíbe específicamente a los navegadores almacenarlo en caché

Ahora, es fácil hacerlo habilitando / deshabilitando la opción de caché en su solicitud ajax, al igual que esto

$(function () {
    var url = 'your url goes here';
    $('#ajaxButton').click(function (e) {
        $.ajax({
            url: url,
            data: {
                test: 'value'
            },
                cache: true, //cache enabled, false to reverse
                complete: doSomething
            });
        });
    });
    //ToDo after ajax call finishes
    function doSomething(data) {
        console.log(data);
    }
});

Si estás usando IE 9, entonces necesitas usar lo siguiente delante de la definición de tu clase de controlador:

[OutputCache (NoStore = true, Duration = 0, VaryByParam="*")]

TestController de clase pública: Controller

Esto evitará que el navegador almacene en caché.

Detalles en este enlace: http://dougwilsonsa.wordpress.com/2011/04/29/disabling-ie9-ajax-response-caching-asp-net-mvc-3-jquery/

En realidad esto resolvió mi problema.

Como dijo @Athasach, de acuerdo con los documentos de jQuery, $.ajaxSetup({cache:false}) no funcionará para otras solicitudes que no sean GET y HEAD.

Es mejor enviar de vuelta un encabezado Cache-Control: no-cache desde su servidor de todos modos. Proporciona una separación más limpia de preocupaciones.

Por supuesto, esto no funcionaría para las URL de servicio que no pertenecen a su proyecto. En ese caso, podría considerar proxy del servicio de terceros desde el código del servidor en lugar de llamarlo desde el código del cliente.

Si está utilizando. net ASP MVC, deshabilite el almacenamiento en caché en la acción controller agregando el siguiente atributo en la función end point: [OutputCacheAttribute (VaryByParam = "*", Duration = 0, NoStore = true)]

Añadir Matemáticas.random() a la url de solicitud