Chrome (on Win and Linux) was unable to load https://apscatalog.com.
Though all other browsers and Chrome on Mac was able to load site with no warnings or errors.
Even external tools say that everything is fine: https://www.ssllabs.com/ssltest/analyze.html?d=apscatalog.com
How can I fix this issue?
Update
It seems to be a Chrome bug. Chrome v.33 works fine while v.32 fails
I would say, that the they have some broken appliance (firewall, load balancer...) in front of it. From wireshark I see the Client Hello from Chrome, but it never gets a response, not even an ACK that the packet was received. That's why it's retransmitting the Client Hello again and again until it finally gives up. I've seen such problems with older F5 BIG-IP load balancers (it's fixed in the meantime, but there are still some broken ones out there) but this does not seem to be the case here. So it's probably yet another broken appliance :(
In case you have knowledge of the infrastructure there I would really like to know what device this might be.
Interesting that https://apscatalog.com works if chrome is started with ssl-version-max=tls1:
google-chrome --ssl-version-max=tls1
Related
I work on a team that is developing a browser based video application. We have been experiencing an occasional severe degradation in the quality of our video starting around November 2022. It happens during a call and continues until the call is ended (the connection is ended), and appears to be a decoding issue (the screen looks pixelated/discolored but you retain some idea of the 'shape' of objects on the video feed).
We use Pexip which acts as an MCU between participants, and have validated from Pexip's outbound packets that it is sending a clear video stream, however on the browser we see the issue nonetheless. This is only seen on a single participants video stream.
The issue has only been seen on Chrome and Edge which default to VP8, and has not been reproduced on Firefox (defaults to H.264). This leads me to believe it is an issue with Chromium.
I have struggled to find any logs that relate to the start of the issue, and am asking if you have any suggestions on where to look on Chrome's logs to find any indication that an issue has started or to understand more about why the issue is happening?
We have tested on Chrome/Edge/Firefox browsers, and the issue only happens in Chrome or Edge (Chromium based). We have tested on a wireless or wired connections and the issue shows in both cases. We have tested on Windows and macOS and it happens on both. We have also tested on a freshly rebooted computer with no other applications running, and the issue still shows. There is nothing interesting happening on CPU/Memory/Network utilization when the issue begins.
So i have the following problem.
Any time i click on a request to view the headers/payload/response
i receive a not responding window.
If i wait ~2 minutes it works.
So what i receive here is a developer tools not responsive status when working on local machine.
I tried to re-install chrome. Nothing changed.
Current Version is: Version 50.0.2661.102 m listed as up to date.
Is there any possibility to get some logs or did anyone faced the same problem?
I think it can be relevant if i show what extensions i have installed.
But i tried to enable/disable them and nothing changed.
And i get the same comportment in incognito mode too.
Later edit: I somehow identified the problem. Idea is that chrome is trying to display the cookie (request headers) which was 18k characters long and it looks like this is slowing a lot developer tools and sometimes make him crash.
I just saw that in Mozilla cookies are limited to a couple of characters (display perspective) and after that they show ...
I can't find any known issues regarding this crash, so here are a couple of steps you could take:
Use the Chrome Cleanup Tool and see if that helps.
Fully clean and re-install Chrome (including deleting user folders). If it works after that, you can slowly add extensions and plugins back and see if any reintroduce the problem.
We had to update our certificate for our ecommerce website recently and ever since we've noticed weird behavior in Firefox and other browsers. About half the computers in the office, as well as my home computer complain that the certificate chain is not complete (Very odd it's not universal). I can view the chain in the Firefox certificate viewer and see that it doesn't have a chain.
Meanwhile Chrome's chain looks fine. This leads me to believe that there isn't an issue with our install of the certificate, as there's a chain there to be read, but Firefox can't seem to see it.
I should note that it seems to have the same issue in Chrome on Android.
So is this our problem or Firefox's?
This is typically the case when the server does not send all necessary intermediate certificates. Chrome on Desktop will go and fetch them. Firefox will use any intermediate certificates cached from previous connections to other sites but will not fetch missing certificates, thus some Firefox instances might work while others not. Chrome on Android will also not fetch missing certificates.
The issue needs to be fixed on the server side. If you check the server at SSLLabs you will probably see a note regarding "chain issues". Add the necessary certificates (they are listed at the report) until you don't see this note any longer and then it should work with the other browsers too.
It looks like a WebSocket creation problem, which should not be happening with chrome.
I tested it with different browsers (including chrome) from different machines (same OS same NW config) and it was OK.
How is this even possible?
I was struggling with a similar issue with chrome and safari about 3 years ago.
In my case it was, at the end, an issue of WebSockets versions
Basically there were 2 main protocols of WebSockets: Hixi and Hybi, Hybi becoming the successor
You mentioned that with the same config one chrome browser works and one gives you that error. Can you please check the versions of Chrome on both scenarios?
I know its a long shot, but if the "broken" one is running a very old version, say bellow 14 from around 2011, according to the chrome version history - this just might be it
BTW, which server are you using?
test site http://socket.trailsandtribulations.net
firefox: v15 works fine. (however, if lots of traffic and slow net, firefox will frequently fail as well (quietly).)
chrome: previously worked, but v21 gets Error during WebSocket handshake: 'Connection' header value is not 'Upgrade'
however, if chrome is running locally, it works fine! it breaks on my client in Thailand and server in Germany. again, Firefox works correctly all the time, as did earlier versions of chrome.
using haproxy to split between websockets via node.js and html via nginx
has something changed that makes this solution not work?
haproxy.cfg now displays the test site link - that way it's always current.
It looks from your message that the error is reported by Chrome while initially I understood it was reported by the server when accessed by Chrome. I think that as a workaround, if you replace "option httpclose" with "option http-server-close", it could make the issue disappear. You also need to remove all "option forceclose". If there is only "option http-server-close", haproxy will not touch the Connection header in the response path, which should make the browser happy. However, you must keep in mind that there is still a bug where the error is displayed and that it should be reported to the software authors.
BTW, your timeouts are far too large, you'll end up with many dead connections at the end of the day, this does not make sense. If you use a recent enough haproxy, you can use "timeout tunnel" to set the WS timeout without having to deal with a large HTTP timeout. But even then, 1 day is far too large for TCP connections. Some of your users will be using smartphones where a TCP connection cannot live more than a few minutes before a handover happens.
firefox uses no-cache when requesting the websocket update; this version of chrome does not. see http://code.google.com/p/chromium/issues/detail?id=148908&thanks=148908&ts=1347523876
for some proxies evidently this is necessary
also, see https://github.com/sockjs/sockjs-node/pull/88 for related issue