Re: HTTP/2 response completed before its request

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