Re: HTTP/2 response completed before its request

In HTTP2, however, it works differently since the browser must always read,
and both sides must respect flow control.

You need to try pretty hard to get it into a pathological case that
deadlocks things (e.g. overly-large/infinite/non-existent flow control
window which the application is unable/unwilling to actually adhere to
coupled with more data sent than the application is willing to read).

For my part, I would not change how the server works.
I'd have the server drop the connection to any endpoint for HTTP2 that was
not reading what the server was sending it.
Similarly, any client should drop the connection to any endpoint that was
not reading what it was sending it.

-=R


On Tue, Jul 1, 2014 at 8: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
> >
>