At least the developer tools (like pow, puma-dev) which do squat on *.dev will now be compelled to support “turnkey https” out of the box, or risk losing many of their users.
Well, since .dev is a real domain, what I actually suspect will happen is they’ll just switch to something else. Which, to be honest, I’d prefer: I’m all for HTTPS everywhere, but on localhost, when doing dev, it’s not worth it 99.9% of the time (and it robs me of tools like nc and tcpdump to casually help with certain issues).
It is not clear to me what is the reason Chrome will start enforcing this HTTPS redirect on .dev domains. Neither the article nor the referenced commit explains this.
Actually, it does: .dev is a legit domain ending (owned by Google, for what it’s worth), and so they’re just adding it to the preloaded HSTS via the normal mechanism. This honestly seems entirely rational to me.
I don’t think it’s that big of a deal. I agree with a comment on the post.
At least the developer tools (like pow, puma-dev) which do squat on *.dev will now be compelled to support “turnkey https” out of the box, or risk losing many of their users.
Or switch to some TLD that’s reserved, like
.testWell, since
.devis a real domain, what I actually suspect will happen is they’ll just switch to something else. Which, to be honest, I’d prefer: I’m all for HTTPS everywhere, but onlocalhost, when doing dev, it’s not worth it 99.9% of the time (and it robs me of tools likencandtcpdumpto casually help with certain issues).It is not clear to me what is the reason Chrome will start enforcing this HTTPS redirect on .dev domains. Neither the article nor the referenced commit explains this.
Actually, it does:
.devis a legit domain ending (owned by Google, for what it’s worth), and so they’re just adding it to the preloaded HSTS via the normal mechanism. This honestly seems entirely rational to me.