- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 1 Jul 2014 14:21:07 -0500
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Willy Tarreau <w@1wt.eu>, Jesse Wilson <jesse@swank.ca>, HTTP Working Group <ietf-http-wg@w3.org>
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. 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 >> >> >
Received on Tuesday, 1 July 2014 19:21:36 UTC