To me it sounds like an API detail between the transport layer and the application protocol layer that could differ between implementations without affecting the protocol specification of QUIC transport or HTTP/3.
Speaking generally and not HTTP/3 specific: If the application requests transport to send stop sending, the application doesn’t directly control the transport, it merely asks the transport to work on its behalf. Thus aborting receive side stream might take an API form such as: 1) ignore all further data on this stream including buffered and transit data 2) ask the peer to not send more data, but give me whatever is still buffered and in transit. Of course this might be several different API calls working together to reach those effects. Mikkel > On 27 Jul 2021, at 10.55, Tatsuhiro Tsujikawa <[email protected]> wrote: > > Hi, > > On Tue, Jul 27, 2021 at 3:31 PM Martin Thomson <[email protected] > <mailto:[email protected]>> wrote: > 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. > > > It is indeed awkward that QUIC stack has to pass stream data all the way to > the end of the stream (or sees RESET_STREAM or closed) to HTTP/3 client even > after it requested stopping reading. And the HTTP/3 client has to process it > just for PUSH_PROMISE. Does any implementation do this? > > Sending STOP_SENDING alone is not enough. As I wrote in the previous post, > by the time STOP_SENDING is received by the HTTP/3 server, it has finished > processing the pushed stream and forgets it. I imagine that if QUIC stack > provides BSD socket-like interface and HTTP/3 server writes all data and can > clear the memory without waiting for an acknowledgement. > > Best regards, > Tatsuhiro Tsujikawa > > 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 >
