W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: HTTP/2 response completed before its request

From: Patrick McManus <mcmanus@ducksong.com>
Date: Wed, 2 Jul 2014 11:51:05 -0400
Message-ID: <CAOdDvNqYaxFAj1sxZ-oBobRMghyy4O_CLjqi4a9Q14y-EEmR7g@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: "William Chan (?????????)" <willchan@chromium.org>, Martin Thomson <martin.thomson@gmail.com>, Jeff Pinner <jpinner@twitter.com>, Jesse Wilson <jesse@swank.ca>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Jul 2, 2014 at 2:59 AM, Willy Tarreau <w@1wt.eu> wrote:There's
something I don't understand here. We used to say that one of the

> benefits of h2 vs h1 was that it was possible to abort a stream without
> breaking a connection,


right!


>
> Does the same problem happen when the client is a browser which retrieves
> a very large file and the user presses "Stop" during the download ?


no - when the user presses stop the client sends a RST_STREAM,CANCEL and
when the server receives that it stops sending data frames. so up to 1
wasted BDP (or so - depending on over buffering) of data flows, but then
the established connection is free to do other things.

Does
> the browser continue to read all data and only stop rendering it in this
> case ?


it does end up reading that BDP worth of data after the cancel and tosses
it away, sure. But it expects the CANCEL will mean that data doesn't just
flow until natural END_STREAM.


>
> Can someone enlighten me on this ?
>
>
I think the confusion is that the okHttp case was about an upload and a
server that responded to that upload before it was complete.. (it didn't
cancel it - the http semantics were complete).. the question is what should
happen to the rest of the upload stream.
Received on Wednesday, 2 July 2014 15:51:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC