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.
After updating to Google Chrome Version 63.0.3239.84 (Official Build) (64-bit), I'm seeing some strange behavior in one of my 302 redirects (shown below).
The cache-control headers are set to no-cache, must-revalidate, yet Chrome now randomly serves content from the disk cache.
Is this a new Chrome bug, or expected behavior?
Note - The request has been had some parts cut out because this is not a publicly accessible system. The URL, Remote IP, and CloudFlare Ray wouldn't provide any useful details unless you're on the white-list.
EDIT
A test URL can be found here:
https://v2.thinklikeamage.com/test302.php
This page will issue a 302 redirect with a no-cache, must-revalidate Cache-Control header.
Regards
It appears that now Google Chrome can store the result of 302 redirects within local disk cache if no-store is not specified.
Adding no-store to the Cache-Control header seems to prevent local disk caching.
-- alternatively --
The 'Use a prediction service to load pages more quickly' setting seems to be tied to this now as well. Switching off this feature seems to alleviate the original issue, but does little to help end-users that may be affected by it.
JetBrains IntelliJ IDEA sometimes loses its own JetBrains IDE Support plugin in Chrome. Upon debugging in IDEA, Chrome complains that:
hmhgeddbohgjknpmjagkdomcpobmllji is blocked
Requests to the server have been blocked by an extension
and stays on this page:
chrome-extension://hmhgeddbohgjknpmjagkdomcpobmllji/loading.html?__QUERY__
Where hmhgeddbohgjknpmjagkdomcpobmllji is JetBrains' plugin ID.
Instead of redirecting to the target page of the form:
http://localhost:63342/__PROJECT__/__PATH__/index.html
Restarting Google Chrome or disabling-and-enabling IDE Support plugin helps. IDEA "finds" Chrome again and Debug workflow works as intended.
Another possible problem is a failed authorization.
To debug a URL like this:
http://localhost:63342/__PROJECT__/__PATH__/index.html
Open it in the browser before starting to debug. It'll give 404 Not Found. Then switch back to IDEA and it will offer you to Copy authorization URL to clipboard:
http://localhost:63342/__PROJECT__/__PATH__/index.html?_ijt=__KEY__
Open this URL.
After this manual authentication is complete, IntelliJ IDEA should be able to debug index.html in Chrome.
IDEA always opens index.html for debugging in the browser window where the latest authentication happened. E.g., in a Chrome Incognito window, instead of a Chrome "normal" window, if you've just authorized IDEA in Incognito.
Going incognito may require an additional setup:
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206201319-launching-chrome-incognito-in-intellij-12
I am currently doing some debugging on my website which involves calling the facebook API.
I've installed dnsmasq to work with my mac os X to redirect all request to facebook.com to 127.0.0.1
I have a echo server which will print out all the raw http request header on port 80 on my laptop.
Now comes my problem. When I access facebook.com, I realize chrome will automatically forward http:// to https:// for facebook.com
I googled and found the way of deleting this HSTS issue. I visit chrome://net-internals#hsts to see something like this:
HSTS chrome image
After entering "facebook.com" under "Delete domain", I can still query "facebook.com" in the input box below.
I tried clearing all user data on chrome, closing and reopening chrome and even using incognito mode.
Why is chrome still redirecting all request to facebook.com to https?
How can I disable this if chrome://net-internals#hsts is not
reliable?
The text next to the Delete domain box on chrome://net-internals/#hsts clearly states that preloaded entries cannot be deleted. This feature request was closed as WontFix in the Chrome bug tracker.
facebook.com and quite a few of its subdomains are included in Chrome's preload list.
You could use another domain name for your tests.
Just make api-calls to facebook-api-test.com, map that domain to localhost and proxy the calls.
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.