http3: add a RoundTripOpt to check the server's SETTINGS frame #4355
Conversation
For some requests, the client is required to check the server's HTTP/3 SETTINGS. For example, a client is only allowed to send HTTP/3 datagrams if the server explicitly enabled support. SETTINGS are sent asynchronously on a control stream (usually the first unidirectional stream). This means that the SETTINGS might not be available at the beginning of the connection. This is not expected to be the common case, since the server can send the SETTINGS in 0.5-RTT data, but we have to be able to deal with arbitrary delays. For WebTransport, there are even more SETTINGS values that the client needs to check. By making CheckSettings a callback on the RoundTripOpt, this entire validation logic can live at the WebTransport layer.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4355 +/- ##
==========================================
+ Coverage 84.81% 84.86% +0.04%
==========================================
Files 150 150
Lines 14287 14303 +16
==========================================
+ Hits 12117 12137 +20
+ Misses 1671 1667 -4
Partials 499 499 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
This API is pretty good. I don't see any shortcomings really except the 1 thing you mentioned that some future changes might require the quic connection state too.
As a quality of life improvement we can include the settings check for Extended Connect in the RoundTripOpt implementation.
Individual protocols can check their individual settings like webtranport checks webtransport_max_sessions.
| // Support for HTTP/3 datagrams (RFC 9297) | ||
| EnableDatagram bool | ||
| // Extended CONNECT, RFC 9220 | ||
| EnableExtendedConnect bool | ||
| // Other settings, defined by the application |
There was a problem hiding this comment.
Why are EnableDatagram and EnableExtendedConnect treated separately?
There was a problem hiding this comment.
What do you mean? It's two different RFCs, so there's two different options.
There was a problem hiding this comment.
I mean why isn't settings typed as
Settings map[uint64]uint64
EnableDatagram / EnableExtendedConnect could also be part of the Other map
There was a problem hiding this comment.
The Other is pretty much a hack, so that WebTransport can add its setting there. I'd much rather just have bools, and let the http3 package deal with serialization.
I like this idea! This would be proper client-side support for Extended CONNECT! |
Fixes #4160. Needed for #3522 and quic-go/webtransport-go#109.
For some requests, the client is required to check the server's HTTP/3 SETTINGS. For example, a client is only allowed to send HTTP/3 datagrams if the server explicitly enabled support.
SETTINGS are sent asynchronously on a control stream (usually the first unidirectional stream). This means that the SETTINGS might not be available at the beginning of the connection. This is not expected to be the common case, since the server can send the SETTINGS in 0.5-RTT data, but we have to be able to deal with arbitrary delays.
For WebTransport, there are even more SETTINGS values that the client needs to check. By making
CheckSettingsa callback on theRoundTripOpt, this entire validation logic can live at the WebTransport layer.There's one thing that this API doesn't cover: While it allows the client to verify HTTP/3 settings, there's no way to perform any checks on any properties of the QUIC connection state. This will be necessary for WebTransport, as WebTransport will require support for the Reliable Stream Reset extension. One option is adding another
RoundTripOptcallback:CheckConnectionState func(quic.ConnectionState) error. This callback would be called right after completion of the handshake, or, for 0-RTT requests, right away (theConnectionStatethen reflects the QUIC transport parameters restored from the session ticket, not the ones negotiated on the new connection, but that's the price you pay for using 0-RTT).