A redirect itself is considered bad by some because it encourages relying on http in the first place (imagine always hitting a web site through http and expecting a redirect instead of going to https directly).

As soon as you do that, you are similarly prone to MITM attacks: on an insecure network, you hit an http site and it replaces the redirect with one to a https site that looks like the same domain but really isn't (with a valid cert for mbsonline.gov.au.foo.io).

For my personal sites, I prefer to go with no redirects and if it really processes data, https-only.

For users, the right solution isfor browsers to always attempt https first even if those could be technically serving entirely different content (that would be one hell of an anti-pattern though, so I wouldn't worry about it).

A permanent redirection before setting the correct headers is the best you can do at the server side.

Yes, the user is using insecure practices, and no, you can't correct it on your server.

I am arguing that the best you can do is not even have HTTP enabled.

A permanent redirect is the second best ;) And yeah, most practical for commercial entities (which is why I highlighted what I do for my personal sites).

No, you're actually less secure without HTTP. Scenario: someone figure out how to mitm your http traffic. You visit the page:

For the first time - you're affected either way.

For the second time - if you still have the permanent redirect cached, you avoid the mitm.

Disabling your own http only helps the attacker in specific situations.

My point is that you want to "educate" visitors to never use HTTP (eg. for their bookmarks and typing the URL in), which I hope is effectively achieved by not having HTTP web site even on a connection you trust (eg. your local network) — so if you succeeded in "educating" them at least for your web site, they are similarly protected when they come back, including from another device. If they only rely on their browsers caching the permanent redirect, they are protected for a short time on the same browser.

But ultimately, browsers have to default to HTTPS for a guaranteed "protection" from the start (whether that's through HSTS preload lists or simply by defaulting to HTTPS, does not matter much).

The best you can do is set HSTS and redirect from http to https.

You not serving http won't prevent a MITM from serving http to the victim.

There's a corner case where users who have never visited your domain (either ever or just on that browser) do so for the first time over a malicious connection. In this case, Mal sends them a page that looks reasonable, they create an account or login or whatever, Mal gets the password and probably proxies the requests to the origin domain (properly over https so even if the site operator redirects all pages to https, this still works) so that the user gets the email confirmation or whatever.

A tiny bit better is to submit your domain to https://hstspreload.org/ so that (major) browsers force https on the first connection. You should still set the HSTS header of course, it's a requirement for inclusion in the preload list and it should also catch people who have a browser from before your inclusion in the list or browsers that don't support the preload list at all.

You could also choose names whose parent domain is already HSTS pre-loaded. The .dev TLD is pre-loaded for example.

What happens if your browser (eg. new device, another browser, first visit) does not have a record of HSTS data for a domain, and you visit it by going to HTTP on an insecure network?

Can't they similarly serve HTTP data without any HSTS headers? Or do browsers also check HTTPS for any HSTS headers on the same IP and cross-compare?