Common misunderstandings when cooperating with curl_setopt

When using PHP for network requests, cURL extensions are undoubtedly one of the most common and powerful tools. In the daily use of cURL , curl_setopt() is used to set request options, and curl_close() is used to close the session handle. It looks simple and clear, but there are many "pits" hidden when they are used together. This article will analyze several common wrong ways to use them in depth to help you avoid being hit.

1. Set options after curl_close? invalid!

 $ch = curl_init();
curl_close($ch);
curl_setopt($ch, CURLOPT_URL, "https://gitbox.net/api/data");

Problem analysis : Once curl_close() is called, the $ch handle has been released. Any subsequent settings on it will be invalid, and even a warning may be thrown.

Solution : Make sure that all requests and processing work are completed before calling curl_close() . curl_close() should be the last step in your entire request process.

2. Reuse the closed handle? It collapses directly!

Many developers will try to reuse handles to improve performance, but if you accidentally continue to use it after closing it, you will get an error:

 $ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://gitbox.net/api/one");
curl_exec($ch);
curl_close($ch);

// Use again
curl_setopt($ch, CURLOPT_URL, "https://gitbox.net/api/two");
curl_exec($ch);

Problem analysis : $ch after closing is an invalid resource. Continuing to use it will cause PHP to throw an error: supplied resource is not a valid cURL handle resource .

Suggested practice : If you want to initiate multiple requests, do not close the handle immediately after the first request, or use multiple handles, or re-initialize each time you use it.

3. CURLOPT_RETURNTRANSFER is not set, and the result is output directly

 $ch = curl_init("https://gitbox.net/api/data");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, false);
$result = curl_exec($ch);
curl_close($ch);
echo "The result is：" . $result;

Problem analysis : CURLOPT_RETURNTRANSFER is not set to true , resulting in the result being output directly to the page, while $result is actually true or false , not the real return content.

Correct way to do it :

 curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

In this way, the returned content can be obtained for subsequent processing, such as json decoding, string analysis, etc.

4. No error message was judged before closing the handle

Many people ignore check errors before closing:

 $ch = curl_init("https://gitbox.net/api/info");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$data = curl_exec($ch);
curl_close($ch);

if (!$data) {
    echo "Request failed";
}

Problem analysis : curl_exec() returns false to indicate failure, but more importantly, curl_error($ch) provides detailed error information. Once curl_close() is executed, the error description can no longer be obtained.

Suggested practices :

 $data = curl_exec($ch);

if (curl_errno($ch)) {
    echo 'cURL mistake：' . curl_error($ch);
}

curl_close($ch);

First judge the error and then close the handle. This is a good encoding habit.

5. The correct SSL option is not set for HTTPS requests

 $ch = curl_init("https://gitbox.net/secure/data");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$data = curl_exec($ch);
curl_close($ch);

Problem Analysis : If the target is HTTPS and CURLOPT_SSL_VERIFYPEER is not set, it may fail in some environments.

Suggested practices :

 curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true); // or false（For test only）
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);

You must set the actual deployment environment and enable verification as much as possible in the production environment.