mirror of
https://github.com/moparisthebest/curl
synced 2024-11-05 00:55:04 -05:00
78 lines
3.1 KiB
Markdown
78 lines
3.1 KiB
Markdown
|
# Items to be removed from future curl releases
|
||
|
|
|
||
|
|
If any of these deprecations is a cause for concern for you, please 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.
|
||
|
|
|
||
|
|
## axTLS backend
|
||
|
|
|
||
|
|
Here are some complaints on axTLS.
|
||
|
|
|
||
|
|
- home page without HTTPS
|
||
|
|
- doesn't support modern TLS features like SNI? [1]
|
||
|
|
- lacks support for modern ciphers [5]
|
||
|
|
- doesn't allow for outside bug report submissions [2]
|
||
|
|
- there's virtually no discussion about it on [3] and [4]
|
||
|
|
|
||
|
|
Combined, this list hints that this is not a library and project we should
|
||
|
|
recommend to users.
|
||
|
|
|
||
|
|
[1] = https://github.com/dsheets/axtls/issues/2
|
||
|
|
[2] = https://sourceforge.net/p/axtls/bugs/
|
||
|
|
[3] = https://sourceforge.net/p/axtls/discussion/
|
||
|
|
[4] = https://sourceforge.net/p/axtls/mailman/axtls-general/
|
||
|
|
[5] = https://github.com/micropython/micropython/issues/3198
|
||
|
|
|
||
|
|
### State
|
||
|
|
|
||
|
|
Since June 1st (curl 7.61.0) axTLS support is disabled in code and
|
||
|
|
requires a small code change to build without errors.
|
||
|
|
|
||
|
|
### Removal
|
||
|
|
|
||
|
|
Remove all axTLS related code from curl on December 1st, exactly six months
|
||
|
|
after previouslt mentioned commit. To be shiped on December 26 (possibly
|
||
|
|
called version 7.64.0)
|
||
|
|
|
||
|
|
## 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 sensitivy 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 (release planned to happen in September 2018), we 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?
|