W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: HTTP/2 response completed before its request

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 1 Jul 2014 18:34:39 +0200
To: Jesse Wilson <jesse@swank.ca>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20140701163439.GC22160@1wt.eu>
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
Received on Tuesday, 1 July 2014 16:35:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC