mirror of
https://github.com/curl/curl.git
synced 2026-07-26 01:27:15 +03:00
pipelining: removed
As previously planned and documented in DEPRECATE.md, all pipelining code is removed. Closes #3651
This commit is contained in:
parent
aba1c51553
commit
2f44e94efb
28 changed files with 190 additions and 1401 deletions
|
|
@ -5,46 +5,6 @@ email the curl-library mailing list as soon as possible and explain to us why
|
|||
this is a problem for you and how your use case can't be satisfied properly
|
||||
using a work around.
|
||||
|
||||
## HTTP pipelining
|
||||
|
||||
HTTP pipelining is badly supported by curl in the sense that we have bugs and
|
||||
it is a fragile feature without enough tests. Also, when something turns out
|
||||
to have problems it is really tricky to debug due to the timing sensitivity so
|
||||
very often enabling debug outputs or similar completely changes the nature of
|
||||
the behavior and things are not reproducing anymore!
|
||||
|
||||
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.
|
||||
|
||||
The bad state of HTTP pipelining was a primary driving factor behind HTTP/2
|
||||
and its multiplexing feature. HTTP/2 multiplexing is truly and really
|
||||
"pipelining done right". It is way more solid, practical and solves the use
|
||||
case in a better way with better performance and fewer downsides and problems.
|
||||
|
||||
In 2018, pipelining *should* be abandoned and HTTP/2 should be used instead.
|
||||
|
||||
### State
|
||||
|
||||
In 7.62.0, we will 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.
|
||||
|
||||
### Removal
|
||||
|
||||
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?
|
||||
|
||||
## `CURLOPT_DNS_USE_GLOBAL_CACHE`
|
||||
|
||||
This option makes libcurl use a global non-thread-safe cache for DNS if
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue