UIWebView n'appelle pas toujours - [Nsurlcache Storecachedresponse: Forquest:]

Avez-vous vérifié l'état HTTP et les en-têtes de cache? Expire, contrôle-cache, etc.? Peut-être qu'un serveur répond avec Statut = 304 sans organisme de réponse?

- (void)connection:(NSURLConnection *)conn didReceiveResponse:(NSURLResponse *)aResponse 
{
  NSLog(@"CODE: %d", ((NSHTTPURLResponse *)aResponse).statusCode);
  NSLog(@"HEADERS: %@", ((NSHTTPURLResponse *)aResponse).allHeaderFields);
}

Réponse à la requête du fournisseur de primes:

Je vois cela pour de petits fichiers (100s d'octets) ainsi. WebView échoue également à l'appel cachedResponseForRequest:

J'ai trouvé cette question que ce comportement adresses directement:

En dépit de la documentation d'Apple indiquant autrement , NSURLCache sur iOS ne fait pas de disque (flash) la mise en cache du tout. Vous peut sous-classe NSURLCache pour modifier le comportement des fonctions de recherche et stocker les opérations d'utiliser le disque (comme SDURLCache fait), mais en raison du suite à des limitations sévères de la façon dont le cache est utilisé et mis en œuvre, cela ne fonctionne pas aussi bien que vous attendez:

• NSURLConnection ne remet même pas storeCachedResponse: forRequest: pour les fichiers sur environ 50 Ko (> = 52428 octets, pour être exact). Cela rend le sous-classement NSURLCache inutile pour notre utilisation (200KB images), car il ne sera pas même pas dans le cache. Comme un Par conséquent, il faut ajouter la mise en cache manuellement à un niveau supérieur NSURLConnection .

• Même si l'on appelle intégré du NSURLCache storeCachedResponse: forRequest: manuellement, il stocke seulement réponse en mémoire si elle est inférieure à 180Ko. Je l'ai testé par ce appelant storeCachedResponse manuellement et voyant que le avant / après currentMemoryUsage n'a pas changé pour les longueurs de données ci-dessus au sujet de 180KB. Nous devons donc écrire notre propre cache mémoire LRU aussi.

  (Non souligné.)

  Cela semble être responsable du comportement étant appelé. Comme les points de réponse acceptée en cours sur , ASIHTTPRequest est la solution de contournement prévue pour ce comportement.

  Cependant, noter que la mise en garde au haut de la page:

  S'il vous plaît noter que je ne travaille plus sur cette bibliothèque - vous pouvez envisager d'utiliser quelque chose d'autre pour les nouveaux projets. :)

  Vous devriez envisager compter sur les bibliothèques prises en charge ou, si vous préférez, contribuant revenir à cette bibliothèque une fois qu'il est à la base de votre code.