W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

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

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 20 Jul 2012 22:44:16 +1200
Message-ID: <50093680.2020603@treenet.co.nz>
To: Willy Tarreau <w@1wt.eu>
CC: Osama Mazahir <OSAMAM@microsoft.com>, Roberto Peon <grmocg@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Adrien de Croy <adrien@qbik.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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.

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 10:45:00 GMT