Re: HTTP/2 response completed before its request

Hi Pat,

On Wed, Jul 02, 2014 at 11:51:05AM -0400, Patrick McManus wrote:
> 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.

OK thanks for explaining. But I still fail to see the difference. And upload
and a download are exactly the same, in both cases we're sending a message
body and any party should be free to abort receipt saying it doesn't want it
anymore. I suspect that some intermediate states are missing. Reminds me when
I was pulling my hair on connection management in haproxy until I found I had
no other solution but adding extra closing states to handle the various end
conditions...

Willy

Received on Wednesday, 2 July 2014 16:05:25 UTC