HTTP status code 0 - Error Domain=NSURLErrorDomain?

I am working on an iOS project.

In this application, I am downloading images from the server.

Problem:

While downloading images I am getting Request Timeout. According to documentation HTTP status code of request timeout is 408.

But in my application, I am getting HTTP status code 0 with the following error

> Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." > UserInfo=0xb9af710 > {NSErrorFailingURLStringKey=http://xxxx.com/resources/p/PNG/1383906967_5621_63.jpg, > NSErrorFailingURLKey=http://xxxx.com/resources/p/PNG/1383906967_5621_63.jpg, > NSLocalizedDescription=The request timed out., > NSUnderlyingError=0x13846870 "The request timed out."}

During a search, over internet, I found no information about HTTP Status Code 0.

Can anyone explain this to me?

There is no HTTP status code 0. What you see is a 0 returned by the API/library that you are using. You will have to check the documentation for that.

A status code of 0 in an NSHTTPURLResponse object generally means there was no response, and can occur for various reasons. The server will never return a status of 0 as this is not a valid HTTP status code.

In your case, you are appearing to get a status code of 0 because the request is timing out and 0 is just the default value for the property. The timeout itself could be for various reasons, such as the server simply not responding in time, being blocked by a firewall, or your entire network connection being down. Usually in the case of the latter though the phone is smart enough to know it doesn't have a network connection and will fail immediately. However, it will still fail with an apparent status code of 0.

Note that in cases where the status code is 0, the real error is captured in the returned NSError object, not the NSHTTPURLResponse.

HTTP status 408 is pretty uncommon in my experience. I've never encountered one myself. But it is apparently used in cases where the client needs to maintain an active socket connection to the server, and the server is waiting on the client to send more data over the open socket, but it doesn't in a given amount of time and the server ends the connection with a 408 status code, essentially telling the client "you took too long".

The Response was Empty. Most of the case the codes will stats with 1xx, 2xx, 3xx, 4xx, 5xx.

List of HTTP status codes

In iOS SDK When your API call time-outs, you get status 0 for that.

From my limited experience, I would say that the following two scenario could cause response status code: 0, keep in mind; their could be more, but I know of those two:

• your connection maybe responding slowly.
• or maybe the the back-end server is not available.

the thing is, status: 0 is slightly generic, and their could be more use cases that trigger an empty response body.

Status code '0' can occur because of three reasons
1) The Client cannot connect to the server
2) The Client cannot receive the response within the timeout period
3) The Request was "stopped(aborted)" by the Client.

But these three reasons are not standardized

HTTP response 0 is not standard HTTP response. But it indicates that client could not connect with server and hence forth time out happened.

Sometimes Browser respond to http error handler with Error Object, that have status set to 0, even if you can see 404, 401, 500 etc. error status in network.

This could happen if your Application and API are on different domains - CORS mechanism is applied. According to CORS for each API request browser sends two requests:

1. preflight OPTIONS request to understand if API allows Actual/Origin request.
2. when API allows (OPTIOS request respond with status 204 and correct Access-Control-Allow-Origin headers) - browser send next "Actual/Origin request".

In Application we are handling Error response for "Actual/Origin request", and if "preflight OPTIONS request" failed - browser doesn't give correct HttpError object for http error handler. So to get correct status of http response - be sure to get success preflight OPTIONS request response.

We got the error:

GET http://localhost/pathToWebSite/somePage.aspx raised an http.status: 0 error

That call is made from windows task that calls a VBS file, so to troubleshoot the problem, pointed a browser to the url and we get a Privacy Error:

> Your connection is not private > > Attackers might be trying to steal your information from localhost > (for example, passwords, messages, or credit cards). > NET::ERR_CERT_COMMON_NAME_INVALID > > Automatically report details of possible security incidents to Google. > Privacy policy Back to safety This server could not prove that it is > localhost; its security certificate is from *.ourdomain.com. This may > be caused by a misconfiguration or an attacker intercepting your > connection. Learn more.

This is because we have a IIS URL Rewrite rule set to force connections use https. That rule diverts http://localhost to https://localhost but our SSL certificate is based on an outside facing domain name not localhost, thus the error which is reported as status code 0. So a Privacy error could be a very obscure reason for this status code 0.

In our case the solution was to add an exception to the rule for localhost and allow http://localhost/pathToWebSite/somePage.aspx to use http. Obscure, yes, but I'll run into this next year and now I'll find my answer in a google search.

I have gotten a status code 0 when my URL starts with file://, i.e. when there is no server but the request is getting the file from the local filesystem.

CORS in my case.

I had such response in a iOS app once. The solution was the missing Access-Control-Allow-Origin: * in the headers.

More: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin

This can happen with a 401 http response if using NSURLConnection.

See https://stackoverflow.com/questions/29391892/nsurlconnection-returning-error-instead-of-response-for-401

In my case, it's the WebKit engine too old, and the web site / web page administrator doesn't properly configurate https settings.