-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add --http3 flag to buf curl #3127
Conversation
go.mod
Outdated
@@ -1,6 +1,8 @@ | |||
module github.com/bufbuild/buf | |||
|
|||
go 1.20 | |||
go 1.21 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like adding the github.com/quic-go/quic-go
dependency bumped this up. I'm unsure why. If it's a problem I can look into this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a problem for a few more weeks - we need to keep compat back for three versions for our enterprise customers who install from source. Can either try to fix now, or just hold off trying to merge this until 1.23 is released - up to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can just wait. There's absolutely no rush for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty reasonable to me, defering to @jhump for a further review.
As it is now, we're blocked on Go 1.23 being released, as we need to support the previous three versions of Go, see comment on PR. This PR either needs to be 1.20-compatible, or we can just wait a few weeks - up to you @sudorandom.
Note: blocked on Golang v1.23.0 and #3123 being merged. |
Would also be good to see quic-go/quic-go#4581 merged first. But it's not really a blocker (if quic-go project proves too slow to accept that patch, we can proceed here without i). |
@sudorandom can you merge in main so we can check this out? |
@bufdev I've rebased, so let me know what you think! |
ab78e8d
to
c88d49f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Just a couple of minor remarks.
@@ -38,6 +38,8 @@ type TLSSettings struct { | |||
// "h2", and exclude "http/1.1". If the server does not pick a | |||
// protocol, "h2" is assumed as the default. | |||
HTTP2PriorKnowledge bool | |||
|
|||
HTTP3 bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: doc comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment!
if f.HTTP3 { | ||
return makeHTTP3Client(f, bufcurl.GetAuthority(host, requestHeaders), container.VerbosePrinter()) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe instead have rename makeHTTPClient
-> makeHTTPRoundTripper
, and have it delegate to makeHTTP3RoundTripper
internally. Then you can factor the two calls to bufcurl.NewVerboseHTTPClient
into a single call right here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe I've implemented your suggestion. I agree, it looks a bit better!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
This PR adds a new flag to buf curl,
--http3
which forcesbuf curl
to use HTTP/3 as the transport. There's no open issue for this that I can find to reference.A couple notes:
net/http
, some of this code can be removed.--insecure
and--http3
{"code": "internal", "message": "protocol error: no Grpc-Status trailer: unexpected EOF"}
since quic-go does not yet support HTTP Trailers.--http3
and--unix-socket
Alt-Srv
. This PR does nothing with this, I just figured it's interesting to note that HTTP/3 "discovery" is possible without just trying and hoping it works.Here's an example of using this against the demo.connectrpc endpoint (which, yes! does work with HTTP/3 already thanks to Google's load balancer)