- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 20 Jul 2012 09:52:29 +0200
- To: Amos Jeffries <squid3@treenet.co.nz>
- 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 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.
Regards,
Willy
Received on Friday, 20 July 2012 07:53:12 UTC