Re: HTTP/2 response completed before its request

Maybe not for web servers, but 100-continue is used for IPP all the time...


On Jul 1, 2014, at 3: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.
> 
> 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
>>> 
>>> 
>> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair