Re: HTTP/2 response completed before its request

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