Hi frends,

I'd like to open this discussion. If you use HTTP Pipelining in your
application I'd be very interested to know how you'd view a future without
support for it in libcurl.

## Background

HTTP Pipelining was introduced in HTTP 1.1 as a way to combat latency problems
with HTTP. To be able to send off more than one request without having to wait
for the previous response. But it was never successful.

HTTP Pipelining is complicated and is not made less complicated by the fact
that lots of servers and middle boxes break it. We have several bugs in our
Pipelining support and Pipelining is not a very commonly used feature. (I
cannot tell exactly how common because I believe people don't exactly know
what Pipelining is, so when we ask users if they use this, far too many answer
yes!)

Due to the many problems with Pipelining no desktop browser has it enabled by
default even today.

HTTP/2 was partly introduced to provide an alternative to Pipelining that is
not only more effective and less error-prone, it is much easier to implement
and test. It works. HTTP/2 is really *the* way to address the latency problem
and its multiplexing is mandatory and working in every HTTP/2
implementation. It is the much better answer for both servers and clients.

## Can we really remove it?

Oh heck, we can do whatever we want. But ultimately, HTTP pipelining was
always sort of requested and advisory only, so a user application could never
count on it being used and couldn't *know* that more than one request was ever
in flight at a given moment. Switching off support would simply guarantee that
pipelining would never be used... Applications will keep working like they did
before, the ones that actually have pipelining enabled and aren't running into
our bugs. We would still allow all the pipelining options, they just wouldn't
do anything and we'd mark them as obslolete in the documentation.

## But really, why?

We'd clean up the code and get rid of hard-to-fix bugs at the same time. For a
rarely used feature with a better alternative around.

## When?

I don't have any schedule or set time line. I want to start the discussion and
see where it leads before we decide on when (or if).

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html