Re: HTTP/2 response completed before its request

On Tue, Jul 1, 2014 at 12:21 PM, Zhong Yu <zhong.j.yu@gmail.com> 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.
>

There are two other conditions that have to be met, but usually aren't, in
order for this to deadlock browsers that don't pump both writes and reads
when sending out the request:
(1) The HTTP response doesn't fit in the browser TCP receive window/buffers.
(2) The server did not pump reads, thereby causing the browser to stall on
uploading the request data.

In practice, this rarely happens.


>
> 100-continue is supposed to be helpful in this case, but it's not
> really adopted in practice.
>
> Zhong Yu
> bayou.io
>
> > -=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
> >>
> >>
> >
>
>