When my iPad application makes a web request using the ASIHTTP library it will fail if there is no internet connection.
I want to identify specifically when there is no internet connection and show a unique error to the user (vs. just identifying that the call failed which can happen for a large number of reasons: e.g. The target website is down.)
I've noticed ASIHTTPRequest returns a Status Code 0 when there is no Internet Connection available. If the webpage is not available or another error occurs in communication with the server, it returns an actual HTTP Status Code.
In this case, You could just check to see if request.responseStatusCode == 0 is true and act on that
Related
Is there any configuration like android user-permission in iOS to control access to internet?
I think all new projects access to internet by default, is that correct?
When I send a request to the internet it returns 0 http-error code, it means I can't access to the internet.
yes, it is correct all the new ios project have access to the internet by default.
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.
Any http request will first be processed by the operating system, and during that phase you can get an error. Getting an error means that your request never got a response from the server (and with the exception of https requests where certificates were not accepted, most likely didn't reach the server).
If this phase succeeds, then you get eventually a reply from the server. This may take time, you may have to wait 60 seconds. Which is why you do all your internet requests on a background thread. That reply will have a status code (status, not error). The status code is NEVER 0.
By default, iOS doesn't allow http requests, and doesn't allow https requests to unsave servers, so you better use only https unless you have a very good reason. You will need a very good reason to convince Apple to let your app on the app store if you want http requests to succeed. But if you get this wrong, you get an error quite early on.
A status of zero most likely means that a background request didn't finish by the time you read the status, a basic programming mistake. You need to learn how background threads and callbacks work. Without that, you won't be able to use http successfully.
Also google for "Reachability" which can tell you if your app currently has internet access (like when WiFi and Mobile Data are turned off, or in Airplane mode).
I have a client/server application where the client is an iOS app and the server is a RESTful api. I have received complaints of requests timing out and I know that some/most of the time, this is due to poor wifi connectivity. In these situations I would like to display an error message on the client which indicates whether the request was received by the server.
Is it possible in iOS to tell the difference between a HTTP request that never reaches the intended destination and one that makes it all the way to the intended destination but never receives a response?
API Call only after you check whether your internet connectivity is reachable or not .show error message if not connected to internet(this is due to poor wifi connectivity)
Example : Check for internet connection availability in Swift
When its checked make api call handle error code 404(never reaches the intended destination) and 504(timeout error code never receives a response) and let user make it success only when status code is 200.But its good to handle 401(authorization error) also.
I don't know which library you are using that why can't provide any code example right now
Try Alamofire Library in swift I suggest handled error codes very well.
I have an issue with a single (at least for now) iPhone not being able to connect to websockets. Unfortunately I don't have access to the device and I can't run more tests on it at the moment, so no proper network dumps or anything else deeper level debugging available. Can't test on other network connections either at the moment.
Everything works perfectly with Chrome 45, Firefox 40, Chrome 45 on Android (many devices), Safari on iOS9 (device A), Safari on iOS8 (device B) etc. No errors, no cutoffs, nothing. Just works.
My websocket server runs on IIS 8.5 / ASP.NET, created as an API controller with the typical way (PullHandler is an async Task whileing until connection closes)
if (HttpContext.Current.IsWebSocketRequest)
{
HttpContext.Current.AcceptWebSocketRequest(PullHandler);
return Request.CreateResponse(HttpStatusCode.SwitchingProtocols);
}
else
return Request.CreateErrorResponse(HttpStatusCode.BadRequest, "Bad request");
This should not cause any issues, especially this one. The client side JavaScript is also the simple
new WebSocket("ws://" + window.location.host + "/api/Some/Endpoint);
I am using plain HTTP, no SSL/TLS.
When trying on iPhone device X with iOS9 (13A344, not entirely sure of which model) it just can't get the connection. I am also using SignalR which automatically goes into longPolling transport on this device. With others it's nicely on webSockets transport.
Quick testing on UK Orange 3G connection showed on my HTTP logs that for some reason the request for my endpoint has gone to the else branch, like something had stripped the upgrade headers away.
GET /api/Some/Endpoint 80 - Mozilla/5.0+(iPhone;+CPU+iPhone+OS+9_0+like+Mac+OS+X)+AppleWebKit/601.1.46+(KHTML,+like+Gecko)+Version/9.0+Mobile/13A344+Safari/601.1 - 400
Status 400 is clearly showing the bad request that my code is sending if the request is not a proper websocket request. I don't know if there could be some transparent proxy, that could explain this. The 400 response was received without any delays.
But this was a problem also through wifi on the same device. Again, a laptop with OS X and Safari had no issues on the same wifi to connect to SignalR and my websocket server. Only the iPhone had issues. On wifi I didn't get any attempts to connect on the logs and SignalR also immediately went into longPolling transport. The wifi apparently used Virgin Media's network based on IP address.
On wifi there is first an open event. Then after some time there is a close event with status 1006, which is abnormal termination without a close packet. My code tries to connect again and the same happens. Strangely there is no log entry at the web server, but it might just be Safari's way to post the open event even though an actual connection was not established and after a timeout it sends the close event.
The device should not have any proxies set up and other browsing works without issues. Unfortunately I couldn't get any information about any other site that would use websockets working or not on that device.
Has anyone run into this kind of situation? I do understand that the 3G might just be a misbehaving proxy, but the wifi issue cannot be explained with that.
Just want to expand the universe for this issue.
I Have an app that runs great in simulator. App has both http Jason IO and web socket IO.
Now that I can target my iPhone and not the simulator. App on iPhone successfully does the http Json stuff but not the web socket stuff.
While I am not using safari and js my symptoms are very similar to yours. I am using Xcode 7 to generate code that targets to iPhone 5 using iOS 9.0.
Apple added in iOS 7 new possibility to execute activities in the background, fetch mode, which can be used e.g. for Twitter, when frequently small amounts of data need to be downloaded (official description: The app regularly downloads and processes small amounts of content from the network.),Apple Document Reference
However, I need to use a TCP connection.
Does anyone know whenever TCP connection may be used in such scenario between the calls?
The scenario is:
I open the TCP socket in the beginning and then the application can use it in these fetch calls. Of course handlers are needed when the TCP connection drops, but there is a difference between rare necessity to reconnect and constant (i.e. in each fetch iteration) need to reconnect.
I have a blackberry program that sends data using http post requests to a backend. Now the code works perfectly on my simulators (OS 5/6/7) and even on real devices, but on some other devices in some countries, the connection fails when using 3g with http error code 400 (Bad Request) but over WiFi it's ok.. After investigating, i realised that those telecom operators' bis-b proxies were "blocking"/"rejecting" the post request because of the size (>7kb). The problem is i can't shorten the request size, so any ideas on how to go about this? Any would be highly appreciated. Thanks
EDIT
This is the connection string used when connecting through the BIS.
deviceside=false;connectionUID=GPMDSXXXX;ConnectionType=mds-public (XXXX varies from network to network)
On further inspection, I realised that the "working" connections use the BIS_B TransportDescriptor type (5) to connect whereas the "failing" connections are using TCP_CELLULAR (1) to connect.
i.e. calling connectionDescriptor.getTransportDescriptor().getTransportType() for the working connections gives 5 and for the failing ones gives 1. Any ideas why this could be happening?
Try to use HTTPS. In this case carrier can't sniff what exactly is going inside.