Czy Safari na iOS 6 buforuje wyniki $ .ajax?

Od czasu uaktualnienia do systemu iOS 6 widzimy, że widok przeglądarki Safari pozwala na buforowanie $.ajaxpołączeń. Jest to w kontekście aplikacji PhoneGap, więc korzysta ona z Safari WebView. Nasze $.ajaxwywołania są POSTmetodami, a pamięć podręczna ma wartość false {cache:false}, ale tak się dzieje. Próbowaliśmy ręcznie dodać a TimeStampdo nagłówków, ale to nie pomogło.

Zrobiliśmy więcej badań i stwierdziliśmy, że Safari zwraca wyniki z pamięci podręcznej tylko dla usług internetowych, które mają podpis funkcji, który jest statyczny i nie zmienia się z połączenia do połączenia. Na przykład wyobraź sobie funkcję o nazwie coś takiego:

getNewRecordID(intRecordType)

Ta funkcja odbiera ciągle te same parametry wejściowe, ale zwracane dane powinny za każdym razem być inne.

Musi być w pośpiechu Apple, aby imponujący zip w iOS 6 był zbyt zadowolony z ustawień pamięci podręcznej. Czy ktoś jeszcze widział takie zachowanie na iOS 6? Jeśli tak, co dokładnie to powoduje?

Obejściem tego problemu było zmodyfikowanie podpisu funkcji w taki sposób:

getNewRecordID(intRecordType, strTimestamp)

a następnie zawsze przekazuj również TimeStampparametr i po prostu odrzuć tę wartość po stronie serwera. Działa to wokół problemu. Mam nadzieję, że pomoże to innej biednej duszy, która spędza 15 godzin w tej sprawie, tak jak ja!

Po krótkiej analizie okazuje się, że Safari na iOS6 będzie buforować pliki POST, które nie mają nagłówków Cache-Control, a nawet „Cache-Control: max-age = 0”.

Jedynym sposobem, w jaki udało mi się zapobiec temu buforowaniu na poziomie globalnym, zamiast konieczności włamywania się do losowych zapytań na koniec zgłoszeń serwisowych, jest ustawienie „Kontrola pamięci podręcznej: brak pamięci podręcznej”.

Więc:

• Brak kontroli Cache lub wygasa nagłówki = iOS6 Safari będzie buforować
• Cache-Control max-age = 0 i natychmiastowe wygaśnięcie = iOS6 Safari będzie buforować
• Kontrola pamięci podręcznej: no-cache = iOS6 Safari NIE będzie buforować

Podejrzewam, że Apple korzysta z tego na podstawie specyfikacji HTTP w sekcji 9.5 na temat POST:

Odpowiedzi na tę metodę nie są buforowane, chyba że odpowiedź zawiera odpowiednie pola nagłówka Cache-Control lub Expires. Jednak odpowiedź 303 (Zobacz inne) może być użyta do nakierowania agenta użytkownika na pobranie zasobu buforowanego.

Teoretycznie możesz buforować odpowiedzi POST ... kto wiedział. Ale jak dotąd żaden inny twórca przeglądarki nie pomyślał, że to dobry pomysł. Ale to NIE uwzględnia buforowania, gdy nie są ustawione nagłówki Kontroli pamięci podręcznej lub Wygasają, tylko jeśli są ustawione. To musi być błąd.

Poniżej znajduje się to, czego używam w odpowiednim fragmencie mojej konfiguracji Apache do kierowania na cały mój API, ponieważ tak się składa, że ​​tak naprawdę nie chcę niczego buforować, nawet dostaje. Nie wiem, jak ustawić to tylko dla testów POST.

Header set Cache-Control "no-cache"

Aktualizacja: Właśnie zauważyłem, że nie zauważyłem, że dzieje się tak tylko wtedy, gdy POST jest taki sam, więc zmień dowolne dane lub adres URL POST i nic ci nie będzie. Możesz więc, jak wspomniano w innym miejscu, po prostu dodać losowe dane do adresu URL lub trochę danych POST.

Aktualizacja: Możesz ograniczyć „brak pamięci podręcznej” tylko do POST, jeśli chcesz tak w Apache:

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

