Re: HTTP/2 response completed before its request

https://code.google.com/p/chromium/issues/detail?id=330860
On Jul 1, 2014 9:48 AM, "Roberto Peon" <grmocg@gmail.com> wrote:

> Getting a response before the request has finished definitely happens
> sometimes, even in HTTP/1.1
> -=R
>
>
> On Tue, Jul 1, 2014 at 9:34 AM, Willy Tarreau <w@1wt.eu> wrote:
>
>> On Tue, Jul 01, 2014 at 10:27:45AM -0600, Jesse Wilson wrote:
>> > Here???s an HTTP/2 scenario that we ran into
>> > <https://github.com/square/okhttp/issues/929> with OkHttp???
>> >
>> >    1. Our client POSTs a large image. In this case, large means
>> ???larger
>> >    than the configured initial window size???.
>> >    2. The server reads our request headers and sends a response
>> (headers +
>> >    body) immediately. The response includes an END_STREAM flag,
>> indicating
>> >    that no further response body frames are expected.
>> >    3. The client continues to upload the request.
>> >    4. The client upload exhausts the window and stalls.
>> >    5. The server never sends a RST_STREAM or WINDOW_UPDATE frame, so the
>> >    client eventually times out.
>> >
>> > What???s interesting???
>> >
>> > The server sent its complete response before the request completed.
>> > Thinking in HTTP/1.1, I hadn???t anticipated this possibility. The
>> response
>> > code was 500, which suggests a crash in the server somewhere. Should the
>> > spec mention this possibility? What are the obligations on the client in
>> > this case? What would it mean for a server to return a 200 response to a
>> > POST-in-progress?
>>
>> A 200 is not that common in this scenario, however 301/302 are fairly
>> common there (eg: session timed out, redirect to the home page). In 1.1,
>> it's said that the server should drain all the client's data to avoid
>> the problem of sending an RST to the client, and that the client should
>> stop uploading if it sees the connection is closed (which generally
>> happens after a redirect to another domain). We need to ensure we handle
>> this case gracefully in HTTP/2 as well.
>>
>> > The error also caused the server to lose our stream. This is a
>> partition in
>> > the CAP sense, and timeouts are the client???s failsafe to detect this.
>> > HTTP/2 can suffer partitions in the application layer!
>> > ???
>>
>> Regards,
>> Willy
>>
>>
>>
>