9

I am using AFNetworking with iOS 11. I am getting error like:

Task <2EC9C49F-1889-4BFF-83B4-2047ED6E5F2A>.<1> HTTP load failed (error code: -999 [1:89]) Error(countries.php): Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo={NSErrorFailingURLStringKey=https://www.plrc.us/api/countries.php, NSLocalizedDescription=cancelled, NSErrorFailingURLKey=https://www.plrc.us/api/countries.php}

I have tried all the possible way.

info.plist

Please help me to solve this.

Thank you

Rob
  • 415,655
  • 72
  • 787
  • 1,044
Riddhi Shah
  • 733
  • 4
  • 11
  • 25
  • 1
    Yes Rob, I know Alamofire, but AFNetworking is already implemented in this project, sonI didn’t change it – Riddhi Shah Sep 28 '17 at 02:16
  • You specifically call out iOS 11. Is this error not happening on iOS 10 and before? Are you sure you are retaining the manager, which could cause the network request to be cancelled? https://stackoverflow.com/a/33154509/3708242 – wottle Sep 29 '17 at 19:57
  • @wottle - That is definitely a problem that can manifest itself in edge cases in Alamofire, which calls `invalidateAndCancel` in `deinit`. But AFNetworking doesn't do that (unless, of course, you subclassed `AFURLSessionManager` of `AFHTTPSessionManager` and called its `invalidateSessionCancelingTasks` yourself in the `dealloc` of your subclass). – Rob Sep 30 '17 at 00:19

2 Answers2

5

There are a few, minor, unrelated issues:

  1. NSExceptionAllowsInsecureHTTPLoads should be a Boolean, not a string.

  2. The web service returns JSON, but leaves its Content-Type as text/html. But AFNetworking (and its Swifty sibling, Alamofire), validate Content-Type HTTP headers.

    If using AFNetworking, this means that you probably want to add text/html to the list of acceptable content-types for the AFJSONResponseSerializer. (Or you could use AFHTTPResponseSerializer, but then you have to parse the JSON yourself.)

But neither of these are likely the source of the NSURLErrorCancelled. I was able to query this web service from iOS without getting this "cancelled" error (both with your plist settings, and without any plist network related settings at all).

I wonder if there might be some configuration problem on your computer or network. I'd try testing this on a physical device rather than the simulator. (That eliminates the computer configuration as possible source of the problem.) If that works, I'd try testing this on cellular connection rather than over wifi. (That eliminates the configuration of your LAN, e.g. some proxy server weirdness, as the source of the problem.)

In AFNetworking, the default authentication challenge routine passes NSURLSessionAuthChallengeCancelAuthenticationChallenge to the completion handler of URLSession:didReceiveChallenge:completionHandler:, which will result in NSURLErrorCancelled. But standard system configuration will not trigger this. But if there's something about your computer or network which triggers this authentication challenge in AFURLSessionManager.

For example, I was able to reproduce your problem when using Charles, and disabling the Charles Root Certificate, resulting in this sort of un-enlightening "cancelled" error. In my particular example, once I configured my simulator to trust Charles for SSL, via Charles' "Help" » "SSL Proxying" » "Install Charles Root Certificate for iOS Simulators"). I'm not saying that this is the precise problem in your case (this is unique to users of Charles), but it's an example of a broader class of problems that might trigger an authentication challenge, resulting in AFNetworking to cancel the challenge, yielding NSURLErrorCancelled.

Bottom line, try varying the configuration with which you're trying to connect to the remote server and see if you can identify configurations that do not manifest the problem and others that do.

Community
  • 1
  • 1
Rob
  • 415,655
  • 72
  • 787
  • 1,044
  • Okay, I will check on my physical device. – Riddhi Shah Sep 28 '17 at 02:21
  • Also, check the date / time on the iOS device. Sometimes it can cause problems with the cert verification. But I agree with Rob - this is not an ATS problem. Something else is happening – wottle Sep 29 '17 at 12:51
  • The only things which should cause a "cancelled" error are either you cancelled the task, or you called `invalidateAndCancel` on the underlying `NSURLSession`. Any issues with proxies, or certificates, or anything else, should produce something other than "cancelled". – Lily Ballard Sep 29 '17 at 19:25
  • Is AFNetworking doing something stupid like cancelling the task during certificate verification? Can you reproduce the surprising "cancelled" error using NSURLSession directly? – Lily Ballard Sep 29 '17 at 20:20
  • 1
    With `URLSession` I get `NSURLErrorServerCertificateUntrusted`. I can only get `NSURLErrorCancelled` if I write a [`urlSession(_:didReceive challenge:completionHandler:)`](https://developer.apple.com/documentation/foundation/urlsessiondelegate/1409308-urlsession) and pass `.cancelAuthenticationChallenge` to the completion handler. In fact, I added breakpoint in AFNetworking and see that's precisely what its default auth challenge handler is doing, calling the completion handler with the Objective-C version, `NSURLSessionAuthChallengeCancelAuthenticationChallenge`. – Rob Sep 30 '17 at 00:12
  • The thing is, with OP’s URL, you won’t see that challenge unless there was some configuration weirdness. – Rob Sep 30 '17 at 00:55
  • In my case, while I am developing iOS app I had a local server. Server and testing physical device were in different wifi connections. When I change my phone wifi to server wifi everything worked fine. – SajithK Feb 07 '19 at 07:21
3

I ran into this issue while developing a proof of concept and our server didn't have the proper certificates. It seemed like most questions related to this was around using AFNetworking 1 and 2, and most of the answers did not work for me with AFNetworking 3, including modifying the .plist.

What did work for me was modifying the AFSecurityPolicy *securityPolicy; like so:

AFSecurityPolicy *sec = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
[sec setAllowInvalidCertificates:YES];
[sec setValidatesDomainName:NO];
manager.securityPolicy = sec;

I found this thanks to Dody Rachmat Wicaksono's answer here.

OP of that question posted answer in Swift.

Note: Like other workarounds similar to this, this is not meant to be used in a production environment.

Tyler927
  • 197
  • 1
  • 12