Ich habe ein Problem mit (möglicherweise) NSURLCache today bei der Überprüfung von Anforderungs- und Antwortheadern in Charles Proxy gefunden. Das Problem ist ein wenig verblüffend, aber ich kann es konsequent wiederholen:
Kurz gesagt, das Problem hat mit dem Zwischenspeichern von NSURLRequest s zu tun, indem das iOS-eigene NSURLCache mit der Standardrichtlinie verwendet wird. Es stellt sich heraus, dass die Anfrage nicht zwischengespeichert wird, wenn die Antwort den Header transfer-encoding: chunked hat. Wenn der Antwortheader jedoch stattdessen content-length: xxx lautet, funktioniert das Caching ordnungsgemäß. Insbesondere scheint es, dass NSURLCache, wenn die Antwort chunked ist, das eTag nicht speichert und auch das Anhängen des if-none-match -Headers an nachfolgende Anforderungen an die gleiche URL ignoriert und folglich das Caching fehlschlägt (wie es sein sollte), dh 200 ist anstelle von 304 zurückgegeben.
Ich teste am iOS8.2-Simulator. Auch wenn Sie keine Lösung haben, würde ich gerne hören, ob Sie das gleiche Problem erfahren haben. Ich habe mindestens einen ähnlichen Bericht gefunden, und hier ist ein related thread gepostet von meinem Back-End-Ingenieur .
Es sollte funktionieren, wenn Sie die Antwortdaten manuell dem Cache hinzufügen. Ich habe eine Image-Lade-Klasse, in der ich sicherstellen möchte, dass alles zwischengespeichert ist, also mache ich so etwas:
%Vor%Tags und Links ios caching swift ios8 nsurlcache