Code layout
The curl source code tree is neither large nor complicated. A key thing to
remember is, perhaps, that libcurl is the library and that library is the
biggest component of the curl command-line tool.
root
We try to keep the number of files in the source tree root to a minimum. You
will see a slight difference in files if you check a release archive compared
to what is stored in the git repository as several files are generated by the
release scripts.
Some of the more notable ones include:
buildconf
: used to build configure and more when
building curl from source out of the git repository.buildconf.bat
: the Windows version of buildconf. Run this after having
checked out the full source code from git.CHANGES
: generated at release and put into the release archive. It
contains the 1000 latest changes to the source repository.configure
: a generated script that is used on Unix-like systems to
generate a setup when building curl.COPYING
: the license detailing the rules for your using the code.GIT-INFO
: only present in git and contains information about how to
build curl after having checked out the code from git.maketgz
: the script used to produce release archives and daily snapshotsREADME
: a short summary of what curl and libcurl are.RELEASE-NOTES
: contains the changes done for the latest release; when
found in git it contains the changes done since the previous release that
are destined to end up in the coming release.
lib
This directory contains the full source code for libcurl. It is the same
source code for all platforms—over one hundred C source files and a few more
private header files. The header files used when building applications against
libcurl are not stored in this directory; see include/curl for those.
Depending on what features are enabled in your own build and what
functions your platform provides, some of the source files or portions of the
source files may contain code that is not used in your particular build.
lib/vtls
The VTLS sub section within libcurl is the home of all the TLS backends
libcurl can be built to support. The “virtual” TLS internal API is a common
API that is used within libcurl to access TLS and crypto functions without the
main code knowing exactly which TLS library that is used. This allows the
person who builds libcurl to select from a wide variety TLS libraries to build
with.
We also maintain a SSL comparison
table on the web site to aid
users.
- OpenSSL: the (by far) most popular TLS library.
- BoringSSL: an OpenSSL fork maintained by Google. It will make libcurl disable a
few features due to lacking some functionality in the library. - LibreSSL: an OpenSSL fork maintained by the OpenBSD team.
- NSS: a full-blown TLS library perhaps most known for being used by the
Firefox web browser. This is the default TLS backend for curl on Fedora and
Redhat systems. - GnuTLS: a full-blown TLS library used by default by the Debian packaged curl.
- mbedTLS: (formerly known as PolarSSL) is a TLS library more targeted
towards the embedded market. - WolfSSL: (formerly known as cyaSSL) is a TLS library more targeted
towards the embedded market. - axTLS: a minuscule TLS library focused on a requiring a small footprint.
- Schannel: the native TLS library on Windows.
- SecureTransport: the native TLS library on Mac OS X.
- GSKit: the native TLS library on OS/400.
src
This directory holds the source code for the curl command-line tool. It is the
same source code for all platforms that run the tool.
Most of what the command-line tool does is to convert given command line
options into the corresponding libcurl options or set of options and then makes
sure to issue them correctly to drive the network transfer according to the
user’s wishes.
This code uses libcurl just as any other application would.
include/curl
Here are the public header files that are provided for libcurl-using
applications. Some of them are generated at configure or release time so they
do not look identical in the git repository as they do in a release archive.
With modern libcurl, all an application is expected to include in its C source code
is #include <curl/curl.h>
docs
The main documentation location. Text files in this directory are typically
plain text files. We have slowly started to move towards Markdown format so a
few (but hopefully growing number of) files use the .md extension to signify
that.
Most of these documents are also shown on the curl web site automatically
converted from text to a web friendly format/look.
BINDINGS
: lists all known libcurl language bindings and where to find themBUGS
: how to report bugs and whereCODE_OF_CONDUCT.md
: how we expect people to behave in this projectCONTRIBUTE
: what to think about when contributing to the projectcurl.1
: the curl command-line tool man page, in nroff formatcurl-config.1
: the curl-config man page, in nroff formatFAQ
: frequently asked questions about various curl-related subjectsFEATURES
: an incomplete list of curl featuresHISTORY
: describes how the project started and has evolved over the yearsHTTP2.md
: how to use HTTP/2 with curl and libcurlHTTP-COOKIES
: how curl supports and works with HTTP cookiesindex.html
: a basic HTML page as a documentation index pageINSTALL
: how to build and install curl and libcurl from sourceINSTALL.cmake
: how to build curl and libcurl with CMakeINSTALL.devcpp
: how to build curl and libcurl with devcppINTERNALS
: details curl and libcurl internal structuresKNOWN_BUGS
: list of known bugs and problemsLICENSE-MIXING
: describes how to combine different third party modules and
their individual licensesMAIL-ETIQUETTE
: this is how to communicate on our mailing listsMANUAL
: a tutorial-like guide on how to use curlmk-ca-bundle.1
: the mk-ca-bundle tool man page, in nroff formatREADME.cmake
: CMake-specific detailsREADME.netware
: Netware-specific detailsREADME.win32
: win32-specific detailsRELEASE-PROCEDURE
: how to do a curl and libcurl releaseRESOURCES
: further resources for further reading on what, why and how curl
does thingsROADMAP.md
: what we want to work on in the futureSECURITY
: how we work on security vulnerabilitiesSSLCERTS
: TLS certificate handling documentedSSL-PROBLEMS
: common SSL problems and their causesTHANKS
: thanks to this extensive list of friendly people, curl exists today!TheArtOfHttpScripting
: a tutorial into HTTP scripting with curlTODO
: things we or you can work on implementingVERSIONS
: how the version numbering of libcurl works
docs/libcurl
All libcurl functions have their own man pages in individual files with .3
extensions, using nroff format, in this directory. The are also a few other
files that are described below.
ABI
index.html
libcurl.3
libcurl-easy.3
libcurl-errors.3
libcurl.m4
libcurl-multi.3
libcurl-share.3
libcurl-thread.3
libcurl-tutorial.3
symbols-in-versions
docs/libcurl/opts
This directory contains the man pages for the individual options for three
different libcurl functions.
curl_easy_setopt()
options start with CURLOPT_
,curl_multi_setopt()
options start with CURLMOPT_
andcurl_easy_getinfo()
options start with CURLINFO_
.
docs/examples
Contains around 100 stand-alone examples that are meant to help readers
understand how libcurl can be used.
See also the libcurl examples section of this book.
scripts
Handy scripts.
contributors.sh
: extracts all contributors from the git repository since a
given hash/tag. The purpose is to generate a list for the RELEASE-NOTES file
and to allow manually added names to remain in there even on updates. The
script uses the ‘THANKS-filter` file to rewrite some names.contrithanks.sh
: extracts contributors from the git repository since a
given hash/tag, filters out all the names that are already mentioned inTHANKS
, and then outputsTHANKS
to stdout with the list of new
contributors appended at the end; it’s meant to allow easier updates of the THANKS
document. The script uses the ‘THANKS-filter` file to rewrite some names.log2changes.pl
: generates theCHANGES
file for releases, as used by the
release script. It simply converts git log output.zsh.pl
: helper script to provide curl command-line completions to users of
the zsh shell.