CODEWITHSUNDEEP
iosnsurlconnectionnsurlsessionnsurlsessiondownloadtask
Karl
Karl

Reputation: 745

Best practice to handle HTTP error with NSURLSession?

From apple's doc - (void)URLSession:(NSURLSession *)session task：(NSURLSessionTask *)task didCompleteWithError:(NSError *)error will only report the client side error through error parameter.

Note: NSURLSession does not report server errors through the error parameter. The only errors your app receives through the error parameter are client-side errors, such as being unable to resolve the hostname or connect to the host. The error codes are described in URL Loading System Error Codes. Server-side errors are reported through the HTTP status code in the NSHTTPURLResponse object.

But however when I test in iOS9 with NSURLSessionDataTask, seems currently apple mapped some HTTP error to NSURLError. For example, 404 to NSURLErrorFileDoesNotExist. This fact break some assume we had before, and many snippet also take the error parameter as connection error, this will be absolutely wrong.

I try to seach and find Apple may only mentioned this change in the NSURLSessionDownloadTask. And not well documented how these map is applied.

Unlike NSURLSessionDataTask or NSURLSessionUploadTask, NSURLSessionDownloadTask reports server-side errors reported through HTTP status codes into corresponding NSError objects.

Personally I think the Apple's Dev team has made a big mistake; And the document is still inconsistent and not ture, even two years passed no any update.

Any one has more information about this change, when this is introduced? And what is the best way to distinguish a connection error and the HTTP error now.

Upvotes: 3

Views: 2113

Answers (1)

dgatwood
dgatwood

Reputation: 10407

The answer is the same as it always was. If your server sends errors with a 200 error code (e.g. in a JSON response), you'll have to handle that checking yourself. Otherwise:

  • If you care about what specific HTTP status code the server sends, implement a didReceiveResponse delegate method and intercept the error.
  • If you only care that the request failed and you don't care why, you're guaranteed to get some error via the error parameter in your completion callback, but you aren't guaranteed to get any particular error.

Note that success is defined as any of:

  • Result code 200 (OK)
  • Result code 304 (NOT MODIFIED)
  • A redirect to a page that returns 200 or 304

If your definition is different (e.g. if your server responds to invalid URLs by redirecting to an error page), you would need to add a delegate method to detect the redirection and treat that as an error.

Upvotes: 0

Related Questions