I am taking over an iOS application connecting to the server through a Web socket connection using the Kaazing Websocket (JMS edition) client side javascript library.
I am using Phonegap for my iOS application and be able to test it both on Chrome and the iOS simulator. About 30% of the time I get a connection error from the library testing on chrome and 70% for testing on the iOS simulator/device. I get an Exception being thrown in the minified js library which just say "ConnectionFailedException : Websocket connection failed" Seems like this is a browser specific issue but I cannot do anything further about it.
I can't directly take a look at the server located in the UK but asking them for debug logs. So I asked for the logs from server and these are the errors that I spotted out that might be the reason:
2014-03-05 08:09:23,670 [NioProcessor-15] DEBUG session.revalidate - No WebSocket authorization timeout has been configured, so no revalidate period can be inferred.
2014-03-05 08:09:23,670 [NioProcessor-15] INFO session.revalidate - WebSocket Session [176128] is not being re-validated because no timeout has been specified for the negotiated "x-kaazing-http-revalidate" extension.
Anybody have any idea about this x-kaazing-http-revalidate and if not, what is the proper way to debug these Websocket connection?
Full disclaimer, I work at Kaazing.
x-kaazing-http-revalidate is a Kaazing HTTP extension, negotiated while establishing WebSocket connection. This is done by setting the authorization-timeout in the gateway-config.xml file (the configuration file we ship has an example). The intention of this extension is to periodically revalidate the user's authorization, because entitlements could change over the duration of a long-running connection.
ConnectionFailedException : WebSocket connection failed can occur, if some intermediaries/proxies associated with the service providers inject an unknown or a suspicious header/s in the WebSocket connection request. If the injected header is unknown/suspicious, then Kaazing gateway will not complete the connection, to avoid intruders from eavesdropping. Using a secure TLS/SSL connection should resolve the intermediary related issues.
To debug and to setup a secure javascript client please follow instructions from the documentation. You can also use WebSocket-debug.js instead of WebSocket.js with script tags in the jms-javascript.html file for more logging. There is also a Walkthrough: Deploy a JavaScript JMS App as a Hybrid iOS App.
Related
I'm deploying my .Net 6, Blazor Server site for the first time on shared hosting. It's all seems to work so far bar two things.
In the browser console (Chrome) I get an error:
Error 1
blazor.server.js:1 WebSocket connection to 'wss://www.mysite.co.uk/_blazor?id=qW5eCRVc_HbgSWt8iESawA' failed:
Information: (WebSockets transport) There was an error with the transport.
Error: Failed to start the transport 'WebSockets': Error: WebSocket failed to connect. The connection could not be found on the server, either the endpoint may not be a SignalR endpoint, the connection ID is not present on the server, or there is a proxy blocking WebSockets. If you have multiple servers check that sticky sessions are enabled.
Warning: Failed to connect via WebSockets, using the Long Polling fallback transport. This may be due to a VPN or proxy blocking the connection. To troubleshoot this, visit https://aka.ms/blazor-server-using-fallback-long-polling.
The page seems to work & I've added all the CSP entries I can find so that's the only error left.
Error 2 is when I call Braintree to capture a payment. That's the only Braintree call & it works fine locally.
Transaction.SubmitForSettlementAsync(transactionId, amount)
gets an exception : The request was canceled due to the configured HttpClient.Timeout of 60 seconds elapsing.
I have no idea why that is & assume is blocking is call. Any help would be appreciated.
For this warning:
Warning: Failed to connect via WebSockets, using the Long Polling fallback transport. This may be due to a VPN or proxy blocking the connection. To troubleshoot this, visit https://aka.ms/blazor-server-using-fallback-long-polling.
see: https://learn.microsoft.com/en-us/aspnet/core/signalr/publish-to-azure-web-app?view=aspnetcore-5.0#configure-the-app-in-azure-app-service
For apps hosted without the Azure SignalR Service, enable:
ARR Affinity to route requests from a user back to the same App Service > instance. The default setting is On.
Web Sockets to allow the Web Sockets transport to function. The default setting is Off.
In the Azure portal, navigate to the web app in App Services.
Open Configuration > General settings.
Set Web sockets to On.
Verify that ARR affinity is set to On.
I've started to evaluate Oryx Embedded CycloneTCP library, and able to run HTTP server / DHCP client with CubeMX config tools and STM32CubeIDE for custom STM32H7 board.
However, I did not get how to configure WebSocket support for HTTP Server. So I need some help / sample / demo code for it.
Its an a bit older question, but nonetheless...
https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/20-21/05/STM32F7_CycloneServer
shows how to implement a simple websocket->CAN Bus gateway.
Take a look at CycloneServer/Core/Src/main.c
In httpServerRequestCallback() the http connection gets upgraded to a websocket connection.
Received frames are processed in a seperate task (clientTask()).
sendCANBusToClient() shows how to send messages to connected websockets.
I have a setup which involves devices connecting to a server via web sockets. I'm experiencing a strange problem where they can connect to one test server without issues, but cannot connect to a different server (hosted on Azure).
I've installed Wireshark on both of them, and can watch both the successful connection and the unsuccessful connection. It appears that the unsuccessful one attempts to initiate an SSL handshake.
Here is the successful connection:
Here is the unsuccessful connection:
It seems like the client in the successful connection is simply setting up an HTTP web socket, but in the unsuccessful setup it's try to set up a secure connection.
Why would the client be setting up different connections depending upon the server address?
The client code to create the websocket is just javascript, invoking new Websocket(address), and in both cases the address begins with the 'ws' prefix.
I have done some further investigation and found another weird behavior. As it happens, there are two domain names pointing to the same server.
If I used the domain name with the top level domain "com" (XXXX.australiaeast.cloudapp.azure.com), then the connection works.
If I used the domain name with the top level domain "dev" (comutername.mydomainname.dev) then the connection fails, with the weird TLSV1 packet.
Both works fine if I run the same client code on the Microsoft Edge browser.
This appears to be a defect in Chrome's implementation of The WebScoket API
I have posted a defect here, let's see how it goes. https://bugs.chromium.org/p/chromium/issues/detail?id=1067076
The issue in play here is HTTP Strict Transport Security (HSTS)
A browser can be configured so that certain domains have an HSTS policy attached, meaning any insecure link will automatically be converted to a secure link.
This policy will be applied if a request returns a Strict-Transport-Security header. But, and here's the significant bit, the Chrome and Firefox browsers automatically apply the policy to all dev domains.
It appears that up until recently, the Chrome browser and Chrome OS was not observing the policy with regard to WebSocket connections. This has changed, and now WebSockets will observe the HSTS policy.
The upshot is, if you have a websocket using the ws protocol and not the wss protocol, and it's on a .dev domain, your Chrome and Firefox browser will not be able to connect to it.
I am facing issue while running sample kurento turorial for javascript.
Below is the exception in the browser console
Firefox can’t establish a connection to the server at wss://:8433/kurento.
Sample tutorial for Java spring boot application working fine. I am able to stream from server.
Is there any configuration or setting changes are required for it.
Thanks
Mohsin
I am not sure whether wss:// can be tested from fire fox.. we may have to use something like below to test wss connection
https://www.websocket.org/echo.html
I have an API application and a web application (for simplicity on the same server -- I'll do the CORS stuff later).
Windows Server 2012 with IIS 8.5
Websockets installed through "Programs and features"
Firewall turned off
The api is using owin + signalr and has the proper initialization (trimmed it down to find the error):
public void Configuration(IAppBuilder app)
{
GlobalHost.Configuration.TransportConnectTimeout = TimeSpan.FromSeconds(5);
app.MapSignalR();
app.UseWebApi(Startup.CreateConfiguration());
}
private static HttpConfiguration CreateConfiguration()
{
HttpConfiguration configuration = new HttpConfiguration();
configuration.MapHttpAttributeRoutes();
return configuration;
}
Everything seems to work perfectly except connection to the actual websockets. Every time the client tries to establish a connection, there is a timeout and it fails over to SSE (or forever frame/long polling in IE). I increased the timeout to 25 seconds and the same symptoms are occurring.
On the client, I consistently get this error with logging turned on:
SignalR: Connecting to websocket endpoint 'ws://[myurl]'.
SignalR: Websocket opened.
SignalR: **webSockets timed out when trying to connect.**
SignalR: Closing the Websocket.
SignalR: Attempting to connect to SSE endpoint 'http://[myurl]'.
SignalR: EventSource connected.
SignalR: serverSentEvents transport selected. Initiating start request.
SignalR: The start request succeeded. Transitioning to the connected state.
I have tried following the guides provided by the signalR team and I cannot see what I am missing.
Thanks for any help!
UPDATE:
I downloaded a sample and ran it as-is on the server.
Same situation, so this is likely a server configuration setting that I missed along the way. I still have not found what I missed.
You need to enable WebSockets for the website in Server Manager.
http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support
Try establishing a SignalR connection from your Windows Server machine itself. This might have something to do with the network. Perhaps there's a proxy or something in between the client and server that doesn't properly support WebSockets.
If you are inside of a network with a "corporate" firewall, it can screw up the websockets handshake.
But, you can prevent this interference if you access your server over SSL. I've seen this first hand be the cause and solution multiple times for websockets problems in corporate environments.
It may be something with your IIS settings. I saw these on http://www.asp.net/signalr/overview/signalr-20/getting-started-with-signalr-20/supported-platforms
-IIS must be running in integrated mode; classic mode is not supported. Message delays of up to 30 seconds may be experienced if IIS is run in classic mode using the Server-Sent Events transport.
-The hosting application must be running in full trust mode.
Also, it mentioned something about .NET 4.5 being the target framework. Hope this helped.