- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 01 Jul 2014 21:00:58 +0000
- To: Roberto Peon <grmocg@gmail.com>
- cc: Jeff Pinner <jpinner@twitter.com>, Johnny Graettinger <jgraettinger@chromium.org>, William Chan (ιζΊζ) <willchan@chromium.org>, Martin Thomson <martin.thomson@gmail.com>, Patrick McManus <mcmanus@ducksong.com>, Jesse Wilson <jesse@swank.ca>, HTTP Working Group <ietf-http-wg@w3.org>
In message <CAP+FsNfx5bO+W5sOEnVj5TJPqZbW-yND2Xo3Tu7nycV_zSaSxA@mail.gmail.com>, Roberto Peon writes: >So, essentially, the bug here would be on the side that isn't reading, >regardless of the endpoint being client or server. > >Any side which ceases reading/examining received bytes can cause the >session to enter into a deadlock state. How would that ever work ? To send any data you need to receive WINDOW updates, so there is no way to stop paying attention to incoming frames and expect things to work in any way. The most likely way that could happen is mutual TCP window lockout, but that can only happen if boths sides are either primitively half-duplex or broken in some other way. -- 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 21:01:21 UTC