In our case, these responses our definitely status 200's with json body. It doesn't happen with all requests only a minor but important chunk of users whom, once they received NSURLErrorCannotParseResponse they tend to get a lot of them. We attempt to retry these requests and that helps but does not resolve the issue.
I have recently been able to reproduce the issue on iOS Simulator but simulating a transient/dropping Network connection with link conditioner. What I see is also in console reported as..
error 17:51:08.138859-0800 nsurlsessiond Task <86EF8AD5-8532-4D5F-B52F-4462078EA23A>.<525> HTTP load failed, 49316/0 bytes (error code: -1017 [4:-1])
We actually snooped CFNetwork binaries and found this string as
_os_log_error_impl(rip - 0x14bb9b, *__os_log_default, 0x10, "%{public}@ HTTP load failed, %lld/%lld bytes (error code: %ld [%ld:%d])", &var_70, 0x3a);
This may be a transient error leaking through a fall through case somewhere specific to background urlsessiond. What is supposed to happen for background URLSession is that transient errors such as lostConnection are never reported back to us and it only uploads when the network connection is good. I fear this is a bug in the network stack which is not recognizing (and retrying or not reporting) a transient error.
Topic:
App & System Services
SubTopic:
General
Tags: