Чи є Safari на iOS 6 кешування результатів $ .ajax?

З моменту оновлення до iOS 6, ми бачимо, що веб-перегляд Safari може вільно кешувати $.ajaxдзвінки. Це в контексті програми PhoneGap, тому він використовує Safari WebView. Наші $.ajaxвиклики - це POSTметоди, і кеш-пам'ять встановлена ​​на помилкову {cache:false}, але все-таки це відбувається. Ми намагалися вручну додати TimeStampзаголовки, але це не допомогло.

Ми провели більше досліджень і виявили, що Safari повертає лише кешовані результати для веб-служб, які мають підпис функції, який є статичним і не змінюється від виклику до виклику. Наприклад, уявіть функцію, яка називається щось на зразок:

getNewRecordID(intRecordType)

Ця функція отримує однакові вхідні параметри знову і знову, але дані, які вона повертає, повинні бути різними щоразу.

Повинно бути в поспіху Apple, щоб зробити iOS 6 zip вражаюче, вони надто задоволені налаштуваннями кешу. Хтось ще бачив таку поведінку на iOS 6? Якщо так, то що саме це викликає?

Ми знайшли рішення, щоб змінити функцію підпису таким чином:

getNewRecordID(intRecordType, strTimestamp)

а потім завжди передайте TimeStampпараметр і просто відкиньте це значення на стороні сервера. Це вирішує проблему. Я сподіваюся, що це допомагає іншій бідній душі, яка витрачає 15 годин на це питання, як я!

Після невеликого розслідування виявляється, що Safari на iOS6 буде кешувати POST, які не мають або заголовків Cache-Control, або навіть "Cache-Control: max-age = 0".

Єдиний спосіб, який я знайшов, щоб запобігти тому, щоб кешування відбувалося на глобальному рівні, а не змушувати хакінгувати випадкові запити в кінці викликів служби, - це встановити "Кеш-контроль: без кешу".

Тому:

• Заголовок кеш-керування або термін дії не закінчується = Safari iOS6 буде кешований
• Кеш-контроль максимального віку = 0 і негайно закінчується = iOS6 Safari буде кешований
• Кеш-контроль: no-cache = iOS6 Safari НЕ буде кешувати

Я підозрюю, що Apple користується цим із специфікації HTTP у розділі 9.5 про POST:

Відповіді на цей метод не підлягають кешуванню, якщо тільки відповідь не включає відповідні поля заголовка кеша або закінчується. Однак відповідь 303 (див. Інше) може бути використана для спрямування агента користувача на отримання кешованого ресурсу.

Тож теоретично ви можете кешувати відповіді POST ... хто знав. Але жоден інший виробник браузера досі не думав, що це було б хорошою ідеєю. Але це НЕ враховує кешування, якщо не встановлено заголовки Cache-Control або Expires, лише коли є деякий набір. Так що це має бути помилка.

Нижче наведено те, що я використовую в правому біті моєї конфігурації Apache, щоб орієнтуватися на весь мій API, оскільки, як це буває, насправді я не хочу нічого кешувати, навіть отримує. Я не знаю, як це встановити лише для постів.

Header set Cache-Control "no-cache"

Оновлення: Щойно помітив, що я не зазначив, що це лише тоді, коли POST однаковий, тож змініть будь-які дані POST або URL-адресу, і ви все в порядку. Таким чином, ви можете, як було зазначено в іншому місці, просто додати деякі випадкові дані до URL-адреси або трохи даних POST.

Оновлення: Ви можете обмежити "не кеш-пам'ять" лише POST, якщо ви хочете, як це в Apache:

SetEnvIf Request_Method "POST" IS_POST
Header set Cache-Control "no-cache" env=IS_POST

Я сподіваюся, що це може бути корисно іншим розробникам, що вдаряють головою об стіну на цьому. Я виявив, що будь-яке з перерахованих вище перешкоджає Safari на iOS 6 кешувати відповідь POST:

• додавання [кеш-контроль: немає кешу] у заголовки запитів
• додавання параметра змінної URL-адреси, наприклад поточного часу
• додавання [pragma: no-cache] у заголовки відповідей
• додавання [кеш-контроль: без кешу] у заголовки відповідей

