- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 01 Jul 2014 19:29:56 +0000
- To: William Chan (ιζΊζ) <willchan@chromium.org>
- cc: Martin Thomson <martin.thomson@gmail.com>, Patrick McManus <mcmanus@ducksong.com>, Jeff Pinner <jpinner@twitter.com>, Jesse Wilson <jesse@swank.ca>, HTTP Working Group <ietf-http-wg@w3.org>
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.
Received on Tuesday, 1 July 2014 19:30:22 UTC