The connection already cancels the base context, so we don't need to manually
cancel the stream context (which is derived from the connection context).
* fix(http3): handle streamStateSendAndReceiveClosed in onStreamStateChange
Signed-off-by: George MacRorie <me@georgemac.com>
* refactor(http3): adjust stateTrackingStream to operate over streamClearer and errorSetter
* test(http3): remove duplicate test case
* chore(http3): rename test spies to be mocks
---------
Signed-off-by: George MacRorie <me@georgemac.com>
On the client side, we always use the configured packet size. This comes
with the risk of failing the handshake if the path doesn't support this
MTU. If the server sends a max_udp_payload_size that's smaller than this
size, we can safely ignore this: Obviously, the server still processed
the (fully padded) Initial packet, despite claiming that it wouldn't do
so.
On the server side, there's no downside to using 1200 bytes until we
received the client's transport parameters:
* If the first packet didn't contain the entire ClientHello, all we can
do is ACK that packet. We don't need a lot of bytes for that.
* If it did, we will have processed the transport parameters and
initialized the MTU discoverer.
* wire: add benchmark tests for initial and retry header parsing
* wire: refactor header parsing to use quicvarint.Parse
* wire: simplify tracking of parsed length for Long Header parsing
* try to sniff content-type as long as the data is not written to the client
* only write when body is allowed
* fix tests
* fix tests
* fix header count
* fix lint
* merge from upstream
* merge updates from master
* Update http3/response_writer.go
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
---------
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
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.
* delay completion of the send stream until the reset error was delivered
* mark the send stream completed on Close after receiving a STOP_SENDING
* fix handling of STOP_SENDING after Close
Abandon is called when a RESET_STREAM frame is received, and marks the
bytes between the highest read position and the final offset as
consumed. Making it possible to call Abandon multiple times makes using
this API a bit easier, since the stream doesn't need to track if it
already called it.
