Re: HTTP/2 response completed before its request

*All the browsers I tested (firefox/chrom/safari/IE) appear to be
half-duplex - they will not read the response until the request body is
completely sent.*
in h1 they are being half-duplex at the application stream level.. but not
at the tcp level. i.e. they are still reading the incoming TCP acks -
otherwise they wouldn't be able to continue to send the request body at
some point due to rwin exhaustion.

in h2 the equivalent of those stream tcp acks are received window updates -
so an h2 client will always be reading the tcp stream to find them even
while generating an upload stream - it simply has to. If it picks up some
data frames along the way its an implementation choice on when to pass
them to the stream sink and when to generate updates that cover them.
(presumably a related choice :))


On Tue, Jul 1, 2014 at 11:02 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:

> On Tue, Jul 1, 2014 at 2:42 PM, Willy Tarreau <w@1wt.eu> wrote:
> > On Tue, Jul 01, 2014 at 02:21:07PM -0500, Zhong Yu wrote:
> >> On Tue, Jul 1, 2014 at 11:45 AM, Roberto Peon <grmocg@gmail.com> wrote:
> >> > Getting a response before the request has finished definitely happens
> >> > sometimes, even in HTTP/1.1
> >>
> >> A server should not do that, or it will cause deadlocks with most
> >> major browsers.
> >>
> >> 100-continue is supposed to be helpful in this case, but it's not
> >> really adopted in practice.
> >
> > I disagree, and there are a number of situations where it's quite
> desirable
> > to act like this. For example, imagine that I'm uploading a large image
> to
> > a site and my session has expired. I want the site to send the error as
> soon
> > as possible so that my browser stops emitting for nothing. I don't want
> it to
> > wait minutes just to know that I need to re-login first then try again.
> >
> > Browsers already handle this quite well in 1.1, and the real issue in
> fact
>
> All the browsers I tested (firefox/chrom/safari/IE) appear to be
> half-duplex - they will not read the response until the request body
> is completely sent. A server can send an immediate response before
> reading the request body, but the browser won't read the response
> immediately.
>
> Since sending the response before draining the request body carries
> the risk of deadlock, it's probably better to drain the request body
> before sending the response. That is, the server is forced to do
> half-duplex, because most clients do half-duplex.
>
> Zhong Yu
> bayou.io
>
> > tends to be on the server side where it's not always easy to drain all
> the
> > request from the client after the response was sent, which sometimes
> results
> > in a TCP RST which risks to clear the response before the client has a
> chance
> > to see it. But correctly done, it's a very useful feature.
> >
> > Willy
> >
>
>