- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Fri, 20 Jul 2012 15:20:47 -0500
- To: James M Snell <jasnell@gmail.com>
- Cc: Willy Tarreau <w@1wt.eu>, Roberto Peon <grmocg@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, Osama Mazahir <OSAMAM@microsoft.com>, Julian Reschke <julian.reschke@gmx.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Adrien de Croy <adrien@qbik.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
I always feel that this mechanism - ask permission first - should be addressed by the app protocol, not by HTTP. On Fri, Jul 20, 2012 at 2:53 PM, James M Snell <jasnell@gmail.com> wrote: > > > On Fri, Jul 20, 2012 at 12:46 PM, Willy Tarreau <w@1wt.eu> wrote: >> >> On Fri, Jul 20, 2012 at 02:35:00PM -0500, Zhong Yu wrote: >> > What are the reasons for such great efforts to keep connection alive >> > when a 100-continue fails? Is it really a big deal to drop connections >> > once in a while? >> >> Some webservice clients make extensive use of Expect: 100-continue over >> connection pools to avoid sending useless data and to keep the connections >> open. In fact, we're realizing that in the end it does not work (unless >> chunked encoding is used). >> > > +1 .. I've had similar experience. It's one of those things that sounds > great in theory but in practice it just doesn't work effectively... at least > not well enough to justify it's use. > > - James > >> >> In the end, these WS clients might as well not send Expect and save one >> round trip and one packet in each direction since the only benefit of >> it goes away in case of failure, which is the only reason for using >> Expect. >> >> Regards, >> Willy >> >
Received on Friday, 20 July 2012 20:21:17 UTC