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

Parece que si cargo contenido dinámico usando $.get(), el resultado se almacena en caché en el navegador.

Agregar una cadena aleatoria en QueryString parece resolver este problema (lo uso new Date().toString()), pero esto se siente como un truco.

¿Hay alguna otra forma de lograr esto? O, si la cadena única es la única forma de lograr esto, ¿alguna sugerencia que no sea new Date()?

Yo uso new Date().getTime(), lo que evitará colisiones a menos que tenga varias solicitudes en el mismo milisegundo:

$.get('/getdata?_=' + new Date().getTime(), function(data) {
    console.log(data); 
});

Editar: Esta respuesta tiene varios años. Todavía funciona (por lo tanto, no lo he eliminado), pero hay formas mejores / más limpias de lograr esto ahora . Mi preferencia es para este método, pero esta respuesta también es útil si desea deshabilitar el almacenamiento en caché para cada solicitud durante la vida útil de una página.

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

$.ajaxSetup({ cache: false });

$ .Get () de JQuery almacenará en caché los resultados. En vez de

$.get("myurl", myCallback)

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

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

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 la página web en todos los navegadores. .

El resultado, al menos para Chrome, sería:

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

otra forma es no proporcionar encabezados de caché desde el lado del servidor 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 );

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

Usualmente uso, Math.random()pero no veo nada de malo en usar la fecha (no deberías estar haciendo 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 cachepropiedad con:

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

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 indica al cliente que la respuesta no debe almacenarse en caché. En algunos casos, es beneficioso almacenar respuestas en caché, algunas veces no. Deje que el servidor decida la vida útil 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 UI.

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

¿Qué pasa con el uso de una solicitud POST en lugar de un GET ...? (Que deberías de todos modos ...)

La verdadera pregunta es por qué necesita que esto no se almacene en caché. Si no debe almacenarse en caché porque cambia todo el tiempo, el servidor debe especificar no almacenar 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 última fecha de modificación de esos recursos (eso es lo que hacemos en los recursos de secuencia de comandos de Microsoft Ajax para que se puedan almacenar en caché para siempre, pero las nuevas versiones aún se pueden servir a medida que aparecen). Si el cliente no puede conocer los cambios, la forma correcta debería ser que el servidor maneje las solicitudes 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 en 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 que debe hacerse es si este recurso realmente debería ser servido a través de GET o debería pasar por 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). POST no se almacenará en caché.

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

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

Una pequeña adición a las excelentes respuestas dadas: si está ejecutando una solución de copia de seguridad que no sea ajax para usuarios sin javascript, de todos modos tendrá que obtener esos encabezados del lado del servidor correctos. Esto no es imposible, aunque entiendo a aquellos que lo abandonan;)

Estoy seguro de que hay otra pregunta sobre SO que le dará el conjunto completo de encabezados que son apropiados. No estoy completamente convencido de que la respuesta de los ratones cubra todas las bases al 100%.

Para aquellos de ustedes que usan la cacheopción de $.ajaxSetup()Safari móvil, parece que puede que tenga que usar una marca de tiempo para POST, ya que Safari móvil también lo almacena en caché. De acuerdo con la documentación sobre $.ajax()(a la que se le dirige $.ajaxSetup()):

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

Por lo tanto, configurar esa opción solo no lo ayudará en el caso que mencioné anteriormente.

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

Almacenamiento en caché Ajax de Internet Explorer: ¿qué va a hacer al respecto? sugiere tres enfoques:

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

Ahora, es fácil hacerlo habilitando / deshabilitando la opción de caché en su solicitud ajax, así

$(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á usando IE 9, debe usar lo siguiente frente a la definición de clase de su controlador:

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

TestController de clase pública: controlador

Esto evitará que el navegador se 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, según los documentos de jQuery, $.ajaxSetup({cache:false}) no funcionará para otras solicitudes que no sean GET y HEAD.

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

Por supuesto, esto no funcionaría para las URL de servicio que no pertenecen a su proyecto. En ese caso, puede considerar enviar el 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 del controlador agregando el siguiente atributo en la función de punto final:

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

agregar encabezado

headers: {
                'Cache-Control':'no-cache'
            }

anexar Math.random() a la url de solicitud