-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
quic: Don't delay TCP attempt when HTTP/3 status is unknown #37040
Conversation
Signed-off-by: Fredy Wijaya <fredyw@google.com>
/retest |
/assign @RyanTheOptimist |
// The first request could either be HTTP/2 or HTTP/3 because we no longer give HTTP/3 a head | ||
// start. | ||
ASSERT_GE(protocols.at(0), Http::Protocol::Http2); | ||
// TODO(fredyw): In EngFlow CI, HTTP/3 does not work and will use HTTP/2 instead. |
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.
Wow, that's interesting. Any idea why yet?
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 don't know yet. I pinged EngFlow in Slack. I suspect UDP is blocked or something even after setting https://docs.engflow.com/re/client/platform-options-reference.html#dockernetwork
Signed-off-by: Fredy Wijaya <fredyw@google.com>
Signed-off-by: Fredy Wijaya <fredyw@google.com>
/retest |
Commit Message: When HTTP/3 is not known to work, we should attempt both QUIC and TCP at the same time instead of giving QUIC a head start and delaying the TCP connection attempt.
Additional Description: In Envoy Mobile, the HTTP/3 status will be reset upon network change.
Risk Level: low (runtime guarded and the default is false)
Testing: unit and integration tests
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: quic, mobile
Optional Runtime guard:
envoy.reloadable_features.quic_no_tcp_delay
(default is false)