I've got a local Apache server running for web development on my Mac running 10.14 Mojave. I've followed this rather excellent guide to set up a local vhost setup aliasing all .dev sites to my local server so I can access my example site at example.dev.
This used to work just fine. Since I've upgraded OSX to Mojave, I can no longer access these sites via Chrome or Firefox. I try to access http://example.dev and instead loading the site, the browser instantly redirects to https://example.dev (note the s!) and it tells me the server refused to connect.
For fun, I tried using curl to see if the sites would load there- (they do!). I've also tried loading the sites in Safari (they do!).
So what seems to be going on is that Chrome and Firefox are getting a 307 redirect from http to https, but Safari is not.
I've checked my Apache httpd.conf (and the files it imports) and I can't find anything about redirecting.
Clearing the cache or using an incognito window does not change anything.
Does anyone have any insight into what could be going on here? I've checked my httpd.conf files and I'm not seeing anything that would be causing this- and the fact that it's affecting certain browsers but not others is really strange.
I found the solution: The .dev TLD was recently defined, and Chrome and Firefox now require it to use HTTPS. Turns out the guide I was working off of was even updated to reference this:
Previous versions of this tutorial used .dev as a local TLD but .dev
has been registered for use by Google and forced by Chrome to use SSL,
so it is no longer an option for local development. The .test TLD is
now reserved for development use. You can also use .localhost or
.example. You can even make up your own as long as it’s not a real TLD
in use.
Related
So I have a rails multi-tenant project running on Heroku where we identify what to serve based on the domain you access from. These domains are added to the app's heroku domains and the cname records provided by Heroku for www.domain.com are added to the domain's DNS and we also add a permanant redirect rule for domain.com/* -> www.domain.com/$1 so that people can access without a www.
This all works perfectly fine on Chrome/Firefox, but on Safari and IOS devices we've been getting reports and were able to reproduce that the websites simply timeout.
I have tried to monitor traffic with wireshark, I can see the GET HTTP request going out but nothing comes back.
I have tried to access the app directly using the appname.herokuapp.com URL, it works perfectly fine in that case.
I have tried accessing with a VPN (Cloudflare WARP), the issue is not present in this case. However I tried manually setting the DNS to Cloudflare's and that did not fix the issue. I have also tried 3 different ISPs and that was also not the issue.
So to sum up, the issue happens if:
You're accessing using a domain that POINTS TO a CNAME record (xxx.herokudns.com) that POINTS TO the app.
You're not using a VPN/Cloudflare WARP.
You're on Safari.
I have found a reference for this issue here but this dates back to 2015. I also have doubts that this Safari update could be relevant.
Has anyone been through this previously or can provide insights on to how I can further debug this?
I never had problems with multiple Virtualhosts on Apache, not on Windows nor BSD.
My secondary virtualhost gives me ERR_CONNECTION_REFUSED in Chrome.
"httpd -S" gives me no errors and a good config, this got me thinking, so I tried "curl -v", which was successful, then I tried IE and EDGE and they are working fine.
I tried to empty Chrome DNS cache, there are no Apache logs for the connections made from Chrome or FF, but there are log entries from 'localhost' and that's accessible from all and produces the logs from all browsers.
I'm kind of curious now, what is this?
Okay, I forgot to mention: I used .dev for tld on my virtualhost, and I won't do it anymore. Here is why:
Chrome 63 (out since December 2017), will force all domains ending on .dev (and .foo) to be redirected to HTTPS via a preloaded HTTP Strict Transport Security (HSTS) header.
Update 07/02/2018: Firefox now also forces .DEV domains to HTTPS.
https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
Conclusion: If you configure your .dev domain for ssl then there is no way to make an exception (firefox or chrome). So no more dev domains for local development, for me at least.
I have recently hosted my site which intends to use wildcard subdomains in its general use. A user would go to account.website.com to access their part of the site. The site is a rails app hosted on heroku and domain is through 123-reg. DNS is set up as per heroku - * , cname , wildcard.app.heroku...
At first i thought 123-reg couldnt handle wildcard routing and i would have to change dns provider as whenever i go to account.website.com it will send me to www.account.website.com which is extremely irritating, but then i found that this does not happen on my windows machine, only on my dev machine (macbook pro). In both cases i am using Chrome. Firefox works as desired, only chrome is messing up.
Any insight into why this is happening would be fantastic.
Thanks
Obviously i immediately solve it after asking and look like a fool - Apparently the cache remembers the redirect from when i assume i hadnt yet set up dns correctly. If you get the same problem, clear browser cache
I have bought my domain from one domain registrar and set domain forwarding to where my website is hosted. Now I have setup my website on amazon cloud and did all changes as described and changed DNS changes from my domain registrar.
Everything works good from IE and even from inbuilt browser of Eclipse. But Firefox is still taking to the site where site was hosted earlier.
what is the reason and how to resolve? I have cleared the cache related to website.
Perhaps these links may be of help:
Firefox invalidate dns cache
http://en.kioskea.net/faq/555-disabling-the-dns-cache-in-mozilla-firefox
When I rewrite HTML source of https page with Opera I got error:
linked script not loaded with http://localhost:4444/index.js.
When I use http://mypage/index.js everything goes right.
Putting any of links directly as address works just the same.
The most mysterious about this is, that it worked few hours ago and opera started to refuse localhost connection after computer restart.
I already tried to reinstall Opera and put localhost as trusted. No firewall active.
I just DONT UNDERSTAND :(
Thanks for any help.
opera:config#Network|AllowCrossNetworkNavigation might help, but this is almost certainly the block for cross network communication. It's a security feature.