PHP RFC: Enable strict_types checking for curl_setopt()
PHP 7.0 introduced strict type checking as part of the scalar types RFC. When enabled, PHP will use strict type-checking mode for function calls and return statements in the file. However, this does not currently apply to the third argument of
curl_setopt() where option values are set.
This RFC proposes that we introduce strict type enforcement inside
declare(strict_types=1) is being used.
Strict type enforcement does not currently apply to the third argument of
curl_setopt because this argument is heavily overloaded into a mixed type which accepts any of the following:
However, each particular option always expects a certain type, so it makes sense to enforce these types in strict type checking mode.
(The full list of options and expected value types can be found in the manual: http://php.net/manual/en/function.curl-setopt.php)
Using weak types can also have unintended consequences. For example, prior to curl 7.28.1, the CURLOPT_SSL_VERIFYHOST option (which controls how to verify an SSL certificate's name against the host) had three possible values:
0: Allow the connection regardless of the names in the certificate.
1: Allow the connection if a common name exists in the certificate.
2: Allow the connection if a common name exists in the certificate AND it matches the hostname provided.
However, if a developer wasn't careful and set this option as
true, PHP would interpret this as
1 and therefore would not check that the certificate matches the hostname (essentially disabling proper hostname validation).
Introducing strict type checks would help prevent these types of issues.
declare(strict_types=1) is used, PHP will now check the third argument of
curl_setopt() to ensure it contains the expected type for the given setting. Checks will be added for the following types:
Passing the incorrect type while strict type checks are enabled would result in a
TypeError with a message like this:
Argument 3 passed to curl_setopt() must be of type integer, boolean given
This behavior matches existing strict type checking functionality.
Backward Incompatible Changes
Any existing code using
curl_setopt() with strict type checking enabled will need to be updated if it doesn't provide the proper types.
Code not using strict type checking (or which already passes the proper types) would be unaffected.
Proposed PHP Version(s)
These changes would only impact the curl extension.
Proposed Voting Choices
Should strict type checking be enforced on the third parameter of
curl_setopt when strict type checking is enabled? As it is not a language or syntax change, the vote will pass if 50%+1 vote yes.
Patches and Tests
The proposed patch can be found here: https://github.com/php/php-src/pull/2495
Mailing list discussion: http://marc.info/?l=php-internals&m=149286128912117&w=2