4 ms·

Yep, it's really disappointing they didn't decide to support it for localhost.

imdadadani 2y ago
I think the reason why they have decided to not support it over plain text is because they would have to detect if the server answers with HTTP/2 or HTTP/1.1, which could be complicated. This is not needed when using TLS since ALPN is used instead
- jrockway 2y ago
  This is meh excuse. If you want your browser to connect to a gopher server, you type gopher://example.com. If you want to use http2, http2://example.com should work. (I know, I know, everyone removed Gopher support a few years ago. Same idea though.) Having said all that, I just copied the certs out of here https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/net/http/internal/testcert/testcert.go https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/... and use them to do browser/http2 stuff locally. Why steal Go's certificates? Because it took 1 second less than making my own!
  - taftster 2y ago
    Hey, thanks for this. It saves me even more than 1 second!
  - e12e 2y ago
    Which browsers/libraries trust these? Or does the go tool chain install them?
    - jrockway 2y ago
      Nothing trusts them, they're just regular self-signed certificates. There is no benefit to using these over your own self-signed certificates except that you don't have to ask your LLM for the commands to generate them ;)
      - e12e 2y ago
        And of course once you trust them on localhost, you expose yourself to some risk, since the whole world can get a copy of the key.
  - johannes1234321 2y ago
    Using http2 as protocol in the URL makes the initial transition complex: One can't share links between different users and clients and from other websites with a guarantee of the "best" experience for the user. Not to mention all old links outside the control of the server operator.
- zinekeller 2y ago
  No, that's rather easy for up-to-date browsers. The real reason is that dumb middle proxies might cache/mangle HTTP/2 requests to the point that it simply fails hard, but encryption makes those concerns go away. Yes, there are proxies that can decrypt TLS, but due to how negotiation of HTTP/2 works in TLS (ALPN), dumb proxies will simply not send the signals that it's HTTP/2 capable.

I think the reason why they have decided to not support it over plain text is because they would have to detect if the server answers with HTTP/2 or HTTP/1.1, which could be complicated. This is not needed when using TLS since ALPN is used instead

jrockway 2y ago
This is meh excuse. If you want your browser to connect to a gopher server, you type gopher://example.com. If you want to use http2, http2://example.com should work. (I know, I know, everyone removed Gopher support a few years ago. Same idea though.) Having said all that, I just copied the certs out of here https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/net/http/internal/testcert/testcert.go https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/... and use them to do browser/http2 stuff locally. Why steal Go's certificates? Because it took 1 second less than making my own!
- taftster 2y ago
  Hey, thanks for this. It saves me even more than 1 second!
- e12e 2y ago
  Which browsers/libraries trust these? Or does the go tool chain install them?
  - jrockway 2y ago
    Nothing trusts them, they're just regular self-signed certificates. There is no benefit to using these over your own self-signed certificates except that you don't have to ask your LLM for the commands to generate them ;)
    - e12e 2y ago
      And of course once you trust them on localhost, you expose yourself to some risk, since the whole world can get a copy of the key.
- johannes1234321 2y ago
  Using http2 as protocol in the URL makes the initial transition complex: One can't share links between different users and clients and from other websites with a guarantee of the "best" experience for the user. Not to mention all old links outside the control of the server operator.
zinekeller 2y ago
No, that's rather easy for up-to-date browsers. The real reason is that dumb middle proxies might cache/mangle HTTP/2 requests to the point that it simply fails hard, but encryption makes those concerns go away. Yes, there are proxies that can decrypt TLS, but due to how negotiation of HTTP/2 works in TLS (ALPN), dumb proxies will simply not send the signals that it's HTTP/2 capable.