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