Моє рішення було таким у моєму Javascript (усі мої запити AJAX - POST).

$.ajaxSetup({
    type: 'POST',
    headers: { "cache-control": "no-cache" }
});

Я також додаю заголовок [pragma: no-cache] до багатьох відповідей мого сервера.

Якщо ви використовуєте вищезазначене рішення, майте на увазі, що будь-які дзвінки $ .ajax (), які ви здійснюєте, встановлені на глобальний: false НЕ використовуватиме налаштування, визначені в $ .ajaxSetup (), тому вам потрібно буде знову додати заголовки.

Просте рішення для всіх запитів вашої веб-служби, якщо ви користуєтесь jQuery:

$.ajaxPrefilter(function (options, originalOptions, jqXHR) {
    // you can use originalOptions.type || options.type to restrict specific type of requests
    options.data = jQuery.param($.extend(originalOptions.data||{}, { 
      timeStamp: new Date().getTime()
    }));
});

Детальніше про дзвінок попереднього фільтра jQuery читайте тут .

Якщо ви не використовуєте jQuery, перевірте документи на вибір бібліотеки. Вони можуть мати подібний функціонал.

У мене просто виникло це питання також у додатку PhoneGap . Я вирішив це за допомогою функції JavaScript getTime()таким чином:

var currentTime = new Date();
var n = currentTime.getTime();
postUrl = "http://www.example.com/test.php?nocache="+n;
$.post(postUrl, callbackFunction);

Я витратив кілька годин, з'ясовуючи це. Apple було б добре повідомити розробників про цю проблему кешування.

У мене була така ж проблема з веб-сервісом отримання даних з веб-сервісу ASP.NET

Це працювало для мене:

public WebService()
{
    HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
    ...
}

Нарешті, я вирішив проблему із завантаженням.

У JavaScript:

var xhr = new XMLHttpRequest();
xhr.open("post", 'uploader.php', true);
xhr.setRequestHeader("pragma", "no-cache");

На PHP :

header('cache-control: no-cache');

З моєї власної публікації в блозі iOS 6.0 кешування запитів Ajax POST :

Як це виправити: Існують різні методи запобігання кешування запитів. Рекомендований метод - додавання заголовка без кешу. Ось як це робиться.

jQuery:

Перевірте iOS 6.0 і встановіть заголовок Ajax таким чином:

$.ajaxSetup({ cache: false });

ZeptoJS:

Перевірте iOS 6.0 і встановіть заголовок Ajax таким чином:

