I have a website that supports HTTP2. If I use Firefox or Chrome in anonymous mode then all the calls are made with HTTP2 (shown as h2 in Chrome developer tools Network tab).
When I use ordinary Chrome though it does exactly the same call but uses HTTP1.1 for some reason. I have tried to turn of all extensions but it is still HTTP1.1.
Sometimes if I restart Chrome is starts using HTTP2 again but then falls back to HTTP 1.1 after a while or after one of the restarts. I cannot figure out what can be the problem and it looks very mysterious.
I did not change any settings explicitly in Chrome if they even exist. What can be the problem here?
P.S. I did "clear browser cache" and "clear browser cookies" and suddenly I got only http2, don't know how this ca affect protocol. This was a temporary improvement though and I got http1.1 after a while again
P.P.S. I have even got a case when loading a website that one request was http1.1 but the other one was http2 to exactly same server.
Related
I am trying to force Google Chrome to use QUIC as the underlying protocol instead of TCP.
I used this command to force QUIC through the command line, but it doesn't work:
chrome --disable-setuid-sandbox --enable-quic --origin-to-force-quic-on=IP:443 http://IP:443/
Wireshark shows me that Google Chrome is still using TCP for that destination.
BTW i am using google chrome Version 97.0.4692.71
Can anyone help me in that matter.
just trying to find a solution for chrome to use http3 without forcing it to, does not work for my local nginx-quic setup, firefox works out of the box... Just found your question. If i remember correctly you can only pass a single domain with that flag to chrome. This works for me:
--origin-to-force-quic-on=mylocaldomain.local:443
I have created several virtual hosts for my development processes. They were working just fine till yesterday. But in my chrome app, today they stopped working. Chrome shows: NET::ERR_CERT_AUTHORITY_INVALID
All my vhosts end with .dev. I changed one .dev to .work and its again working. But I can not do this for all vhosts as there are too many of them. What do I do?
PS:
They are working fine in firefox.
The error remains same in chrome incognito mode.
I tried clearing cache and hard reload, deleted my history and cache, restarting chrome even windows multiple time, nothing works.
In one solution, I found an exception can be included in chrome://net-internals/#hsts. I tried deleting domain in there but somehow it still appears in Query Domain search.
Chrome have switched the .dev sub domain to HTTPS only.
They have done this by turning on HSTS for this top level domain, but by preloading this in the Chrome code rather than sending the HSTS header. This means it cannot be switched off in the chrome://net-internals/#hsts screen.
More info:
https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
So you’re only options are:
Update you’re vhosts to a different TLD (e.g. .test). And yes this might be painful because you have so many.
Move to HTTPS by creating a certificate and updating your URLs. A self signed certificate that you can create yourself will do, however note that HSTS not only blocks accessing the site over plaintext HTTP, but also prevents you clicking through certificate errors. So you’ll need to manually accept any certificate to your trust store before it can be used.
The chrome team have been pushing HTTPS more and more and certain features are now HTTPS-only so even dev envs will need it now. So maybe it’s finally time take the effort to make the switch.
I am currently experiencing an error everytime I use my Microsoft Edge. Whenever I try to go to a site, I always end up with this error. The weird thing is, this issue only happens on certain websites (such as Facebook and Yahoo currently) and sometimes with Google. It likes to disconnect me often and I really don't want to have to deal with this issue anymore.
My internet works fine as my laptop (which I'm currently on) and phone can connect to it without issue. I don't know why it doesn't work on my desktop especially since its internet is Ethernet.
I tested this on other browsers to see if it was only on Edge but it turns out that chrome and firefox experience the same issue with different sites as well. For all three, I haven't been able to go on Facebook and Yahoo, and sometimes Google.
I know the problem is from my end because clearly, the sites are up. Is there any way to solve this or has anyone else found a solution to this?
I'm running Windows 10.
I've tried the following:
ipconfig / flush
ipconfig / reset
ipconfig / release
ipconfig / renew
clearing caches and browsing history
a full scan for malware using malwarebytes and windows defender, already removed/quarantined all threats, did this multiple times to ensure there were none left
reinstallation of chrome and firefox and a reset of edge
ipv4 - changing preferred and alternate dns address to 8.8.8.8 and 8.8.8.4 respectively
checked to see if a proxy was up, no proxy
If I were to do a factory reset, would this solve the issue?
To narrow it down a bit, can you confirm that you only get this when navigating to the sites listed and they're using SSL / HTTPS? Some will auto re-direct to HTTPS if you go to their non-SSL equivalent, but it's worth trying this on sites like Google which do support both.
If this does help narrow down the behaviour, then I've seen this behaviour once before, but this was behind a corporate proxy which didn't support SSL SPDY.
You can try disabling SPDY support, but there is likely to be an underlying issue (perhaps anti-virus acting as a proxy?).
To test disabling SPDY:
Internet Explorer 11
In the browser, select Tools > Internet Options > Advanced > HTTP
Settings and clear the Use SPDY/3 option.
Firefox
In the browser, enter about:config in the address bar and press
Enter. Confirm the security warning. Type
network.http.spdy.enabled in the Search field. For all the entries, set the Value to false.
Chrome
Use a switch to disable SPDY for Chrome. Edit the shortcut for Chrome
and add the following switch at the end of the Target path:
--use-spdy=off
For example, if Chrome's default shortcut link is pointing to
"C:\Program Files\Google\Chrome\Application\chrome.exe", change it to
"C:\Program Files\Google\Chrome\Application\chrome.exe" –use-spdy=off.
Source:-
http://bluecoat.force.com/knowledgebase/articles/Solution/HowtodisableSPDYprotocolsupportinbrowsers
I had a caller who was getting the "can't load page" error in Chrome only when logging into the AMEX site. Every other browser worked. The fix was to disable some weird experimental Chrome setting that is on by default. Go to chrome://flags, search for "experimental quic protocol" and "Disable" it.
Source
Click on start/control pane/IE options/Privacy Tab/Sites
Look at list of sites to see if any Google sites are blocked.
We have a web application that runs within a VPN. It has a self signed cert on it and is accessed through the server's IP address.
Part of the functionality of this app are some legacy Java apps (that no longer run in Chrome). Our initial work around for our Chrome users was to run Shell In A Box within an iframe of the web app to run those. All was good until the latest version of Chrome, v45.
What we’re seeing is that appears to be blocking the iframed content (maybe because of the self-signed cert?). If we grab the ShellinABox URL and drop it in a new tab, it works as it used to in the iframe. If we go back to the iframe, it now works. If we close Chrome and open it back up, it still works.
I should also note that we tried the canary builds as well. It's up to v47.x and we still see the same behavior there. We were reading through some of the Chrome group/bug lists and saw some reports that were similar but the "fixes" supposedly going through canary still didn't resolve it.
So, it appears that an exception is being logged somewhere. Does anyone have an explanation for this behavior and is there a way to set this exception without jumping through those hoops?
It turned out it was due to a permissions issue with ShellInABox that didn't reveal itself until v45 of Chrome, for some odd reason.
I have an existing site that works fine over http and https (SSL). The SSL certificate is valid and can be confirmed by inspecting in the browser.
I am starting to use a manifest file to enable the HTML5 application cache on my website. This is useful for making the page load faster, and eventually for offline capabilities. This is working great when using a regular http connection. The problems happens when accessing the site over https (SSL). When I do this, I can access my website's content just fine, and the URL says "https" however I see the following behavior:
Safari: It displays the lock icon, but when I click the lock icon to inspect the certificate, it says that the certificate is invalid.
Firefox: Does not display the colored address bar indicating encryption, and when inspecting the certificate, it says that there is no certificate.
Chrome and Opera: Correctly displays the secure nature of the URL, and when clicking the lock icon it displays the SSL certificate information. Yes!
I understand that using the application cache causes resources to be served locally from the browser, and as such there is no encryption happening, however customers don't necessarily know that there is an application cache happening in the background, and they are expecting to see a valid SSL certificate and indications that the connection is secure. Safari and Firefox appear to be doing this incorrectly, unless I am missing something. That is my question. Does anyone know how to get Safari and Firefox to display the SSL certificate for pages served from the application cache? Is there something special that you need to do, or is it a Safari and Firefox bug?
I believe someone has discussed this with me before. Please let me know if this helps.
Change all of your script and css references from
http:// or https:// to //.
If you haven't any then it is moot, but if you do, please let me know if that has an effect.
I believe this may be related to not being able to verify the references from a cached page.
Based on the history of vulnerabilities, I'd guess this may have been overlooked for the sake of fixing more critical issues. That said, I think this should be reported to both vendors now that some of the glaring vulnerabilities have been patched. Have you tested this with the latest releases of Firefox and Safari?
Did you serve the application manifest over SSL?