[thayne]

Also, http/2 over cleartext is not very well supported by a lot of things. Which is probably a good thing when going over the open internet. But it means you have to deal with setting up certificates even if just developing locally, and makes it more difficult to use for IPC on a single host.

[mort96]

My preferred setup is to have an unencrypted service running on 127.0.0.1 (so not publicly available), and then have nginx in front to handle certificates. Lets me do all certificate stuff across all virtual hosts in one place. HTTP/2 makes this impossible due to its ridiculous TLS requirement, so I, and everyone who does it the way I do, must keep using HTTP/1.1 forever.

It's my belief that requiring TLS for HTTP/2 is what killed the protocol. It just causes too much friction during both development and deployment, for little to no (or negative) performance gain.

[simiones]

> My preferred setup is to have an unencrypted service running on 127.0.0.1 (so not publicly available),

Don't forget that JS from any webpage can access your 127.0.0.1 to various degrees. Depending on what types of requests exactly the server accepts, it may be somewhat unsafe for a machine with a browser.

[mort96]

Oh, that was for a server. So the process which serves e.g my pastebin (https://sr.ht/~mort/coffeepaste/) runs an unecrypted HTTP server on 127.0.0.1 on some high port, then an nginx reverse proxy handles HTTPS on port 443.

On a machine with a browser, local servers are dangerous, HTTPS or not.

[bpicolo]

A few years back it seemed the ecosystem had the tools needed for h2c (HTTP/2 minus TLS) to work out. Was able to get the proto service set up in Golang, and work with a couple different proxy options