libcurl - What Makes It Special
Solid and Reliable!
libcurl was released in its current "incarnation" in the year 2000 and it has been in constant use by a large number of applications and companies ever since. Sure there have been bugs and even a few security-related flaws, but it has remained a very solid and reliable library and lots of users are still using libcurl versions released many years ago as they stick with what works.
libcurl is the most used C-based highly portable transfer library in the world. Some of the world's biggest companies use libcurl in high volume applications. Some of the open source applications using libcurl are very widely used.
libcurl has been ported to numerous platforms and CPUs. libcurl offers the same API and feature set on all of them! Using libcurl assures you that you can write your application to work on very large amount of systems, including but not limited to Solaris, NetBSD, FreeBSD, OpenBSD, Darwin, HPUX, IRIX, AIX, Tru64, Linux, UnixWare, HURD, Windows, Amiga, OS/2, BeOs, Mac OS X, Ultrix, QNX, OpenVMS, RISC OS, Novell NetWare, DOS and more...
libcurl is thread safe but there are a few exceptions. Refer to libcurl-thread(3) for more information.
Unmatched Set of Features!
There simply is no other HTTP and FTP library that can boast the same amount and set of features that libcurl does. Be it free or commercial.
Also, libcurl's unique offer of both a pull and push interface allows applications to use it exactly the way they please.
If compiled with IPv6 support enabled, All protocols work splendidly on IPv6 stacks. There are some minor quirks to keep in mind: kerberos4 does not work over IPv6 by design and the SOCKS4 support is not properly adapted for IPv6.
There is nothing in particular needed to get IPv6 to be used, the library API remains exactly the same and adjusts to IPv4/Ipv6 dynamicly. You can use host names that only have AAAA DNS records, or you can use IPv6 IP-only style addresses like [::1].
We claim libcurl is well supported because you can get help on one of the mailing lists, very quickly and accurately. Often within a few hours. Having the mailing list archives available on the web also makes them searchable and allows you to find already mentioned solutions and answers.
We have a public bug tracker and known bugs are mostly fixed very swiftly.
We also provide very detailed documentation on all operations, not just in every release archive but also available on the web site(s).
You can get paid support from one of the listed curl support companies.
Tests performed by independent users, have proved libcurl to be equally fast, up to a lot faster than libwww in comparable test cases.
When using libcurl bindings, you will get unmatched speeds due to libcurl being programmed in C and very often the language-specific alternatives (be it perl, Python, PHP, tcl or whatever) are much slower.
TODO: add references to hard facts here. If you have any or know any comparisons with real-world numbers, then please let us know!
All functions in libcurl have their own detailed man pages describing their actual functionality and purpose.
There is a libcurl tutorial.
We have numerous commented source code examples.
Stable API and ABI
In the libcurl development we take API and ABI stability very seriously. We have a few rules when it comes to API and ABI compatibility and they are:
- We don't break API or ABI compatibility
- Seriously, we really don't and we work very hard to provide alternatives that introduce new ways instead of breaking old
- A few times in the beginning of our project we felt forced to break existing behavior and we did API and ABI bumps. It was painful and hard and bad and we really really don't want to do it again. Ever! We have not done it since 2006.