blob: 681593b61e77deda25a1616b6c556d7b819de0ab (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
# 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?
|
