"Fossies" - the Fresh Open Source Software archive 
"Fossies" - the Fresh Open Source Software archive
CURLcode curl_easy_setopt(CURL *handle, CURLoption option, parameter);
Options set with this function call are valid for all forthcoming transfers performed using this handle. The options are not in any way reset between transfers, so if you want subsequent transfers with different options, you must change them between the transfers. You can optionally reset all options back to internal default with curl_easy_reset(3).
Strings passed to libcurl as ’char *’ arguments, are copied by the library; thus the string storage associated to the pointer argument may be overwritten after curl_easy_setopt() returns. Exceptions to this rule are described in the option details below.
Before version 7.17.0, strings were not copied. Instead the user was forced keep them available until libcurl no longer needed them.
The handle is the return code from a curl_easy_init(3) or curl_easy_duphandle(3) call.
You hardly ever want this set in production use, you will almost always want this when you debug/report problems. Another neat option for debugging is the CURLOPT_DEBUGFUNCTION.
Future versions of libcurl are likely to not have any built-in progress meter at all.
If this option is set and libcurl has been built with the standard name resolver, timeouts will not occur while the name resolve takes place. Consider building libcurl with c-ares support to enable asynchronous DNS lookups, which enables nice timeouts for name resolves without signals.
Setting CURLOPT_NOSIGNAL to 1 makes libcurl NOT ask the system to ignore SIGPIPE signals, which otherwise are sent by the system when trying to send data to a socket which is closed in the other end. libcurl makes an effort to never cause such SIGPIPEs to trigger, but some operating systems have no way to avoid them and even on those that have there are some corner cases when they may still happen, contrary to our desire. In addition, using CURLAUTH_NTLM_WB authentication could cause a SIGCHLD signal to be raised.
By default, libcurl uses its internal wildcard matching implementation. You can provide your own matching function by the CURLOPT_FNMATCH_FUNCTION option.
This feature is only supported by the FTP download for now.
A brief introduction of its syntax follows:
ftp://example.com/some/path/photo?.jpeg
- ? - QUESTION MARK
- Question mark matches any (exactly one) character.
ftp://example.com/some/path/[a-z[:upper:]\\].jpeg
- [ - BRACKET EXPRESSION
- The left bracket opens a bracket expression. The question mark and asterisk have no special meaning in a bracket expression. Each bracket expression ends by the right bracket and matches exactly one character. Some examples follow:
[a-zA-Z0-9] or [f-gF-G] - character interval
[abc] - character
enumeration
[^abc] or [!abc] - negation
[[:name:]] class expression. Supported classes are alnum,lower, space, alpha, digit, print, upper, blank, graph, xdigit.
[][-!^] - special case - matches only ’-’, ’]’, ’[’, ’!’ or ’^’. These characters have no special purpose.
[\[\]\\] - escape syntax. Matches ’[’, ’]’ or ’\’.
Using the rules above, a file name pattern can be constructed:
(This was added in 7.21.0)
From 7.18.0, the function can return CURL_WRITEFUNC_PAUSE which then will cause writing to this connection to become paused. See curl_easy_pause(3) for further details.
This function may be called with zero bytes data if the transferred file is empty.
Set this option to NULL to get the internal default function. The internal default function will write the data to the FILE * given with CURLOPT_WRITEDATA.
Set the userdata argument with the CURLOPT_WRITEDATA option.
The callback function will be passed as much data as possible in all invokes, but you cannot possibly make any assumptions. It may be one byte, it may be thousands. The maximum amount of body data that can be passed to the write callback is defined in the curl.h header file: CURL_MAX_WRITE_SIZE (the usual default is 16K). If you however have CURLOPT_HEADER set, which sends header data to the write callback, you can get up to CURL_MAX_HTTP_HEADER bytes of header data passed into it. This usually means 100K.
The internal CURLOPT_WRITEFUNCTION will write the data to the FILE * given with this option, or to stdout if this option hasn’t been set.
If you’re using libcurl as a win32 DLL, you MUST use the CURLOPT_WRITEFUNCTION if you set this option or you will experience crashes.
This option is also known with the older name CURLOPT_FILE, the name CURLOPT_WRITEDATA was introduced in 7.9.7.
If you stop the current transfer by returning 0 "pre-maturely" (i.e before the server expected it, like when you’ve said you will upload N bytes and you upload less than N bytes), you may experience that the server "hangs" waiting for the rest of the data that won’t come.
The read callback may return CURL_READFUNC_ABORT to stop the current operation immediately, resulting in a CURLE_ABORTED_BY_CALLBACK error code from the transfer (Added in 7.12.1)
From 7.18.0, the function can return CURL_READFUNC_PAUSE which then will cause reading from this connection to become paused. See curl_easy_pause(3) for further details.
Bugs: when doing TFTP uploads, you must return the exact amount of data that the callback wants, or it will be considered the final packet by the server end and the transfer will end there.
If you set this callback pointer to NULL, or don’t set it at all, the default internal read function will be used. It is doing an fread() on the FILE * userdata set with CURLOPT_READDATA.
If you’re using libcurl as a win32 DLL, you MUST use a CURLOPT_READFUNCTION if you set this option.
This option was also known by the older name CURLOPT_INFILE, the name CURLOPT_READDATA was introduced in 7.9.7.
Use CURLOPT_SEEKFUNCTION instead to provide seeking!
If you forward the input arguments directly to "fseek" or "lseek", note that the data type for offset is not the same as defined for curl_off_t on many systems! (Option added in 7.18.0)
CURLSOCKTYPE_IPCXN for actively created connections or since 7.28.0 CURLSOCKTYPE_ACCEPT for FTP when the connection was setup with PORT/EPSV (in earlier versions these sockets weren’t passed to this callback).
Future versions of libcurl may support more purposes. It passes the newly created socket descriptor so additional setsockopt() calls can be done at the user’s discretion. Return 0 (zero) from the callback on success. Return 1 from the callback function to signal an unrecoverable error to the library and it will close the socket and return CURLE_COULDNT_CONNECT. (Option added in 7.16.0)
Added in 7.21.5, the callback function may return CURL_SOCKOPT_ALREADY_CONNECTED, which tells libcurl that the socket is in fact already connected and then libcurl will not attempt to connect it.
return socket(addr->family, addr->socktype, addr->protocol);(Option added in 7.17.1.)
If you transfer data with the multi interface, this function will not be called during periods of idleness unless you call the appropriate libcurl function that performs transfers.
CURLOPT_NOPROGRESS must be set to 0 to make this function actually get called.
A complete HTTP header that is passed to this function can be up to CURL_MAX_HTTP_HEADER (100K) bytes.
If this option is not set, or if it is set to NULL, but CURLOPT_HEADERDATA (CURLOPT_WRITEHEADER) is set to anything but NULL, the function used to accept response data will be used instead. That is, it will be the function specified with CURLOPT_WRITEFUNCTION, or if it is not specified or NULL - the default, stream-writing function.
It’s important to note that the callback will be invoked for the headers of all responses received after initiating a request and not just the final response. This includes all responses which occur during authentication negotiation. If you need to operate on only the headers from the final response, you will need to collect headers in the callback yourself and use HTTP status lines, for example, to delimit response boundaries.
When a server sends a chunked encoded transfer, it may contain a trailer. That trailer is identical to a HTTP header and if such a trailer is received it is passed to the application using this callback as well. There are several ways to detect it being a trailer and not an ordinary header: 1) it comes after the response-body. 2) it comes after the final header line (CR LF) 3) a Trailer: header among the regular response-headers mention what header(s) to expect in the trailer.
For non-HTTP protocols like FTP, POP3, IMAP and SMTP this function will get called with the server responses to the commands that libcurl sends.
Available curl_infotype values:
Pass a pointer to a function that matches the following prototype: CURLcode sslctxfun(CURL *curl, void *sslctx, void *parm); This function gets called by libcurl just before the initialization of a SSL connection after having processed all other SSL related options to give a last chance to an application to modify the behaviour of openssl’s ssl initialization. The sslctx parameter is actually a pointer to an openssl SSL_CTX. If an error is returned no attempt to establish a connection is made and the perform operation will return the error code from this callback function. Set the parm argument with the CURLOPT_SSL_CTX_DATA option. This option was introduced in 7.11.0.
This function will get called on all new connections made to a server, during the SSL negotiation. The SSL_CTX pointer will be a new one every time.
To use this properly, a non-trivial amount of knowledge of the openssl libraries is necessary. For example, using this function allows you to use openssl callbacks to add additional validation code for certificates, and even to change the actual URI of a HTTPS request (example used in the lib509 test case). See also the example section for a replacement of the key, certificate and trust file settings.
These three options apply to non-ASCII platforms only. They are available only if CURL_DOES_CONVERSIONS was defined when libcurl was built. When this is the case, curl_version_info(3) will return the CURL_VERSION_CONV feature bit set.
The data to be converted is in a buffer pointed to by the ptr parameter. The amount of data to convert is indicated by the length parameter. The converted data overlays the input data in the buffer pointed to by the ptr parameter. CURLE_OK should be returned upon successful conversion. A CURLcode return value defined by curl.h, such as CURLE_CONV_FAILED, should be returned if an error was encountered.
CURLOPT_CONV_TO_NETWORK_FUNCTION and CURLOPT_CONV_FROM_NETWORK_FUNCTION convert between the host encoding and the network encoding. They are used when commands or ASCII data are sent/received over the network.
CURLOPT_CONV_FROM_UTF8_FUNCTION is called to convert from UTF8 into the host encoding. It is required only for SSL processing.
If you set a callback pointer to NULL, or don’t set it at all, the built-in libcurl iconv functions will be used. If HAVE_ICONV was not defined when libcurl was built, and no callback has been established, conversion will return the CURLE_CONV_REQD error code.
If HAVE_ICONV is defined, CURL_ICONV_CODESET_OF_HOST must also be defined. For example:
#define CURL_ICONV_CODESET_OF_HOST
"IBM-1047"
The iconv code in libcurl will default the network and UTF8 codeset names as follows:
#define CURL_ICONV_CODESET_OF_NETWORK "ISO8859-1"
#define CURL_ICONV_CODESET_FOR_UTF8 "UTF-8"
You will need to override these definitions if they are different on your system.
Interleaved RTP poses some challenges for the client application. Since the stream data is sharing the RTSP control connection, it is critical to service the RTP in a timely fashion. If the RTP data is not handled quickly, subsequent response processing may become unreasonably delayed and the connection may close. The application may use CURL_RTSPREQ_RECEIVE to service RTP data when no requests are desired. If the application makes a request, (e.g. CURL_RTSPREQ_PAUSE) then the response handler will process any pending RTP data before marking the request as finished. (Added in 7.20.0)
This callback makes sense only when using the CURLOPT_WILDCARDMATCH option for now.
The target of transfer_info parameter is a "feature depended" structure. For the FTP wildcard download, the target is curl_fileinfo structure (see curl/curl.h). The parameter ptr is a pointer given by CURLOPT_CHUNK_DATA. The parameter remains contains number of chunks remaining per the transfer. If the feature is not available, the parameter has zero value.
Return CURL_CHUNK_BGN_FUNC_OK if everything is fine, CURL_CHUNK_BGN_FUNC_SKIP if you want to skip the concrete chunk or CURL_CHUNK_BGN_FUNC_FAIL to tell libcurl to stop if some error occurred. (This was added in 7.21.0)
Return CURL_CHUNK_END_FUNC_OK if everything is fine or CURL_CHUNK_END_FUNC_FAIL to tell the lib to stop if some error occurred. (This was added in 7.21.0)
Return CURL_FNMATCHFUNC_MATCH if pattern matches the string, CURL_FNMATCHFUNC_NOMATCH if not or CURL_FNMATCHFUNC_FAIL if an error occurred. (This was added in 7.21.0)
Use CURLOPT_VERBOSE and CURLOPT_DEBUGFUNCTION to better debug/trace why errors happen.
If the library does not return an error, the buffer may not have been touched. Do not rely on the contents in those cases.
This method is not fail-safe and there are occasions where non-successful response codes will slip through, especially when authentication is involved (response codes 401 and 407).
You might get some amounts of headers transferred before this situation is detected, like when a "100-continue" is received as a response to a POST/PUT and a 401 or 407 is received immediately afterwards.
scheme://host:port/path
For a greater explanation of the format please see RFC3986.
If the given URL lacks the scheme, or protocol, part ("http://" or "ftp://" etc), libcurl will attempt to resolve which protocol to use based on the given host mame. If the protocol is not supported, libcurl will return (CURLE_UNSUPPORTED_PROTOCOL) when you call curl_easy_perform(3) or curl_multi_perform(3). Use curl_version_info(3) for detailed information on which protocols are supported.
The host part of the URL contains the address of the server that you want to connect to. This can be the fully qualified domain name of the server, the local network name of the machine on your network or the IP address of the server or machine represented by either an IPv4 or IPv6 address. For example:
http://www.example.com/
http://hostname/
http://192.168.0.1/
http://[2001:1890:1112:1::20]/
It is also possible to specify the user name and password as part of the host, for some protocols, when connecting to servers that require authentication.
For example the following types of authentication support this:
http://user:password@www.example.com
ftp://user:password@ftp.example.com
pop3://user:password@mail.example.com
The port is optional and when not specified libcurl will use the default port based on the determined or specified protocol: 80 for HTTP, 21 for FTP and 25 for SMTP, etc. The following examples show how to specify the port:
http://www.example.com:8080/ - This will connect to a web server using port 8080 rather than 80.
smtp://mail.example.com:587/ - This will connect to a SMTP server on the alternative mail port.
The path part of the URL is protocol specific and whilst some examples are given below this list is not conclusive:
HTTP
The path part of a HTTP request specifies the file to retrieve and from what directory. If the directory is not specified then the web server’s root directory is used. If the file is omitted then the default document will be retrieved for either the directory specified or the root directory. The exact resource returned for each URL is entirely dependent on the server’s configuration.
http://www.example.com - This gets the main page from the web server.
http://www.example.com/index.html - This returns the main page by explicitly requesting it.
http://www.example.com/contactus/ - This returns the default document from the contactus directory.
FTP
The path part of an FTP request specifies the file to retrieve and from what directory. If the file part is omitted then libcurl downloads the directory listing for the directory specified. If the directory is omitted then the directory listing for the root / home directory will be returned.
ftp://ftp.example.com - This retrieves the directory listing for the root directory.
ftp://ftp.example.com/readme.txt - This downloads the file readme.txt from the root directory.
ftp://ftp.example.com/libcurl/readme.txt - This downloads readme.txt from the libcurl directory.
ftp://user:password@ftp.example.com/readme.txt - This retrieves the readme.txt file from the user’s home directory. When a username and password is specified, everything that is specified in the path part is relative to the user’s home directory. To retrieve files from the root directory or a directory underneath the root directory then the absolute path must be specified by prepending an additional forward slash to the beginning of the path.
ftp://user:password@ftp.example.com//readme.txt - This retrieves the readme.txt from the root directory when logging in as a specified user.
SMTP
The path part of a SMTP request specifies the host name to present during communication with the mail server. If the path is omitted then libcurl will attempt to resolve the local computer’s host name. However, this may not return the fully qualified domain name that is required by some mail servers and specifying this path allows you to set an alternative name, such as your machine’s fully qualified domain name, which you might have obtained from an external function such as gethostname or getaddrinfo.
smtp://mail.example.com - This connects to the mail server at example.com and sends your local computer’s host name in the HELO / EHLO command.
smtp://mail.example.com/client.example.com - This will send client.example.com in the HELO / EHLO command to the mail server at example.com.
POP3
The path part of a POP3 request specifies the mailbox (message) to retrieve. If the mailbox is not specified then a list of waiting messages is returned instead.
pop3://user:password@mail.example.com - This lists the available messages pop3://user:password@mail.example.com/1 - This retrieves the first message
SCP
The path part of a SCP request specifies the file to retrieve and from what directory. The file part may not be omitted. The file is taken as an absolute path from the root directory on the server. To specify a path relative to the user’s home directory on the server, prepend ~/ to the path portion. If the user name is not embedded in the URL, it can be set with the CURLOPT_USERPWD or CURLOPT_USERNAME option.
scp://user@example.com/etc/issue - This specifies the file /etc/issue
scp://example.com/~/my-file - This specifies the file my-file in the user’s
home directory on the server
SFTP
The path part of a SFTP request specifies the file to retrieve and from what directory. If the file part is omitted then libcurl downloads the directory listing for the directory specified. If the path ends in a / then a directory listing is returned instead of a file. If the path is omitted entirely then the directory listing for the root / home directory will be returned. If the user name is not embedded in the URL, it can be set with the CURLOPT_USERPWD or CURLOPT_USERNAME option.
sftp://user:password@example.com/etc/issue - This specifies the file
/etc/issue
sftp://user@example.com/~/my-file - This specifies the file my-file
in the user’s home directory
sftp://ssh.example.com/~/Documents/ - This requests
a directory listing of the Documents directory under the user’s home directory
LDAP
The path part of a LDAP request can be used to specify the: Distinguished Name, Attributes, Scope, Filter and Extension for a LDAP search. Each field is separated by a question mark and when that field is not required an empty string with the question mark separator should be included.
ldap://ldap.example.com/o=My%20Organisation - This will perform a LDAP search with the DN as My Organisation.
ldap://ldap.example.com/o=My%20Organisation?postalAddress - This will perform the same search but will only return postalAddress attributes.
ldap://ldap.example.com/?rootDomainNamingContext - This specifies an empty DN and requests information about the rootDomainNamingContext attribute for an Active Directory server.
For more information about the individual components of a LDAP URL please see RFC4516.
NOTES
Starting with version 7.20.0, the fragment part of the URI will not be sent as part of the path, which was previously the case.
CURLOPT_URL is the only option that must be set before curl_easy_perform(3) is called.
CURLOPT_PROTOCOLS can be used to limit what protocols libcurl will use for this transfer, independent of what libcurl has been compiled to support. That may be useful if you accept the URL from an external source and want to limit the accessibility.
When you tell the library to use a HTTP proxy, libcurl will transparently convert operations to HTTP even if you specify an FTP URL etc. This may have an impact on what other features of the library you can use, such as CURLOPT_QUOTE and similar FTP specifics that don’t work unless you tunnel through the HTTP proxy. Such tunneling is activated with CURLOPT_HTTPPROXYTUNNEL.
libcurl respects the environment variables http_proxy, ftp_proxy, all_proxy etc, if any of those are set. The CURLOPT_PROXY option does however override any possibly set environment variables.
Setting the proxy string to "" (an empty string) will explicitly disable the use of a proxy, even if there is an environment variable set for it.
Since 7.14.1, the proxy host string given in environment variables can be specified the exact same way as the proxy can be set with CURLOPT_PROXY, include protocol prefix (http://) and embedded user + password.
Since 7.21.7, the proxy string may be specified with a protocol:// prefix to specify alternative proxy protocols. Use socks4://, socks4a://, socks5:// or socks5h:// (the last one to enable socks5 and asking the proxy to do the resolving, also known as CURLPROXY_SOCKS5_HOSTNAME type) to request the specific SOCKS version to be used. No protocol specified, http:// and all others will be treated as HTTP proxies.
If you set CURLOPT_PROXYTYPE to CURLPROXY_HTTP_1_0, it will only affect how libcurl speaks to a proxy when CONNECT is used. The HTTP version used for "regular" HTTP requests is instead controlled with CURLOPT_HTTP_VERSION.
Starting with 7.24.0: If the parameter starts with "if!" then it is treated as only as interface name and no attempt will ever be named to do treat it as an IP address or to do name resolution on it. If the parameter starts with "host!" it is treated as either an IP address or a hostname. Hostnames are resolved synchronously. Using the if! format is highly recommended when using the multi interfaces to avoid allowing the code to block. If "if!" is specified but the parameter does not match an existing interface, CURLE_INTERFACE_FAILED is returned.
The name resolve functions of various libc implementations don’t re-read name server information unless explicitly told so (for example, by calling res_init(3)). This may cause libcurl to keep using the older server even if DHCP has updated the server info, and this may look like a DNS cache issue to the casual libcurl-app user.
WARNING: this option is considered obsolete. Stop using it. Switch over to using the share interface instead! See CURLOPT_SHARE and curl_share_init(3).
This size is by default set as big as possible (CURL_MAX_WRITE_SIZE), so it only makes sense to use this option if you want it smaller.
Setting this option will disable TCP’s Nagle algorithm. The purpose of this algorithm is to try to minimize the number of small packets on the network (where "small packets" means TCP segments less than the Maximum Segment Size (MSS) for the network).
Maximizing the amount of data sent per TCP segment is good because it amortizes the overhead of the send. However, in some cases (most notably telnet or rlogin) small segments may need to be sent without delay. This is less efficient than sending larger amounts of data at a time, and can contribute to congestion on the network if overdone.
libcurl uses a user name (and supplied or prompted password) supplied with CURLOPT_USERPWD in preference to any of the options controlled by this parameter.
Pass a long, set to one of the values described below.
Undefined values of the option will have this effect.
This is the default.
libcurl does not verify that the file has the correct properties set (as the standard Unix ftp client does). It should only be readable by user.
When using NTLM, you can set the domain by prepending it to the user name and separating the domain and name with a forward (/) or backward slash (\). Like this: "domain/user:password" or "domain\user:password". Some HTTP servers (on Windows) support this style even for Basic authentication.
When using HTTP and CURLOPT_FOLLOWLOCATION, libcurl might perform several requests to possibly different hosts. libcurl will only send this user and password information to hosts using the initial host name (unless CURLOPT_UNRESTRICTED_AUTH is set), so if libcurl follows locations to other hosts it will not send the user and password to those. This is enforced to prevent accidental information leakage.
CURLOPT_USERNAME sets the user name to be used in protocol authentication. You should not use this option together with the (older) CURLOPT_USERPWD option.
In order to specify the password to be used in conjunction with the user name use the CURLOPT_PASSWORD option. (Added in 7.19.1)
The CURLOPT_PASSWORD option should be used in conjunction with the CURLOPT_USERNAME option. (Added in 7.19.1)
The CURLOPT_PROXYUSERNAME option should be used in same way as the CURLOPT_PROXYUSERPWD is used. In comparison to CURLOPT_PROXYUSERPWD the CURLOPT_PROXYUSERNAME allows the username to contain a colon, like in the following example: "sip:user@example.com". The CURLOPT_PROXYUSERNAME option is an alternative way to set the user name while connecting to Proxy. There is no meaning to use it together with the CURLOPT_PROXYUSERPWD option.
In order to specify the password to be used in conjunction with the user name use the CURLOPT_PROXYPASSWORD option. (Added in 7.19.1)
The CURLOPT_PROXYPASSWORD option should be used in conjunction with the CURLOPT_PROXYUSERNAME option. (Added in 7.19.1)
You need to build libcurl with a suitable GSS-API library for this to work.
You need to build libcurl with either OpenSSL, GnuTLS or NSS support for this option to work, or build libcurl on Windows.
Note that libcurl will fork when necessary to run the winbind application and kill it when complete, calling waitpid() to await its exit when done. On POSIX operating systems, killing the process will cause a SIGCHLD signal to be raised (regardless of whether CURLOPT_NOSIGNAL is set), which must be handled intelligently by the application. In particular, the application must not unconditionally call wait() in its SIGCHLD signal handler to avoid being subject to a race condition. This behavior is subject to change in future versions of libcurl.
You need to build libcurl with GnuTLS or OpenSSL with TLS-SRP support for this to work. (Added in 7.21.4)
This is a request, not an order; the server may or may not do it. This option must be set (to any non-NULL value) or else any unsolicited encoding done by the server is ignored. See the special file lib/README.encoding for details.
(This option was called CURLOPT_ENCODING before 7.21.6)
Transfer-Encoding differs slightly from the Content-Encoding you ask for with CURLOPT_ACCEPT_ENCODING in that a Transfer-Encoding is strictly meant to be for the transfer and thus MUST be decoded before the data arrives in the client. Traditionally, Transfer-Encoding has been much less used and supported by both HTTP clients and HTTP servers.
(Added in 7.21.6)
This means that the library will re-send the same request on the new location and follow new Location: headers all the way until no more such headers are returned. CURLOPT_MAXREDIRS can be used to limit the number of redirects libcurl will follow.
Since 7.19.4, libcurl can limit what protocols it will automatically follow. The accepted protocols are set with CURLOPT_REDIR_PROTOCOLS and it excludes the FILE protocol by default.
The non-RFC behaviour is ubiquitous in web browsers, so the library does the conversion by default to maintain consistency. However, a server may require a POST to remain a POST after such a redirection. This option is meaningful only when setting CURLOPT_FOLLOWLOCATION. (Added in 7.17.1) (This option was known as CURLOPT_POST301 up to 7.19.0 as it only supported the 301 then)
This option is deprecated and starting with version 7.12.1 you should instead use CURLOPT_UPLOAD.
Use one of CURLOPT_POSTFIELDS or CURLOPT_COPYPOSTFIELDS options to specify what data to post and CURLOPT_POSTFIELDSIZE or CURLOPT_POSTFIELDSIZE_LARGE to set the data size.
Optionally, you can provide data to POST using the CURLOPT_READFUNCTION and CURLOPT_READDATA options but then you must make sure to not set CURLOPT_POSTFIELDS to anything but NULL. When providing data with a callback, you must transmit it using chunked transfer-encoding or you must set the size of the data with the CURLOPT_POSTFIELDSIZE or CURLOPT_POSTFIELDSIZE_LARGE option. To enable chunked encoding, you simply pass in the appropriate Transfer-Encoding header, see the post-callback.c example.
You can override the default POST Content-Type: header by setting your own with CURLOPT_HTTPHEADER.
Using POST with HTTP 1.1 implies the use of a "Expect: 100-continue" header. You can disable this header with CURLOPT_HTTPHEADER as usual.
If you use POST to a HTTP 1.1 server, you can send data without knowing the size before starting the POST if you use chunked encoding. You enable this by adding a header like "Transfer-Encoding: chunked" with CURLOPT_HTTPHEADER. With HTTP 1.0 or without chunked transfer, you must specify the size in the request.
When setting CURLOPT_POST to 1, it will automatically set CURLOPT_NOBODY to 0 (since 7.14.1).
If you issue a POST request and then want to make a HEAD or GET using the same re-used handle, you must explicitly set the new request type using CURLOPT_NOBODY or CURLOPT_HTTPGET or similar.
The pointed data are NOT copied by the library: as a consequence, they must be preserved by the calling application until the transfer finishes.
This POST is a normal application/x-www-form-urlencoded kind (and libcurl will set that Content-Type by default when this option is used), which is the most commonly used one by HTML forms. See also the CURLOPT_POST. Using CURLOPT_POSTFIELDS implies CURLOPT_POST.
If you want to do a zero-byte POST, you need to set CURLOPT_POSTFIELDSIZE explicitly to zero, as simply setting CURLOPT_POSTFIELDS to NULL or "" just effectively disables the sending of the specified string. libcurl will instead assume that you’ll send the POST data using the read callback!
Using POST with HTTP 1.1 implies the use of a "Expect: 100-continue" header. You can disable this header with CURLOPT_HTTPHEADER as usual.
To make multipart/formdata posts (aka RFC2388-posts), check out the CURLOPT_HTTPPOST option.
Because data are copied, care must be taken when using this option in conjunction with CURLOPT_POSTFIELDSIZE or CURLOPT_POSTFIELDSIZE_LARGE: If the size has not been set prior to CURLOPT_COPYPOSTFIELDS, the data are assumed to be a NUL-terminated string; else the stored size informs the library about the data byte count to copy. In any case, the size must not be changed after CURLOPT_COPYPOSTFIELDS, unless another CURLOPT_POSTFIELDS or CURLOPT_COPYPOSTFIELDS option is issued. (Added in 7.17.1)
Using POST with HTTP 1.1 implies the use of a "Expect: 100-continue" header. You can disable this header with CURLOPT_HTTPHEADER as usual.
When setting CURLOPT_HTTPPOST, it will automatically set CURLOPT_NOBODY to 0 (since 7.14.1).
The first line in a request (containing the method, usually a GET or POST) is not a header and cannot be replaced using this option. Only the lines following the request-line are headers. Adding this method line in this list of headers will only cause your request to send an invalid header.
Pass a NULL to this to reset back to no custom headers.
The most commonly replaced headers have "shortcuts" in the options CURLOPT_COOKIE, CURLOPT_USERAGENT and CURLOPT_REFERER.
The linked list should be a fully valid list of struct curl_slist structs, and be properly filled in. Use curl_slist_append(3) to create the list and curl_slist_free_all(3) to clean up an entire list.
The alias itself is not parsed for any version strings. Before libcurl 7.16.3, Libcurl used the value set by option CURLOPT_HTTP_VERSION, but starting with 7.16.3 the protocol is assumed to match HTTP 1.0 when an alias matched.
If you need to set multiple cookies, you need to set them all using a single option and thus you need to concatenate them all in one single string. Set multiple cookies in one string like this: "name1=content1; name2=content2;" etc.
This option sets the cookie header explicitly in the outgoing request(s). If multiple requests are done due to authentication, followed redirections or similar, they will all get this cookie passed on.
Using this option multiple times will only make the latest string override the previous ones.
Given an empty or non-existing file or by passing the empty string (""), this option will enable cookies for this curl handle, making it understand and parse received cookies and then use matching cookies in future requests.
If you use this option multiple times, you just add more files to read. Subsequent files will add more cookies.
If the cookie jar file can’t be created or written to (when the curl_easy_cleanup(3) is called), libcurl will not and cannot report an error for this. Using CURLOPT_VERBOSE or CURLOPT_DEBUGFUNCTION will get a warning to display, but that is the only visible feedback you get about this possibly lethal situation.
When setting CURLOPT_HTTPGET to 1, it will automatically set CURLOPT_NOBODY to 0 (since 7.14.1).
An originator email address should be specified with angled brackets (<>) around it, which if not specified, will be added by libcurl from version 7.21.4 onwards. Failing to provide such brackets may cause the server to reject the email.
If this parameter is not specified then an empty address will be sent to the mail server which may or may not cause the email to be rejected.
(Added in 7.20.0)
Each recipient should be specified within a pair of angled brackets (<>), however, should you not use an angled bracket as the first character libcurl will assume you provided a single email address and enclose that address within brackets for you.
(Added in 7.20.0)
This optional parameter allows co-operating agents in a trusted environment to communicate the authentication of individual messages and should only be used by the application program, using libcurl, if the application is itself a mail server acting in such an environment. If the application is operating as such and the AUTH address is not known or is invalid, then an empty string should be used for this parameter.
Unlike CURLOPT_MAIL_FROM and CURLOPT_MAIL_RCPT, the address should not be specified within a pair of angled brackets (<>). However, if an empty string is used then a pair of brackets will be sent by libcurl as required by RFC2554.
(Added in 7.25.0)
The address can be followed by a ’:’ to specify a port, optionally followed by a ’-’ to specify a port range. If the port specified is 0, the operating system will pick a free port. If a range is provided and all ports in the range are not available, libcurl will report CURLE_FTP_PORT_FAILED for the handle. Invalid port/range settings are ignored. IPv6 addresses followed by a port or portrange have to be in brackets. IPv6 addresses without port/range specifier can be in brackets. (added in 7.19.5)
Examples with specified ports:
eth0:0 192.168.1.2:32000-33000 curl.se:32123 [::1]:1234-4567
You disable PORT again and go back to using the passive version by setting this option to NULL.
The set of valid FTP commands depends on the server (see RFC959 for a list of mandatory commands).
The valid SFTP commands are: chgrp, chmod, chown, ln, mkdir, pwd, rename, rm, rmdir, symlink (see curl(1)) (SFTP support added in 7.16.3)
This causes an FTP NLST command to be sent on an FTP server. Beware that some FTP servers list only files in their response to NLST; they might not include subdirectories and symbolic links.
Setting this option to 1 also implies a directory listing even if the URL doesn’t end with a slash, which otherwise is necessary.
Do NOT use this option if you also use CURLOPT_WILDCARDMATCH as it will effectively break that feature then.
(This option was known as CURLOPT_FTPLISTONLY up to 7.16.4)
(This option was known as CURLOPT_FTPAPPEND up to 7.16.4)
If the server is an IPv6 host, this option will have no effect as of 7.12.3.
If the server is an IPv6 host, this option will have no effect as of 7.12.3.
This setting also applies to SFTP-connections. curl will attempt to create the remote directory if it can’t obtain a handle to the target-location. The creation will fail if a file of the same name as the directory to create already exists or lack of permissions prevents creation. (Added in 7.16.3)
Starting with 7.19.4, you can also set this value to 2, which will make libcurl retry the CWD command again if the subsequent MKD command fails. This is especially useful if you’re doing many simultaneous connections against the same server and they all have this option enabled, as then CWD may first fail but then another connection does MKD before this connection and thus MKD fails but trying CWD works! 7.19.4 also introduced the CURLFTP_CREATE_DIR and CURLFTP_CREATE_DIR_RETRY enum names for these arguments.
Before version 7.19.4, libcurl will simply ignore arguments set to 2 and act as if 1 was selected.
This option has no effect if PORT, EPRT or EPSV is used instead of PASV.
libcurl does not do a complete ASCII conversion when doing ASCII transfers over FTP. This is a known limitation/flaw that nobody has rectified. libcurl simply sets the mode to ASCII and performs a standard transfer.
Pass a NULL to this option to disable the use of ranges.
Ranges work on HTTP, FTP, FILE (since 7.18.0), and RTSP (since 7.20.0) transfers only.
When doing uploads with FTP, the resume position is where in the local/source file libcurl should try to resume the upload from and it will then append the source file to the remote target file.
Please don’t perform this
at will, on HTTP based requests, by making sure your server supports the
command you are sending first.
When you change the request method by setting CURLOPT_CUSTOMREQUEST to
something, you don’t actually change how libcurl behaves or acts in regards
to the particular request method, it will only change the actual string
sent in the request.
For example:
With the HTTP protocol when you tell libcurl to do a HEAD request, but then specify a GET though a custom request libcurl will still act as if it sent a HEAD. To switch to a proper HEAD use CURLOPT_NOBODY, to switch to a proper POST use CURLOPT_POST or CURLOPT_POSTFIELDS and to switch to a proper GET use CURLOPT_HTTPGET.
With the POP3 protocol when you tell libcurl to use a custom request it will behave like a LIST or RETR command was sent where it expects data to be returned by the server. As such CURLOPT_NOBODY should be used when specifying commands such as DELE and NOOP for example.
Restore to the internal default by setting this to NULL.
Many people have wrongly used this option to replace the entire request with their own, including multiple headers and POST contents. While that might work in many cases, it will cause libcurl to send invalid requests and it could possibly confuse the remote server badly. Use CURLOPT_POST and CURLOPT_POSTFIELDS to set POST data. Use CURLOPT_HTTPHEADER to replace or extend the set of headers sent by libcurl. Use CURLOPT_HTTP_VERSION to change HTTP version.
(Support for POP3 added in 7.26.0)
To change request to GET, you should use CURLOPT_HTTPGET. Change request to POST with CURLOPT_POST etc.
For uploading using SCP, this option or CURLOPT_INFILESIZE_LARGE is mandatory.
When sending emails using SMTP, this command can be used to specify the optional SIZE parameter for the MAIL FROM command. (Added in 7.23.0)
This option does not limit how much data libcurl will actually send, as that is controlled entirely by what the read callback returns.
For uploading using SCP, this option or CURLOPT_INFILESIZE is mandatory.
This option does not limit how much data libcurl will actually send, as that is controlled entirely by what the read callback returns.
Using PUT with HTTP 1.1 implies the use of a "Expect: 100-continue" header. You can disable this header with CURLOPT_HTTPHEADER as usual.
If you use PUT to a HTTP 1.1 server, you can upload data without knowing the size before starting the transfer if you use chunked encoding. You enable this by adding a header like "Transfer-Encoding: chunked" with CURLOPT_HTTPHEADER. With HTTP 1.0 or without chunked transfer, you must specify the size.
The file size is not always known prior to download, and for such files this option has no effect even if the file transfer ends up being larger than this given limit. This concerns both FTP and HTTP transfers.
The file size is not always known prior to download, and for such files this option has no effect even if the file transfer ends up being larger than this given limit. This concerns both FTP and HTTP transfers.
The last modification time of a file is not always known and in such instances this feature will have no effect even if the given time condition would not have been met. curl_easy_getinfo(3) with the CURLINFO_CONDITION_UNMET option can be used after a transfer to learn if a zero-byte successful "transfer" was due to this condition not matching.
In unix-like systems, this might cause signals to be used unless CURLOPT_NOSIGNAL is set.
Default timeout is 0 (zero) which means it never times out.
When reaching the maximum limit, curl closes the oldest one in the cache to prevent increasing the number of open connections.
If you already have performed transfers with this curl handle, setting a smaller MAXCONNECTS than before may cause open connections to get closed unnecessarily.
If you add this easy handle to a multi handle, this setting is not acknowledged, and you must instead use curl_multi_setopt(3) and the CURLMOPT_MAXCONNECTS option.
In unix-like systems, this might cause signals to be used unless CURLOPT_NOSIGNAL is set.
This option is useful with the CURLINFO_LASTSOCKET option to curl_easy_getinfo(3). The library can set up the connection and then the application can obtain the most recently used socket for special data transfers. (Added in 7.15.2)
This is for enabling SSL/TLS when you use FTP, SMTP, POP3, IMAP etc.
(This option was known as CURLOPT_FTP_SSL up to 7.16.4, and the constants were known as CURLFTPSSL_*)
Each single name resolve string should be written using the format HOST:PORT:ADDRESS where HOST is the name libcurl will try to resolve, PORT is the port number of the service where libcurl wants to connect to the HOST and ADDRESS is the numerical IP address. If libcurl is built to support IPv6, ADDRESS can of course be either IPv4 or IPv6 style addressing.
This option effectively pre-populates the DNS cache with entries for the host+port pair so redirects and everything that operations against the HOST+PORT will instead use your provided ADDRESS.
You can remove names from the DNS cache again, to stop providing these fake resolves, by including a string in the linked list that uses the format "-HOST:PORT". The host name must be prefixed with a dash, and the host name and port number must exactly match what was already added previously.
(Added in 7.21.3)
host[:port][,host[:port]]...
For example:
192.168.1.100,192.168.1.101,3.4.5.6
This option requires that libcurl was built with a resolver backend that supports this operation. The c-ares backend is the only such one.
(Added in 7.24.0)
With NSS this can also be the nickname of the certificate you wish to authenticate with. If you want to use a file from the current directory, please precede it with "./" prefix, in order to avoid confusion with a nickname.
The format "ENG" enables you to load the private key from a crypto engine. In this case CURLOPT_SSLKEY is used as an identifier passed to the engine. You have to set the crypto engine with CURLOPT_SSLENGINE. "DER" format key file currently does not work because of a bug in OpenSSL.
(This option was known as CURLOPT_SSLKEYPASSWD up to 7.16.4 and CURLOPT_SSLCERTPASSWD up to 7.9.2)
If the crypto device cannot be loaded, CURLE_SSL_ENGINE_NOTFOUND is returned.
If the crypto device cannot be set, CURLE_SSL_ENGINE_SETFAILED is returned.
Even though this option doesn’t need any parameter, in some configurations curl_easy_setopt might be defined as a macro taking exactly three arguments. Therefore, it’s recommended to pass 1 as parameter to this option.
This option determines whether curl verifies the authenticity of the peer’s certificate. A value of 1 means curl verifies; 0 (zero) means it doesn’t.
When negotiating a SSL connection, the server sends a certificate indicating its identity. Curl verifies whether the certificate is authentic, i.e. that you can trust that the server is who the certificate says it is. This trust is based on a chain of digital signatures, rooted in certification authority (CA) certificates you supply. curl uses a default bundle of CA certificates (the path for that is determined at build time) and you can specify alternate certificates with the CURLOPT_CAINFO option or the CURLOPT_CAPATH option.
When CURLOPT_SSL_VERIFYPEER is nonzero, and the verification fails to prove that the certificate is authentic, the connection fails. When the option is zero, the peer certificate verification succeeds regardless.
Authenticating the certificate is not by itself very useful. You typically want to ensure that the server, as authentically identified by its certificate, is the server you mean to be talking to. Use CURLOPT_SSL_VERIFYHOST to control that. The check that the host name in the certificate is valid for the host name you’re connecting to is done independently of the CURLOPT_SSL_VERIFYPEER option.
This option is by default set to the system path where libcurl’s cacert bundle is assumed to be stored, as established at build time.
When built against NSS, this is the directory that the NSS certificate database resides in.
This option makes sense only when used in combination with the CURLOPT_SSL_VERIFYPEER option. Otherwise, the result of the check is not considered as failure.
A specific error code (CURLE_SSL_ISSUER_ERROR) is defined with the option, which is returned if the setup of the SSL/TLS session has failed due to a mismatch with the issuer of peer certificate (CURLOPT_SSL_VERIFYPEER has to be set too for the check to fail). (Added in 7.19.0)
When curl is built to use NSS or GnuTLS, there is no way to influence the use of CRL passed to help in the verification process. When libcurl is built with OpenSSL support, X509_V_FLAG_CRL_CHECK and X509_V_FLAG_CRL_CHECK_ALL are both set, requiring CRL check against all the elements of the certificate chain if a CRL file is passed.
This option makes sense only when used in combination with the CURLOPT_SSL_VERIFYPEER option.
A specific error code (CURLE_SSL_CRL_BADFILE) is defined with the option. It is returned when the SSL exchange fails because the CRL file cannot be loaded. A failure in certificate verification due to a revocation information found in the CRL does not trigger this specific error. (Added in 7.19.0)
This option determines whether libcurl verifies that the server cert is for the server it is known as.
When negotiating a SSL connection, the server sends a certificate indicating its identity.
When CURLOPT_SSL_VERIFYHOST is 2, that certificate must indicate that the server is the server to which you meant to connect, or the connection fails.
Curl considers the server the intended one when the Common Name field or a Subject Alternate Name field in the certificate matches the host name in the URL to which you told Curl to connect.
When the value is 1, libcurl will return a failure. It was previously (in 7.28.0 and earlier) a debug option of some sorts, but it is no longer supported due to frequently leading to programmer mistakes.
When the value is 0, the connection succeeds regardless of the names in the certificate.
The default value for this option is 2.
This option controls checking the server’s certificate’s claimed identity. The server could be lying. To control lying, see CURLOPT_SSL_VERIFYPEER. If libcurl is built against NSS and CURLOPT_SSL_VERIFYPEER is zero, CURLOPT_SSL_VERIFYHOST is ignored.
For OpenSSL and GnuTLS valid examples of cipher lists include ’RC4-SHA’, ’SHA1+DES’, ’TLSv1’ and ’DEFAULT’. The default list is normally set when you compile OpenSSL.
You’ll find more details about cipher lists on this URL: http://www.openssl.org/docs/apps/ciphers.html
For NSS, valid examples of cipher lists include ’rsa_rc4_128_md5’, ’rsa_aes_128_sha’, etc. With NSS you don’t add/remove ciphers. If one uses this option then all known ciphers are disabled and only those passed in are enabled.
You’ll find more details about the NSS cipher lists on this URL: http://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html#Directives
CURLSSLOPT_ALLOW_BEAST is the only supported bit and by setting this the user will tell libcurl to not attempt to use any workarounds for a security flaw in the SSL3 and TLS1.0 protocols. If this option isn’t used or this bit is set to 0, the SSL layer libcurl uses may use a work-around for this flaw although it might cause interoperability problems with some (older) SSL implementations. WARNING: avoiding this work-around loosens the security, and by setting this option to 1 you ask for exactly that. (Added in 7.25.0)
(This option was known as CURLOPT_KRB4LEVEL up to 7.16.3)
The curl_sshkeycallback function gets passed the CURL handle, the key from the known_hosts file, the key from the remote site, info from libcurl on the matching status and a custom pointer (set with CURLOPT_SSH_KEYDATA). It MUST return one of the following return codes to tell libcurl how to act:
If you add a share that is set to share cookies, your easy handle will use that cookie cache and get the cookie engine enabled. If you unshare an object that was using cookies (or change to another object that doesn’t share cookies), the easy handle will get its cookie engine disabled.
Data that the share object is not set to share will be dealt with the usual way, as if no share was used.
If you try to set an option that libcurl doesn’t know about, perhaps because the library is too old to support it or the option was removed in a recent version, this function will return CURLE_FAILED_INIT.