The difference between cURL between different versions of PHP (-Experience), different versions of curl

I used to make a collection tool to realize the collection of articles and save the pictures. .The content of the article is saved in the database, and the image needs to be uploaded to the image server first, and then the image address is returned and the image address of the article is replaced.

Here comes the problem: everything can be collected successfully, but the local test is normal, and the pictures can be uploaded successfully, but there are no pictures in the production environment. Then I debugged step by step, and found that the data is there, but Why can’t I upload pictures successfully during production?

After struggling for a few days, after reading the code step by step, debugging, and Baidu, I finally found the answer. What a big pitfall.

Use curl post to upload to the image server,

PHP’s cURL supports generating POST requests for CURL_POSTFIELDS by passing an associative array (instead of a string) to multipart/form-data.

Traditionally, PHP's cURL supports attaching files by using the "@ full file path" syntax in the array data for cURL to read and upload. This is consistent with the syntax for directly calling the cURL program from the command line:

<code>curl_setopt(ch, CURLOPT_POSTFIELDS, <span class="hljs-keyword">array(
    <span class="hljs-string">'file' => <span class="hljs-string">'@'.realpath(<span class="hljs-string">'image.png'), 
)); 
equals
$ curl -F <span class="hljs-string">"file=@/absolute/path/to/image.png" <url>
</span></span></span></span></span></code>

But PHP has introduced a new CURLFile class since 5.5 to point to files. The CURLFile class can also define in detail additional information such as MIME types, file names, etc. that may appear in multipart/form-data data. PHP recommends using CURLFile instead of the old @ syntax:

<code>curl_setopt(ch, CURLOPT_POSTFIELDS, [
    <span class="hljs-string">'file' => <span class="hljs-keyword">new CURLFile(realpath(<span class="hljs-string">'image.png')), 
]); 
</span></span></span></code>

PHP 5.5 also introduces the CURL_SAFE_UPLOAD option, which can force PHP's cURL module to reject the old @ syntax and only accept CURLFile-style files. The default value is false for 5.5 and true for 5.6.

But the pitfall is: the @ syntax has been deprecated in 5.5, and was directly deleted in 5.6 (it will generate ErorException: The usage of the @filename API for file uploading is deprecated. Please use the CURLFile class instead).

For PHP 5.6, manually setting CURL_SAFE_UPLOAD to false is meaningless. It is not literally understood as "setting it to false will enable the old unsafe method" - the old method has completely ceased to exist as obsolete syntax. PHP 5.6 == CURLFile only, don't have any illusions.

My deployment environment is 5.4 (@ syntax only), but my development environment is 5.6 (CURLFile only). Neither is focused on 5.5, a transitional version that both support. As a result, two sets of codes with environmental judgment must be written.

Now comes the problem...

Environmental judgment: Be careful with the magic numbers!

I have seen this kind of environment judgment code:

<code><span class="hljs-keyword">if (version_compare(phpversion(), <span class="hljs-string">'5.4.0') >= <span class="hljs-number">0)
</span></span></span></code>

I only have one word for this kind of code: Shit.

This judgment falls into the typical magic number trap. The version number appears inexplicably in the code. Without checking the PHP manual and update history for a long time, it is difficult to understand which function change the author is stuck on.

Code should go back to its roots. Our actual needs are actually: use CURLFile first, without regressing to the traditional @ syntax. Then the code is here:

<code><span class="hljs-keyword">if (class_exists(<span class="hljs-string">'\CURLFile')) {
    <span class="hljs-variable">$field = <span class="hljs-keyword">array(<span class="hljs-string">'fieldname' => <span class="hljs-keyword">new \CURLFile(realpath(<span class="hljs-variable">$filepath)));
} <span class="hljs-keyword">else {
    <span class="hljs-variable">$field = <span class="hljs-keyword">array(<span class="hljs-string">'fieldname' => <span class="hljs-string">'@' . realpath(<span class="hljs-variable">$filepath));
}
</span></span></span></span></span></span></span></span></span></span></span></span></span></code>

Explicitly specified degradation options are recommended

From a reliable perspective, it is recommended to specify the value of CURL_SAFE_UPLOAD to clearly tell PHP whether to tolerate or prohibit the old @ syntax. Note that in lower versions of PHP, the CURLOPT_SAFE_UPLOAD constant itself may not exist and needs to be judged:

<code><span class="hljs-keyword">if (class_exists(<span class="hljs-string">'\CURLFile')) {
    curl_<span class="hljs-built_in">setopt(<span class="hljs-variable">$ch, CURLOPT_SAFE_UPLOAD, <span class="hljs-literal">true);
} <span class="hljs-keyword">else {
    <span class="hljs-keyword">if (defined(<span class="hljs-string">'CURLOPT_SAFE_UPLOAD')) {
        curl_<span class="hljs-built_in">setopt(<span class="hljs-variable">$ch, CURLOPT_SAFE_UPLOAD, <span class="hljs-literal">false);
    }
}
</span></span></span></span></span></span></span></span></span></span></span></code>

The order of cURL option settings

Whether it is curl_setopt() single or curl_setopt_array() batch, cURL’s options always take effect one by one, and the set options will immediately affect the behavior of cURL when setting subsequent options.

For example, CURLOPT_SAFE_UPLOAD is related to CURLOPT_POSTFIELDS’s behavior. If CURLOPT_POSTFIELDS is set first and then CURLOPT_SAFE_UPLOAD is set, the latter's constraint will not take effect. Because when setting the former, cURL has already completed the actual reading and processing of the data!

CURL has several options that have this pitfall, so be careful. Fortunately, there are not many options for this kind of "dependency", and the mechanism is not complicated, so it can be handled simply. My method is to set all options in batches first, and then use curl_exec()single settingscurl_setopt() until just before CURLOPT_POSTFIELDS.

In fact, in the array used by curl_setopt_array(), it is guaranteed that the position of CURLOPT_POSTFIELDS is reliable at the end. PHP’s associative arrays are sequence guaranteed. We can also assume that the internal execution order of curl_setopt_array() must be sequential from beginning to end[注A], so you can rest assured.

My approach is just to add extra insurance to the code performance, highlighting the importance of order to prevent future mistakes.

Namespace

PHP 5.2 or below does not have namespaces. If the space delimiter is used in the code, a parser error will occur. It's actually easy to take care of PHP 5.2, just give up the namespace.

What should be noted is that PHP 5.3 has namespaces. Whether you are calling CURLFile or using class_exists() to determine the existence of CURLFile, it is recommended to write CURLFile to clearly specify the top-level space to prevent the code from crashing when it is wrapped in the namespace.

Okay, this hole is quite deep, so I’ll share it when I jump out.

(The above solutions are reproduced from the website, thank you for letting me find your article!)