* pass a context to Transport.ConnContext
This context is cancelled when the QUIC connection is closed, or when
the QUIC handshake fails. This allows the application to easily build
and garbage collect a map of active connections.
* correctly handle fresh contexts returned from ConnContext
This is more useful than the maximum frame size. The user of the library
shouldn't have to care about the QUIC framing layer.
---------
Co-authored-by: 世界 <i@sekai.icu>
Currently the HTTPStreamer is implemented on the http.Request.Body. This
complicates usage, since it's not easily possible to flush the HTTP
header, requiring users to manually flash the header before taking over
the stream.
With this change, the HTTP header is now flushed automatically as soon
as HTTPStream is called.
The stream exposes two methods required for doing an HTTP request:
SendRequestHeader and ReadResponse. This can be used by applications
that wish to use the stream for non-HTTP content afterwards. This will
lead to a simplification in the API we need to expose for WebTransport,
and will make it easier to send HTTP Datagrams associated with this
stream.
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.
* 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.
* add Transport config options to limit the number of handshakes
* fix accounting for failed handshakes
* increase handshake limits, improve documentation
So far, we used Connection.destroy, which destroys a connection without
sending out a CONNECTION_CLOSE frame. This is useful (for example) when
receiving a stateless reset, but it's not what we want when the server
refuses an incoming connection. In this case, we want to send out a
packet with a CONNECTION_CLOSE frame to inform the client that the
connection attempt is being rejected.
There's no need to have a dedicated shutdown method, as the use case
(shutting down an outgoing connection attempt on context cancellation)
can be achieved by using Connection.destroy.
