libcurl
Docs
ABI All functions API Bindings Competitors Examples Features Mailing list Related libs Using libcurl Security Symbols Tutorial Testimonials
curl / libcurl / What Makes It Special

libcurl - What Makes It Special

Related:
License

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.

Widely Used

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.

We estimate that every internet connected human on the globe uses (lib)curl, knowingly or not, every day.

Portable

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, macOS, Ultrix, QNX, OpenVMS, RISC OS, Novell NetWare, DOS and more...

Thread Safe

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.

libcurl also offers an unmatched set of bindings, enabling you to access and use libcurl from basically whatever language you can think of.

Supports IPv6

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 dynamically. You can use hostnames that only have AAAA DNS records, or you can use IPv6 IP-only style addresses like [::1].

Well Supported

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 website(s).

You can get paid support from one of the listed curl support companies.

Since the code is free and available, any skilled programmer can fix and improve the tool and library whenever. If you cannot, you can hire one.

Fast

Tests performed by independent users, have repeatedly proved libcurl to be fast.

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.

Thoroughly Documented

All functions in libcurl have their own detailed manpages describing their actual functionality and purpose.

All interfaces have overview-style manpages describing the concepts that glue all the functions together: easy, multi, share and URL parsing.

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:

  1. We do not break API or ABI compatibility
  2. Seriously, we really do not and we work very hard to provide alternatives that introduce new ways instead of breaking old
  3. 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 do not want to do it again. Ever. We have not done it since 2006.