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
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 creating a new web site, where I was redirecting HTTP traffic on port 80 to port 443, using certificates created by Certbot. I was using NginX as a reverse proxy for Apache2, so all requests for PHP scripts were to be served from Apache.
I encountered a problem, and decided to remove the HTTPS redirection, stop the Apache server, and start again from the beginning. In other words, I now had Nginx working on its own, and just on port 80.
When testing in Google Chrome 62.0.3202.75, I dutifully cleared the cache. Many times. However Chrome continued to redirect my requests for http://sub.domain.com/index.php to https://sub.domain.com/index.php, which of course failed. Other browsers were happy to download the index.php file, with no complaints.
It was only when I decide to restore the original default settings for Chrome that Chrome started to behave correctly again.
How is it that Chrome was determined to unilaterally perform a redirect that was no longer valid, even after emptying the cache? Is there a more powerful way (other than restoring settings their original defaults) of getting Chrome to let go of a page?
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.
I do not have a choice of installing a network traffic analyzer.
How would I go about looking at the response from chrome to a websocket's ping frame.
In chrome dev tools, it seems we can only see the incoming frames.
Background: I am trying to develop a websocket java client, but the server sends a close soon after a ping, I am assuming this is because of lack of response from the client. I have tried responding with a "pong" and 0xA byte, but still the connection is closed.
I am trying to get a simple web page server from within a Google Chrome Packaged App. There is already a UDP server running within the app and working without any problems.
I am starting the socket.listen on 0.0.0.0:8080 and copying most of the code from
https://github.com/GoogleChrome/chrome-app-samples/tree/master/webserver
. The same issue is replicated in the sample app.
What I am doing is accepting the request and sending a single HTML file to all requests which have some data in the request (request.data.length > 0). The flow of the app is similar to the sample app with near-equivalent functions.
To test this I am using Socket Test 3.0 (from SourceForge). Creating a socket to 127.0.0.1:8080 and sending it GET / HTTP/1.1 as the content. As intended the Chrome App responds with the html file and correct headers. I can repeat this multiple times without restarting the App. The problem arises when the App is sent a request through Chrome. On first look it works as intended, but then it Time Out on refresh. This is also replicated in the sample app.
On debugging I found that every thing was being handles. The write socket being destroyed and a socket.accept(serverSocket, ...) being issued. I also made sure that it was done inside the callback function of the socket.write. The first request as intended is for the page requested (GET / HTTP/1.1 for localhost:8080). Second was for favicon.ico as GET /favicon.ico HTTP/1.1. And then a third connection with none in data (which is then ignored and socket destroyed). Unlike in the SocketTest where every request was answered back.
I have created a video showing the screencast while reproducing the error on YouTube. Also the repo for the project that I'm working on is at GitHub.
I had the same issues with Google's sample web server. I wrote a more robust socket server app that does not hang. The source is on GitHub at https://github.com/kzahel/web-server-chrome and you can install it from the Chrome web store at https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb