The http.Request.Body can be type-asserted to a http3.Settingser. The
Settings method on this interface blocks until the client's SETTINGS
frame has been received.
Under normal circumstances, we should be able to send out control frames
right away, so we don't expect any queue to build up. To defend against
resource exhaustion attacks, we limit the control frame queue to 16384
elements.
* use Transport.VerifySourceAddress to control the Retry Mechanism
This can be used to rate-limit handshakes originating from unverified
source addresses. Rate-limiting for handshakes can be implemented using
the GetConfigForClient callback on the Config.
* pass the remote address to Transport.VerifySourceAddress
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.
* docs: improve API documentation for OpenStreamSync
Both `OpenStream` and `OpenStreamSync` themselves only create steam objects locally, but `OpenStreamSync` does not add document descriptions, which will cause ambiguity.
* additional description
If the user provides a quic.Config, we shouldn't modify it. Instead, we
should return an error if the user enables HTTP Datagrams but fails to
enable datagrams on the QUIC layer.
This prevents a race condition when the underlying ClientSessionCache
provided by the application returns the same session ticket for multiple
connections. Reusing session tickets is explicitly recommended against
by both RFC 8446 and RFC 9001, but it's not forbidden. This fix only
benefits applications that compromise their users' privacy by reusing
session tickets.
This technically violates the stateless reset handling logic described
in RFC 9000 section 10.3.1 (see comment), but it saves one map lookup in
the hot path.
The slice will be allocated when STREAM frames are appended. By not
preallocating it is made sure that the slice is only created in cases
where STREAM frames are actually sent in this packet.
* avoid lock contention when accepting new connections
The server used to hold the packet handler map's lock while creating the
connection struct for a newly accepted connection. This was intended to
make sure that no two connections with the same Destination Connection
ID could be created.
This is a corner case: it can only happen if two Initial packets with
the same Destination Connection ID are received at the same time. If
the second one is received after the first one has already been
processed, it would be routed to the first connection. We don't need to
optimized for this corner case. It's ok to create a new connection in
that case, and immediately close it if this collision is detected.
* only pass 0-RTT to the connection if it was actually accepted
