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.
Related
Due to the too-strict filtering in Iran by its government, any proxy I've ever used has been blocked.
I used L2TP, IPSec, Shaddowsocks, V2ray (Vmess, Vless), and many VPN applications like StarVPN, X-VPN, HotspotShield and etc, but they've been blocked recently.
V2ray was working until yesterday, but today it has been blocked. I even changed the server and it's not still working.
I don't know how exactly the government blocks these protocols, but I think they are recognizable, so I'm looking for an unrecognizable proxy protocol. Do you have any suggestions?
Thanks in advance
In the past, websockets were not supported by all browsers and networks.
We were required to provide fallback solutions like HTTP Long Polling.
This situation appeared to change.
At least the browsers support looks great now: https://caniuse.com/#feat=websockets
I could not find any statistics about networks blocking websockets.
Do we have any data proving that there is still a justification for websocket fallback solutions?
Last year, I had an issue using Trello at work. While the page was initially shown, some changes were not reflecting on the page. I investigated using the Chrome debugger and found out that WebSockets connection was blocked (at least for that website).
After a few exchanges with IT, and some firewall black magic on their side, the issue was resolved and now Trello works fine.
So, in a few corporate environments, some WebSockets scenarios still need a fallback IMHO.
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 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.
I am working on a project where the user will transfer his username to activate the internet. I want to always redirect the user to the https version and make the http version redirect to the https aswell, so there is only an http version. Is this a smart move? Could there be problems with mobile devices (WiFi enabled devices)
Thomas
I don't think that there are many devices which don't support ssl. There are some stupidly configured proxies, though.
Most site aren't "complete ssl" because of server load, ssl can bring a server to its knees really fast.
If you're transmitting secure data, then it's definitely smart to to redirect to HTTPS. As a hacker, you'd immediately look for the easiest opening in a site. In this case, it would be attacking any devices that are excepted from the SSL rule.