- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 21 Jul 2012 11:48:04 +1200
- To: ietf-http-wg@w3.org
On 21/07/2012 7:53 a.m., James M Snell wrote: > > > On Fri, Jul 20, 2012 at 12:46 PM, Willy Tarreau <w@1wt.eu > <mailto: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 Depends on what the application considers to be its use-case. For those of you shavign off RTT, it breaks your ideal situation by adding RTT. For services where TCP TIME_WAIT from closure is some large multiple of RTT, the single RTT added by Expect is saved many times over by total throughput capacity on the re-usable connection. Particularly since those types of connections are usually only seen between two piece of high-performance middleware and not by the end-user or origin server. In such middleware Connection:close is a major problem impacting many other users, not just the one being very helpful by sending Expect. > 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. > +1. For these cases. It makes little sense to use Expect: without chunked or some other nice way to early-abort the entity when the race is lost. Amos
Received on Friday, 20 July 2012 23:48:38 UTC