问题
In iOS 9, I'm using NSURL with NSURLConnection and for one specific URL, it's generating the following error in the - (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error delegate method.
Error Domain=NSPOSIXErrorDomain Code=89 "Operation canceled" UserInfo={NSErrorFailingURLStringKey=URL, _kCFStreamErrorDomainKey=1, NSErrorPeerAddressKey={length = 16, capacity = 16, bytes = 0x100201bb41d733370000000000000000}, _kCFStreamErrorCodeKey=89, NSErrorFailingURLKey=URL}
The request isn't being canceled, at least not by our code. What's strange is that the error here isn't even NSURLErrorDomain, it's NSPosixErrorDomain.
A user in the field reported an issue and this is the root cause, but it's tough to determine exactly why this is happening. Accessing this specific URL with curl on OS X(using the same request, User-Agent and all), doesn't produce this error, the response is completely as expected. However, even accessing this specific URL from the iOS Safari browser still doesn't work. It's possible there is some strange server configuration, but I wouldn't expect the error to be so general like canceled.
It's also been reported that this wasn't occurring with iOS 8. There's nothing out of the ordinary about this URL, it just seems it can't pass through our stack. No auth challenges or any kind of delegate callbacks occur, except for didFailWithError and it occurs immediately. Anyone else seen this kind of behavior in iOS 9?
Update: The particular URL that seems to produce this error is NOT limited to our apps alone. In fact, simply trying to access this particular URL in iOS Safari on iOS 9 produces the same error. I managed to test this on iOS 8.3 in iOS Safari and the error was not reproduced.
回答1:
Could this be an ATS issue? For apps linked against the iOS 9 SDK, iOS 9 uses stricter rules for what types of TLS certs it will accept, and for what TLS protocols it will allow (e.g. no more SSLv3). Additionally, it requires that all requests be HTTPS (not HTTP).
You can either override this behavior (if you must) or fix the server.
For details, see Apple's Info.plist documentation.
If that doesn't help, try enabling CFNetwork debugging as described in QA 1887 and see what it spits out.
回答2:
Just to add some color to this issue, I'll explain our similar situation and how we are handling it.
The setup:
- We are using SPDY for HTTP/2 requests on iOS 9
- We were randomly receiving a NSPOSIXErrorDomain error with code 89; this is defined at a very low-level in the OS kernel here
- We ruled out most server conditions and lack of network as the cause
Root cause:
- We found that if we introduced a sleep into one of our backend routes, iOS would surface it as this cryptic POSIX 89 kernel error
- The timeout on the iOS side is exactly 120 seconds which is the TCP default max segment lifetime
What else we tried:
- If we set our server to use HTTPS instead of SPDY (HTTP/2), it timed out with a normal network connection error
How we're "fixing" it:
- Filing a radar with Apple to better understand why the timeout is properly handled for HTTPS calls but not for SPDY
- Making the assumption that the only time we'll see this error domain/code combination is during a network timeout, at which point we should retry under certain situations
来源：https://stackoverflow.com/questions/33790260/why-would-an-nsurlconnection-generate-this-error-nsposixerrordomain-operation