Description

The HTTP/3 RFC specifies the following for unidirectional streams:

A sender can close or reset a unidirectional stream unless otherwise specified. A receiver MUST tolerate unidirectional streams being closed or reset prior to the reception of the unidirectional stream header.

This behavior is violated when receiving a unidirectional server-initated stream here. The code is missing a try-catch block, because the QuicStream.ReadAsync may throw, which leads to an abort of the whole H/3 connection.

Note that the behavior is violated only when tracing is enabled.

Reproduction Steps

The problem depends on timing, because the first read from the received stream handles an exception properly (see here). Nonetheless, I will describe the inputs and the timings that lead to the incorrect behavior.

1. The connection is established.
2. The server opens a unidirectional stream with stream type that is encoded into 2 bytes or more.
3. The server sends the first byte of the stream type.
4. The client receives the unidirectional stream.
5. The client reads the first byte successfully and reaches L674.
6. The server resets the stream.
7. The client throws on line L674, which causes an abort - a connection level error.

Expected behavior

The stream reset by the server should not cause a connection level error.

Actual behavior

The stream reset by the server causes the client to close the connection, because it considers it a connection level error.

Regression?

No response

Known Workarounds

Disable tracing.

Configuration

No response

Other information

No response