I found an issue with (possibly) NSURLCache
today while inspecting request and response headers in Charles Proxy. The issue is a little perplexing, but I'm able to repro it consistently:
In a nutshell, the issue has to do with caching of NSURLRequest
s using iOS's native NSURLCache
with the default policy. It turns out that the request is not cached whenever the response has the header transfer-encoding: chunked
. But if the response header is content-length: xxx
instead, caching works fine. Specifically, it seems that when the response is chunked, NSURLCache doesn't save the eTag and also neglects appending the if-none-match
header to subsequent requests to the same url, and consequently, caching fails (as it should), i.e. a 200 is returned instead of a 304.
I'm testing on the iOS8.2 simulator. Even if you don't have a solution, I'd love to hear if you've experienced the same issue. I've found at least one similar report), and here's a related thread posted by my back-end engineer.