I use this code.
var apiPath : String = "/api/list/"
let configuration = NSURLSessionConfiguration.defaultSessionConfiguration()
configuration.timeoutIntervalForRequest = 60
let manager = Alamofire.Manager(configuration: configuration)
manager.session.configuration.HTTPAdditionalHeaders = ["_token" : self._token]
manager.request(.GET, self._host + self._url + apiPath, parameters: nil)
.responseSwiftyJSON ({ (request, response, resultJson, error) in
if (resultJson["Success"]) {
//get list success
} else {
println("request : \(request)")
println("response : \(response)")
println("resultJson : \(resultJson)")
println("error : \(error)")
}
})
And I got some problem
Alamofire version 1.2.1 : No Problem
Alamofire version 1.2.2 & 1.2.3 :
request : { URL: https://test.com/api/list/ }
response : nil
resultJson : null
error : Optional(Error Domain=NSURLErrorDomain Code=-999 "cancelled" UserInfo=0x7feb92c434f0 {NSErrorFailingURLKey=https ://test.com/api/list/, NSLocalizedDescription=cancelled, NSErrorFailingURLStringKey=http s://test.com/api/list/})
why response was nil and resultJson was null on version 1.2.2 and 1.2.3 Please help me what problem in this code..
I just encountered the same problem as you today after updating Alamofire from 1.2.1 to 1.2.3.
I discovered by adding "manager.session.invalidateAndCancel()" at the end and inside the responseJSON block fixed this issue. But what I cannot get my head around is that how can this line of code INSIDE the responseJSON block affects the responseJSON results.
Anyway I will just run with this fix until the Alamofire team fixes it or someone explains to me why this is happening.
I noticed that your API endpoint indicates to a secure connection:
httpS://test.com/api/list/
Just try it just in case, maybe it repeats your situation.
In my case, this was a typo in the API manager code. Which from the part can be said is connected with App Transport Security Settings.
Just changed the protected protocol from httpS://
to http://
and the error:
NSURLErrorDomain Code = -999 "cancelled"
was gone and it all worked!
+And also if you had a similar problem. Be sure to discuss this with a backend specialist who deals with the server or API configuration for your application. This means that the server does not have valid security certificates. Perhaps you still need a secure connection. Or this specialist can again configure everything back from http://
to httpS://
, and I'm not sure (did not check) whether this will work again when in the code you are already using a non-secure http://
connection.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With