Mam nadzieję, że może to być przydatne dla innych programistów walących głową o ścianę. Odkryłem, że którykolwiek z poniższych przypadków uniemożliwia przeglądarce Safari w systemie iOS 6 buforowanie odpowiedzi POST:

• dodawanie [kontrola pamięci podręcznej: brak pamięci podręcznej] w nagłówkach żądania
• dodając zmienny parametr URL, taki jak aktualny czas
• dodanie [pragma: no-cache] w nagłówkach odpowiedzi
• dodawanie [cache-control: no-cache] w nagłówkach odpowiedzi

Moje rozwiązanie było następujące w moim Javascript (wszystkie moje żądania AJAX to POST).

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

Dodam również nagłówek [pragma: no-cache] do wielu moich odpowiedzi serwera.

Jeśli użyjesz powyższego rozwiązania, pamiętaj, że wszelkie wywołania $ .ajax (), które są ustawione na globalne: false NIE będą używać ustawień określonych w $ .ajaxSetup (), więc będziesz musiał ponownie dodać nagłówki.

Proste rozwiązanie dla wszystkich żądań usług sieciowych, przy założeniu, że używasz 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()
    }));
});

Przeczytaj więcej o wywołaniu filtra wstępnego jQuery tutaj .

Jeśli nie korzystasz z jQuery, sprawdź dokumenty w wybranej bibliotece. Mogą mieć podobną funkcjonalność.

Właśnie miałem ten problem w aplikacji PhoneGap . Rozwiązałem go za pomocą funkcji JavaScript getTime()w następujący sposób:

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

Zmarnowałem kilka godzin, zastanawiając się nad tym. Byłoby miło, gdyby Apple powiadomił programistów o tym problemie z buforowaniem.

Miałem ten sam problem z aplikacją internetową pobierającą dane z usługi ASP.NET

To działało dla mnie:

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

Wreszcie mam rozwiązanie mojego problemu z przesyłaniem.

W JavaScript:

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

W PHP :

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

Z mojego własnego posta na blogu iOS 6.0 buforuje żądania Ajax POST :

Jak to naprawić: Istnieją różne metody zapobiegania buforowaniu żądań. Zalecaną metodą jest dodanie nagłówka bez pamięci podręcznej. Tak to się robi.

jQuery:

Sprawdź iOS 6.0 i ustaw nagłówek Ajax w następujący sposób:

$.ajaxSetup({ cache: false });

ZeptoJS:

Sprawdź system iOS 6.0 i ustaw nagłówek Ajax w następujący sposób:

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

Po stronie serwera

Jawa:

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

Pamiętaj, aby dodać to u góry strony, zanim jakiekolwiek dane zostaną wysłane do klienta.

.NETTO

Response.Cache.SetNoStore();

Lub

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.

Ten fragment kodu JavaScript działa doskonale w przypadku jQuery i jQuery Mobile:

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

Po prostu umieść go gdzieś w kodzie JavaScript (po załadowaniu jQuery, najlepiej przed zrobieniem żądań AJAX) i powinno to pomóc.

Możesz również rozwiązać ten problem, modyfikując funkcję Ajax jQuery , wykonując następujące czynności (od 1.7.1) na górze funkcji Ajax (funkcja zaczyna się od linii 7212). Ta zmiana aktywuje wbudowaną funkcję anty-cache jQuery dla wszystkich żądań POST.

(Pełny skrypt jest dostępny pod adresem http://dl.dropbox.com/u/58016866/jquery-1.7.1.js.)

Wstaw poniżej wiersza 7221:

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

Następnie zmodyfikuj następujące elementy (od linii ~ 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 : "");
    }
}

Do:

// 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 : "");
}

Szybkim obejściem usług GWT-RPC jest dodanie tego do wszystkich metod zdalnych:

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

To jest aktualizacja odpowiedzi Baz1nga. Ponieważ options.datanie jest obiektem, ale ciągiem, po prostu uciekłem się do konkatenacji znacznika czasu:

$.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();
  }
});

