caddy
caddy copied to clipboard
caddyserver
Serve http2 when listener wrapper doesn't return *tls.Conn
Thanks for working on this!
So, my understanding of this is, that it allows us to serve HTTP/2 even if the underlying Conn is wrapped by a ListenerWrapper plugin so that if it's not a tls.Conn, it can still be recognized as one?
Thanks for working on this!
So, my understanding of this is, that it allows us to serve HTTP/2 even if the underlying Conn is wrapped by a ListenerWrapper plugin so that if it's not a tls.Conn, it can still be recognized as one?
Yes, because golang http.server won't directly serve http2 when return non tls.Conn, I have to manually configure h2server. tls.Conn still uses http.Server code path, because when handshake is not complete, it won't have "h2" as negotiated protocol.
@mholt I noticed you don't allow serve only http2, if you want, I can use http2.Server.ServeConn in this case.
@WeidiDeng Yeah, we'd have to write our own HTTP server. I'm not sure I'm quite ready for that since it seems like a maintenance burden. You can see my attempt here: https://github.com/caddyserver/caddy/pull/4707#issuecomment-1204438638
I'll review this soon!
@mholt I looked at you code, that's because http2.Server requires tls handshake to be complete, if there is any. To be fair, http2.Server can serve h2c with prior knowledge, that's like how currently reverse_proxy h2c transport is implemented.
But yes I agree it's a burden, especially if we are allowing serve http2 with non tls.Conn. Perhaps it's easier to configure tls nextproto directly, normal clients won't send h1 requests on a h2 tls.Conn.
@WeidiDeng could you rebase this?
I'm not sure there's anything really blocking merging this. Seems like a reasonable fix for a usecase only used by caddy-l4 currently.
@francislavoie I'll also need to update l4 listener module, that part is left as a todo.
There are some parts that I'm not sure, like using x/net/http2 instead of builtin http2, should there be an option?