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
