>Actual localhost traffic that never leaves your machine
Unless you run
ssh servera -L 8080:serverb:80
I sometimes do this if there's a firewalled serverb that I can't access that's running a webserver, and a non-firewalled servera that I have ssh access and can access serverb.
Then you can open http://localhost in your browser and talk to serverb. If you want HTTPS to work, then ideally you'll map serverb to 127.0.0.1 in your /etc/hosts so that its HTTPS certificate matches the host, or use --host-resolver-rules="MAP serverb 127.0.0.1" as a Chrome commandline flag. Of course then you're no longer using localhost in the host.
come on. by that point you are explaining something weird.
my question is this. if i set up nginx/apache2 on my local network to serve a webpage, or i have a plex server or something similar or say nextcloud or whatever people self host these days, why should i be forced to have https?
that data wont be leaving my subnet if at all anything more so whats the threat model for a local only service?
You don't need to enable HTTPS for those use cases. Your Plex and Nextcloud will work just fine.
If you configure your server to send a HSTS header, though, you're telling your browser to only trust HTTPS connections for that domain from then on. That's what's happening here, and that's something you just… shouldn't do, I guess? If I tell my browser to permanently redirect localhost to Google.com, there's no reason why I should be mad at my browser for listening to my perma redirect.
HTTP traffic is a bigger problem in huge, flat, corporate networks, running intranet services with routes spanning several locations. At any time a hacker could be listening in an exfiltrating company logins. Also think about the Snowden slides, where the NSA intercepted unencrypted traffic over Google's internal network. Local network encryption is essential in those use cases and relatively easy to set up.
That's not localhost. One threat model is some IoT device you have attached to your wifi gets hacked. Or your wifi has a weak password and it gets hacked. Or a guest that you let onto your wifi has a devices that's been hacked.
Unless you run
ssh servera -L 8080:serverb:80
I sometimes do this if there's a firewalled serverb that I can't access that's running a webserver, and a non-firewalled servera that I have ssh access and can access serverb.
Then you can open http://localhost in your browser and talk to serverb. If you want HTTPS to work, then ideally you'll map serverb to 127.0.0.1 in your /etc/hosts so that its HTTPS certificate matches the host, or use --host-resolver-rules="MAP serverb 127.0.0.1" as a Chrome commandline flag. Of course then you're no longer using localhost in the host.