Since the QUIC connection establishment process includes TLS handshake logic,
Connect and TLS handshake are called in the following order:
ConnectStart -> TLSHandshakeStart -> TLSHandshakeDone -> ConnectDone.
Notice: Wait100Continue not implemented as quic-go doesn't support handling
Expect: 100-continue.
* http3: rename RoundTripper to Transport
* http3: rename SingleDestinationRoundTripper to ClientConn
* http3: construct the ClientConn via Transport.NewClientConn
* http3: implement server idle timeout support
This update introduces the ability for an HTTP/3 server to enforce an idle
timeout on connections. This timeout will trigger when no new requests are
received on a connection, irrespective of any PING frames received at the
QUIC level.
* fix deadlock when http3 idle timeout is not enabled
* fix typo
* Switch to a more efficient implementation
* Avoid a goroutine
* Avoid constent re-adjusting of a timer
* Works with hijacked streams
* Generalize the idle timeout description
* Add an integration test for http server idle timeout
* Attempt to fix other tests impacted by the new idle timeout test
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 stream hijackers only need to be able to associate the stream with
the underlying QUIC connection. They are not supposed to call any
functions on the quic.Connection. As such, the better API is to just
pass them a unique identifier.
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.
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.
* http3: fix race condition when accessing the client's connection
* add an integration test for concurrent HTTP requests
---------
Co-authored-by: Bulat Khasanov <afti@yandex.ru>
* http3: use a mock roundTripCloser in tests
* http3: correctly handle failed clients
Specifically,
* immediately remove a client when a request errored
* if that error was an idle error, and the client was a reused client
(from an earlier request that already completed the handshake),
re-dial the connection
