Re: HTTP/2 response completed before its request

are you suggesting that as required or reasonable client behavior?

It's definitely reasonable. But it seems plausible to build an application
that doesn't cancel (perhaps these data segments are the moral equivalent
of FYI trailers that don't impact the response generation)- I don't see a
reason to require the cancel.

The only firm bug there seems to be the server not sending updates.


On Tue, Jul 1, 2014 at 2:47 PM, Jeff Pinner <jpinner@twitter.com> wrote:

> RST_STREAM NO_ERROR
>
> On Tue, Jul 1, 2014 at 11:41 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> > On 1 July 2014 10:55, William Chan (陈智昌) <willchan@chromium.org> wrote:
> >> This same theoretical problem happens for HTTP/1.X over TCP. If the
> peers
> >> don't call read() to pull the TCP data into user space, the kernel's TCP
> >> stack will eventually shrink the receive window to 0. Of course, the TCP
> >> receive windows will generally be larger than HTTP/2's initial windows
> >> (64K).
> >
> > The stall is half of the problem, but do you cancel the send as well?
> > If the server has provided a response and closed the stream, there is
> > no point in continuing to send them data.  Especially if they forget
> > to send window updates.
> >
> > RST_STREAM seems appropriate, but what do you think is the right code?
> >
>
>