Re: HTTP/2 response completed before its request

Like TCP, HTTP/2 streams are full duplex. From the server's perspective,
the stream was in a half-closed-local state. As in TCP, a stream in such a
state must be consumed or reset to avoid a stall. The server had the choice
of either, and did neither.

Without knowing the application context, it's impossible to say what would
have been sensible client behavior, but it doesn't matter here.


On Tue, Jul 1, 2014 at 3:29 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <
> CAA4WUYgM_uQyjCH3XYCtb3t7YzbUf66_6it6Hp4_H2xEeDu-Ow@mail.gmail.com>,
> =?UTF-8?B?V2lsbGlhbSBDaGF
> uICjpmYjmmbrmmIwp?= writes:
>
> >> Definitely.  But who gets the blame for the stall?
> >
> >The server.
>
> I'm not so sure.
>
> The server acts sensibly:  A client which tries to POST a 1TB file to
> http://example.com should not be able to tie up bandwidth and resources
> for ages before the server can tell it to forget it.
>
> The sensible client will stop transmitting on seing END_STREAM from
> the server and put an END_STREAM on the next packet going out and
> abandon the stream.
>
> At the very latest, a modestly conforming client will discover
> the servers END_STREAM when the window closes to zero, since it has
> to shift to receive to get WINDOW updates.
>
> The only question is what to do about non-modestly conforming clients
> and intentionally malicious clients?
>
> I would propose the server do something like the following:
>
>         Issue no further credits towards the window, but let it
>         close to zero.
>
>         Discard all packets received on this stream.  If any of
>         them contain END_STREAM, we're done.  (sensible clients)
>
>         Once window is at zero, wait a couple of seconds.
>
>         Issue a single window credit, only 100 bytes or so.
>
>         If the next frame on this stream received from the client
>         does not contain END_STREAM close the connection.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>