@@ -5,46 +5,6 @@ email the curl-library mailing list as soon as possible and explain to us why
55this is a problem for you and how your use case can't be satisfied properly
66using a work around.
77
8- ## HTTP pipelining
9-
10- HTTP pipelining is badly supported by curl in the sense that we have bugs and
11- it is a fragile feature without enough tests. Also, when something turns out
12- to have problems it is really tricky to debug due to the timing sensitivity so
13- very often enabling debug outputs or similar completely changes the nature of
14- the behavior and things are not reproducing anymore!
15-
16- HTTP pipelining was never enabled by default by the large desktop browsers due
17- to all the issues with it. Both Firefox and Chrome have also dropped
18- pipelining support entirely since a long time back now. We are in fact over
19- time becoming more and more lonely in supporting pipelining.
20-
21- The bad state of HTTP pipelining was a primary driving factor behind HTTP/2
22- and its multiplexing feature. HTTP/2 multiplexing is truly and really
23- "pipelining done right". It is way more solid, practical and solves the use
24- case in a better way with better performance and fewer downsides and problems.
25-
26- In 2018, pipelining * should* be abandoned and HTTP/2 should be used instead.
27-
28- ### State
29-
30- In 7.62.0, we will add code that ignores the "enable pipeline" option
31- setting). The * setopt() function would still return "OK" though so the
32- application couldn't tell that this is happening.
33-
34- Users who truly need pipelining from that version will need to modify the code
35- (ever so slightly) and rebuild.
36-
37- ### Removal
38-
39- Six months later, in sync with the planned release happen in April 2019,
40- (might be 7.66.0), assuming no major riots have occurred due to this in the
41- mean time, we rip out the pipelining code. It is in the order of 1000 lines of
42- libcurl code.
43-
44- Left to answer: should the * setopt() function start to return error when these
45- options are set to be able to tell when they're trying to use options that are
46- no longer around or should we maintain behavior as much as possible?
47-
488## ` CURLOPT_DNS_USE_GLOBAL_CACHE `
499
5010This option makes libcurl use a global non-thread-safe cache for DNS if
0 commit comments