curl / Mailing Lists / curl-library / Single Mail


Re: Pipelining is a pain, can we ditch it now?

From: James Fuller <>
Date: Sun, 1 Jul 2018 21:25:36 +0200

I (semantically) prefer deprecated vs removed ... and of course
deleting code is always more valuable then adding code so a big +1 to
the plan for removals.


On 1 July 2018 at 13:04, Daniel Stenberg <> wrote:
> On Sat, 30 Jun 2018, Daniel Stenberg wrote:
>> HTTP Pipelining was never enabled by default by the large desktop browsers
>> due to all the issues with it. Both Firefox and Chrome have also dropped
>> Pipelining support entirely since a long time back now. We are in fact over
>> time becoming more and more lonely in supporting pipelining.
> Here's a plan on how to deprecate pipelining support from libcurl!
> 1. In 7.62.0 (release planned to happen in September 2018), we add code that
> ignores the "enable pipeline" option setting). The *setopt() function would
> still return "OK" though so the application couldn't tell that this is
> happening.
> Users who truly need pipelining from that version will need to modify the
> code (ever so slightly) and rebuild.
> 2. Six months later, in sync with the planned release happen in April 2019,
> (might be 7.66.0), assuming no major riots have occurred due to this in the
> mean time, we rip out the pipelining code. It is in the order of 1000 lines
> of libcurl code.
> Left to answer: should the *setopt() function start to return error when
> these options are set to be able to tell when they're trying to use options
> that are no longer around or should we maintain behavior as much as
> possible?
> Is this plan compatible with our API/ABI guarantees?
> Yes in fact it is. Pipelining is and was always just a "wish" from the
> application's perspective and it can never really be guaranteed to happen.
> From an application's perspective, this just makes the wish never come true
> over the wire.
> Appeal?
> If you want to object to this plan and decision, please bring it up here on
> the curl-library mailing list and explain to us why your use case breaks
> terribly by this action with no useful work-arounds.
> Since this is now the second item on the "to be removed" list (axTLS being
> the first), I figure maybe I should setup a page somewhere to help us keep
> track of them...
> - As always, your input is appreciated!
> --
> /
> -------------------------------------------------------------------
> Unsubscribe:
> Etiquette:
Received on 2018-07-01