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