I'm using Stomp and Sockjs to register a websocket with my Spring Boot self-contained server (3.1.1), which all works fine. However, I have implemented a ServiceWorker to handle offline services, which is all working, except for the socket. The call to ws://localhost/registerSocket yields this error on the frontend:
Firefox can't establish a connection to the server at ws://localhost/registerSocket/351/4vevdv79/websocket.
And this on the backend:
ERROR o.s.w.s.s.s.DefaultHandshakeHandler - Handshake failed due to invalid Upgrade header: null
In my ServiceWorker I've specifically excluded it from intercepting the ws request:
if (uri.indexOf("/registerSocket") === -1) {
event.respondWith(getResponse(event));
}
Yet, inevitably the ws upgrade fails and it reverts to the old comet style polyfill.
Does anybody know of a way to get websockets working correctly with ServiceWorker?
I've just found out about a bug in Firefox 44 that prevented Web Socket connections from working when a Service Worker was used.
See this bug report.
The bug should be fixed now (since Firefox 44.0.1; it's even in the release notes).
fetch event handlers in a service worker are only triggered in response to HTTP requests. Requests to open a WebSocket or transmitting data over that WebSocket won't trigger the fetch event handler, meaning that the service worker won't get involved.
Related
I Have a simple back-end app on a Google cloud virtual machine. It receives websocket connections and sends some simple messages to clients. I also have nginx server running on same machine, listening to 443 port and redirecting requests to my application (http://127.0.0.1:8080). Everything is secured by a valid SSL certificate, so requests are made through https:// and wss://.
Now I'm writing Angular front-end application that connects to my server like this:
return webSocket({
url: `wss://www.mydomain.site/${path}`,
closeObserver: {
next: (event: CloseEvent) => { console.log(event) }
}
}).multiplex(() => {}, () => {}, () => true)
When I try to run the code in my browser with AdBlock chrome extension enabled, it thinks that my request to websocket is an ad and blocks it. So my server doesn't even receive Upgrade request and browser logs WebSocket connection to 'wss://mydomain.site/something' failed.
When AdBlock is disabled, everything works fine: Request is sent to my server and incoming messages are received on the browser.
Also, when I try sending request directly to my app and bypassing nginx proxy like this: ws://www.mydomain.site:8080/something, everything works fine with AdBlock enabled.
My website doesn't use ads, so I don't care if users have AdBlock on or off, and asking users to disable AdBlock might be annoying for them and bad for UX.
My question is, what can I do to prevent AdBlock from treating my wss:// request as an ad and blocking it?
My domain is .site, can that be causing this issue ?
Same issue, I was previously using no-ip.com to redirect the websocket using certbot TLS system with domain name, but no-ip was requesting an update every month which is really tedious work for a 8$/mo server hosted on google cloud.
I started using duckdns which doesn't require every month update, and when I investigated for 5 hours why it couldn't connect, it was adblock which doesn't like duckdns.com it seems ...
You can use no-ip if you are not afraid to click "update" every month, or find another service which isn't blocked by adblock :)
I am writing a web server, specifically, a server that handles HTTP/1.0 and HTTP/1.1 protocols. I implemented HTTP/1.0 features in my server and wanted to look at persistent HTTP connections (Connection: Keep-Alive). I also implemented that feature and tested the server via telnet. Everything works fine for telnet, the server does not close the client socket after every request, waits for 15 seconds, and closes the socket if it is inactive.
To ensure that it works correctly, I re-tested the server with Postman. Here is the screenshot:
As you can see from the logs, the socket connection is not dropped after sending the response. After 15 seconds of inactivity, the server closes the socket. This is the desired behavior
However, when I used the Google Chrome web browser, it turns out that it does not work correctly (not the same with the desired behavior). Here is the screenshot:
I speculate that Google Chrome creates a new socket connection for every request even though Connection: Keep-Alive is present in both HTTP request/response messages. However, I am not sure whether this is true or not. By the way, I also used Safari and the output is the same.
Is this the reason why persistent HTTP connection does not work in Google, yet it works with telnet and Postman?
Thanks
I'm developing a Chrome application using node, video via WebRTC, and Leap Motion functionality via socket.io and testing it locally.
Before the Chrome Security updates (version 46 and earlier) my LM controller and rigged hand functionality worked fine.
Now, after I implemented a secure HTTPS connection generating my own keys via OpenSSL to comply with Chrome security, my controller no longer works. I receive the error (both occur in leap.js):
WebSocket connection to 'wss://<myIP>:6436/v6.json' failed: Error in connection establishment: net:: ERR_CONNECTION_REFUSED
Mixed Content: The page at 'https://<myIP>:2013/expert.html' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://<myIP>:6437/v6.json'. This request has been blocked; this endpoint must be available over WSS.
Other functionality that depends on websocket.io (drawing tool, freeze tool, etc.) functions properly, so this leads me to believe that my error is something that I need to address with Chrome itself.
Any insights are appreciated!
In the context of a unit test I need to send some code to the console of a chrome app I am developing. It's clear that I can do that from the chrome.debug API, but is there a way to do that from outside the browser?
Yes, there is a way; if you can do something with chrome.debug you can do so with remote debugging.
You need to enable remote debugging with command line switches; you can then connect to Chrome with a debugger client instance.
Google lists some existing debugger clients, and you can implement your own by following the debugger protocol (which works over HTTP+WebSockets).
The procedure for a debugger client is to request /json from the debugger port over HTTP, which lists all possible debug targets; the client then connects to the WebSocket associated with that target to work with it.
I have C++ Win32 app that uses HttpSendRequest to request some URL (via https). It worked OK earlier; but then errors ERROR_INTERNET_INCORRECT_HANDLE_STATE began happen. Why these ones? Any ideas?
I stumbled across something very similar recently. It suggests that your HttpOpenRequest has either failed or not yet completed, or during the HttpSendRequest() call the connection died for some reason (SSL handshake problems, Certificate problems, or just simple TCP connection problems).
I specifically saw the problem when developing an app using the asynchronous WinINET process, and my calls to HttpQueryInfo and InternetReadFile were failing with that return code.
In my case, I wasn't correctly waiting for the async notifications from HttpSendRequest to be received before calling the other methods, and also in cases where I wasn't correctly dealing with failures during the connection.
I know its a year late, but hopefully that helps.
It seems trivial but,
did you have flag INTERNET_FLAG_SECURE in making HttpOpenRequest?
as described in:
http://support.microsoft.com/kb/168151
For I myself was stuck here for hours until I found above knowledge base entry.
I got the same error on Windows XP for HTTPS connection (all flags correct) for the HTTP2 server endpoint, I wonder if it can't properly handle HTTP2 connection or the certificate.