[GIT-PULLS] [php-src] PR #22757: error when curl read func returns unexpected long
[email protected] (Sjord) Thu, 16 Jul 2026 08:41:11 +0000
| Newsgroups | php.git-pulls |
|---|---|
| Message-ID | <zhexI0CREECzkTOHMXiLiyp2352ydDmeh0RlUuSQbmE@main.internal.php.net> |
Pull Request: https://github.com/php/php-src/pull/22757 Author: Sjord Raise a value error when the callback registered with CURLOPT_READFUNCTION returns an unexpected long. The function registered with CURLOPT_READFUNCTION should return a string. PHP then writes that string to a buffer and returns the length, so that curl can read that many bytes from the buffer. The function can also return CURL_READFUNC_ABORT and CURL_READFUNC_PAUSE, so it also supports returning longs. However, when it returns a long other than these two constants, it is interpreted as a length. PHP does not update the buffer, but does instruct curl it can read that many bytes from the buffer. It reads whatever uninitialized data that is in the buffer and sends it over the line to the server. This seems bad, so validate the return value of the read function and raise an error. Returning 0 is a bit of an edge case. It is not documented but does results in correct behavior (i.e. end-of-file). So we accept that, but don't advertise it as valid in the error message. I am not worried about BC-break, because sending an uninitialized buffer does not result in a valid request, so this would already not work. I considered silently casting the int to a string. This would be very "old PHP" behavior. I think throwing an error is more strict and better and more in line with "new PHP" behavior, if that makes sense. Related to https://github.com/php/php-src/issues/10270