This is a case where QUIC processing something doesn't imply HTTP/3 processing something. QUIC read the data and "processed" it. HTTP/3 decided not to handle it deliberately, and the PUSH_PROMISE fell between the cracks.
One "solution" is to insist that endpoints attempt to process streams for this stuff if they decide to discard responses. This is like how in HTTP/2 you still have to update the HPACK table after resetting a stream. It's awkward, but I think that it would work if data is available. I don't think that there is any case in which data is unavailable to the client but the server doesn't receive STOP_SENDING. On Tue, Jul 27, 2021, at 13:01, Tatsuhiro Tsujikawa wrote: > Hi, > > It looks like in certain conditions, client is unable to process pushed > stream and leaves it in unprocessable state indefinitely. > > Consider that client opens bidi stream and server sends PUSH_PROMISE > and completes the response body which is very short (just a single packet > or two). For some reason, client has decided to stop reading > response, but FIN is seen (data recvd state), and does not send > STOP_SENDING because it is not required (RFC mentions that it has a > little value to send STOP_SENDING in data recvd state and > unnecessary). Client discards all stream data without handing it over > to application, so PUSH_PROMISE is not processed. Client does not > know the push ID. Because STOP_SENDING is not sent, server has no signal > which indicates PUSH_PROMISE is not processed, and opens a pushed > stream. Client receives pushed stream, but unable to find the > corresponding PUSH_PROMISE. It holds pushed stream until it sees > PUSH_PROMISE, but it never come. This causes the pushed stream to be held by > client indefinitely. > > Even if client sends STOP_SENDING to the bidi stream, it might not > work if server finishes sending stream data and a pushed stream and > forgets them before receiving STOP_SENDING. > > Best regards, > Tatsuhiro Tsujikawa
