read remaining data before deciding to send STOP_SENDING frames

[Ruben2424]

The h3 repository uses the h3spec tool to test the codebase.

After I tried out some stuff in hyperium/h3#244 I noticed that h3spec is failing:
https://github.com/hyperium/h3/actions/runs/10340143789/job/28620383129#step:6:1210

I think this is because h3 drops the stream before all data is read. But the error didn't occur every time.

This fixes the problem by reading and ignoring all stream data before the stream gets dropped.

If you consider merging this, please review carefully because I am not familiar with the internals of quinn or quic.

[Ralith]

Thanks for looking into this! This sounds like a problem at the h3 layer, not the transport layer. If it's incorrect for h3 to drop the stream without reading all data first, then it shouldn't do that. I'd recommend following up at the h3 layer to find a direct solution.

[Ruben2424]

Thanks for your Reply @Ralith.

After reading my first message again I noticed, that there are information missing which led me believe that this could be a problem on the quic layer. I am sorry for that.

When dropping the stream, quinn sends a quic STOP_SENDING frame if not all data is read even if the peer already finished or reset the stream
With wireshark I saw that quinn already sent ACKs for the RESET_STREAM or STREAM with FIN=1 frames before sending the STOP_SENDING.

[Ralith]

That is compliant with the RFC, and sometimes absolutely necessary. What makes you think this is relevant to your h3 test failures?

[Ruben2424]

What makes you think this is relevant to your h3 test failures?

This error message https://github.com/hyperium/h3/actions/runs/10340143789/job/28620383129#step:6:1210.
And iirc it only failed when I observed a STOP_SENDING with wireshark.

That is compliant with the RFC, and sometimes absolutely necessary?

I did not find anything in the RFC (allowing or forbidding it). But you know better then I, so it is probably a false positive in h3spec.

[Ralith]

This error message https://github.com/hyperium/h3/actions/runs/10340143789/job/28620383129#step:6:1210.

I'm not familiar with h3spec's error terms.

I did not find anything in the RFC (allowing or forbidding it)

https://www.rfc-editor.org/rfc/rfc9000.html#name-permitted-frame-types

The receiver only sends MAX_STREAM_DATA frames in the "Recv" state. A receiver MAY send a STOP_SENDING frame in any state where it has not received a RESET_STREAM frame -- that is, states other than "Reset Recvd" or "Reset Read". However, there is little value in sending a STOP_SENDING frame in the "Data Recvd" state, as all stream data has been received. A sender could receive either of these two types of frames in any state as a result of delayed delivery of packets.

If you can positively demonstrate quinn sending STOP_SENDING after receiving a reset, please open a bug for that, but it doesn't appear to be possible. Regardless, as the RFC explains, the sender must handle that possibility, so it sounds like you might want to open a conformance issue on h3spec.