Re: usability of 100-continue, was: HTTP2 Expression of Interest : Squid

On 20/07/2012 7:52 p.m., Willy Tarreau wrote:
> On Fri, Jul 20, 2012 at 07:28:47PM +1200, Amos Jeffries wrote:
>>> But it does not cover the client which immediately receives the 417 and
>>> which refrains from sending and instead reuses the connection.
>> Did you mean the tricky case where encoding is attempted and the 417
>> returns.
> no, see with the example below :-)
>
>> Could we mandate a minimum client timeout suitable for slow high latency
>> connections. Or suggest that it is linked to RTT somehow? as you say it
>> is RTT related race, making a timeout depend on RTT seams reasonable if
>> possible.
> Application never have any idea of RTT, especially when they're behind
> reverse-proxies.
>
>>> It is all a matter of race condition : depending on the RTT between the
>>> client and the server, the exact same sequence of operations at both sides
>>> may lead to a different behaviour :
>>>    - only headers are sent, client does not send body and goes on with next
>>>      request ;
>>>    - body starts to be sent and server has to drain it.
>>>
>>> So the server cannot detect whether what follows is a body or a next
>>> request.
>>>
>>> I suspect that sending request-looking data in a POST with an Expect
>>> header might produce interesting results which merit being studied on
>>> various products :
>>>
>>>     POST /public HTTP/1.1
>>>     Host: www.example.com
>>>     Expect: 100-Continue
>>>     Content-Length: 100
>>>
>>>     GET /private HTTP/1.1
>>>     Host: www.example.com
>> In the above example the use of content-length requires that the server
>> drain 100 bytes regardless of what the client does.
> Exactly. The problem is that the client is not forced to send data on a
> failed expectation (which is the purpose). Imagine with the example above :
>
>     Client                                                           Server
>          -------------------- request headers ------------------------>
>
>          <----------- 417 failed --------------------------------------
>
>          ------ no body, then go on with next request ---------------->
>
> Or :
>
>     Client                                                           Server
>          -------------------- request headers ------------------------>
>
>                                        ... <------ 417 failed ---------
>          ---------- tired of waiting, sending body ------------------->
>          <------ 417 failed ------ ...
>
>
> In both situations, the server receives something after it has sent 417.
> In one case it's the next request and in the other case it's the body.
> It could be the same with 401 BTW.
>
> So after a failed expectation with a content-length, the connection must
> not be reused. Chunked encoding does not have this issue however since
> the end of the message is always known.

That is still a content-length case though (absene of encoding type). 
Part 1 section 3.3.3 point #5.  In all of those cases content-length 
amount of bytes MUST be sent or the connection aborted.
417 is a final response to that initial request. Therefore the server 
drains the content-length body and connection re-use can begin. Client 
is responsible for aborting the connection or padding with disposable 
garbage bytes.  At no point can the client send content-length then 
re-use the connection earlier.


Amos

Received on Friday, 20 July 2012 10:44:54 UTC