blob: eb52d1877f48b1b81bc9a5159d712a7fd8c1b919 (
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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
curl the next few years - perhaps
=================================
Roadmap of things Daniel Stenberg and Steve Holme want to work on next. It is
intended to serve as a guideline for others for information, feedback and
possible participation.
HTTP/2
------
- test suite
Base this on existing nghttp2 server to start with to make functional
tests. Later on we can adopt that code or work with nghttp2 to provide ways
to have the http2 server respond with broken responses to make sure we deal
with that nicely as well.
To decide: if we need to bundle parts of the nghttp2 stuff that probably
won't be shipped by many distros.
- stream properties API
Provide options for setting priorities and dependencies among the streams
(easy handles). They are mostly information set for the stream and sent to
the server so we don't have to add much logic for this.
- server push
Not exactly clear exactly how to support this API-wise, but by adding
handles without asking for a resource it could be a way to be prepared to
receive pushes in case such are sent. We probably need it to still specify
a URL with host name, port etc but we probably need a special option to
tell libcurl it is for server push purposes.
- provide option for HTTP/2 "prior knowledge" over clear text
As it would avoid the roundtrip-heavy Upgrade: procedures when you _know_
it speaks HTTP/2.
- provide option to allow curl to default to HTTP/2 only when using HTTPS
We could switch on HTTP/2 by-default for HTTPS quite easily and it
shouldn't hurt anyone, while HTTP/2 for HTTP by default could introduce
lots of Upgrade: roundtrips that users won't like. So a separated option
alternative makes sense.
SRV records
-----------
How to find services for specific domains/hosts.
HTTPS to proxy
--------------
To avoid network traffic to/from the proxy getting snooped on.
curl_formadd()
--------------
make sure there's an easy handle passed in to `curl_formadd()`,
`curl_formget()` and `curl_formfree()` by adding replacement functions and
deprecating the old ones to allow custom mallocs and more
third-party SASL
----------------
add support for third-party SASL libraries such as Cyrus SASL - may need to
move existing native and SSPI based authentication into vsasl folder after
reworking HTTP and SASL code
SASL authentication in LDAP
---------------------------
...
Simplify the SMTP email
-----------------------
Simplify the SMTP email interface so that programmers don't have to
construct the body of an email that contains all the headers, alternative
content, images and attachments - maintain raw interface so that
programmers that want to do this can
email capabilities
------------------
Allow the email protocols to return the capabilities before
authenticating. This will allow an application to decide on the best
authentication mechanism
Win32 pthreads
--------------
Allow Windows threading model to be replaced by Win32 pthreads port
dynamic buffer size
-------------------
Implement a dynamic buffer size to allow SFTP to use much larger buffers and
possibly allow the size to be customizable by applications. Use less memory
when handles are not in use?
New stuff - curl
----------------
1. Embed a language interpreter (lua?). For that middle ground where curl
isn’t enough and a libcurl binding feels “too much”. Build-time conditional
of course.
2. Simplify the SMTP command line so that the headers and multi-part content
don't have to be constructed before calling curl
Improve
-------
1. build for windows (considered hard by many users)
2. curl -h output (considered overwhelming to users)
3. we have > 160 command line options, is there a way to redo things to
simplify or improve the situation as we are likely to keep adding
features/options in the future too
4. docs (considered "bad" by users but how do we make it better?)
- split up curl.1
5. authentication framework (consider merging HTTP and SASL authentication to
give one API for protocols to call)
6. Perform some of the clean up from the TODO document, removing old
definitions and such like that are currently earmarked to be removed years
ago
Remove
------
1. makefile.vc files as there is no point in maintaining two sets of Windows
makefiles. Note: These are currently being used by the Windows autobuilds
|
