Re: HTTP/2 response completed before its request

Although OkHttp's network layer is constantly reading from the socket, it
won't acknowledge response body data until it's been consumed by the
application layer. And the application layer won't consume the response
until after it's done transmitting the request.

So we're vulnerable to deadlock because our application layer is not
concurrent and our network layer refuses to buffer an unbounded amount of
data.
 On Jul 1, 2014 9:07 PM, "Roberto Peon" <grmocg@gmail.com> wrote:

> 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
>> >
>>
>
>