I have a site, that runs on a Nginx 1.10.0 on Ubuntu 16.04 server (OpenSSL 1.0.2h). I want to serve this site over HTTP/2, so I configured Nginx accordingly:
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server
And it works fine in FF 47 and Chrome 51 on my office Ubuntu 15.10 desktop and in the same browsers on my home Ubuntu 15.10 desktop.
However on my home Windows 10 desktop and laptop HTTP/2 works only in FF. Chrome 51, IE 11 and Edge are using HTTP/1.1 on this site.
So, I'm baffled. This service says, that my site supports HTTP/2 and ALPN (which is required for HTTP/2 to work in Chrome since version 51).
Chrome versions and capabilities are exactly the same:
HTTPS works, and Security panel in Chrome Dev Tools shows, that everything is secured.
This demo in Chrome, IE and Edge displays message "This browser is not HTTP/2 enabled.", and "Your browser supports HTTP/2!" in FF.
But HTTP/2 on medium.com works just fine in all of this browsers.
So, my question is: what's going on and how to fix this?
Are you using antivirus software (e.g. Avast) and is it inspecting your HTTPS traffic?
It does this by acting like a MITM so you connect it it and it connects to the real website. And if they only support http/1 (which as far as I know they only do) then that would explain this. Though oddly not for for Medium unless you have an exception for this.
Should be easy enough to check by looking at the HTTPS cert when visiting the site to see if it was "issued" by your local Avast server.
If not that then suggest you look at your ciphers as HTTP/2 is picky about which ones it uses. Anything weird showing on https://www.ssllabs.com/servertest for your site? What cipher is it using for Chrome?
Related
My websites are https and my hosting company says my server is http2 enabled and functioning correctly. However, when I check my sites they are always utilizing the http1.1 protocol. I have contacted tech support and they say http2 is working and even sent me a screen shot to prove it.
I have tested both of my computers via my home internet and my mobile hotspot on both Firefox and Chrome. I have also tested with my ESET antivirus disabled. It always shows http1.1 via the Network Tab Protocol Column. I also have some site testing tools tell me http2 is function and others say that http2 isn't functioning.
I am looking for a cause-solution and my hosting provider is giving me nothing to work with. They almost act as if they have something to hide.
I am on a shared hosting plan. Apache Version 2.4.33. Anyone have any thoughts?
Additional Details:
I checked 3 http/2 site checking tools and all 3 said my server/website supports http/2. In addition to Chrome and Firefox Network tabs showing http/1.1, Chrome lighthouse(via DevTools > Audits Tab) says my site is not utilizing http/2.
Via Hosting Tech Support:
There is no load balancer, prefork MPM, and nothing in front of server.
Via https://www.ssllabs.com/ssltest
ALPN = Yes (h2 http/1.1)
Cipher = This server accepts RC4 cipher, but only with older protocols
Site URL:
https://spinerealignment.com
I have a very strange problem.
I've tried to test HTTP/2 with Chrome using this URL : https://http2.akamai.com/demo
It tells me that the browser doesn't have HTTP/2 enabled but it's activated by default in last version of Chrome.
I've tested with Firefox and I have the same problem.
That's weird because it works with Chrome on Mobile ...
Does anyone have a clue ?
Thanks for your help
You are likely not connecting directly to the server and have either a proxy (if at a company computer) or anti-virus software which is downgrading your connection.
For the latter you can normally disable HTTPS traffic sniffing to avoid this. Of course that loses the protection of that traffic sniffing though some say the intercepting it does for HTTPS traffic sniffing causes more harm than it solves and a well patched computer should not need this.
I have an old VB app that uses the Microsoft Internet Transfer Control (or Inet) to read info from a web page over HTTPS. It is installed on a number of Windows 10 machines and it works fine on all of them except for one. On this machine, when the call is made over HTTPS, the response comes back blank. The request never makes it to the web server because there is no entry for it in the IIS logs. Calls over HTTP to the same URL work just fine, only the HTTPS call has this problem.
I suspect the problem is with TLS 1.0. That protocol is disabled on the web server. I'm aware that older browsers, including old versions of IE, require TLS 1.0. Is there a setting that controls whether Inet can support TLS 1.1+? I did check Internet Options and "Use TLS 1.1" and "Use TLS 1.2" are already checked, so maybe these settings don't apply to Inet and I need to look elsewhere. Or is the problem something else?
Here is the code that uses Inet to make the HTTPS call. It's pretty straightforward.
response = Inet1.OpenURL("https://my_site/some_page")
' response is blank
I had the same issue. Experimenting with internet properties I found that unchecking "Use HTTP 1.1", leave "HTTP 1.1 through proxy connections" checked, fixes the problem. Have to close your program and restart it if you make the change while it's running. Don't have to reboot your PC. Hope this helps
if you disabled the TLS 1.0 in the WebServer then it will not work in the machines those are supported till TLS 1.0.
VB browser uses IE7 by default. If the HTTPS link works on the machine regular browser then you need to check for document mode settings otherwise you need to enable TLS 1.0 in the webserver.
So I just upgraded to nginx 1.9.5 which supports HTTP2.
I replaced all listen spdy by listen http2, removed spdy_headers_comp directive and also removed add_header Alternate-Protocol 443:npn-spdy/3;
Then I opened my site in Firefox, opened network monitor, and voila: Version: HTTP/2.0
But how does Firefox know my site supports HTTP2? Does it always first try to connect via HTTP2 before trying HTTP1.1?
HTTP/2 sites are deployed over TLS.
Browsers use a TLS extension called ALPN to tell the server what protocols they can speak.
Browsers always send this TLS extension, and always include both HTTP/2 and HTTP/1.1 (and may also include the old SPDY protocol).
The server receives the list of protocols that browsers can speak, and if the server supports HTTP/2 (and if a number of other conditions are met - in particular regarding the TLS protocol version and the cipher suite), the server decides to speak HTTP/2 with the browser, and sends the chosen protocol back to the browser, again using the ALPN extension.
If the server does not support HTTP/2 then it will send to the browser that it can only speak HTTP/1.1 via the ALPN extension.
If the server does not support the ALPN extension, then it will not send it to the browser, and the browser will default to speak HTTP/1.1 to that server.
I wanna create a connection between my mobile Safari and nodejs + socket.io on my Macbook.
When i call localhost:8080 from my laptop, everything works fine. The console says that the client is connected and my little website is displayed.
When i call it over my mobile browser with 10.0.1.5:8080, the website is displayed as well, but my socket.io don't identify the mobile browser (iPhone) as client and nothing happens on the console board.
Does anybody where the problem is?
I found this post on SO, probably can help you out. why does my nodejs socket.io app not work on ios6
Localhost is local to the machine. You're IP should use a ip address
or domain name:
something like: io.connect('192.168.1.110'); or
io.connect('test.myapp.com');
WebSockets do not work over cellular network as they are not forwarded by the http proxy.
A possible workaround it to set the WebSocket server port to 443 (https) which forwards everything (as https is encrypted the proxy has to forward it in order to support https).
To see a real world example which solves this problem this way checkout nearby.
Remember this requires using two http servers:
Serving you mobile application (on port 80)
Serving the web sockets on (port 443)
Else you always have to use the specific ports in your urls which is mostly not preferred in production.