curl_easy_setopt - set options for a curl easy handle
#include <curl/curl.h>
CURLcode curl_easy_setopt(CURL *handle, CURLoption option, parameter);
curl_easy_setopt() is used to tell libcurl how to behave. By using the appropriate options to curl_easy_setopt, you can change libcurl's behavior. All options are set with the option followed by a parameter. That parameter can be a long, a function pointer, an object pointer or a curl_off_t, depending on what the specific option expects. Read this manual carefully as bad input values may cause libcurl to behave badly! You can only set one option in each function call. A typical application uses many curl_easy_setopt() calls in the setup phase.
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, will not be copied by the library. Instead you should keep them available until libcurl no longer needs them. Failing to do so will cause very odd behavior or even crashes. libcurl will need them until you call curl_easy_cleanup(3) or you set the same option again to use a different pointer.
The handle is the return code from a curl_easy_init(3) or curl_easy_duphandle(3) call.
Set the parameter to non-zero to get the library to display a lot of verbose information about its operations. Very useful for libcurl and/or protocol debugging and understanding. The verbose information will be sent to stderr, or the stream set with CURLOPT_STDERR.
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.
A non-zero parameter tells the library to include the header in the body output. This is only relevant for protocols that actually have headers preceding the data (like HTTP).
A non-zero parameter tells the library to shut off the built-in progress meter completely.
Future versions of libcurl is likely to not have any built-in progress meter at all.
Pass a long. If it is non-zero, libcurl will not use any functions that install signal handlers or any functions that cause signals to be sent to the process. This option is mainly here to allow multi-threaded unix applications to still set/use all timeout options etc, without risking getting signals. (Added in 7.10)
Consider building libcurl with ares support to enable asynchronous DNS lookups. It enables nice timeouts for name resolves without signals.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as there is data received that needs to be saved. The size of the data pointed to by ptr is size multiplied with nmemb, it will not be zero terminated. Return the number of bytes actually taken care of. If that amount differs from the amount passed to your function, it'll signal an error to the library and it will abort the transfer and return CURLE_WRITE_ERROR.
This function may be called with zero bytes data if the transfered 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 stream 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 data that can be passed to the write callback is defined in the curl.h header file: CURL_MAX_WRITE_SIZE.
Data pointer to pass to the file write function. If you use the CURLOPT_WRITEFUNCTION option, this is the pointer you'll get as input. If you don't use a callback, you must pass a 'FILE *' as libcurl will pass this to fwrite() when writing data.
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.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as it needs to read data in order to send it to the peer. The data area pointed at by the pointer ptr may be filled with at most size multiplied with nmemb number of bytes. Your function must return the actual number of bytes that you stored in that memory area. Returning 0 will signal end-of-file to the library and cause it to stop the current transfer.
If you stop the current transfer by returning 0 "pre-maturely" (i.e before the server expected it, like when you've told 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)
If you set the callback pointer to NULL, or doesn't set it at all, the default internal read function will be used. It is simply doing an fread() on the FILE * stream set with CURLOPT_READDATA.
Data pointer to pass to the file read function. If you use the CURLOPT_READFUNCTION option, this is the pointer you'll get as input. If you don't specify a read callback but instead rely on the default internal read function, this data must be a valid readable FILE *.
If you're using libcurl as a win32 DLL, you MUST use a CURLOPT_READFUNCTION if you set this option.
This option is also known with the older name CURLOPT_INFILE, the name CURLOPT_READDATA was introduced in 7.9.7.
Function pointer that should match the curl_ioctl_callback prototype found in <curl/curl.h>. This function gets called by libcurl when something special I/O-related needs to be done that the library can't do by itself. For now, rewinding the read data stream is the only action it can request. The rewinding of the read data stream may be necessary when doing a HTTP PUT or POST with a multi-pass authentication method. (Opion added in 7.12.3)
Pass a pointer that will be untouched by libcurl and passed as the 3rd argument in the ioctl callback set with CURLOPT_IOCTLFUNCTION. (Option added in 7.12.3)
Function pointer that should match the curl_progress_callback prototype found in <curl/curl.h>. This function gets called by libcurl instead of its internal equivalent with a frequent interval during operation (roughly once per second) no matter if data is being transfered or not. Unknown/unused argument values passed to the callback will be set to zero (like if you only download data, the upload size will remain 0). Returning a non-zero value from this callback will cause libcurl to abort the transfer and return CURLE_ABORTED_BY_CALLBACK.
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. Usage of the CURLOPT_PROGRESSFUNCTION callback is not recommended when using the multi interface.
CURLOPT_NOPROGRESS must be set to FALSE to make this function actually get called.
Pass a pointer that will be untouched by libcurl and passed as the first argument in the progress callback set with CURLOPT_PROGRESSFUNCTION.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream);. This function gets called by libcurl as soon as it has received header data. The header callback will be called once for each header and only complete header lines are passed on to the callback. Parsing headers should be easy enough using this. The size of the data pointed to by ptr is size multiplied with nmemb. Do not assume that the header line is zero terminated! The pointer named stream is the one you set with the CURLOPT_WRITEHEADER option. The callback function must return the number of bytes actually taken care of, or return -1 to signal error to the library (it will cause it to abort the transfer with a CURLE_WRITE_ERROR return code).
Since 7.14.1: 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 response-headers mention what header to expect in the trailer.
(This option is also known as CURLOPT_HEADERDATA) Pass a pointer to be used to write the header part of the received data to. If you don't use your own callback to take care of the writing, this must be a valid FILE *. See also the CURLOPT_HEADERFUNCTION option above on how to set a custom get-all-headers callback.
Function pointer that should match the following prototype: int curl_debug_callback (CURL *, curl_infotype, char *, size_t, void *); CURLOPT_DEBUGFUNCTION replaces the standard debug function used when CURLOPT_VERBOSE is in effect. This callback receives debug information, as specified with the curl_infotype argument. This function must return 0. The data pointed to by the char * passed to this function WILL NOT be zero terminated, but will be exactly of the size as told by the size_t argument.
Available curl_infotype values:
The data is informational text.
The data is header (or header-like) data received from the peer.
The data is header (or header-like) data sent to the peer.
The data is protocol data received from the peer.
The data is protocol data sent to the peer.
Pass a pointer to whatever you want passed in to your CURLOPT_DEBUGFUNCTION in the last void * argument. This pointer is not used by libcurl, it is only passed to the callback.
Function pointer that should match the following prototype: CURLcode sslctxfun(CURL *curl, void *sslctx, void *parm); This function gets called by libcurl just before the initialization of an 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. Using this function allows for example to use openssl callbacks to add additional validation code for certificates, and even to change the actual URI of an 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.
Data pointer to pass to the ssl c transfers. You can optionally reset all options back to internal default with curl_easy_reset(3).
Strings passed to libcurl as 'char *' arguments, will not be copied by the library. Instead you should keep them available until libcurl no longer needs them. Failing to do so will cause very odd behavior or even crashes. libcurl will need them until you call curl_easy_cleanup(3) or you set the same option again to use a different pointer.
The handle is the return code from a curl_easy_init(3) or curl_easy_duphandle(3) call.
Set the parameter to non-zero to get the library to display a lot of verbose information about its operations. Very useful for libcurl and/or protocol debugging and understanding. The verbose information will be sent to stderr, or the stream set with CURLOPT_STDERR.
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.
A non-zero parameter tells the library to include the header in the body output. This is only relevant for protocols that actually have headers preceding the data (like HTTP).
A non-zero parameter tells the library to shut off the built-in progress meter completely.
Future versions of libcurl is likely to not have any built-in progress meter at all.
Pass a long. If it is non-zero, libcurl will not use any functions that install signal handlers or any functions that cause signals to be sent to the process. This option is mainly here to allow multi-threaded unix applications to still set/use all timeout options etc, without risking getting signals. (Added in 7.10)
Consider building libcurl with ares support to enable asynchronous DNS lookups. It enables nice timeouts for name resolves without signals.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as there is data received that needs to be saved. The size of the data pointed to by ptr is size multiplied with nmemb, it will not be zero terminated. Return the number of bytes actually taken care of. If that amount differs from the amount passed to your function, it'll signal an error to the library and it will abort the transfer and return CURLE_WRITE_ERROR.
This function may be called with zero bytes data if the transfered 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 stream 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 data that can be passed to the write callback is defined in the curl.h header file: CURL_MAX_WRITE_SIZE.
Data pointer to pass to the file write function. If you use the CURLOPT_WRITEFUNCTION option, this is the pointer you'll get as input. If you don't use a callback, you must pass a 'FILE *' as libcurl will pass this to fwrite() when writing data.
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.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as it needs to read data in order to send it to the peer. The data area pointed at by the pointer ptr may be filled with at most size multiplied with nmemb number of bytes. Your function must return the actual number of bytes that you stored in that memory area. Returning 0 will signal end-of-file to the library and cause it to stop the current transfer.
If you stop the current transfer by returning 0 "pre-maturely" (i.e before the server expected it, like when you've told 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)
If you set the callback pointer to NULL, or doesn't set it at all, the default internal read function will be used. It is simply doing an fread() on the FILE * stream set with CURLOPT_READDATA.
Data pointer to pass to the file read function. If you use the CURLOPT_READFUNCTION option, this is the pointer you'll get as input. If you don't specify a read callback but instead rely on the default internal read function, this data must be a valid readable FILE *.
If you're using libcurl as a win32 DLL, you MUST use a CURLOPT_READFUNCTION if you set this option.
This option is also known with the older name CURLOPT_INFILE, the name CURLOPT_READDATA was introduced in 7.9.7.
Function pointer that should match the curl_ioctl_callback prototype found in <curl/curl.h>. This function gets called by libcurl when something special I/O-related needs to be done that the library can't do by itself. For now, rewinding the read data stream is the only action it can request. The rewinding of the read data stream may be necessary when doing a HTTP PUT or POST with a multi-pass authentication method. (Opion added in 7.12.3)
Pass a pointer that will be untouched by libcurl and passed as the 3rd argument in the ioctl callback set with CURLOPT_IOCTLFUNCTION. (Option added in 7.12.3)
Function pointer that should match the curl_progress_callback prototype found in <curl/curl.h>. This function gets called by libcurl instead of its internal equivalent with a frequent interval during operation (roughly once per second) no matter if data is being transfered or not. Unknown/unused argument values passed to the callback will be set to zero (like if you only download data, the upload size will remain 0). Returning a non-zero value from this callback will cause libcurl to abort the transfer and return CURLE_ABORTED_BY_CALLBACK.
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. Usage of the CURLOPT_PROGRESSFUNCTION callback is not recommended when using the multi interface.
CURLOPT_NOPROGRESS must be set to FALSE to make this function actually get called.
Pass a pointer that will be untouched by libcurl and passed as the first argument in the progress callback set with CURLOPT_PROGRESSFUNCTION.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream);. This function gets called by libcurl as soon as it has received header data. The header callback will be called once for each header and only complete header lines are passed on to the callback. Parsing headers should be easy enough using this. The size of the data pointed to by ptr is size multiplied with nmemb. Do not assume that the header line is zero terminated! The pointer named stream is the one you set with the CURLOPT_WRITEHEADER option. The callback function must return the number of bytes actually taken care of, or return -1 to signal error to the library (it will cause it to abort the transfer with a CURLE_WRITE_ERROR return code).
Since 7.14.1: 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 response-headers mention what header to expect in the trailer.
(This option is also known as CURLOPT_HEADERDATA) Pass a pointer to be used to write the header part of the received data to. If you don't use your own callback to take care of the writing, this must be a valid FILE *. See also the CURLOPT_HEADERFUNCTION option above on how to set a custom get-all-headers callback.
Function pointer that should match the following prototype: int curl_debug_callback (CURL *, curl_infotype, char *, size_t, void *); CURLOPT_DEBUGFUNCTION replaces the standard debug function used when CURLOPT_VERBOSE is in effect. This callback receives debug information, as specified with the curl_infotype argument. This function must return 0. The data pointed to by the char * passed to this function WILL NOT be zero terminated, but will be exactly of the size as told by the size_t argument.
Available curl_infotype values:
The data is informational text.
The data is header (or header-like) data received from the peer.
The data is header (or header-like) data sent to the peer.
The data is protocol data received from the peer.
The data is protocol data sent to the peer.
Pass a pointer to whatever you want passed in to your CURLOPT_DEBUGFUNCTION in the last void * argument. This pointer is not used by libcurl, it is only passed to the callback.
Function pointer that should match the following prototype: CURLcode sslctxfun(CURL *curl, void *sslctx, void *parm); This function gets called by libcurl just before the initialization of an 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. Using this function allows for example to use openssl callbacks to add additional validation code for certificates, and even to change the actual URI of an 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.
Data pointer to pass to the ssl c transfers. You can optionally reset all options back to internal default with curl_easy_reset(3).
Strings passed to libcurl as 'char *' arguments, will not be copied by the library. Instead you should keep them available until libcurl no longer needs them. Failing to do so will cause very odd behavior or even crashes. libcurl will need them until you call curl_easy_cleanup(3) or you set the same option again to use a different pointer.
The handle is the return code from a curl_easy_init(3) or curl_easy_duphandle(3) call.
Set the parameter to non-zero to get the library to display a lot of verbose information about its operations. Very useful for libcurl and/or protocol debugging and understanding. The verbose information will be sent to stderr, or the stream set with CURLOPT_STDERR.
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.
A non-zero parameter tells the library to include the header in the body output. This is only relevant for protocols that actually have headers preceding the data (like HTTP).
A non-zero parameter tells the library to shut off the built-in progress meter completely.
Future versions of libcurl is likely to not have any built-in progress meter at all.
Pass a long. If it is non-zero, libcurl will not use any functions that install signal handlers or any functions that cause signals to be sent to the process. This option is mainly here to allow multi-threaded unix applications to still set/use all timeout options etc, without risking getting signals. (Added in 7.10)
Consider building libcurl with ares support to enable asynchronous DNS lookups. It enables nice timeouts for name resolves without signals.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as there is data received that needs to be saved. The size of the data pointed to by ptr is size multiplied with nmemb, it will not be zero terminated. Return the number of bytes actually taken care of. If that amount differs from the amount passed to your function, it'll signal an error to the library and it will abort the transfer and return CURLE_WRITE_ERROR.
This function may be called with zero bytes data if the transfered 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 stream 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 data that can be passed to the write callback is defined in the curl.h header file: CURL_MAX_WRITE_SIZE.
Data pointer to pass to the file write function. If you use the CURLOPT_WRITEFUNCTION option, this is the pointer you'll get as input. If you don't use a callback, you must pass a 'FILE *' as libcurl will pass this to fwrite() when writing data.
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.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as it needs to read data in order to send it to the peer. The data area pointed at by the pointer ptr may be filled with at most size multiplied with nmemb number of bytes. Your function must return the actual number of bytes that you stored in that memory area. Returning 0 will signal end-of-file to the library and cause it to stop the current transfer.
If you stop the current transfer by returning 0 "pre-maturely" (i.e before the server expected it, like when you've told 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)
If you set the callback pointer to NULL, or doesn't set it at all, the default internal read function will be used. It is simply doing an fread() on the FILE * stream set with CURLOPT_READDATA.
Data pointer to pass to the file read function. If you use the CURLOPT_READFUNCTION option, this is the pointer you'll get as input. If you don't specify a read callback but instead rely on the default internal read function, this data must be a valid readable FILE *.
If you're using libcurl as a win32 DLL, you MUST use a CURLOPT_READFUNCTION if you set this option.
This option is also known with the older name CURLOPT_INFILE, the name CURLOPT_READDATA was introduced in 7.9.7.
Function pointer that should match the curl_ioctl_callback prototype found in <curl/curl.h>. This function gets called by libcurl when something special I/O-related needs to be done that the library can't do by itself. For now, rewinding the read data stream is the only action it can request. The rewinding of the read data stream may be necessary when doing a HTTP PUT or POST with a multi-pass authentication method. (Opion added in 7.12.3)
Pass a pointer that will be untouched by libcurl and passed as the 3rd argument in the ioctl callback set with CURLOPT_IOCTLFUNCTION. (Option added in 7.12.3)
Function pointer that should match the curl_progress_callback prototype found in <curl/curl.h>. This function gets called by libcurl instead of its internal equivalent with a frequent interval during operation (roughly once per second) no matter if data is being transfered or not. Unknown/unused argument values passed to the callback will be set to zero (like if you only download data, the upload size will remain 0). Returning a non-zero value from this callback will cause libcurl to abort the transfer and return CURLE_ABORTED_BY_CALLBACK.
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. Usage of the CURLOPT_PROGRESSFUNCTION callback is not recommended when using the multi interface.
CURLOPT_NOPROGRESS must be set to FALSE to make this function actually get called.
Pass a pointer that will be untouched by libcurl and passed as the first argument in the progress callback set with CURLOPT_PROGRESSFUNCTION.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream);. This function gets called by libcurl as soon as it has received header data. The header callback will be called once for each header and only complete header lines are passed on to the callback. Parsing headers should be easy enough using this. The size of the data pointed to by ptr is size multiplied with nmemb. Do not assume that the header line is zero terminated! The pointer named stream is the one you set with the CURLOPT_WRITEHEADER option. The callback function must return the number of bytes actually taken care of, or return -1 to signal error to the library (it will cause it to abort the transfer with a CURLE_WRITE_ERROR return code).
Since 7.14.1: 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 response-headers mention what header to expect in the trailer.
(This option is also known as CURLOPT_HEADERDATA) Pass a pointer to be used to write the header part of the received data to. If you don't use your own callback to take care of the writing, this must be a valid FILE *. See also the CURLOPT_HEADERFUNCTION option above on how to set a custom get-all-headers callback.
Function pointer that should match the following prototype: int curl_debug_callback (CURL *, curl_infotype, char *, size_t, void *); CURLOPT_DEBUGFUNCTION replaces the standard debug function used when CURLOPT_VERBOSE is in effect. This callback receives debug information, as specified with the curl_infotype argument. This function must return 0. The data pointed to by the char * passed to this function WILL NOT be zero terminated, but will be exactly of the size as told by the size_t argument.
Available curl_infotype values:
The data is informational text.
The data is header (or header-like) data received from the peer.
The data is header (or header-like) data sent to the peer.
The data is protocol data received from the peer.
The data is protocol data sent to the peer.
Pass a pointer to whatever you want passed in to your CURLOPT_DEBUGFUNCTION in the last void * argument. This pointer is not used by libcurl, it is only passed to the callback.
Function pointer that should match the following prototype: CURLcode sslctxfun(CURL *curl, void *sslctx, void *parm); This function gets called by libcurl just before the initialization of an 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. Using this function allows for example to use openssl callbacks to add additional validation code for certificates, and even to change the actual URI of an 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.
Data pointer to pass to the ssl c transfers. You can optionally reset all options back to internal default with curl_easy_reset(3).
Strings passed to libcurl as 'char *' arguments, will not be copied by the library. Instead you should keep them available until libcurl no longer needs them. Failing to do so will cause very odd behavior or even crashes. libcurl will need them until you call curl_easy_cleanup(3) or you set the same option again to use a different pointer.
The handle is the return code from a curl_easy_init(3) or curl_easy_duphandle(3) call.
Set the parameter to non-zero to get the library to display a lot of verbose information about its operations. Very useful for libcurl and/or protocol debugging and understanding. The verbose information will be sent to stderr, or the stream set with CURLOPT_STDERR.
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.
A non-zero parameter tells the library to include the header in the body output. This is only relevant for protocols that actually have headers preceding the data (like HTTP).
A non-zero parameter tells the library to shut off the built-in progress meter completely.
Future versions of libcurl is likely to not have any built-in progress meter at all.
Pass a long. If it is non-zero, libcurl will not use any functions that install signal handlers or any functions that cause signals to be sent to the process. This option is mainly here to allow multi-threaded unix applications to still set/use all timeout options etc, without risking getting signals. (Added in 7.10)
Consider building libcurl with ares support to enable asynchronous DNS lookups. It enables nice timeouts for name resolves without signals.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as there is data received that needs to be saved. The size of the data pointed to by ptr is size multiplied with nmemb, it will not be zero terminated. Return the number of bytes actually taken care of. If that amount differs from the amount passed to your function, it'll signal an error to the library and it will abort the transfer and return CURLE_WRITE_ERROR.
This function may be called with zero bytes data if the transfered 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 stream 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 data that can be passed to the write callback is defined in the curl.h header file: CURL_MAX_WRITE_SIZE.
Data pointer to pass to the file write function. If you use the CURLOPT_WRITEFUNCTION option, this is the pointer you'll get as input. If you don't use a callback, you must pass a 'FILE *' as libcurl will pass this to fwrite() when writing data.
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.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as it needs to read data in order to send it to the peer. The data area pointed at by the pointer ptr may be filled with at most size multiplied with nmemb number of bytes. Your function must return the actual number of bytes that you stored in that memory area. Returning 0 will signal end-of-file to the library and cause it to stop the current transfer.
If you stop the current transfer by returning 0 "pre-maturely" (i.e before the server expected it, like when you've told 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)
If you set the callback pointer to NULL, or doesn't set it at all, the default internal read function will be used. It is simply doing an fread() on the FILE * stream set with CURLOPT_READDATA.
Data pointer to pass to the file read function. If you use the CURLOPT_READFUNCTION option, this is the pointer you'll get as input. If you don't specify a read callback but instead rely on the default internal read function, this data must be a valid readable FILE *.
If you're using libcurl as a win32 DLL, you MUST use a CURLOPT_READFUNCTION if you set this option.
This option is also known with the older name CURLOPT_INFILE, the name CURLOPT_READDATA was introduced in 7.9.7.
Function pointer that should match the curl_ioctl_callback prototype found in <curl/curl.h>. This function gets called by libcurl when something special I/O-related needs to be done that the library can't do by itself. For now, rewinding the read data stream is the only action it can request. The rewinding of the read data stream may be necessary when doing a HTTP PUT or POST with a multi-pass authentication method. (Opion added in 7.12.3)
Pass a pointer that will be untouched by libcurl and passed as the 3rd argument in the ioctl callback set with CURLOPT_IOCTLFUNCTION. (Option added in 7.12.3)
Function pointer that should match the curl_progress_callback prototype found in <curl/curl.h>. This function gets called by libcurl instead of its internal equivalent with a frequent interval during operation (roughly once per second) no matter if data is being transfered or not. Unknown/unused argument values passed to the callback will be set to zero (like if you only download data, the upload size will remain 0). Returning a non-zero value from this callback will cause libcurl to abort the transfer and return CURLE_ABORTED_BY_CALLBACK.
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. Usage of the CURLOPT_PROGRESSFUNCTION callback is not recommended when using the multi interface.
CURLOPT_NOPROGRESS must be set to FALSE to make this function actually get called.
Pass a pointer that will be untouched by libcurl and passed as the first argument in the progress callback set with CURLOPT_PROGRESSFUNCTION.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream);. This function gets called by libcurl as soon as it has received header data. The header callback will be called once for each header and only complete header lines are passed on to the callback. Parsing headers should be easy enough using this. The size of the data pointed to by ptr is size multiplied with nmemb. Do not assume that the header line is zero terminated! The pointer named stream is the one you set with the CURLOPT_WRITEHEADER option. The callback function must return the number of bytes actually taken care of, or return -1 to signal error to the library (it will cause it to abort the transfer with a CURLE_WRITE_ERROR return code).
Since 7.14.1: 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 response-headers mention what header to expect in the trailer.
(This option is also known as CURLOPT_HEADERDATA) Pass a pointer to be used to write the header part of the received data to. If you don't use your own callback to take care of the writing, this must be a valid FILE *. See also the CURLOPT_HEADERFUNCTION option above on how to set a custom get-all-headers callback.
Function pointer that should match the following prototype: int curl_debug_callback (CURL *, curl_infotype, char *, size_t, void *); CURLOPT_DEBUGFUNCTION replaces the standard debug function used when CURLOPT_VERBOSE is in effect. This callback receives debug information, as specified with the curl_infotype argument. This function must return 0. The data pointed to by the char * passed to this function WILL NOT be zero terminated, but will be exactly of the size as told by the size_t argument.
Available curl_infotype values:
The data is informational text.
The data is header (or header-like) data received from the peer.
The data is header (or header-like) data sent to the peer.
The data is protocol data received from the peer.
The data is protocol data sent to the peer.
Pass a pointer to whatever you want passed in to your CURLOPT_DEBUGFUNCTION in the last void * argument. This pointer is not used by libcurl, it is only passed to the callback.
Function pointer that should match the following prototype: CURLcode sslctxfun(CURL *curl, void *sslctx, void *parm); This function gets called by libcurl just before the initialization of an 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. Using this function allows for example to use openssl callbacks to add additional validation code for certificates, and even to change the actual URI of an 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.
Data pointer to pass to the ssl c transfers. You can optionally reset all options back to internal default with curl_easy_reset(3).
Strings passed to libcurl as 'char *' arguments, will not be copied by the library. Instead you should keep them available until libcurl no longer needs them. Failing to do so will cause very odd behavior or even crashes. libcurl will need them until you call curl_easy_cleanup(3) or you set the same option again to use a different pointer.
The handle is the return code from a curl_easy_init(3) or curl_easy_duphandle(3) call.
Set the parameter to non-zero to get the library to display a lot of verbose information about its operations. Very useful for libcurl and/or protocol debugging and understanding. The verbose information will be sent to stderr, or the stream set with CURLOPT_STDERR.
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.
A non-zero parameter tells the library to include the header in the body output. This is only relevant for protocols that actually have headers preceding the data (like HTTP).
A non-zero parameter tells the library to shut off the built-in progress meter completely.
Future versions of libcurl is likely to not have any built-in progress meter at all.
Pass a long. If it is non-zero, libcurl will not use any functions that install signal handlers or any functions that cause signals to be sent to the process. This option is mainly here to allow multi-threaded unix applications to still set/use all timeout options etc, without risking getting signals. (Added in 7.10)
Consider building libcurl with ares support to enable asynchronous DNS lookups. It enables nice timeouts for name resolves without signals.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as there is data received that needs to be saved. The size of the data pointed to by ptr is size multiplied with nmemb, it will not be zero terminated. Return the number of bytes actually taken care of. If that amount differs from the amount passed to your function, it'll signal an error to the library and it will abort the transfer and return CURLE_WRITE_ERROR.
This function may be called with zero bytes data if the transfered 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 stream 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 data that can be passed to the write callback is defined in the curl.h header file: CURL_MAX_WRITE_SIZE.
Data pointer to pass to the file write function. If you use the CURLOPT_WRITEFUNCTION option, this is the pointer you'll get as input. If you don't use a callback, you must pass a 'FILE *' as libcurl will pass this to fwrite() when writing data.
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.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as it needs to read data in order to send it to the peer. The data area pointed at by the pointer ptr may be filled with at most size multiplied with nmemb number of bytes. Your function must return the actual number of bytes that you stored in that memory area. Returning 0 will signal end-of-file to the library and cause it to stop the current transfer.
If you stop the current transfer by returning 0 "pre-maturely" (i.e before the server expected it, like when you've told 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)
If you set the callback pointer to NULL, or doesn't set it at all, the default internal read function will be used. It is simply doing an fread() on the FILE * stream set with CURLOPT_READDATA.
Data pointer to pass to the file read function. If you use the CURLOPT_READFUNCTION option, this is the pointer you'll get as input. If you don't specify a read callback but instead rely on the default internal read function, this data must be a valid readable FILE *.
If you're using libcurl as a win32 DLL, you MUST use a CURLOPT_READFUNCTION if you set this option.
This option is also known with the older name CURLOPT_INFILE, the name CURLOPT_READDATA was introduced in 7.9.7.
Function pointer that should match the curl_ioctl_callback prototype found in <curl/curl.h>. This function gets called by libcurl when something special I/O-related needs to be done that the library can't do by itself. For now, rewinding the read data stream is the only action it can request. The rewinding of the read data stream may be necessary when doing a HTTP PUT or POST with a multi-pass authentication method. (Opion added in 7.12.3)
Pass a pointer that will be untouched by libcurl and passed as the 3rd argument in the ioctl callback set with CURLOPT_IOCTLFUNCTION. (Option added in 7.12.3)
Function pointer that should match the curl_progress_callback prototype found in <curl/curl.h>. This function gets called by libcurl instead of its internal equivalent with a frequent interval during operation (roughly once per second) no matter if data is being transfered or not. Unknown/unused argument values passed to the callback will be set to zero (like if you only download data, the upload size will remain 0). Returning a non-zero value from this callback will cause libcurl to abort the transfer and return CURLE_ABORTED_BY_CALLBACK.
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. Usage of the CURLOPT_PROGRESSFUNCTION callback is not recommended when using the multi interface.
CURLOPT_NOPROGRESS must be set to FALSE to make this function actually get called.
Pass a pointer that will be untouched by libcurl and passed as the first argument in the progress callback set with CURLOPT_PROGRESSFUNCTION.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream);. This function gets called by libcurl as soon as it has received header data. The header callback will be called once for each header and only complete header lines are passed on to the callback. Parsing headers should be easy enough using this. The size of the data pointed to by ptr is size multiplied with nmemb. Do not assume that the header line is zero terminated! The pointer named stream is the one you set with the CURLOPT_WRITEHEADER option. The callback function must return the number of bytes actually taken care of, or return -1 to signal error to the library (it will cause it to abort the transfer with a CURLE_WRITE_ERROR return code).
Since 7.14.1: 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 response-headers mention what header to expect in the trailer.
(This option is also known as CURLOPT_HEADERDATA) Pass a pointer to be used to write the header part of the received data to. If you don't use your own callback to take care of the writing, this must be a valid FILE *. See also the CURLOPT_HEADERFUNCTION option above on how to set a custom get-all-headers callback.
Function pointer that should match the following prototype: int curl_debug_callback (CURL *, curl_infotype, char *, size_t, void *); CURLOPT_DEBUGFUNCTION replaces the standard debug function used when CURLOPT_VERBOSE is in effect. This callback receives debug information, as specified with the curl_infotype argument. This function must return 0. The data pointed to by the char * passed to this function WILL NOT be zero terminated, but will be exactly of the size as told by the size_t argument.
Available curl_infotype values:
The data is informational text.
The data is header (or header-like) data received from the peer.
The data is header (or header-like) data sent to the peer.
The data is protocol data received from the peer.
The data is protocol data sent to the peer.
Pass a pointer to whatever you want passed in to your CURLOPT_DEBUGFUNCTION in the last void * argument. This pointer is not used by libcurl, it is only passed to the callback.
Function pointer that should match the following prototype: CURLcode sslctxfun(CURL *curl, void *sslctx, void *parm); This function gets called by libcurl just before the initialization of an 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. Using this function allows for example to use openssl callbacks to add additional validation code for certificates, and even to change the actual URI of an 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.
Data pointer to pass to the ssl c transfers. You can optionally reset all options back to internal default with curl_easy_reset(3).
Strings passed to libcurl as 'char *' arguments, will not be copied by the library. Instead you should keep them available until libcurl no longer needs them. Failing to do so will cause very odd behavior or even crashes. libcurl will need them until you call curl_easy_cleanup(3) or you set the same option again to use a different pointer.
The handle is the return code from a curl_easy_init(3) or curl_easy_duphandle(3) call.
Set the parameter to non-zero to get the library to display a lot of verbose information about its operations. Very useful for libcurl and/or protocol debugging and understanding. The verbose information will be sent to stderr, or the stream set with CURLOPT_STDERR.
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.
A non-zero parameter tells the library to include the header in the body output. This is only relevant for protocols that actually have headers preceding the data (like HTTP).
A non-zero parameter tells the library to shut off the built-in progress meter completely.
Future versions of libcurl is likely to not have any built-in progress meter at all.
Pass a long. If it is non-zero, libcurl will not use any functions that install signal handlers or any functions that cause signals to be sent to the process. This option is mainly here to allow multi-threaded unix applications to still set/use all timeout options etc, without risking getting signals. (Added in 7.10)
Consider building libcurl with ares support to enable asynchronous DNS lookups. It enables nice timeouts for name resolves without signals.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as there is data received that needs to be saved. The size of the data pointed to by ptr is size multiplied with nmemb, it will not be zero terminated. Return the number of bytes actually taken care of. If that amount differs from the amount passed to your function, it'll signal an error to the library and it will abort the transfer and return CURLE_WRITE_ERROR.
This function may be called with zero bytes data if the transfered 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 stream 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 data that can be passed to the write callback is defined in the curl.h header file: CURL_MAX_WRITE_SIZE.
Data pointer to pass to the file write function. If you use the CURLOPT_WRITEFUNCTION option, this is the pointer you'll get as input. If you don't use a callback, you must pass a 'FILE *' as libcurl will pass this to fwrite() when writing data.
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.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); This function gets called by libcurl as soon as it needs to read data in order to send it to the peer. The data area pointed at by the pointer ptr may be filled with at most size multiplied with nmemb number of bytes. Your function must return the actual number of bytes that you stored in that memory area. Returning 0 will signal end-of-file to the library and cause it to stop the current transfer.
If you stop the current transfer by returning 0 "pre-maturely" (i.e before the server expected it, like when you've told 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)
If you set the callback pointer to NULL, or doesn't set it at all, the default internal read function will be used. It is simply doing an fread() on the FILE * stream set with CURLOPT_READDATA.
Data pointer to pass to the file read function. If you use the CURLOPT_READFUNCTION option, this is the pointer you'll get as input. If you don't specify a read callback but instead rely on the default internal read function, this data must be a valid readable FILE *.
If you're using libcurl as a win32 DLL, you MUST use a CURLOPT_READFUNCTION if you set this option.
This option is also known with the older name CURLOPT_INFILE, the name CURLOPT_READDATA was introduced in 7.9.7.
Function pointer that should match the curl_ioctl_callback prototype found in <curl/curl.h>. This function gets called by libcurl when something special I/O-related needs to be done that the library can't do by itself. For now, rewinding the read data stream is the only action it can request. The rewinding of the read data stream may be necessary when doing a HTTP PUT or POST with a multi-pass authentication method. (Opion added in 7.12.3)
Pass a pointer that will be untouched by libcurl and passed as the 3rd argument in the ioctl callback set with CURLOPT_IOCTLFUNCTION. (Option added in 7.12.3)
Function pointer that should match the curl_progress_callback prototype found in <curl/curl.h>. This function gets called by libcurl instead of its internal equivalent with a frequent interval during operation (roughly once per second) no matter if data is being transfered or not. Unknown/unused argument values passed to the callback will be set to zero (like if you only download data, the upload size will remain 0). Returning a non-zero value from this callback will cause libcurl to abort the transfer and return CURLE_ABORTED_BY_CALLBACK.
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. Usage of the CURLOPT_PROGRESSFUNCTION callback is not recommended when using the multi interface.
CURLOPT_NOPROGRESS must be set to FALSE to make this function actually get called.
Pass a pointer that will be untouched by libcurl and passed as the first argument in the progress callback set with CURLOPT_PROGRESSFUNCTION.
Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream);. This function gets called by libcurl as soon as it has received header data. The header callback will be called once for each header and only complete header lines are passed on to the callback. Parsing headers should be easy enough using this. The size of the data pointed to by ptr is size multiplied with nmemb. Do not assume that the header line is zero terminated! The pointer named stream is the one you set with the CURLOPT_WRITEHEADER option. The callback function must return the number of bytes actually taken care of, or return -1 to signal error to the library (it will cause it to abort the transfer with a CURLE_WRITE_ERROR return code).
Since 7.14.1: 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 response-headers mention what header to expect in the trailer.
(This option is also known as CURLOPT_HEADERDATA) Pass a pointer to be used to write the header part of the received data to. If you don't use your own callback to take care of the writing, this must be a valid FILE *. See also the CURLOPT_HEADERFUNCTION option above on how to set a custom get-all-headers callback.
Function pointer that should match the following prototype: int curl_debug_callback (CURL *, curl_infotype, char *, size_t, void *); CURLOPT_DEBUGFUNCTION replaces the