1# Items to be removed from future curl releases 2 3If any of these deprecated features is a cause for concern for you, please 4email the curl-library mailing list as soon as possible and explain to us why 5this is a problem for you and how your use case can't be satisfied properly 6using a work around. 7 8## HTTP pipelining 9 10HTTP pipelining is badly supported by curl in the sense that we have bugs and 11it is a fragile feature without enough tests. Also, when something turns out 12to have problems it is really tricky to debug due to the timing sensitivity so 13very often enabling debug outputs or similar completely changes the nature of 14the behavior and things are not reproducing anymore! 15 16HTTP pipelining was never enabled by default by the large desktop browsers due 17to all the issues with it. Both Firefox and Chrome have also dropped 18pipelining support entirely since a long time back now. We are in fact over 19time becoming more and more lonely in supporting pipelining. 20 21The bad state of HTTP pipelining was a primary driving factor behind HTTP/2 22and its multiplexing feature. HTTP/2 multiplexing is truly and really 23"pipelining done right". It is way more solid, practical and solves the use 24case in a better way with better performance and fewer downsides and problems. 25 26In 2018, pipelining *should* be abandoned and HTTP/2 should be used instead. 27 28### State 29 30In 7.62.0, we will add code that ignores the "enable pipeline" option 31setting). The *setopt() function would still return "OK" though so the 32application couldn't tell that this is happening. 33 34Users who truly need pipelining from that version will need to modify the code 35(ever so slightly) and rebuild. 36 37### Removal 38 39Six 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 41mean time, we rip out the pipelining code. It is in the order of 1000 lines of 42libcurl code. 43 44Left to answer: should the *setopt() function start to return error when these 45options are set to be able to tell when they're trying to use options that are 46no longer around or should we maintain behavior as much as possible? 47 48## `CURLOPT_DNS_USE_GLOBAL_CACHE` 49 50This option makes libcurl use a global non-thread-safe cache for DNS if 51enabled. The option has been marked as "obsolete" in the header file and in 52documentation for several years already. 53 54There's proper and safe method alternative provided since many years: the 55share API. 56 57### State 58 59In curl 7.62.0 setting this option to TRUE will not have any effect. The 60global cache will not be enabled. The code still remains so it is easy to 61revert if need be. 62 63### Removal 64 65Remove all global-cache related code from curl around April 2019 (might be 667.66.0). 67 68## HTTP/0.9 69 70Supporting this is non-obvious and might even come as a surprise to some 71users. Potentially even being a security risk in some cases. 72 73### State 74 75curl 7.64.0 introduces options to disable/enable support for this protocol 76version. The default remains supported for now. 77 78### Removal 79 80The support for HTTP/0.9 will be switched to disabled by default in 6 months, 81in the September 2019 release (possibly called curl 7.68.0). 82