_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) Using HTTP/2 Cleartext for a server in Go 1.24
ssfak wrote 17 hours 38 min ago:
Related:
(HTM) [1]: https://http1mustdie.com/
LtWorf wrote 9 hours 26 min ago:
Except you can do http1 requests in bash easily and many http3
libraries are bad anyway so you don't get the advantages of using it.
I wanted to do something fast using http3 but it ended up being way
faster using ad-hoc code I wrote using http1. It would be even faster
if I did it with http3 but hand writing for that protocol is a
nightmare so here we areâ¦
edit: downvoting me will not change the reality.
tenuousemphasis wrote 5 hours 27 min ago:
Ok, none of that makes HTTP/1.1 any more secure.
superkuh wrote 1 day ago:
This is excellent news for human persons. Protocol implementations that
only allow TLS are not very robust without human maintenence for more
than a few years. That said, the human person use cases for HTTP/2 are
pretty limited. Generally HTTP/1.1 is a better choice.
miladyincontrol wrote 1 day ago:
I'd much rather http2/3 with an expired cert over cleartext anyday.
LtWorf wrote 9 hours 24 min ago:
Could I interest you in installing my root certificate on your
machine?
xyzzy_plugh wrote 1 day ago:
Has HTTP/2 performance improved as of Go 1.24? Last I checked forcing
HTTP/1.1 everywhere was a massive improvement in throughout and latency
for a very busy distributed system.
jeffbee wrote 1 day ago:
It has a bit, but there are fundamental issues. Given the way the Go
runtime wants to deal with reading and writing sockets, HTTP/2
requires 2 extra goroutines per connection, and the bouncing around
over channels that this implies. This might not be a law of physics
but there isn't another obvious way to do it in Go.
In the past when I wanted a really fast Go service using HTTP/2 I put
the HTTP server in a C++ subprocess that handled the sockets and
communicated with the Go application over a pipe. That was nice and
fast, avoided the congestive collapse that Go suffers with too many
runnable goroutines.
tgv wrote 23 hours 49 min ago:
Any idea at what point that happens, or how much too
many is?
mdavidn wrote 1 day ago:
Note that AWS ALB does not support h2c. When the client and server do,
ALB will dutifully forward the h2c header and fail to handle the
upgraded response.
latchkey wrote 1 day ago:
I love that anyone can write a blog post like this that will get
slurped into all the models and we can just say: "use terraform to
deploy H2C on GCR"... and it will know exactly what to do.
Npovview wrote 17 hours 45 min ago:
To use a Analogy, AI is acting like pip install library in this case.
Do you really want to do performative acts of Sisyphus or are more
interested in end result?
gear54rus wrote 21 hours 47 min ago:
which would be pretend doing it, make 1000 mistakes then say "you're
absolutely right" after you point to it's fuckups
nickcw wrote 1 day ago:
I just merged a commit for exactly this in rclone [1] It is interesting
to dig into why.
There was a security vulnerability in golang.org/x/net/http2/h2c which
meant govulncheck warned about it in the CI.
So I updated it and got a warning from the linter that the h2c sub
package was deprecated in the latest version, so I removed it.
That is a lot of great tooling working to make things more secure in
the Go ecosystem.
It does make work for maintainers though, and the Cambrian explosion of
AI discovered security vulnerabilities has been particularly trying!
(HTM) [1]: https://github.com/rclone/rclone/commit/ad8a108453f3ce983fb6c3...
(DIR) <- back to front page