Hi

I've been going through the answers people filled in to the last question in
the survey: What bug/feature would you like us to work on next?

We got a lot of "thankyous" in there and also some ramblings that really
didn't contain any suggestions. I've taken the liberty of filtering out some
of those responses.

Otherwise the suggestions are unfiltered. I'm happy for all comments, feedback
or additions you have to any of them.

==========================================
This is what people ask for
==========================================

World domination!

SPDY

More of the same - I think things are ticking along nicely.

libcurl doesn't work at all with Windows SSPI when Negotiate proxy auth is
enabled and a Microsoft Forefront Threat Management Server 2010 proxy is used
- bug #1363

Better polling api.

Easier method attachment

colored output

Full speed file transfers across all protocols, and continued development of
mail handling protocols. Session multiplexing made easy. Applications over
ssh as a transport.

This survey should have a "no basis for judgement" option for the "How good is
the project and its members to handle..." section.

HTTPS: Live CRL checking and OCSP.

HTTPS: Some type of certificate pinning and/or a generic way to evaluate the
certificate chain (independent of SSL backend) would be neat.

Easier build instructions for curl w/NSS on Windows. That seems rather harder
than it should be.

SRV records in HTTP2 implementation. Implement Mark Andrews' draft. It will
push things forward.

Ability to use wildcard and download multiple files without any need for
additional programming.

ZeroMQ support

up-to-date windows binaries by knauf

wget/httrack -like (and js/css/font/etc -aware) addon in the bundle for
recursive fetching

Support for the WinRT-Platform like it is proposed by
https://github.com/martell/libcurl-winrt

easily support [] chars in urls without them being interpreter as a
range. from the CLI.

I think we could have a little more examples. The ones in the website are very
basic. The new stuff seems to not be there sometimes... I hope to be able to
contribute more with libcurl in a near future.

libcurl tcl api crashes in a mysterious manner when -bodyvar and -file options
are both used, even at different times with the same handle. There are a
couple other options which are surprisingly mutually exclusive, and not
documented as such.

My only preference would be if you could offer a generic makefile that would
come close to working on common systems. I am using mingw-w64 on 64-bit
windows. I don't use automake because it introduces a bunch of new
dependencies, but it appears that automake is the only build mechanism
supported for my environment. I managed to find a pre-compiled mingw-w64
version of libcurl elsewhere, and if I had not, I probably would not have used
libcurl. (Although my application was developed on windows, it runs also on
linux, and its libcurl file access has been use to a limited extent on linux.
The standard libcurl package for that linux distribution worked out of the box
with my application.)

Review defaults for non functional reasons. e.g. Connection handling: timeouts
tend to be far too long, allowing software developers that don't consider such
things to freely sink servers. Fall fast, and make people override where
there's just reason...

Cifs support

Curious about latest http/1.1 update in relation to libcurl.

Fix the problem where header files became platform/architecture dependent (a
few years ago), making cross-builds cumbersome even in such a simple scenario
as building 32-bit libcurl on a 64-bit Linux system. It would seem to be a
better solution to detect bitness and other platform dependent stuff
dynamically inside the headers at compile-time. [Sorry if this was sorted out
since.]

control of curl internal buffer sizes, including option to release the buffer
when not needed (such as when waiting for server response). buffer pool would
be a good approach (as done with openssl MODE_RELEASE_BUFFER).

I'd really like to be able to use curl as a raw tcp socket too (with optional
ssl)

Continue your excellent support of http and https in the areas of ipv6 and
SPDY

I used easy interface for a long time, but once tried multy for the one of my
C++ projects and had a lot of problems with it. There are was a race condition
in host resolving and main thread on Windows, so all FTP connections
failed. Latest release seems to fix it, but another bug has appeared -
url_open example, on which based my FTP streaming solution, stop working with
latest libcurl on Windows. There are infinite loop in socket reading. So I
stop using multy interface at all and switch to easy interface with my own
threading implementation. I was very surprised as there are so buggy multy
interface implementation on Windows. The same code works great on Unix. So I
discovered libcurl is not so good for crossplatform development

Rsync copy, delta is not needed

Recursive down/uploads for [s]ftp

Honestly, curl/libcurl already has support for everything that I want so
far. The one time that it didn't support something (XOAUTH2), I was able to
implement it easily. The process took less than a week from start to finish,
and that is with having never seen the curl source prior, and with me being a
rather novice programmer.

Docs and tutorial about non HTTP/FTP protocols. How to work with
imap/smtp/telnet ...

the progress bar does not always show up when the file is downloaded 100%

My biggest issue is that the key feature I need is only available with the
OpenSSL backend. For my application (and frankly most others, they just don't
actually care enough), it's essential to be able to control validation of the
server's key while setting up a TLS connection. Without that feature, use of
TLS is completely unsafe for applications, and right now that's OpenSSL
only. So the portability to other back-ends is both not useful, and has
actually caused bugs in the OpenSSL back-end because of the complexity of
supporting the others.

Ability to generate more than 2 threads for FTP transfer.

Finer control over HTTP Digest authentication, connection reuse, pipelining.

More vigilant tracking/updating of the examples when the API
changes. (e.g. examples using deprecated functions)

Better support for windows protocols like ldap and socks

I use Pan for NNTP(S), post large binaries etc with the 'yencee' Perl script
found on Sourceforge with my own modifications.

I use wget for Shoutcast / Icecast streams (seems good enough, haven't tried
curl).

The main problem with NNTP(S) is the posting phase: we might get an error
(usually network) that will require a 'retransmission' at the interrupted
point, we've been able to recode parts of 'yencee' to handle some kinds of
this, but I'd much rather have a 'fully native' proggie written in C (not C++
nor any scripting language if at all possible).

I think the CLI of curl is clunky, some effort should be put into modernizing
it. But maybe it's just the documentation. I only use curl for simple stuff,
because of the bad doc I consider PUT/POST something complicated with
curl. But you know what, many libraries in that field are overly
complicated. Go's http client is cool ;)

There should be a list of constants for option numbers, etc. instead of
macros: for languages that don't understand them it's laborious to translate
them. It would be nice to get json support in cli

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html