Aby rozwiązać ten problem dla aplikacji internetowych dodanych do ekranu głównego, należy przestrzegać obu najczęściej głosowanych obejść. Buforowanie musi być wyłączone na serwerze WWW, aby zapobiec buforowaniu nowych żądań w przyszłości, a do każdego żądania postu należy dodać losowe dane wejściowe, aby żądania, które już zostały buforowane, zostały zrealizowane. Proszę odnieść się do mojego postu:

iOS6 - Czy istnieje sposób na wyczyszczenie buforowanych żądań POST dla aplikacji WWW dodanych do ekranu głównego?

OSTRZEŻENIE: każdemu, kto zaimplementował obejście, dodając znacznik czasu do swoich żądań bez wyłączania buforowania na serwerze. Jeśli Twoja aplikacja zostanie dodana do ekranu głównego, KAŻDY post postu będzie teraz buforowany, wyczyszczenie pamięci podręcznej safari nie wyczyści jej i nie będzie wygasać. Chyba że ktoś ma sposób, aby to wyczyścić, wygląda to na potencjalny wyciek pamięci!

Rzeczy, które NIE DZIAŁAŁY dla mnie na iPadzie 4 / iOS 6:

Moja prośba zawiera: Cache-Control: no-cache

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

Dodanie bufora: false do mojego wywołania jQuery ajax

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

Tylko to załatwiło sprawę:

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

To jest obejście 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);    

Moje obejście w ASP.NET (pagemethods, webservice itp.)

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

Chociaż dodanie parametrów pomijania pamięci podręcznej, aby wyglądało inaczej, wydaje się solidnym rozwiązaniem, odradzam to, ponieważ zaszkodziłoby każdej aplikacji, która opiera się na faktycznym buforowaniu. Uczynienie wyjściowymi interfejsami API poprawnych nagłówków jest najlepszym możliwym rozwiązaniem, nawet jeśli jest to nieco trudniejsze niż dodawanie modułów blokujących pamięć podręczną do dzwoniących.

Dla tych, którzy używają Struts 1, oto jak naprawiłem problem.

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() {
    }

}

Byłem w stanie rozwiązać problem, używając kombinacji $ .ajaxSetup i dołączając znacznik czasu do adresu URL mojego postu (nie do parametrów / treści postu). Opiera się to na zaleceniach poprzednich odpowiedzi

$(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');
                }
            }
        });
    });
});

Myślę, że rozwiązałeś już swój problem, ale pozwól, że podzielę się pomysłami na temat buforowania w sieci.

To prawda, że ​​możesz dodać wiele nagłówków w każdym używanym języku, po stronie serwera, po stronie klienta i możesz użyć wielu innych sztuczek, aby uniknąć buforowania w sieci, ale zawsze myśl, że nigdy nie wiesz, skąd klient łączy się z twoim serwerem, nigdy nie wiadomo, czy korzysta on z hotelowego połączenia „Hot-Spot”, które wykorzystuje Squid lub inne produkty buforowania.

Jeśli użytkownicy używają proxy do ukrycia swojej prawdziwej pozycji itp.… Prawdziwej jedynym sposobem uniknięcia buforowania jest znacznik czasu w żądaniu, również jeśli nie jest używany.

Na przykład:

/ajax_helper.php?ts=3211321456

Następnie każdy menedżer pamięci podręcznej, który musisz przekazać, nie znalazł tego samego adresu URL w repozytorium pamięci podręcznej i ponownie pobierał zawartość strony.

W zależności od aplikacji możesz teraz rozwiązać problem w iOS 6 za pomocą Safari> Zaawansowane> Inspektor sieci, więc jest to pomocne w tej sytuacji.

Podłącz telefon do Safari na komputerze Mac, a następnie użyj menu programisty, aby rozwiązać problemy z aplikacją internetową.

Wyczyść dane witryny na iPhonie po aktualizacji do iOS6, w tym dane specyficzne dla aplikacji za pomocą Widoku internetowego. Tylko jedna aplikacja miała problem i to rozwiązało go podczas testów IOS6 Beta w przeszłości, od tamtej pory nie było żadnych poważnych problemów.

Konieczne może być również spojrzenie na aplikację, sprawdź NSURLCache, jeśli w WebView w aplikacji niestandardowej.

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

Myślę, że w zależności od prawdziwej natury twojego problemu, wdrożenia itp.

