When receiving a GOAWAY frame, the client:
* immediately closes the connection if there are no active requests
* refuses to open streams with stream IDs larger than the stream ID in
the GOAWAY frame
* closes the connection once the stream count drops to zero
* pass *ClientInfo to ConnContext
This allows users to set some state related to the client's remote
address in `ConnContext`.
This also refuses connection early if the returned context is cancelled.
* review comments
* better error assertion
---------
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
* http3: reset request streams accepted after graceful shutdown
The server needs to let the client know that these streams
are not getting processed, using the H3_REQUEST_REJECTED
error code.
* add an integration test for graceful shutdown stream cancellations
Several proxy tests timed out because it got stuck in the packet read
loop after all tests have run. Avoid this by running the `conn.Close()`
Cleanup call from `newUPDConnLocalhost` before the timeout handler.
Update CI to run these tests.
Fixes: 3e87ea3f50 ("proxy: add function to simulate NAT rebinding (#4922)")
Relates to: #5009
* make it possible to pack path probes with multiple frames
* simplify function signature of pathManager.HandlePacket
* simplify connection short header packet handling logic
No functional change expected.
* make server send PATH_RESPONSEs on the same path
This makes sure that we’re actually testing for return routability.
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.
DATA_BLOCKED frames should be sent in the same as the STREAM frames that
resulted in the connection becoming blocked on connection flow control.
If there's not enough space left in that packet, the DATA_BLOCKED frame
is sent in the next packet.
* refactor the framer to pack both control and STREAM frames
* refactor framer STREAM frame packing logic
* pack STREAM_DATA_BLOCKED in the same packet as the STREAM frame
This makes debugging easier (and is slightly more efficient). In the
pathological case where there is not enough space remaning in the packet
to pack the STREAM_DATA_BLOCKED frame, it is queued for the next packet.
* add an integration test
Instead of transferring data in one direction, we should echo the data
sent. This makes sure that a roughly equal number of packets is sent in
each direction.