ich ein Problem gefunden (möglicherweise) NSURLCache heute während Anfrage- und Antwort Inspektion Header in Charles Proxy. Das Problem ist ein wenig verwirrend, aber ich bin in der Lage es konsequent Repro:NSURLCache funktioniert nicht, wenn Antwort-Header-Wert für Transfer-Encoding gestückelt ist
Auf den Punkt gebracht, hat das Problem mit Caching von NSURLRequest s mit iOS native NSURLCache mit der Standardrichtlinie zu tun. Es stellt sich heraus, dass die Anfrage nicht zwischengespeichert wird, wenn die Antwort den Header transfer-encoding: chunked hat. Aber wenn der Antwortheader stattdessen content-length: xxx ist, funktioniert das Zwischenspeichern gut. Insbesondere scheint es, dass, wenn die Antwort gestückelt wird, wird NSURLCache nicht ETAG speichern und vernachlässigt auch die if-none-match Header nachfolgende Anfragen auf den gleichen URL anhängen und damit Caching nicht (wie es sein sollte), dh ein 200 statt zurück ein 304
teste ich auf dem 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 one similar report gefunden, und hier ist ein related thread posted by my back-end engineer.
Hallo, irgendwelche Updates zu diesem Thema? –
Keine, außer dass wir diesen Fehler mit hoher Sicherheit wiederholen können. Im Moment versuchen wir, den JSON immer mit dem Content-Length-Header zurückzusenden. Was ist das Wesen deines Problems? – rainypixels
Hallo, unser Backend-System kann keine Inhaltslänge zurückgeben, da die Antwort riesig ist und als Chunks zurückgegeben werden muss. Also müssen wir die Möglichkeit finden, eine Chunked-Response zu cachen oder eine offizielle Dokumentation, die sagt, dass das unmöglich ist. Schätze jeden Rat. –