Ref: $ .ajax połączenia

Znalazłem jedno obejście, które mnie ciekawi, dlaczego to działa. Zanim przeczytałem odpowiedź Tadej'a dotyczącą serwisu internetowego ASP.NET, próbowałem wymyślić coś, co by działało.

I nie mówię, że to dobre rozwiązanie, ale chciałem to tutaj udokumentować.

strona główna: zawiera funkcję JavaScript, checkStatus (). Metoda wywołuje inną metodę, która używa wywołania AJAX jQuery do aktualizacji zawartości HTML. Użyłem setInterval do wywołania checkStatus (). Oczywiście napotkałem problem z buforowaniem.

Rozwiązanie: użyj innej strony, aby wywołać aktualizację.

Na stronie głównej ustawiłem zmienną boolowską, runUpdate, i dodałem następujące do tagu body:

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

W pliku helper.html:

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

Jeśli więc funkcja checkStatus () zostanie wywołana ze strony głównej, otrzymam buforowaną zawartość. Jeśli wywołam checkStatus ze strony podrzędnej, otrzymam zaktualizowaną treść.

Podczas gdy moje strony logowania i rejestracji działają jak urok w Firefox, IE i Chrome ... Walczyłem z tym problemem w Safari dla IOS i OSX, kilka miesięcy temu znalazłem obejście dla SO.

<body onunload="">

LUB przez javascript

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

To trochę brzydka rzecz, ale działa przez jakiś czas.

Nie wiem dlaczego, ale zwracając null do onunloadzdarzenia, strona nie jest buforowana w Safari.

Okazało się, że starsze iPhone'y i iPady z systemem iOS w wersji 9 i 10 czasami zwracają fałszywe, puste wyniki AJAX, być może z powodu zmniejszenia szybkości procesora przez Apple. Zwracając pusty wynik, iOS nie wywołuje serwera, tak jakby zwracał wynik z pamięci podręcznej. Częstotliwość różni się znacznie, od około 10% do 30% połączeń AJAX zwraca puste.

Trudno w to uwierzyć. Poczekaj 1s i zadzwoń ponownie. W naszych testach wystarczyło tylko jedno powtórzenie, ale napisaliśmy kod, aby wywołać go 4 razy. Nie jesteśmy pewni, czy oczekiwanie 1s jest wymagane, ale nie chcieliśmy ryzykować obciążeniem naszego serwera serią powtarzających się połączeń.

Odkryliśmy, że problem wystąpił w przypadku dwóch różnych wywołań AJAX, wywołujących różne pliki API z różnymi danymi. Ale obawiam się, że może się to zdarzyć przy każdym połączeniu AJAX. Po prostu nie wiemy, ponieważ nie sprawdzamy każdego wyniku AJAX i nie testujemy każdego połączenia wiele razy na starych urządzeniach.

Oba problematyczne wywołania AJAX używały: POST, Asynchronicznie = true, setRequestHeader = ('Content-Type', 'application / x-www-form-urlencoded')

Kiedy problem się pojawia, zwykle trwa tylko jedno wywołanie AJAX. Nie jest to spowodowane nakładającymi się połączeniami AJAX. Czasami problem występuje, gdy urządzenie jest zajęte, ale czasami nie, a bez DevTools tak naprawdę nie wiemy, co się dzieje w tym czasie.

iOS 13 tego nie robi, ani Chrome, ani Firefox. Nie mamy żadnych urządzeń testowych z systemem iOS 11 lub 12. Być może ktoś inny mógłby je przetestować?

Zwracam na to uwagę, ponieważ to pytanie jest najwyższym wynikiem Google podczas wyszukiwania tego problemu.

Działa z ASP.NET dopiero po dodaniu pragma:no-cachenagłówka w IIS . Cache-Control: no-cachebyło za mało.

Sugeruję obejście problemu, aby zmodyfikować sygnaturę funkcji tak, aby wyglądała mniej więcej tak:

getNewRecordID (intRecordType, strTimestamp), a następnie zawsze przekazuje również parametr TimeStamp i po prostu odrzuca tę wartość po stronie serwera. Działa to wokół problemu.