Libcurl several precautions to use

0. Add a defined protocol header for the Curl URL used

Original:
If you specify URL without protocol://prefix, Curl would attempt to guess what protocol you might want. It would then default to HTTP but try the other protocols based on often-used host name prefixes. For example, the for host names starting with "ftp." Curl would assume you want to speak ftp.

1. Write the Curl_easy_perform () callback data directly into the document (file *)

Original:
Libcurl offers its own default internal callback that'll take care of the data if you don ' t set the callback with Curlop T_writefunction. It would then simply output of the received data to stdout. You can has the default callback write the data to a different file handle by passing a ' file * ' to a file opened for WRI Ting with the curlopt_writedata option.
The implementation of the source code:

In this way, you can write less a callback function (Hello, how lazy you are), such as the following

FILE *fp;fp = fopen("/root/test.bmp""wb");...curl_easy_setopt(curl, CURLOPT_WRITEDATA, fp);...fclose(fp);

2. Curl_easy_perform return value Processing

Use Curlopt_errorbuffer to save errors, buf_size=curl_error_size
or use Curl_easy_strerror (res) (feel this simple)
Example:

 / * Perform the request, res'll get the return code * /  res = curl_easy_perform (curl); / * Check for errors * /  if(res! = CURLE_OK) { printf "%s curl_easy_perform () error! \ n ", __function__); printf "error msg =%s\ n" , Curl_easy_strerror (res));   return-1; }

3. Multi-threaded environment configuration curlopt_nosignal

Original:
When using multiple threads you should set the Curlopt_nosignal option to 1 for all handles. Everything would or might work fine except that timeouts is not honored during the DNS Lookup-which you can work around By building Libcurl and c-ares support. C-ares is a library of that provides asynchronous name resolves. On some platforms, Libcurl simply won't function properly multi-threaded unless this option is set.
For Curlopt_timeout (default 0), Curlopt_connecttimeout (default 300) Option:
In Unix-like systems, this might cause signals to being used unless curlopt_nosignal is set.

4. The necessity of setting curlopt_verbose and Curlopt_header

Original:
There ' s one golden rule when these things occur:set the curlopt_verbose option to 1. It ' ll cause the library to spew out the entire protocol details it sends, some internal info and some received protocol DA Ta as well (especially when using FTP). If you ' re using HTTP, adding the headers. The received output to study is also a clever a-to get a better Understandin G Why the server behaves the it does. Include headers in the normal body output with Curlopt_header set 1.
After testing:
After setting curl_easy_setopt (Curl, Curlopt_header, 1L), the callback function returns information about the HTTP header (which was originally output directly to stdout), so do not set this if you want to filter the information.

5. Curl Post Considerations

Original:
Using POST with HTTP 1.1 implies the use of a "expect:100-continue" header. You can disable the this header with Curlopt_httpheader as usual.
Explain:
When using the Libcurl post method, if the post data size is greater than 1024 bytes, Libcurl does not send the POST request directly, but is divided into two steps to execute the request:
<1> sends a request that contains a expect:100-continue field to ask the server if it is willing to accept the data
<2> When an answer is received from the 100-continue returned from the server, it actually initiates the POST request and sends the data to the server.
For the field "100-continue", the RFC document (http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3) explains this:
It can let the client before sending the request data to determine whether the server is willing to receive the data, if the server is willing to receive, the client will actually send the data,
The reason for this is that if the client sends the request data directly, but the server rejects the request, this behavior creates a significant resource overhead.
So in order to avoid this, Libcurl takes this approach when sending a POST request that is larger than 1024 bytes, but in contrast, it causes a delay in the request to increase,
In addition, not all servers will correctly handle and answer "100-continue", such as LIGHTTPD, will return 417 "expectation Failed", resulting in a request logic error.
Workaround :

//Post data is greater than 1024 bytesstructCurl_slist *headerlist =NULL;Static Const CharBuf[] = "Expect:" ; headerlist = Curl_slist_append (headerlist, buf);/ * Initalize Custom Header list * /Curl_easy_setopt (Curl, Curlopt_httpheader, headerlist);/ * Set header*/Curl_slist_free_all (headerlist);/ * Free Slist * /

6. Correct return of callback function

return (size * nmemb);

Reason:
Your callback function should return the number of bytes it "took care of". If that's not the exact same amount of bytes that's passed to it, Libcurl'll abort the operation and return with an E Rror code.

If the data received in the callback function is incorrect, the personal feeling can return 0 or return the number of data you have processed.
Because the source code processing is as follows:

 / * If the previous block of data ended with CR and this block of data is just a NL, then the length might is zero * / //Len is the length of data to be sent to the callback function if(LEN) { wrote = Data->set.fwrite_func (PTR,1, Len, data->set.out); } Else{ wrote = Len; }if(wrote! = len) {FAILF (data, "Failed writing body (%zu! =%zu)" , wrote, Len);returnCurle_write_error;}

Libcurl several precautions to use