The php_stream_read() and php_stream_write() functions now return
an ssize_t value, with negative results indicating failure. Functions
like fread() and fwrite() will return false in that case.
As a special case, EWOULDBLOCK and EAGAIN on non-blocking streams
should not be regarded as error conditions, and be reported as
successful zero-length reads/writes instead. The handling of EINTR
remains unclear and is internally inconsistent (e.g. some code-paths
will automatically retry on EINTR, while some won't).
I'm landing this now to make sure the stream wrapper ops API changes
make it into 7.4 -- however, if the user-facing changes turn out to
be problematic we have the option of clamping negative returns to
zero in php_stream_read() and php_stream_write() to restore the
old behavior in a relatively non-intrusive manner.
Used in php-src the past and today removed and not used anymore:
- HAVE_CURL_EASY_STRERROR
- HAVE_CURL_MULTI_STRERROR
- HAVE_NEW_MIME2TEXT
- HAVE_MBSTR_CN
- HAVE_MBSTR_JA
- HAVE_MBSTR_KR
- HAVE_MBSTR_RU
- HAVE_MBSTR_TW
Part of oniguruma which doesn't use these anymore
- NOT_RUBY
- HAVE_STDARG_PROTOTYPES
Unused:
- HAVE_MPIR
Closes GH-4427
The output of the three handles may be interleaved. We already have
curl_basic_018.phpt which uses curl_multi_getcontent() and thus
has predictable output. As such, I'm dropping this test altogether.
libcurl may link against 7 different ssl libraries, all of which
are thread-safe -- apart from openssl, of course. We check for
openssl and register locking callbacks in that case, but we should
not warn if any other library is used.
`curl_version()`[1] (of ext/curl) makes `curl_version_info()`[2] (of
libcurl) available to PHP userland. The latter requires to pass an
`age` argument which usually is `CURLVERSION_NOW`, so that the
information returned by the runtime matches the declarations used
during compile time. For C programs it is simply necessary to pass
this information, and in rare occasions it might make sense to pass
something else than `CURLVERSION_NOW`. curl.h notes:
| The 'CURLVERSION_NOW' is the symbolic name meant to be used by
| basically all programs ever that want to get version information.
For the PHP binding, using a newer `age` than available at compile time
will neither provide the PHP program more information, nor would using
an older `age` have tangible benefits.
We therefore deprecate the useless `$version` parameter, and if it is
passed nonetheless, we use `CURLVERSION_NOW` instead of the supplied
value, and raise a warning.
[1] <https://www.php.net/manual/en/function.curl-version.php>
[2] <https://curl.haxx.se/libcurl/c/curl_version_info.html>
Normalization include:
- Use dnl for everything that can be ommitted when configure is built in
favor of the shell comment character # which is visible in the output.
- Line length normalized to 80 columns
- Dots for most of the one line sentences
- Macro definitions include similar pattern header comments now
`CURLPIPE_HTTP1` is deprecated and has no effect as of cURL 7.62.0[1].
We therefore deprecate the PHP constant as well, and trigger a warning
that it is no longer supported, if used against cURL 7.62.0 and up.
[1] <https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html>
Due to former restrictions of the libcurl API, curl multipart/formdata
file uploads supported only proper files. However, as of curl 7.56.0
the new `curl_mime_*()` API is available (and already supported by
PHP[1]), which allows us to support arbitrary *seekable* streams, which
is generally desirable, and particularly resolves issues with the
transparent Unicode and long part support on Windows (see bug #77711).
Note that older curl versions are still supported, but CURLFile is
still restricted to proper files in this case.
[1] <http://git.php.net/?p=php-src.git;a=commit;h=a83b68ba56714bfa06737a61af795460caa4a105>
This is only relevant for the gcrypt backend, which is no longer in
use. I couldn't find any hard info on when exactly gcrypt support was
dropped, but nette is the default since 2.11.1. Most code that still
has the gcrypt handling is checking against < 2.12. In either case,
those versions were released in 2010/2011.
This check introduced in 2004 is wrong and removed. A HEAD request with
curl does *not* cause this error code - only if you make a regular GET
request but tell curl to send a HEAD using CURLOPT_CUSTOMREQUEST and
then you've asked for it.
You do a proper HEAD request with curl by setting the CURLOPT_NOBODY
option to 1L.
This was the case in 2004. This is still the case in 2019. This is also
documented in libcurl documentation.
This check hides the possibly serious error when this error code is
genuinely and correctly returned by curl because the transfer was
truncated and ended up partial.
As can be seen, I objected to this change already in the original bug:
https://bugs.php.net/bug.php?id=27341
