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
Related
my server on jetty serves API.
Some requests return 200, but other requests to the same endpoint with different params return:
(failed)net::ERR_HTTP2_PROTOCOL_ERROR
It occurs only in Chrome. In FF it works well.
Do you know what could be the reason and how to fix it?
You should look at the Jetty server DEBUG logs for more information, or report them here for analysis.
One reason for these errors may be the fact that Jetty protects against these vulnerabilities using parameter jetty.http2.rateControl.maxEventsPerSecond which defaults at 20.
Different browsers send different frames to the server; in particular, Chrome sends many PRIORITY frames to the server and for pages with a large number of resources, the maxEventsPerSecond=20 threshold may be tripped.
You may want to configure this parameter to a higher value, say 50, and see if the error still happens.
If you are using Jetty embedded, you want to use code similar to this:
HTTP2ServerConnectionFactory http2 = ...;
http2.setRateControlFactory(endPoint -> new WindowRateControl.Factory(50));
When I had this error, I also thought it is only in Chrome - when I tried FF for couple of times, it seemed to work. But few more couple of times revealed that in FF is just same random as in Chrome.
There is some discussion here.
You might want to check if your Windows Update didn't pull KB5003637 which is suspected to cause this issue. My teammate did uninstall that patch and it fixed for him.
I have this 1 Mb file for testing purposes (though the issue applies to any file hosted at lptoronto.com): https://lptoronto.com/sandbox/test.png
It always loads instantly in Internet Explorer (both via http and https).
In Google Chrome (currently Version 63.0.3239.132 (Official Build) (64-bit) on Windows 10) the situation is as follows.
When fetched via http, this file loads instantly without an issue.
When fetched via https, the same file takes about 40 (!) seconds to load (with very rare and irregular exceptions, when it also loads fast via https on occasion).
Chrome network monitor shows that all that 40 seconds the image is being slowly but steadily downloaded at low speed, i.e. there is nothing like waiting for server response etc.
Here's the screencast showing IE and Chrome side-by-side loading the same image:
https://www.youtube.com/watch?v=M4cUuhG1YuM
From time to time the issue disappears for a few minutes or an hour, but then re-appears again, without me doing anything on my side.
Same behavior is observed on at least one other computer - the one of my colleague (different ISP, different location).
Needless to say that I'm testing in a clean environment - cache cleared, extensions, firewall, antivirus disabled, connection verified and measured etc.
No Chrome issue whatsoever with any other website, be it http or https.
Hosting provider is yet unable to troubleshoot on their end, but they're still trying to help (it takes some time). They tried disabling mod_deflate, re-installing SSL, disabling caching rules, but to no avail.
The same issue was once observed about 2 months ago. That time I asked the hosting provider to disable SSL completely just to be able to work on my website content. When they re-enabled SSL in less than a day, the issue has gone; but now it re-appeared again, and there is no clue as to what is going on.
The bottomline:
issue appears only in Chrome, only with certain site, only with https
changing only the browser solves the issue
changing only the protocol (https to http) solves the issue
I honestly tried to google out anything similar, but failed to.
I would appreciate if you try the link above in the incognito Chrome window and report the load/refresh time, and of course any ideas are more than welcome.
I'm trying to debug difference between HTTP/1.1 and HTTP/2.
Is there any possibility for disabling HTTP/2 in chrome or chromium?
I couldn't find this option flag in chrome 56. I have tried chromium 58 with flag --disable-http2:
./Chromium.app/Contents/MacOS/Chromium --disable-http2
But content is still delivered with HTTP/2 protocol after using this flag:
For what it is worth, the flag works.
The issue is that you need to quit EVERYTHING Chrome for it to take effect. Including plugin shims and other chrome tabs and so on.
It is not enough just to add the command line switch.
An easier way to achieve something broadly equivalent is to use an HTTP Proxy, like https://www.telerik.com/fiddler. This adds negligible additional time to your requests, and (as far as I know) doesn't support http/2 at all (yet); even if it did, I'm pretty sure it would be much easier/practical to switch behavior in than restarting all your Chrome windows.
The advantage of this approach is that it takes effect immediately - disabling and reenabling HTTP/2 becomes as easy as starting and stopping the proxy, without messing with the (if you're anything like me) dozens of Chrome tabs you have open, to StackOverflow and elsewhere :)
What happens when you try doing the same thing in WebPageTest (select Chrome as the test agent and add the command line switch in the Chrome tab under advanced settings)
Here's a test I did for my personal site just now and the flag appears to work OK (if you look at the response headers you'll see HTTP/1.1)
https://www.webpagetest.org/result/170322_1B_ab8656afcfb8bcc4103e9872ff56c28b/1/details/#waterfall_view_step1
I have seen the same problem created by a firewall running in proxy mode vs flow mode.
The firewall would buffer the entire file so it could scan it then pass it along vs scanning the individual packets.
https://docs.fortinet.com/document/fortigate/6.4.4/administration-guide/721410/inspection-modes
The problem would only happen when using http2 and might have something to do with http request priority not being handled properly or it forced it single threaded.
We would have a video request start with a low priority that would stall then start causing other file downloads to be delayed. Then there was a api poler in the background coming in with high priority requests. After a few high priority requests were blocked chrome would cancel the low priority video.
It would happen in other cases but the video made it very reproduceable for us.
https://medium.com/dev-channel/javascript-loading-priorities-in-chrome-57c54cfa6672
https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/
https://blog.cloudflare.com/http-2-prioritization-with-nginx/
https://calendar.perfplanet.com/2018/http2-prioritization/
We set it back to flow mode on the firewall and the problem went away.
Afterwards the downloads all happened in parallel with no blocking or stalling in the chrome network waterfall.
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
I have a weird problem with websockets and chrome (22.0.1229.79m) (I haven't coded authentication for other browsers yet so I cant test them). It seems like if I reload chrome 3 times, there will be a huge delay in connecting to my websocket server. The server is not delaying the connection, I tested this by connecting to it with another PC while chrome was delaying and it connected perfectly.
Is there anyway to fix this? This is a problem when I am switching servers receiving data. It will halt, and delay. This is really bad for user experience. I would assume this is strictly related to the chrome browser not closing the socket...
I have also seen this delay when creating multiple WebSocket connections from the same browser tab in Chrome within a short period of time. I believe this is to address a potential security issue with WebSockets which would allow a browser to be hijacked to do port scanning inside a network. By limiting the number of WebSocket connections that can happen within a given amount of time, you greatly limit the utility of a browser as a remote port scanner. In addition, the amount of information that is returned by onclose and onerror is intentionally limited for the same reasons.