Re: HTTP/2 response completed before its request

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

Received on Wednesday, 2 July 2014 06:59:43 UTC