Re: HTTP/2 response completed before its request

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
>

Received on Wednesday, 2 July 2014 03:03:08 UTC