- From: Jason Greene <jason.greene@redhat.com>
- Date: Wed, 2 Jul 2014 11:26:12 -0500
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: Willy Tarreau <w@1wt.eu>, "William Chan (陈智昌)" <willchan@chromium.org>, 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>
On Jul 2, 2014, at 10:43 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > Kind of. In HTTP/1.1, if you’ve started receiving entity body and decide you don’t want it any more, you have to RST the TCP connection. That doesn’t mean you keep reading to the end, but it does mean that until the server sees the RST, they’re going to keep sending data your way and it gets dropped either by your TCP stack or some intermediary who’s tracking TCP session state. > > In HTTP/2, you can do the same thing, RST the stream. But the scenario here is when the request is completed, not because the client doesn’t need the response any more, but because the server already sent the response and doesn’t need the request body. > > I think it’s entirely appropriate for the client to RST_STREAM NO_ERROR in this situation, to alert the server that it’s abruptly stopping the (unneeded) entity body. The concern is that complementary bugs could interact in the wild: > • Client doesn’t read HEADERS/DATA until it has finished sending the body > • Server doesn’t send WINDOW_UPDATE on a half-closed stream Is it RST_STREAM CANCEL or NO_ERROR? -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Wednesday, 2 July 2014 16:27:17 UTC