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

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