$.ajax({
    type: 'POST',
    headers : { "cache-control": "no-cache" },
    url : ,
    data:,
    dataType : 'json',
    success : function(responseText) {…}

Сторона сервера

Java:

httpResponse.setHeader("Cache-Control", "no-cache, no-store, must-revalidate");

Не забудьте додати це вгорі сторінки, перш ніж будь-які дані будуть надіслані клієнту.

.NET

Response.Cache.SetNoStore();

Або

Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache);

PHP

header('Cache-Control: no-cache, no-store, must-revalidate'); // HTTP 1.1.
header('Pragma: no-cache'); // HTTP 1.0.

Цей фрагмент JavaScript чудово працює з jQuery та jQuery Mobile:

$.ajaxSetup({
    cache: false,
    headers: {
        'Cache-Control': 'no-cache'
    }
});

Просто розмістіть його десь у вашому коді JavaScript (після завантаження jQuery, і найкраще, перш ніж робити запити AJAX), і це повинно допомогти.

Ви також можете вирішити цю проблему, змінивши функцію jQuery Ajax , виконавши наступні дії (станом на 1.7.1) вгорі функції Ajax (функція починається у рядку 7212). Ця зміна активує вбудовану функцію проти кешу jQuery для всіх POST-запитів.

(Повний сценарій доступний за адресою http://dl.dropbox.com/u/58016866/jquery-1.7.1.js.)

Вставити під рядок 7221:

if (options.type === "POST") {
    options.cache = false;
}

Потім змініть наступне (починаючи з рядка ~ 7497).

if (!s.hasContent) {
    // If data is available, append data to URL
    if (s.data) {
        s.url += (rquery.test(s.url) ? "&" : "?") + s.data;
        // #9682: remove data so that it's not used in an eventual retry
        delete s.data;
    }

    // Get ifModifiedKey before adding the anti-cache parameter
    ifModifiedKey = s.url;

    // Add anti-cache in URL if needed
    if (s.cache === false) {
        var ts = jQuery.now(),
        // Try replacing _= if it is there
        ret = s.url.replace(rts, "$1_=" + ts);

        // If nothing was replaced, add timestamp to the end.
        s.url = ret + ((ret === s.url) ? (rquery.test(s.url) ? "&" : "?") + "_=" + ts : "");
    }
}

До:

// More options handling for requests with no content
if (!s.hasContent) {
    // If data is available, append data to URL
    if (s.data) {
        s.url += (rquery.test(s.url) ? "&" : "?") + s.data;
        // #9682: remove data so that it's not used in an eventual retry
        delete s.data;
    }

    // Get ifModifiedKey before adding the anti-cache parameter
    ifModifiedKey = s.url;
}

// Add anti-cache in URL if needed
if (s.cache === false) {
    var ts = jQuery.now(),
    // Try replacing _= if it is there
    ret = s.url.replace(rts, "$1_=" + ts);

    // If nothing was replaced, add timestamp to the end.
    s.url = ret + ((ret === s.url) ? (rquery.test(s.url) ? "&" : "?") + "_=" + ts : "");
}

Швидке розв’язання послуг GWT-RPC полягає в тому, щоб додати це до всіх віддалених методів:

getThreadLocalResponse().setHeader("Cache-Control", "no-cache");

Це оновлення відповіді Баз1нга. Оскільки options.dataце не об'єкт, а рядок, я просто вдався до об'єднання часової позначки:

$.ajaxPrefilter(function (options, originalOptions, jqXHR) {
  if (originalOptions.type == "post" || options.type == "post") {

    if (options.data && options.data.length)
      options.data += "&";
    else
      options.data = "";

    options.data += "timeStamp=" + new Date().getTime();
  }
});

Щоб вирішити цю проблему для WebApps, доданого на головний екран, потрібно дотримуватися обох найголовніших способів вирішення. Кешування потрібно вимкнути на веб-сервері, щоб запобігти подальшому кешування нових запитів, а до кожного запиту на пошту потрібно додати деякий випадковий ввід, щоб запити, які вже були кешовані, проходили. Будь ласка, зверніться до мого повідомлення:

iOS6 - Чи є спосіб очищення кешованих ajax запитів POST для веб-сайту, доданих на головний екран?

Попередження: всім, хто реалізував рішення, додавши позначку часу до своїх запитів, не вимикаючи кешування на сервері. Якщо додаток додано на головний екран, КОЖНА відповідь на повідомлення тепер буде кешована, очищення кеша сафарі не очистить його і, здається, не закінчується. Якщо хтось не має способу його очистити, це виглядає як потенційний витік пам'яті!

Те, що не працювало для мене з iPad 4 / iOS 6:

Мій запит, що містить: Кеш-контроль: немає кешу

//asp.net's:
HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache)

Додавання кеша: false для мого дзвінка ajax jQuery

 $.ajax(
        {
            url: postUrl,
            type: "POST",
            cache: false,
            ...

Тільки це зробило трюк:

var currentTime = new Date();
var n = currentTime.getTime();
postUrl = "http://www.example.com/test.php?nocache="+n;
$.post(postUrl, callbackFunction);

Ось така робота для GWT-RPC

class AuthenticatingRequestBuilder extends RpcRequestBuilder 
{
       @Override
       protected RequestBuilder doCreate(String serviceEntryPoint) 
       {
               RequestBuilder requestBuilder = super.doCreate(serviceEntryPoint);           
               requestBuilder.setHeader("Cache-Control", "no-cache");

               return requestBuilder;
       }
}

AuthenticatingRequestBuilder builder = new AuthenticatingRequestBuilder();
((ServiceDefTarget)myService).setRpcRequestBuilder(builder);    

Моє вирішення в ASP.NET (параметоди, веб-сервіс тощо)

protected void Application_BeginRequest(object sender, EventArgs e)
{
    Response.Cache.SetCacheability(HttpCacheability.NoCache);
}

Хоча додавання параметрів кеш-бустера для того, щоб запит виглядав інакше, схоже на надійне рішення, я б радив цього не сприймати, оскільки це зашкодить будь-якій програмі, яка покладається на фактичне кешування, що має місце. Зробити API виведення правильних заголовків є найкращим можливим рішенням, навіть якщо це трохи складніше, ніж додавати кестери кеша до абонентів.

Для тих, хто використовує Struts 1, ось як я виправив проблему.

web.xml

<filter>
    <filter-name>SetCacheControl</filter-name>
    <filter-class>com.example.struts.filters.CacheControlFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>SetCacheControl</filter-name>
    <url-pattern>*.do</url-pattern>
    <http-method>POST</http-method>
</filter-mapping>

com.example.struts.filters.CacheControlFilter.js

package com.example.struts.filters;

import java.io.IOException;
import java.util.Date;
import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;

public class CacheControlFilter implements Filter {

        public void doFilter(ServletRequest request, ServletResponse response,
                     FilterChain chain) throws IOException, ServletException {

        HttpServletResponse resp = (HttpServletResponse) response;
        resp.setHeader("Expires", "Mon, 18 Jun 1973 18:00:00 GMT");
        resp.setHeader("Last-Modified", new Date().toString());
        resp.setHeader("Cache-Control", "no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0");
        resp.setHeader("Pragma", "no-cache");

        chain.doFilter(request, response);
    }

    public void init(FilterConfig filterConfig) throws ServletException {
    }

    public void destroy() {
    }

}

Мені вдалося виправити свою проблему, використовуючи комбінацію $ .ajaxSetup та додавши часову позначку до URL моєї публікації (не до параметрів / тіла публікації). Це грунтується на рекомендаціях попередніх відповідей

$(document).ready(function(){
    $.ajaxSetup({ type:'POST', headers: {"cache-control","no-cache"}});

    $('#myForm').submit(function() {
        var data = $('#myForm').serialize();
        var now = new Date();
        var n = now.getTime();
        $.ajax({
            type: 'POST',
            url: 'myendpoint.cfc?method=login&time='+n,
            data: data,
            success: function(results){
                if(results.success) {
                    window.location = 'app.cfm';
                } else {
                    console.log(results);
                    alert('login failed');
                }
            }
        });
    });
});

Я думаю, ви вже вирішили свою проблему, але дозвольте мені поділитися ідеєю щодо кешування веб-сторінок.

Це правда, що ви можете додати багато заголовків у кожній мові, яку ви використовуєте, на стороні сервера, на стороні клієнта, і ви можете використовувати багато інших хитрощів, щоб уникнути кешування веб-сторінок, але завжди думайте, що ви ніколи не можете знати, звідки клієнт підключається до вашого сервера, ви ніколи не знаєте, чи він використовує підключення до готелю "Hot-Spot", в якому використовуються кальмари або інші продукти кешування.

Якщо користувачі використовують проксі - сервер , щоб приховати своє справжнє становище, і т.д ... реальний єдиним способом кешування уникнути , є відміткою часу в запиті також , якщо не використовується.

Наприклад:

/ajax_helper.php?ts=3211321456

Тоді кожен кеш-менеджер, який вам потрібно буде пройти, не знайшов однакову URL-адресу в сховищі кешу і перезавантажив вміст сторінки.

Залежно від програми ви можете вирішити проблему зараз у iOS 6 за допомогою Safari> Advanced> Web Inspector, що допоможе в цій ситуації.

Підключіть телефон до Safari на Mac, а потім скористайтеся меню розробника, щоб усунути проблеми з веб-додатком.

Очистіть дані веб-сайтів на iPhone після оновлення до iOS6, включаючи специфічні для програми програми Web View. Лише в одній програмі виникла проблема, і це вирішило її під час тестування бета-версії IOS6, оскільки з цього часу не виникало реальних проблем.

Можливо, вам також доведеться переглянути свій додаток, перевірити NSURLCache, якщо він є у WebView у власному додатку.

https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/Foundation/Classes/NSURLCache_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40003754

Я думаю, залежно від справжнього характеру вашої проблеми, реалізації тощо.

Довідка: $ .ajax дзвінки

Я знайшов одне вирішення, яке мене цікавить, чому це працює. Перш ніж прочитати відповідь Тадея щодо веб-сервісу ASP.NET, я намагався придумати щось, що спрацювало б.

І я не кажу, що це гарне рішення, але я просто хотів це зафіксувати тут.

головна сторінка: включає функцію JavaScript, checkStatus (). Метод викликає інший метод, який використовує виклик jQuery AJAX для оновлення вмісту html. Я використовував setInterval для виклику checkStatus (). Звичайно, я зіткнувся з проблемою кешування.

Рішення: використовуйте іншу сторінку для виклику оновлення.

На головній сторінці я встановив булеву змінну, runUpdate та додав до тегу body таке:

<iframe src="helper.html" style="display: none; visibility: hidden;"></iframe>

На сторінці helper.html:

<meta http-equiv="refresh" content="5">
<script type="text/javascript">
    if (parent.runUpdate) { parent.checkStatus(); }
</script>

Отже, якщо callStatus () викликається з головної сторінки, я отримую кешований вміст. Якщо я дзвоню checkStatus з дочірньої сторінки, я отримую оновлений вміст.

Хоча сторінки мого входу та реєстрації працюють як шарм у Firefox, IE та Chrome ... Я боровся з цією проблемою в Safari для IOS та OSX, кілька місяців тому я знайшов вирішення проблеми SO.

<body onunload="">

АБО через javascript

<script type="text/javascript">
window.onunload = function(e){
    e.preventDefault();
    return;
};
</script>   

Це щось потворне, але працює деякий час.

Я не знаю чому, але повернувши нуль до onunloadподії, сторінка не буде кешована в Safari.

Ми виявили, що старі телефони iPhone та iPad, що працюють під управлінням iOS версії 9 та 10, періодично повертають фіктивні результати AJAX, можливо, через зниження швидкості процесора Apple. При поверненні порожнього результату iOS не викликає сервер, як би повертаючи результат з кешу. Частота коливається в широких межах - приблизно від 10% до 30% AJAX-дзвінків.

У рішення важко повірити. Просто зачекайте 1 і передзвоніть знову. У нашому тестуванні було лише одне повторення, що коли-небудь було потрібно, але ми написали код для виклику до 4 разів. Ми не впевнені, чи потрібен 1-й час очікування, але ми не хотіли ризикувати обтяжувати наш сервер спалахами повторних дзвінків.

Ми виявили, що ця проблема сталася з двома різними дзвінками AJAX, що викликали різні файли API з різними даними. Але я переживаю, що це може статися на будь-якому дзвінку AJAX. Ми просто не знаємо, оскільки не перевіряємо кожен результат AJAX і не тестуємо кожен виклик кілька разів на старих пристроях.

Обидва проблемні виклики AJAX використовували: POST, Asynchronically = true, setRequestHeader = ('Content-Type', 'application / x-www-form-urlencoded')

Коли проблема виникає, зазвичай відбувається лише один дзвінок AJAX. Тож це не через перекриття дзвінків AJAX. Іноді проблема трапляється, коли пристрій зайнятий, але іноді ні, і без DevTools ми не знаємо, що відбувається в цей час.

iOS 13 цього не робить, ні Chrome, ні Firefox. У нас немає тестових пристроїв під керуванням iOS 11 або 12. Можливо, хтось ще міг би протестувати їх?

Я зазначу це тут, тому що це питання є головним результатом Google при пошуку цієї проблеми.

Він працював з ASP.NET лише після додавання pragma:no-cacheзаголовка в IIS . Cache-Control: no-cacheбуло недостатньо

Я пропоную вирішити, щоб змінити функцію підпису таким чином:

getNewRecordID (intRecordType, strTimestamp), а також завжди передайте параметр TimeStamp, а також просто відкиньте це значення на стороні сервера. Це вирішує проблему.