[Suspected Bug]It seems lsquic does not comply with the requirements of RFC 9000 when processing the "MAX_STREAM_DATA frame"

[Lingtaonju]

Dear all:

The story begins here:

When lsquic serves as the server and handles chromium's(client) ietf quic v1 requests, we encountered a problem.
The error log from client-side is as follows:

I chromium: [918:1415:1119/151718.781863:INFO:quic_connection.cc(2153)] Client: Received Transport ConnectionClose for connection: 7330ae0c3284cfd2, with error: QUIC_IETF_GQUIC_ERROR_MISSING (received MAX_STREAM_DATA frame on never-opened stream 0), transport error code: STREAM_STATE_ERROR, error frame type: 0

It seems lsquic close the connection, as stream 0 was not opened, but the MAX_STREAM_DATA frame arrived first.
Following is the code:

When we captured the packet, we saw that the MAX_STREAM_DATA frame encoded before the request for stream 0

It seems normal.

My question:

But, when I read the RFC 9000, it writes:

So, I think when checking whether the stream is already opened at the point receiving the MAX_STREAM_DATA frame, the lsquic need to check if the stream belong to its side first?
We can discuss more about this.
Wait for your reply.

---

Yours sincerely
Michel Kong

[Lingtaonju]

I will submit a fix later.