In our app we are reliant on a web socket inside a WKWebview. In previous releases this web socket worked well. In the iOS 15 betas though this web socket behaves differently: it connects to our server successfully but once the client tries to send any data through it the web socket throws an error and closes with a non descriptive error:
The operation couldn’t be completed. (kNWErrorDomainPOSIX error 54 -
Connection reset by peer)
Looking into the system log the deepest error I can make out is:
nw_protocol_boringssl_error(1772) [C12.1.1:2][0x102e0d540] Lower
protocol stack error post TLS handshake. [54: ]
A test web socket to another server seems to be working.
I also notices that a MitM proxy like Charles no longer shows web socket connections in the iOS 15 beta. This just indicates that something might have changed.
Because the communication via this socket is very important for the functionality of our app I must know what the issue is. I tried adding ATS exceptions for the URL of the socket to no avail.
Maybe this is a temporary bug in iOS 15 that will be fixed until its released? Or maybe anyone has experienced this kind of error in the past?
It seems that the issue is related with websocket compression on IOS 15 (permessage deflate). Disabling the compression for ios 15 devices on the server side helped.
This is obviously not a solution, but only a quick fix (if you have an access to the server). Here is a discussion on the same topic.
Related
The error logged (on iOS 9):
Error Domain=NSURLErrorDomain Code=-1005 “The network connection was lost.”
It occurs frequently with https:// request and with http:// it works far more better, but still it throws error sometimes.
Is this error because of https call? Do we need to have http request for iOS 9 in order to resolve this issue?
Thanks in advance.
This usually means that your network connection dropped out while making the request... Do you have a good strong internet connection? Are you seeing issues when using other apps/programs?
Is this happening on the device or simulator? Try resetting the simulator or restarting the device.
You aren't monitoring network traffic via a proxy are you? You can sometimes run into issues like this when SSL verification fails because for example you are monitoring network traffic via tools such as Charles.
Does the server you are talking with (https one) have a valid and trusted SSL certificate? Could be related to that too.
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.
I have been trying to open a websocket from iOS with an API developed in Sails.JS running on Heroku. But I am not sure where to point the web socket.
Attempting to connect directly to ws://my-domain.herokuapp.com fails with a 503 error every time.
What I have noticed, however, when opening my app in chrome, and monitor the console - I occasionally see this error in the console:
WebSocket connection to 'ws://my-domain.herokuapp.com/socket.io/1/websocket/2RNf_dS2sjcShe397tEQ' failed: Unexpected response code: 503
But almost immediately after, it connects. My question is: where is the socket path on that URL coming from? Is that something that Sails.JS issues upon an HTTP Connection, and is that something I should request in iOS? Or am I missing something else?
I would suggest taking a look at: https://github.com/balderdashy/sails-examples/tree/master/SampleAppiOS. Instead of using web sockets, it uses socket.io.
We're currently dealing with a performance issues in our app, and we believe that some of these issues might be related to the fact that the app and the underlying AFNetworking network stack seems to ignore keep-alive on HTTP 1.1.
We got information from Apple that persistent connections are purged after 3, 6 or 30 seconds respectively, depending on iOS version and WiFi/WWAN connectivity, regardless of server-side keep-alive information.
While monitoring the connection handshakes on our servers, we noted the weird behavior that an SSL connection from our app on an iOS device is left open and not closed with a FIN packet. As soon as new request is made from the app, the left over connection from the previous request is THEN closed with a FIN packet and a new connection is created.
While we understand that iOS purges the connections to keep the battery consumption low, we wonder that it doesn't terminate the existing connection properly and defers that termination to the start of a new request.
Could someone explain this behavior, and suggest solutions to avoid expensive SSL handshakes in connections which are covered by keep-alive under regular conditions?
I bumped into the same problem some weeks ago.
The solution was to force webserver ignore keepalive http header from iOs device and close connection immediately.
I try to make an app that can make a connection into a FTP server. I've use Chilkat library to do this connection. The problem is, I want to test my app and make a wrong connection. So i make a connection into my FTP server, but using SSL connection (base on chilkat example in Chilkat sample code for implicit SSL connection)
FYI, I am not setting SSL in my FTP server. After I run my code on device, the app crashed, and the debugger showed SIGPIPE. I know SIGPIPE is because I made a wrong socket connection, but I dont know how to handle it. I have read an article about uncaught exception on this link, but I don't know how to implement these.
Can somebody tell me, how to handle these SIGPIPE exceptions?
Have a look at this answer: Prevent Sigpipes
When you ignore sigpipes your app won't crash anymore when recieving a sigpipe.