Environment:
Ubuntu 18.04.6 Desktop 64-bit
Google Chrome 98.0.4758.80 (Official Build) (64-bit)
FireFox 92.0 (64-bit)
What I did:
Install apache2 (so it starts a default local website that I can access at http://localhost).
Edit /etc/hosts and add the following entries:
127.0.0.1 app
127.0.0.1 app2
127.0.0.1 napp
On Google Chrome, open the following URIs:
http://localhost: Successfully opened the "Apache2 Ubuntu Default Page" as an insecure domain.
http://app: Got redirected to https://app automatically and returned the error "This site can’t be reached"
http://app2: Same as http://localhost.
http://napp: Same as http://localhost.
On FireFox, open the following URIs:
http://localhost: Successfully opened the "Apache2 Ubuntu Default Page" as an insecure domain.
http://app: Same as http://localhost.
http://app2: Same as http://localhost.
http://napp: Same as http://localhost.
I searched on Google and saw posts that talk about the automatic redirect from http to https, such as How to Stop Chrome from Automatically Redirecting to https. I followed the posts by deleting the security policy for the domain app and clearing the browser cache of all the time, but I still got redirected from http://app to https://app. (In fact, I was using a freshly installed OS and Google Chrome and had never opened any websites before doing the test.)
Why does Google Chrome automatically redirect http://app to https://app but doesn't do that to http://app2 or http://napp?
I also learned that Chrome & Firefox now force .dev domains to HTTPS via preloaded HSTS and Google rolls out .app domains with built‑in HTTPS. So it looks like the browsers are using preloaded/builtin HSTS to enforce the use of HTTPS. But does http://app count as a case of .app domain?
I think it should be some browser settings because FireFox didn't do the redirection.
Simply put, Chrome uses a HSTS preload list to automatically redirect certain domains from HTTP to HTTPS. This preload list is "a list of sites that are hardcoded into Chrome as being HTTPS only." app is already included into this preload list, as shown by this link: "Status: app is currently preloaded." Therefore, when http://app is entered, Chrome automatically redirects it to https://app. But app2 and napp are not included, so http://app2 and http://napp are untouched.
I wrote the article Why does Google Chrome automatically redirect http://app to https://app but doesn't do that to http://app2 or http://napp? to explain this with more details and other related links.
All request comes on HTTPs and internally managed on HTTP. Everything works fine until it hits re-direct return "redirect:/link/somePage.htm";
The moment redirect is called, Chrome browser complains about insecure page and the message displayed is The information you’re about to submit is not secure. The same works fine on Firefox.
Of course redirect causes link to change from HTTPs to HTTP on Chrome. Where as Firefox has no issue.
Has anyone encountered this recently on above mentioned browsers or something underline has changed, which would mean deeper investigation.
Firefox - 81.0.2 & 83.0, Chrome - 87.0.4280.88
We searched for a solution all day long.
We found that we need to add the following headers:
For Appache server: RequestHeader set X-Forwarded-Proto https
For NGINX server: proxy_set_header X-Forwarded-Proto $scheme;
Another possible solution on NGINX with reverse proxy is to use the command :
proxy_redirect http:// https://;
Source : https://community.bitnami.com/t/ssl-https-connection-implemented-but-getting-error-while-accessing-some-pages/89877/4
We had this problem, reported to me on Monday (12/14/2020). It was reproduceable on Tuesday (12/15/2020). Today, Wednesday (12/16/2020) we do not get the warning from Chrome. No changes have been made to the site. However, accessing the site with lighthouse, does report the problem. Did something happen to change the detection or reporting?
After some experiments with PWA I've encountered a strange issue with Google Chrome only. Every other browser works just fine.
When I load http://localhost the response is: "This site can’t be reached"
The error status is: "ERR_FAILED" (404)
Note:
"ping localhost" returns 127.0.0.1 (as it should be).
wget -qO - 'http://localhost' loads the correct content in terminal.
every other browser loads the correct content.
the setting in /etc/hosts leads to 127.0.0.1
if I access the content via IP (127.0.0.1) it loads just fine.
I have cleared the browsing cache
the PWA cache seems to be clean.
The offline box in the network tab is not checked.
If anyone has any ideas on what could cause the issue please share.
The only clue I have is that in the sources tab of the code inspector
there's the content of sw.js (my service worker) but there's nothing to do with it.
I came out that the issue was caused by a cookie called ServiceWorker.
After deleting it everything works fine.
Similar to this question:
Chrome Doesn't Trust Fiddler Root Certificate
But the upvoted answer (https://stackoverflow.com/a/33818661/1250301) doesn't seem to be working for me in fiddler v 5.0.
If I load a site with https in chrome I get NET::ERR_CERT_AUTHORITY_INVALID message. If I "reset all certificates" under the HTTPS tab of the options dialog (as per the suggestion in the answer) then I no longer get the certificate errors in Chrome, but Fiddler will only intercept the "Tunnel to" requests and nothing else. If I close fiddler and restart it, then my certificate is no good again for some reason!
I'm trying to run a local node server, but for whatever reason localhost:3000 does not work. The error page states This webpage is not available ERR_CONNECTION_CLOSED However, 127.0.0.1:3000 does work. I have tried making changes to my hosts file, but to no avail. Does anyone have any idea what's causing the problem?
Chrome version is 46.0.2490.80 m
Here are the steps I took to make this work correctly:
Edited my hosts file so 127.0.0.1 localhost. was present, and saved the file
Cleared my Chrome cache, specifically cookies and cached files
Cleared host cache in chrome://net-internals/#dns
Restarted chrome
Alternatively, this also works:
Navigate to chrome://net-internals/#hsts
Under "Delete domain", type localhost and delete
Unbeknownst to me, my project had an HSTS middleware that set an HSTS cookie
For me (I had HTTP and HTTPs dev server on same port)
Chrome Dev tools F12
Application tab
Clear storage sub-tab
"Clear site data" button
I ran into a similar issue on my MacBook but none of the existing answers worked. I even tried the nuclear option and did a factory reset on my computer.
The issue turned out to be coming from the AirPlay receiver listening on Ports 5000 and 7000, which was creating the 403 error when I tried to serve something at localhost:5000.
The solution, as detailed here, was to uncheck AirPlay Receiver in System Preferences > Sharing
I solved my problem by:
opening the developer console F12
Going to network tab
Check Disable Cache
Browse locahost
What you can do is go to Chrome setting > Privacy and Settings > See all the cookies and site data, search for localhost and delete it. Then refresh your site it will be working.
Regards
if you're using a proxy there's a checkbox to bypass it for local addresses.
follow these steps.
open chrome
go to setting
Privacy and security
Clear browsing data
check cookies and other site data
click clear data.
I had same issue and I cleared cookies and cache and it worked
Go to Setting/clearBrowserData and just check all of history, cookies and cached files.
For me, Browse in Private (Ctrl + Shift + N) was enough.
Finally I have solved this problem
For those who have tried the clearing the cache from the browser and still facing the same issue follow these steps
search for live server(ctrl+shift+x) you will find a settings icon. click on Extension
settings
you can find Live server>Settings:Chrome Debugging Attachment click on edit in Settings.json
just add this (if there are multiple lines make sure to add comma[,])
"liveServer.settings.port": 0
Doing This It will randomly pick an opened port each time.