Re: HTTP/2 response completed before its request

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

Sent from Windows Mail

From: Willy Tarreau<mailto:w@1wt.eu>
Sent: ?Wednesday?, ?July? ?2?, ?2014 ?12?:?02? ?AM
To: William Chan (陈智昌)<mailto:willchan@chromium.org>
Cc: Martin Thomson<mailto:martin.thomson@gmail.com>, Patrick McManus<mailto:mcmanus@ducksong.com>, Jeff Pinner<mailto:jpinner@twitter.com>, Jesse Wilson<mailto:jesse@swank.ca>, HTTP Working Group<mailto:ietf-http-wg@w3.org>

On Tue, Jul 01, 2014 at 12:03:41PM -0700, William Chan (?????????) wrote:
> On Tue, Jul 1, 2014 at 11:56 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
> > On 1 July 2014 11:54, Patrick McManus <mcmanus@ducksong.com> wrote:
> > > are you suggesting that as required or reasonable client behavior?
> >
> > Just reasonable.  It's perfectly OK to complete the request, however
> > long that takes.
> >
> > > The only firm bug there seems to be the server not sending updates.
> >
> > Definitely.  But who gets the blame for the stall?
> >
>
> The server. Even if it doesn't actually use the request data, it needs to
> send to /dev/null and send WINDOW_UPDATEs, until it gets to the point that
> it can send the full response and send a RST_STREAM. I assert this to be
> generally true for HTTP semantics, regardless of HTTP/1.X or HTTP/2 on the
> wire.

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, but here it seems to be the complete opposite.

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 ? Does
the browser continue to read all data and only stop rendering it in this
case ? That does not make much sense, because the primary purpose for
"Stop" is to release the small DSL or POTS line and be able to quickly
use it for another request. Here if every time a user presses Stop, the
client has to break the whole connection to abort, it possibly means
stopping ongoing downloads and such things, which is really not appropriate.
At least in HTTP/1 when you stop a large file transfer, you don't stop other
transfers from the same server. The typical case is on download sites, you
have a download of a tar.bz2 coming and at the same time you click on a
MANIFEST file which is huge and you're not interested in downloading.

Can someone enlighten me on this ?

Thanks,
Willy