40b8cc8ec19a8a0ee53409ec5174c5b1baad9059
[platform/upstream/curl.git] / docs / TODO
1                                   _   _ ____  _
2                               ___| | | |  _ \| |
3                              / __| | | | |_) | |
4                             | (__| |_| |  _ <| |___
5                              \___|\___/|_| \_\_____|
6
7                 Things that could be nice to do in the future
8
9  Things to do in project cURL. Please tell us what you think, contribute and
10  send us patches that improve things!
11
12  Be aware that these are things that we could do, or have once been considered
13  things we could do. If you want to work on any of these areas, please
14  consider bringing it up for discussions first on the mailing list so that we
15  all agree it is still a good idea for the project!
16
17  All bugs documented in the KNOWN_BUGS document are subject for fixing!
18
19  1. libcurl
20  1.2 More data sharing
21  1.3 struct lifreq
22  1.4 signal-based resolver timeouts
23  1.5 get rid of PATH_MAX
24  1.6 Modified buffer size approach
25  1.7 Detect when called from within callbacks
26  1.8 Allow SSL (HTTPS) to proxy
27  1.9 Cache negative name resolves
28  1.10 Support IDNA2008
29  1.11 minimize dependencies with dynamicly loaded modules
30  1.12 have form functions use CURL handle argument
31  1.14 Typesafe curl_easy_setopt()
32  1.15 Monitor connections in the connection pool
33  1.16 Try to URL encode given URL
34  1.17 Add support for IRIs
35  1.18 try next proxy if one doesn't work
36  1.19 Timeout idle connections from the pool
37  1.20 SRV and URI DNS records
38  1.21 API for URL parsing/splitting
39  1.23 Offer API to flush the connection pool
40
41  2. libcurl - multi interface
42  2.1 More non-blocking
43  2.2 Better support for same name resolves
44  2.3 Non-blocking curl_multi_remove_handle()
45  2.4 Split connect and authentication process
46  2.5 Edge-triggered sockets should work
47
48  3. Documentation
49  3.1 Update date and version in man pages
50  3.2 Provide cmake config-file
51
52  4. FTP
53  4.1 HOST
54  4.2 Alter passive/active on failure and retry
55  4.3 Earlier bad letter detection
56  4.4 REST for large files
57  4.5 ASCII support
58  4.6 GSSAPI via Windows SSPI
59  4.7 STAT for LIST without data connection
60
61  5. HTTP
62  5.1 Better persistency for HTTP 1.0
63  5.2 support FF3 sqlite cookie files
64  5.3 Rearrange request header order
65  5.4 Use huge HTTP/2 windows
66  5.5 auth= in URLs
67  5.6 Refuse "downgrade" redirects
68  5.7 Brotli compression
69  5.8 QUIC
70
71  6. TELNET
72  6.1 ditch stdin
73  6.2 ditch telnet-specific select
74  6.3 feature negotiation debug data
75  6.4 send data in chunks
76
77  7. SMTP
78  7.1 Pipelining
79  7.2 Enhanced capability support
80  7.3 Add CURLOPT_MAIL_CLIENT option
81
82  8. POP3
83  8.1 Pipelining
84  8.2 Enhanced capability support
85
86  9. IMAP
87  9.1 Enhanced capability support
88
89  10. LDAP
90  10.1 SASL based authentication mechanisms
91
92  11. SMB
93  11.1 File listing support
94  11.2 Honor file timestamps
95  11.3 Use NTLMv2
96  11.4 Create remote directories
97
98  12. New protocols
99  12.1 RSYNC
100
101  13. SSL
102  13.1 Disable specific versions
103  13.2 Provide mutex locking API
104  13.3 Evaluate SSL patches
105  13.4 Cache OpenSSL contexts
106  13.5 Export session ids
107  13.6 Provide callback for cert verification
108  13.7 improve configure --with-ssl
109  13.8 Support DANE
110  13.9 Support TLS v1.3
111
112  14. GnuTLS
113  14.1 SSL engine stuff
114  14.2 check connection
115
116  15. WinSSL/SChannel
117  15.1 Add support for client certificate authentication
118  15.2 Add support for custom server certificate validation
119  15.3 Add support for the --ciphers option
120
121  16. SASL
122  16.1 Other authentication mechanisms
123  16.2 Add QOP support to GSSAPI authentication
124  16.3 Support binary messages (i.e.: non-base64)
125
126  17. SSH protocols
127  17.1 Multiplexing
128  17.2 SFTP performance
129
130  18. Command line tool
131  18.1 sync
132  18.2 glob posts
133  18.3 prevent file overwriting
134  18.4 simultaneous parallel transfers
135  18.5 provide formpost headers
136  18.6 warning when setting an option
137  18.7 warning when sending binary output to terminal
138  18.8 offer color-coded HTTP header output
139  18.9 Choose the name of file in braces for complex URLs
140  18.10 improve how curl works in a windows console window
141  18.11 -w output to stderr
142  18.12 keep running, read instructions from pipe/socket
143  18.13 support metalink in http headers
144  18.14 --fail without --location should treat 3xx as a failure
145
146  19. Build
147  19.1 roffit
148
149  20. Test suite
150  20.1 SSL tunnel
151  20.2 nicer lacking perl message
152  20.3 more protocols supported
153  20.4 more platforms supported
154  20.5 Add support for concurrent connections
155  20.6 Use the RFC6265 test suite
156
157  21. Next SONAME bump
158  21.1 http-style HEAD output for FTP
159  21.2 combine error codes
160  21.3 extend CURLOPT_SOCKOPTFUNCTION prototype
161
162  22. Next major release
163  22.1 cleanup return codes
164  22.2 remove obsolete defines
165  22.3 size_t
166  22.4 remove several functions
167  22.5 remove CURLOPT_FAILONERROR
168  22.6 remove CURLOPT_DNS_USE_GLOBAL_CACHE
169  22.7 remove progress meter from libcurl
170  22.8 remove 'curl_httppost' from public
171
172 ==============================================================================
173
174 1. libcurl
175
176 1.2 More data sharing
177
178  curl_share_* functions already exist and work, and they can be extended to
179  share more. For example, enable sharing of the ares channel and the
180  connection cache.
181
182 1.3 struct lifreq
183
184  Use 'struct lifreq' and SIOCGLIFADDR instead of 'struct ifreq' and
185  SIOCGIFADDR on newer Solaris versions as they claim the latter is obsolete.
186  To support IPv6 interface addresses for network interfaces properly.
187
188 1.4 signal-based resolver timeouts
189
190  libcurl built without an asynchronous resolver library uses alarm() to time
191  out DNS lookups. When a timeout occurs, this causes libcurl to jump from the
192  signal handler back into the library with a sigsetjmp, which effectively
193  causes libcurl to continue running within the signal handler. This is
194  non-portable and could cause problems on some platforms. A discussion on the
195  problem is available at https://curl.haxx.se/mail/lib-2008-09/0197.html
196
197  Also, alarm() provides timeout resolution only to the nearest second. alarm
198  ought to be replaced by setitimer on systems that support it.
199
200 1.5 get rid of PATH_MAX
201
202  Having code use and rely on PATH_MAX is not nice:
203  http://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html
204
205  Currently the SSH based code uses it a bit, but to remove PATH_MAX from there
206  we need libssh2 to properly tell us when we pass in a too small buffer and
207  its current API (as of libssh2 1.2.7) doesn't.
208
209 1.6 Modified buffer size approach
210
211  Current libcurl allocates a fixed 16K size buffer for download and an
212  additional 16K for upload. They are always unconditionally part of the easy
213  handle. If CRLF translations are requested, an additional 32K "scratch
214  buffer" is allocated. A total of 64K transfer buffers in the worst case.
215
216  First, while the handles are not actually in use these buffers could be freed
217  so that lingering handles just kept in queues or whatever waste less memory.
218
219  Secondly, SFTP is a protocol that needs to handle many ~30K blocks at once
220  since each need to be individually acked and therefore libssh2 must be
221  allowed to send (or receive) many separate ones in parallel to achieve high
222  transfer speeds. A current libcurl build with a 16K buffer makes that
223  impossible, but one with a 512K buffer will reach MUCH faster transfers. But
224  allocating 512K unconditionally for all buffers just in case they would like
225  to do fast SFTP transfers at some point is not a good solution either.
226
227  Dynamically allocate buffer size depending on protocol in use in combination
228  with freeing it after each individual transfer? Other suggestions?
229
230 1.7 Detect when called from within callbacks
231
232  We should set a state variable before calling callbacks, so that we
233  subsequently can add code within libcurl that returns error if called within
234  callbacks for when that's not supported.
235
236 1.8 Allow SSL (HTTPS) to proxy
237
238  To prevent local users from snooping on your traffic to the proxy. Supported
239  by Firefox and Chrome already:
240  https://www.chromium.org/developers/design-documents/secure-web-proxy
241
242  See this stale work in progress branch:
243  https://github.com/curl/curl/tree/HTTPS-proxy based on this PR:
244  https://github.com/curl/curl/pull/305
245
246 1.9 Cache negative name resolves
247
248  A name resolve that has failed is likely to fail when made again within a
249  short period of time. Currently we only cache positive responses.
250
251 1.10 Support IDNA2008
252
253  International Domain Names are supported in libcurl since years back, powered
254  by libidn. libidn implements IDNA2003 which has been superseded by IDNA2008.
255  libidn2 is an existing library offering support for IDNA2008.
256
257 1.11 minimize dependencies with dynamicly loaded modules
258
259  We can create a system with loadable modules/plug-ins, where these modules
260  would be the ones that link to 3rd party libs. That would allow us to avoid
261  having to load ALL dependencies since only the necessary ones for this
262  app/invoke/used protocols would be necessary to load.  See
263  https://github.com/curl/curl/issues/349
264
265 1.12 have form functions use CURL handle argument
266
267  curl_formadd() and curl_formget() both currently have no CURL handle
268  argument, but both can use a callback that is set in the easy handle, and
269  thus curl_formget() with callback cannot function without first having
270  curl_easy_perform() (or similar) called - which is hard to grasp and a design
271  mistake.
272
273  The curl_formadd() design can probably also be reconsidered to make it easier
274  to use and less error-prone. Probably easiest by splitting it into several
275  function calls.
276
277 1.14 Typesafe curl_easy_setopt()
278
279  One of the most common problems in libcurl using applications is the lack of
280  type checks for curl_easy_setopt() which happens because it accepts varargs
281  and thus can take any type.
282
283  One possible solution to this is to introduce a few different versions of the
284  setopt version for the different kinds of data you can set.
285
286   curl_easy_set_num() - sets a long value
287
288   curl_easy_set_large() - sets a curl_off_t value
289
290   curl_easy_set_ptr() - sets a pointer
291
292   curl_easy_set_cb() - sets a callback PLUS its callback data
293
294 1.15 Monitor connections in the connection pool
295
296  libcurl's connection cache or pool holds a number of open connections for the
297  purpose of possible subsequent connection reuse. It may contain a few up to a
298  significant amount of connections. Currently, libcurl leaves all connections
299  as they are and first when a connection is iterated over for matching or
300  reuse purpose it is verified that it is still alive.
301
302  Those connections may get closed by the server side for idleness or they may
303  get a HTTP/2 ping from the peer to verify that they're still alive. By adding
304  monitoring of the connections while in the pool, libcurl can detect dead
305  connections (and close them) better and earlier, and it can handle HTTP/2
306  pings to keep such ones alive even when not actively doing transfers on them.
307
308 1.16 Try to URL encode given URL
309
310  Given a URL that for example contains spaces, libcurl could have an option
311  that would try somewhat harder than it does now and convert spaces to %20 and
312  perhaps URL encoded byte values over 128 etc (basically do what the redirect
313  following code already does).
314
315  https://github.com/curl/curl/issues/514
316
317 1.17 Add support for IRIs
318
319  IRIs (RFC 3987) allow localized, non-ascii, names in the URL. To properly
320  support this, curl/libcurl would need to translate/encode the given input
321  from the input string encoding into percent encoded output "over the wire".
322
323  To make that work smoothly for curl users even on Windows, curl would
324  probably need to be able to convert from several input encodings.
325
326 1.18 try next proxy if one doesn't work
327
328  Allow an application to specify a list of proxies to try, and failing to
329  connect to the first go on and try the next instead until the list is
330  exhausted. Browsers support this feature at least when they specify proxies
331  using PACs.
332
333  https://github.com/curl/curl/issues/896
334
335 1.19 Timeout idle connections from the pool
336
337  libcurl currently keeps connections in its connection pool for an indefinite
338  period of time, until it either gets reused, gets noticed that it has been
339  closed by the server or gets pruned to make room for a new connection.
340
341  To reduce overhead (especially for when we add monitoring of the connections
342  in the pool), we should introduce a timeout so that connections that have
343  been idle for N seconds get closed.
344
345 1.20 SRV and URI DNS records
346
347  Offer support for resolving SRV and URI DNS records for libcurl to know which
348  server to connect to for various protocols (including HTTP!).
349
350 1.21 API for URL parsing/splitting
351
352  libcurl has always parsed URLs internally and never exposed any API or
353  features to allow applications to do it. Still most or many applications
354  using libcurl need that ability. In polls to users, we've learned that many
355  libcurl users would like to see and use such an API.
356
357 1.23 Offer API to flush the connection pool
358
359  Sometimes applications want to flush all the existing connections kept alive.
360  An API could allow a forced flush or just a forced loop that would properly
361  close all connections that have been closed by the server already.
362
363
364 2. libcurl - multi interface
365
366 2.1 More non-blocking
367
368  Make sure we don't ever loop because of non-blocking sockets returning
369  EWOULDBLOCK or similar. Blocking cases include:
370
371  - Name resolves on non-windows unless c-ares is used
372  - NSS SSL connections
373  - HTTP proxy CONNECT operations
374  - SOCKS proxy handshakes
375  - file:// transfers
376  - TELNET transfers
377  - The "DONE" operation (post transfer protocol-specific actions) for the
378    protocols SFTP, SMTP, FTP. Fixing Curl_done() for this is a worthy task.
379
380 2.2 Better support for same name resolves
381
382  If a name resolve has been initiated for name NN and a second easy handle
383  wants to resolve that name as well, make it wait for the first resolve to end
384  up in the cache instead of doing a second separate resolve. This is
385  especially needed when adding many simultaneous handles using the same host
386  name when the DNS resolver can get flooded.
387
388 2.3 Non-blocking curl_multi_remove_handle()
389
390  The multi interface has a few API calls that assume a blocking behavior, like
391  add_handle() and remove_handle() which limits what we can do internally. The
392  multi API need to be moved even more into a single function that "drives"
393  everything in a non-blocking manner and signals when something is done. A
394  remove or add would then only ask for the action to get started and then
395  multi_perform() etc still be called until the add/remove is completed.
396
397 2.4 Split connect and authentication process
398
399  The multi interface treats the authentication process as part of the connect
400  phase. As such any failures during authentication won't trigger the relevant
401  QUIT or LOGOFF for protocols such as IMAP, POP3 and SMTP.
402
403 2.5 Edge-triggered sockets should work
404
405  The multi_socket API should work with edge-triggered socket events. One of
406  the internal actions that need to be improved for this to work perfectly is
407  the 'maxloops' handling in transfer.c:readwrite_data().
408
409 3. Documentation
410
411 3.1 Update date and version in man pages
412
413  'maketgz' or another suitable script could update the .TH sections of the man
414  pages at release time to use the current date and curl/libcurl version
415  number.
416
417 3.2 Provide cmake config-file
418
419  A config-file package is a set of files provided by us to allow applications
420  to write cmake scripts to find and use libcurl easier. See
421  https://github.com/curl/curl/issues/885
422
423 4. FTP
424
425 4.1 HOST
426
427  HOST is a command for a client to tell which host name to use, to offer FTP
428  servers named-based virtual hosting:
429
430  https://tools.ietf.org/html/rfc7151
431
432 4.2 Alter passive/active on failure and retry
433
434  When trying to connect passively to a server which only supports active
435  connections, libcurl returns CURLE_FTP_WEIRD_PASV_REPLY and closes the
436  connection. There could be a way to fallback to an active connection (and
437  vice versa). https://curl.haxx.se/bug/feature.cgi?id=1754793
438
439 4.3 Earlier bad letter detection
440
441  Make the detection of (bad) %0d and %0a codes in FTP URL parts earlier in the
442  process to avoid doing a resolve and connect in vain.
443
444 4.4 REST for large files
445
446  REST fix for servers not behaving well on >2GB requests. This should fail if
447  the server doesn't set the pointer to the requested index. The tricky
448  (impossible?) part is to figure out if the server did the right thing or not.
449
450 4.5 ASCII support
451
452  FTP ASCII transfers do not follow RFC959. They don't convert the data
453  accordingly.
454
455 4.6 GSSAPI via Windows SSPI
456
457 In addition to currently supporting the SASL GSSAPI mechanism (Kerberos V5)
458 via third-party GSS-API libraries, such as Heimdal or MIT Kerberos, also add
459 support for GSSAPI authentication via Windows SSPI.
460
461 4.7 STAT for LIST without data connection
462
463 Some FTP servers allow STAT for listing directories instead of using LIST, and
464 the response is then sent over the control connection instead of as the
465 otherwise usedw data connection: http://www.nsftools.com/tips/RawFTP.htm#STAT
466
467 This is not detailed in any FTP specification.
468
469 5. HTTP
470
471 5.1 Better persistency for HTTP 1.0
472
473  "Better" support for persistent connections over HTTP 1.0
474  https://curl.haxx.se/bug/feature.cgi?id=1089001
475
476 5.2 support FF3 sqlite cookie files
477
478  Firefox 3 is changing from its former format to a a sqlite database instead.
479  We should consider how (lib)curl can/should support this.
480  https://curl.haxx.se/bug/feature.cgi?id=1871388
481
482 5.3 Rearrange request header order
483
484  Server implementors often make an effort to detect browser and to reject
485  clients it can detect to not match. One of the last details we cannot yet
486  control in libcurl's HTTP requests, which also can be exploited to detect
487  that libcurl is in fact used even when it tries to impersonate a browser, is
488  the order of the request headers. I propose that we introduce a new option in
489  which you give headers a value, and then when the HTTP request is built it
490  sorts the headers based on that number. We could then have internally created
491  headers use a default value so only headers that need to be moved have to be
492  specified.
493
494 5.4 Use huge HTTP/2 windows
495
496  We're currently using nghttp2's default window size which is terribly small
497  (64K). This becomes a bottle neck over high bandwidth networks. We should
498  instead make the window size to be very big (512MB?) as we really don't do
499  much flow control anyway.
500
501 5.5 auth= in URLs
502
503  Add the ability to specify the preferred authentication mechanism to use by
504  using ;auth=<mech> in the login part of the URL.
505
506  For example:
507
508  http://test:pass;auth=NTLM@example.com would be equivalent to specifying --user
509  test:pass;auth=NTLM or --user test:pass --ntlm from the command line.
510
511  Additionally this should be implemented for proxy base URLs as well.
512
513 5.6 Refuse "downgrade" redirects
514
515  See https://github.com/curl/curl/issues/226
516
517  Consider a way to tell curl to refuse to "downgrade" protocol with a redirect
518  and/or possibly a bit that refuses redirect to change protocol completely.
519
520 5.7 Brotli compression
521
522  Compression algorithms that perform better than gzip are being considered for
523  use and inclusion in existing browsers. For example 'brotli'. If servers
524  follow along it is a good reason for us to also allow users to take advantage
525  of this. The algorithm: https://github.com/google/brotli The Firefox bug:
526  https://bugzilla.mozilla.org/show_bug.cgi?id=366559
527
528 5.8 QUIC
529
530  The standardization process of QUIC has been taken to the IETF and can be
531  followed on the [IETF QUIC Mailing
532  list](https://www.ietf.org/mailman/listinfo/quic). I'd like us to get on the
533  bandwagon. Ideally, this would be done with a separate library/project to
534  handle the binary/framing layer in a similar fashion to how HTTP/2 is
535  implemented. This, to allow other projects to benefit from the work and to
536  thus broaden the interest and chance of others to participate.
537
538
539 6. TELNET
540
541 6.1 ditch stdin
542
543 Reading input (to send to the remote server) on stdin is a crappy solution for
544 library purposes. We need to invent a good way for the application to be able
545 to provide the data to send.
546
547 6.2 ditch telnet-specific select
548
549  Move the telnet support's network select() loop go away and merge the code
550  into the main transfer loop. Until this is done, the multi interface won't
551  work for telnet.
552
553 6.3 feature negotiation debug data
554
555   Add telnet feature negotiation data to the debug callback as header data.
556
557 6.4 send data in chunks
558
559   Currently, telnet sends data one byte at a time.  This is fine for interactive
560   use, but inefficient for any other.  Sent data should be sent in larger
561   chunks.
562
563 7. SMTP
564
565 7.1 Pipelining
566
567  Add support for pipelining emails.
568
569 7.2 Enhanced capability support
570
571  Add the ability, for an application that uses libcurl, to obtain the list of
572  capabilities returned from the EHLO command.
573
574 7.3 Add CURLOPT_MAIL_CLIENT option
575
576  Rather than use the URL to specify the mail client string to present in the
577  HELO and EHLO commands, libcurl should support a new CURLOPT specifically for
578  specifying this data as the URL is non-standard and to be honest a bit of a
579  hack ;-)
580
581  Please see the following thread for more information:
582  https://curl.haxx.se/mail/lib-2012-05/0178.html
583
584
585 8. POP3
586
587 8.1 Pipelining
588
589  Add support for pipelining commands.
590
591 8.2 Enhanced capability support
592
593  Add the ability, for an application that uses libcurl, to obtain the list of
594  capabilities returned from the CAPA command.
595
596 9. IMAP
597
598 9.1 Enhanced capability support
599
600  Add the ability, for an application that uses libcurl, to obtain the list of
601  capabilities returned from the CAPABILITY command.
602
603 10. LDAP
604
605 10.1 SASL based authentication mechanisms
606
607  Currently the LDAP module only supports ldap_simple_bind_s() in order to bind
608  to an LDAP server. However, this function sends username and password details
609  using the simple authentication mechanism (as clear text). However, it should
610  be possible to use ldap_bind_s() instead specifying the security context
611  information ourselves.
612
613 11. SMB
614
615 11.1 File listing support
616
617 Add support for listing the contents of a SMB share. The output should probably
618 be the same as/similar to FTP.
619
620 11.2 Honor file timestamps
621
622 The timestamp of the transferred file should reflect that of the original file.
623
624 11.3 Use NTLMv2
625
626 Currently the SMB authentication uses NTLMv1.
627
628 11.4 Create remote directories
629
630 Support for creating remote directories when uploading a file to a directory
631 that doesn't exist on the server, just like --ftp-create-dirs.
632
633 12. New protocols
634
635 12.1 RSYNC
636
637  There's no RFC for the protocol or an URI/URL format.  An implementation
638  should most probably use an existing rsync library, such as librsync.
639
640 13. SSL
641
642 13.1 Disable specific versions
643
644  Provide an option that allows for disabling specific SSL versions, such as
645  SSLv2 https://curl.haxx.se/bug/feature.cgi?id=1767276
646
647 13.2 Provide mutex locking API
648
649  Provide a libcurl API for setting mutex callbacks in the underlying SSL
650  library, so that the same application code can use mutex-locking
651  independently of OpenSSL or GnutTLS being used.
652
653 13.3 Evaluate SSL patches
654
655  Evaluate/apply Gertjan van Wingerde's SSL patches:
656  https://curl.haxx.se/mail/lib-2004-03/0087.html
657
658 13.4 Cache OpenSSL contexts
659
660  "Look at SSL cafile - quick traces look to me like these are done on every
661  request as well, when they should only be necessary once per SSL context (or
662  once per handle)". The major improvement we can rather easily do is to make
663  sure we don't create and kill a new SSL "context" for every request, but
664  instead make one for every connection and re-use that SSL context in the same
665  style connections are re-used. It will make us use slightly more memory but
666  it will libcurl do less creations and deletions of SSL contexts.
667
668 13.5 Export session ids
669
670  Add an interface to libcurl that enables "session IDs" to get
671  exported/imported. Cris Bailiff said: "OpenSSL has functions which can
672  serialise the current SSL state to a buffer of your choice, and recover/reset
673  the state from such a buffer at a later date - this is used by mod_ssl for
674  apache to implement and SSL session ID cache".
675
676 13.6 Provide callback for cert verification
677
678  OpenSSL supports a callback for customised verification of the peer
679  certificate, but this doesn't seem to be exposed in the libcurl APIs. Could
680  it be? There's so much that could be done if it were!
681
682 13.7 improve configure --with-ssl
683
684  make the configure --with-ssl option first check for OpenSSL, then GnuTLS,
685  then NSS...
686
687 13.8 Support DANE
688
689  DNS-Based Authentication of Named Entities (DANE) is a way to provide SSL
690  keys and certs over DNS using DNSSEC as an alternative to the CA model.
691  https://www.rfc-editor.org/rfc/rfc6698.txt
692
693  An initial patch was posted by Suresh Krishnaswamy on March 7th 2013
694  (https://curl.haxx.se/mail/lib-2013-03/0075.html) but it was a too simple
695  approach. See Daniel's comments:
696  https://curl.haxx.se/mail/lib-2013-03/0103.html . libunbound may be the
697  correct library to base this development on.
698
699  Björn Stenberg wrote a separate initial take on DANE that was never
700  completed.
701
702 13.9 Support TLS v1.3
703
704  TLS version 1.3 is about to ship and is getting implemented by TLS libraries
705  as we speak. We should start to support the symbol and make sure all backends
706  handle it accordingly, then gradually add support as the TLS libraries add
707  the corresponding support. There may be a need to add some additional options
708  to allow libcurl to take advantage of the new features in 1.3.
709
710
711 14. GnuTLS
712
713 14.1 SSL engine stuff
714
715  Is this even possible?
716
717 14.2 check connection
718
719  Add a way to check if the connection seems to be alive, to correspond to the
720  SSL_peak() way we use with OpenSSL.
721
722 15. WinSSL/SChannel
723
724 15.1 Add support for client certificate authentication
725
726  WinSSL/SChannel currently makes use of the OS-level system and user
727  certificate and private key stores. This does not allow the application
728  or the user to supply a custom client certificate using curl or libcurl.
729
730  Therefore support for the existing -E/--cert and --key options should be
731  implemented by supplying a custom certificate to the SChannel APIs, see:
732  - Getting a Certificate for Schannel
733    https://msdn.microsoft.com/en-us/library/windows/desktop/aa375447.aspx
734
735 15.2 Add support for custom server certificate validation
736
737  WinSSL/SChannel currently makes use of the OS-level system and user
738  certificate trust store. This does not allow the application or user to
739  customize the server certificate validation process using curl or libcurl.
740
741  Therefore support for the existing --cacert or --capath options should be
742  implemented by supplying a custom certificate to the SChannel APIs, see:
743  - Getting a Certificate for Schannel
744    https://msdn.microsoft.com/en-us/library/windows/desktop/aa375447.aspx
745
746 15.3 Add support for the --ciphers option
747
748  The cipher suites used by WinSSL/SChannel are configured on an OS-level
749  instead of an application-level. This does not allow the application or
750  the user to customize the configured cipher suites using curl or libcurl.
751
752  Therefore support for the existing --ciphers option should be implemented
753  by mapping the OpenSSL/GnuTLS cipher suites to the SChannel APIs, see
754  - Specifying Schannel Ciphers and Cipher Strengths
755    https://msdn.microsoft.com/en-us/library/windows/desktop/aa380161.aspx
756
757 16. SASL
758
759 16.1 Other authentication mechanisms
760
761  Add support for other authentication mechanisms such as OLP,
762  GSS-SPNEGO and others.
763
764 16.2 Add QOP support to GSSAPI authentication
765
766  Currently the GSSAPI authentication only supports the default QOP of auth
767  (Authentication), whilst Kerberos V5 supports both auth-int (Authentication
768  with integrity protection) and auth-conf (Authentication with integrity and
769  privacy protection).
770
771 16.3 Support binary messages (i.e.: non-base64)
772
773   Mandatory to support LDAP SASL authentication.
774
775
776 17. SSH protocols
777
778 17.1 Multiplexing
779
780  SSH is a perfectly fine multiplexed protocols which would allow libcurl to do
781  multiple parallel transfers from the same host using the same connection,
782  much in the same spirit as HTTP/2 does. libcurl however does not take
783  advantage of that ability but will instead always create a new connection for
784  new transfers even if an existing connection already exists to the host.
785
786  To fix this, libcurl would have to detect an existing connection and "attach"
787  the new transfer to the existing one.
788
789 17.2 SFTP performance
790
791  libcurl's SFTP transfer performance is sub par and can be improved, mostly by
792  the approach mentioned in "1.6 Modified buffer size approach".
793
794 18. Command line tool
795
796 18.1 sync
797
798  "curl --sync http://example.com/feed[1-100].rss" or
799  "curl --sync http://example.net/{index,calendar,history}.html"
800
801  Downloads a range or set of URLs using the remote name, but only if the
802  remote file is newer than the local file. A Last-Modified HTTP date header
803  should also be used to set the mod date on the downloaded file.
804
805 18.2 glob posts
806
807  Globbing support for -d and -F, as in 'curl -d "name=foo[0-9]" URL'.
808  This is easily scripted though.
809
810 18.3 prevent file overwriting
811
812  Add an option that prevents cURL from overwriting existing local files. When
813  used, and there already is an existing file with the target file name
814  (either -O or -o), a number should be appended (and increased if already
815  existing). So that index.html becomes first index.html.1 and then
816  index.html.2 etc.
817
818 18.4 simultaneous parallel transfers
819
820  The client could be told to use maximum N simultaneous parallel transfers and
821  then just make sure that happens. It should of course not make more than one
822  connection to the same remote host. This would require the client to use the
823  multi interface. https://curl.haxx.se/bug/feature.cgi?id=1558595
824
825  Using the multi interface would also allow properly using parallel transfers
826  with HTTP/2 and supporting HTTP/2 server push from the command line.
827
828 18.5 provide formpost headers
829
830  Extending the capabilities of the multipart formposting. How about leaving
831  the ';type=foo' syntax as it is and adding an extra tag (headers) which
832  works like this: curl -F "coolfiles=@fil1.txt;headers=@fil1.hdr" where
833  fil1.hdr contains extra headers like
834
835    Content-Type: text/plain; charset=KOI8-R"
836    Content-Transfer-Encoding: base64
837    X-User-Comment: Please don't use browser specific HTML code
838
839  which should overwrite the program reasonable defaults (plain/text,
840  8bit...)
841
842 18.6 warning when setting an option
843
844  Display a warning when libcurl returns an error when setting an option.
845  This can be useful to tell when support for a particular feature hasn't been
846  compiled into the library.
847
848 18.7 warning when sending binary output to terminal
849
850  Provide a way that prompts the user for confirmation before binary data is
851  sent to the terminal, much in the style 'less' does it.
852
853 18.8 offer color-coded HTTP header output
854
855  By offering different color output on the header name and the header
856  contents, they could be made more readable and thus help users working on
857  HTTP services.
858
859 18.9 Choose the name of file in braces for complex URLs
860
861  When using braces to download a list of URLs and you use complicated names
862  in the list of alternatives, it could be handy to allow curl to use other
863  names when saving.
864
865  Consider a way to offer that. Possibly like
866  {partURL1:name1,partURL2:name2,partURL3:name3} where the name following the
867  colon is the output name.
868
869  See https://github.com/curl/curl/issues/221
870
871 18.10 improve how curl works in a windows console window
872
873  If you pull the scrollbar when transferring with curl in a Windows console
874  window, the transfer is interrupted and can get disconnected. This can
875  probably be improved. See https://github.com/curl/curl/issues/322
876
877 18.11 -w output to stderr
878
879  -w is quite useful, but not to those of us who use curl without -o or -O
880  (such as for scripting through a higher level language). It would be nice to
881  have an option that is exactly like -w but sends it to stderr
882  instead. Proposed name: --write-stderr. See
883  https://github.com/curl/curl/issues/613
884
885 18.12 keep running, read instructions from pipe/socket
886
887  Provide an option that makes curl not exit after the last URL (or even work
888  without a given URL), and then make it read instructions passed on a pipe or
889  over a socket to make further instructions so that a second subsequent curl
890  invoke can talk to the still running instance and ask for transfers to get
891  done, and thus maintain its connection pool, DNS cache and more.
892
893 18.13 support metalink in http headers
894
895  Curl has support for downloading a metalink xml file, processing it, and then
896  downloading the target of the metalink. This is done via the --metalink option.
897  It would be nice if metalink also supported downloading via metalink
898  information that is stored in HTTP headers (RFC 6249). Theoretically this could
899  also be supported with the --metalink option.
900
901  See https://tools.ietf.org/html/rfc6249
902
903  See also https://lists.gnu.org/archive/html/bug-wget/2015-06/msg00034.html for
904  an implematation of this in wget.
905
906 18.14 --fail without --location should treat 3xx as a failure
907
908  To allow a command line like this to detect a redirect and consider it a
909  failure:
910
911     curl -v --fail -O https://example.com/curl-7.48.0.tar.gz
912
913  ... --fail must treat 3xx responses as failures too. The least problematic
914  way to implement this is probably to add that new logic in the command line
915  tool only and not in the underlying CURLOPT_FAILONERROR logic.
916
917
918 19. Build
919
920 19.1 roffit
921
922  Consider extending 'roffit' to produce decent ASCII output, and use that
923  instead of (g)nroff when building src/tool_hugehelp.c
924
925 20. Test suite
926
927 20.1 SSL tunnel
928
929  Make our own version of stunnel for simple port forwarding to enable HTTPS
930  and FTP-SSL tests without the stunnel dependency, and it could allow us to
931  provide test tools built with either OpenSSL or GnuTLS
932
933 20.2 nicer lacking perl message
934
935  If perl wasn't found by the configure script, don't attempt to run the tests
936  but explain something nice why it doesn't.
937
938 20.3 more protocols supported
939
940  Extend the test suite to include more protocols. The telnet could just do FTP
941  or http operations (for which we have test servers).
942
943 20.4 more platforms supported
944
945  Make the test suite work on more platforms. OpenBSD and Mac OS. Remove
946  fork()s and it should become even more portable.
947
948 20.5 Add support for concurrent connections
949
950  Tests 836, 882 and 938 were designed to verify that separate connections aren't
951  used when using different login credentials in protocols that shouldn't re-use
952  a connection under such circumstances.
953
954  Unfortunately, ftpserver.pl doesn't appear to support multiple concurrent
955  connections. The read while() loop seems to loop until it receives a disconnect
956  from the client, where it then enters the waiting for connections loop. When
957  the client opens a second connection to the server, the first connection hasn't
958  been dropped (unless it has been forced - which we shouldn't do in these tests)
959  and thus the wait for connections loop is never entered to receive the second
960  connection.
961
962 20.6 Use the RFC6265 test suite
963
964  A test suite made for HTTP cookies (RFC 6265) by Adam Barth is available at
965  https://github.com/abarth/http-state/tree/master/tests
966
967  It'd be really awesome if someone would write a script/setup that would run
968  curl with that test suite and detect deviances. Ideally, that would even be
969  incorporated into our regular test suite.
970
971
972 21. Next SONAME bump
973
974 21.1 http-style HEAD output for FTP
975
976  #undef CURL_FTP_HTTPSTYLE_HEAD in lib/ftp.c to remove the HTTP-style headers
977  from being output in NOBODY requests over FTP
978
979 21.2 combine error codes
980
981  Combine some of the error codes to remove duplicates.  The original
982  numbering should not be changed, and the old identifiers would be
983  macroed to the new ones in an CURL_NO_OLDIES section to help with
984  backward compatibility.
985
986  Candidates for removal and their replacements:
987
988     CURLE_FILE_COULDNT_READ_FILE => CURLE_REMOTE_FILE_NOT_FOUND
989
990     CURLE_FTP_COULDNT_RETR_FILE => CURLE_REMOTE_FILE_NOT_FOUND
991
992     CURLE_FTP_COULDNT_USE_REST => CURLE_RANGE_ERROR
993
994     CURLE_FUNCTION_NOT_FOUND => CURLE_FAILED_INIT
995
996     CURLE_LDAP_INVALID_URL => CURLE_URL_MALFORMAT
997
998     CURLE_TFTP_NOSUCHUSER => CURLE_TFTP_ILLEGAL
999
1000     CURLE_TFTP_NOTFOUND => CURLE_REMOTE_FILE_NOT_FOUND
1001
1002     CURLE_TFTP_PERM => CURLE_REMOTE_ACCESS_DENIED
1003
1004 21.3 extend CURLOPT_SOCKOPTFUNCTION prototype
1005
1006  The current prototype only provides 'purpose' that tells what the
1007  connection/socket is for, but not any protocol or similar. It makes it hard
1008  for applications to differentiate on TCP vs UDP and even HTTP vs FTP and
1009  similar.
1010
1011 22. Next major release
1012
1013 22.1 cleanup return codes
1014
1015  curl_easy_cleanup() returns void, but curl_multi_cleanup() returns a
1016  CURLMcode. These should be changed to be the same.
1017
1018 22.2 remove obsolete defines
1019
1020  remove obsolete defines from curl/curl.h
1021
1022 22.3 size_t
1023
1024  make several functions use size_t instead of int in their APIs
1025
1026 22.4 remove several functions
1027
1028  remove the following functions from the public API:
1029
1030  curl_getenv
1031
1032  curl_mprintf (and variations)
1033
1034  curl_strequal
1035
1036  curl_strnequal
1037
1038  They will instead become curlx_ - alternatives. That makes the curl app
1039  still capable of using them, by building with them from source.
1040
1041  These functions have no purpose anymore:
1042
1043  curl_multi_socket
1044
1045  curl_multi_socket_all
1046
1047 22.5 remove CURLOPT_FAILONERROR
1048
1049  Remove support for CURLOPT_FAILONERROR, it has gotten too kludgy and weird
1050  internally. Let the app judge success or not for itself.
1051
1052 22.6 remove CURLOPT_DNS_USE_GLOBAL_CACHE
1053
1054  Remove support for a global DNS cache. Anything global is silly, and we
1055  already offer the share interface for the same functionality but done
1056  "right".
1057
1058 22.7 remove progress meter from libcurl
1059
1060  The internally provided progress meter output doesn't belong in the library.
1061  Basically no application wants it (apart from curl) but instead applications
1062  can and should do their own progress meters using the progress callback.
1063
1064  The progress callback should then be bumped as well to get proper 64bit
1065  variable types passed to it instead of doubles so that big files work
1066  correctly.
1067
1068 22.8 remove 'curl_httppost' from public
1069
1070  curl_formadd() was made to fill in a public struct, but the fact that the
1071  struct is public is never really used by application for their own advantage
1072  but instead often restricts how the form functions can or can't be modified.
1073
1074  Changing them to return a private handle will benefit the implementation and
1075  allow us much greater freedoms while still maintaining a solid API and ABI.