rmccue/requests
A simple, lightweight HTTP library for PHP. Requests provides an easy API for making GET/POST calls, handling headers, cookies, redirects, proxies, timeouts, and authentication, with support for transports like cURL and sockets.
Reflection*::setAccessible() #940curl_close() #947 Props @TobiasBgUsing null as an array offset #956FilteredIterator to accept objects (PHP 8.5 deprecation). #968
Note: This is technically a breaking change as this was documented behaviour. However, FilteredIterator is an internal class and the only detected use of this behavior was in a test.roave/security-advisories (no longer needed with Composer 2.9+). #961stream_context_set_option(). #822 Props @jrfnlCookie::parse_from_headers() method.
Classes which extend the Cookie class and overload the parse_from_headers() method should be updated for the new method signature.
Additionally, if code calling the Cookie::parse_from_headers() method would be wrapped in a try - catch to catch a potential PHP TypeError (PHP 7.0+) or Exception (PHP < 7.0) for when invalid data was passed as the $origin parameter, this code will need to be updated to now also catch a potential WpOrg\Requests\Exception\InvalidArgumentException.
As due diligence could not find any classes which would be affected by this BC-break, we have deemed it acceptable to include this fix in the 2.0.11 release.Props [@alpipego]gh-alpipego, [@costdev]gh-costdev, [@jegrandet]gh-jegrandet [@jrfnl]gh-jrfnl, [@schlessera]gh-schlessera
As Requests 2.0.0 is a major release, this version contains breaking changes. There is an upgrade guide available to guide you through making the necessary changes in your own code.
New minimum PHP version
Support for PHP 5.2 - 5.5 has been dropped. The new minimum supported PHP version is now 5.6.
Support for HHVM has also been dropped formally now.
(props @datagutten, @jrfnl, @schlessera, #378, #470, #509)
New release branch name
The stable version of Requests can be found in the stable branch (was master).
Development of Requests happens in the develop branch.
(props @jrfnl, @schlessera, #463, #490)
All code is now namespaced (PSR-4)
The code within the Requests library has all been namespaced and now lives in the WpOrg\Requests namespace.
The namespaced classes can be found in the src directory. The old library directory and the files within are deprecated.
For a number of classes, some subtle changes have also been made to their base class name, like renaming the Hooker interface to HookManager.
A full backward-compatibility layer is available and using the non-namespaced class names will still work during the 2.x and 3.x release cycles, though a deprecation notice will be thrown the first time a class using one of the old PSR-0 based class names is requested.
For the lifetime of Requests 2.x, the deprecation notices can be disabled by defining a global REQUESTS_SILENCE_PSR0_DEPRECATIONS constant and
setting the value of this constant to true.
A complete "translation table" between the Requests 1.x and 2.x class names is available in the upgrade guide.
Users of the Requests native custom autoloader will need to adjust their code to initialize the autoloader:
// OLD: Using the custom autoloader in Requests 1.x.
require_once 'path/to/Requests/library/Requests.php';
Requests::register_autoloader();
// NEW: Using the custom autoloader in Requests 2.x.
require_once 'path/to/Requests/src/Autoload.php';
WpOrg\Requests\Autoload::register();
(props @jrfnl, @schlessera, #503, #519, #586, #587, #594)
A large number of classes have been marked as final
Marking a class as final prohibits extending it.
These changes were made after researching which classes were being extended in userland code and due diligence has been applied before making these changes. If this change is causing a problem we didn't anticipate, please open an issue to report it.
(props @jrfnl, @schlessera, #514, #534)
Input validation
All typical entry point methods in Requests will now, directly or indirectly, validate the received input parameters for being of the correct type.
When an incorrect parameter type is received, a catchable WpOrg\Requests\Exception\InvalidArgument exception will be thrown.
The input validation has been set up to be reasonably liberal, so if Requests was being used as per the documentation, this change should not affect you. If you still find the input validation to be too strict and you have a good use-case of why it should be loosened for a particular entry point, please open an issue to discuss this.
The code within Requests itself has also received various improvements to be more type safe.
(props @jrfnl, @schlessera, #499, #542, #547, #558, #572, #573, #574, #591, #592, #593, #601, #602, #603, #604, #605, #609, #610, #611, #613, #614, #615, #620, #621, #629)
Update bundled certificates
The bundled certificates were updated with the latest version available (published 2021-10-26).
Previously the bundled certificates in Requests would include a small subset of expired certificates for legacy reasons. This is no longer the case as of Requests 2.0.0.
:warning: Note: the included certificates bundle is only intended as a fallback.
This fallback should only be used for servers that are not properly configured for SSL verification. A continuously managed server should provide a more up-to-date certificate authority list than a software library which only gets updates once in a while.
Setting the
$options['verify']key totruewhen initiating a request enables certificate verification using the certificate authority list provided by the server environment, which is recommended.
The documentation regarding Secure Requests with SSL has also been updated to reflect this and it is recommended to have a read through.
The included certificates file has now also been moved to a dedicated /certificates directory off the project root.
(props @jrfnl, @schlessera, @wojsmol, @ZsgsDesign, #535, #571, #577, #622, #632)
New functionality
The following new functionality has been added:
public static WpOrg\Requests\Requests::has_capabilities($capabilities = array()) method is now available to check whether there is a transport available which supports the requested capabilities.public WpOrg\Requests\Response::decode_body($associative = true, $depth = 512, $options = 0) method is now available to handle JSON-decoding a response body.
The method parameters correspond to the parameters of the PHP native json_decode() function.
The method will throw an WpOrg\Requests\Exception when the response body is not valid JSON.WpOrg\Requests\Capability interface. This interface provides constants for the known capabilities. Transports can be tested whether or not they support these capabilities.
Currently, the only capability supported is Capability::SSL.WpOrg\Requests\Port class. This class encapsulates typical port numbers as constants and offers a static Port::get($type) method to retrieve a port number based on a request type.
Using this class when referring to port numbers is recommended.WpOrg\Requests\Exceptions\InvalidArgument class. This class is intended for internal use only.WpOrg\Requests\Utility\InputValidator class with helper methods for input validation. This class is intended for internal use only.(props @ccrims0n, @dd32, @jrfnl, @schlessera, #167, #214, #250, #251, #492, #499, #538, #542, #547, #559)
Changed functionality
WpOrg\Requests\Requests::decompress() method has been fixed to recognize more compression levels and handle these correctly.WpOrg\Requests\Transport::test() interface method has been adjusted to enforce support for an optional $capabilities parameter.
The Request native WpOrg\Requests\Transport\Curl::test() and WpOrg\Requests\Transport\Fsockopen::test() methods both already supported this parameter.WpOrg\Requests\Transport\Curl::request() and the WpOrg\Requests\Transport\Fsockopen::request() methods will now throw an WpOrg\Requests\Exception when the $options['filename'] contains an invalid path.WpOrg\Requests\Transport\Curl::request() method will no longer set the CURLOPT_REFERER option.$key parameter in the WpOrg\Requests\Cookie\Jar::normalize_cookie() method has been changed from null to an empty string.(props @datagutten, @dustinrue, @jrfnl, @schlessera, @soulseekah, @twdnhfr, #301, #309, #379, #444, #492, #610)
Removed functionality
The following methods, which were deprecated during the 1.x cycle, have now been removed:
Requests::flattern(), use WpOrg\Requests\Requests::flatten() instead.Requests_Cookie::formatForHeader(), use WpOrg\Requests\Cookie::format_for_header() instead.Requests_Cookie::formatForSetCookie(), use WpOrg\Requests\Cookie::format_for_set_cookie() instead.Requests_Cookie::parseFromHeaders(), use WpOrg\Requests\Cookie::parse_from_headers() instead.Requests_Cookie_Jar::normalizeCookie(), use WpOrg\Requests\Cookie\Jar::normalize_cookie() insteadA duplicate method has been removed:
Requests::match_domain(), use WpOrg\Requests\Ssl::match_domain() instead.A redundant method has been removed:
Hooks::__construct().(props @jrfnl, @schlessera, #510, #525, #617)
Compatibility with PHP 8.0 named parameters
All parameter names have been reviewed to prevent issues for users using PHP 8.0 named parameters and where relevant, a number of parameter names have been changed.
After this release, a parameter name rename will be treated as a breaking change (reserved for major releases) and will be marked as such in the changelog.
(props @jrfnl, @schlessera, #533, #560, #561, #599, #612)
PHP 8.1 compatibility
All known PHP 8.1 compatibility issues have been fixed and tests are now running (and passing) against PHP 8.1.
In case you still run into a PHP 8.1 deprecation notice or other PHP 8.1 related issue, please open an issue to report it.
(props @jrfnl, @schlessera, #498, #499, #500, #501, #505, #634)
Updated documentation
The documentation website has been updated to reflect all the changes in Requests 2.0.0.
The API documentation for Requests 2.x is now generated using phpDocumentor :heart: and available on the website. For the time being, the Requests 1.x API documentation will still be available on the website as well.
(props @costdev, @jrfnl, @schlessera, @szepeviktor, #476, #480, #489, #495, #526, #528, #532, #543, #562, #578, #590, #606, #607, #608, #618, #622, #625, #626, #630, #642)
General housekeeping
In a number of places, code modernizations, possible now the minimum PHP version has gone up to PHP 5.6, have been applied. (#504, #506, #512, #539, #541, #599, #623)
Lots of improvements were made to render the tests more reliable and increase the coverage. (#446, #459, #472, #503, #508, #511, #520, #521, #548, #549, #550, #551, #552, #553, #554, #555, #556, #557, #558, #566, #581, #591, #595, #640)
The move for all CI to GitHub Actions has been finalized. Travis is dead, long live Travis and thanks for all the fish. (#447, #575, #579)
A GitHub Actions workflow has been put in place to allow for automatically updating the website on releases. This should allow for more rapid releases from now on. (#466, #544, #545, #563, #569, #583, #626)
Development-only dependencies have been updated. (#516, #517)
Various other general housekeeping and improvements for contributors. (#488, #491, #523, #513, #515, #522, #524, #531, #535, #536, #537, #540, #588, #616)
(props @jrfnl, @schlessera)
Requests::VERSION constant has been updated to reflect the actual version for the release. @jrfnl, #485.gitattributes file to include fewer files in the distribution. @mbabker, #484Release 1.8.0 will be the last release with compatibility for PHP 5.2 - 5.5. With the next release (v2.0.0), the minimum PHP version will be bumped to 5.6.
Release 1.8.0 will be the last release to be distributed via PEAR. From release 2.0.0 onwards, consumers of this library will have to switch to Composer to receive updates.
[SECURITY FIX] Disable deserialization in FilteredIterator
A Deserialization of Untrusted Data weakness was found in the FilteredIterator class.
This security vulnerability was first reported to the WordPress project. The security fix applied to WordPress has been ported back into the library.
GitHub security advisory: Insecure Deserialization of untrusted data
CVE: CVE-2021-29476 - Deserialization of Untrusted Data
Related WordPress CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-28032
(props [@dd32]gh-dd32, [@desrosj]gh-desrosj, [@jrfnl]gh-jrfnl, [@peterwilsoncc]gh-peterwilsoncc, [@SergeyBiryukov]gh-SergeyBiryukov, [@whyisjake]gh-whyisjake, [@xknown]gh-xknown, #421, #422)
Repository moved to WordPress\Requests
The Requests library has been moved to the WordPress GitHub organization and can now be found under https://github.com/WordPress/Requests.
All links in code and documentation were updated accordingly.
Note: the Composer package name remains unchanged (rmccue/requests), as well as the documentation site (requests.ryanmccue.info).
(props [@dd32]gh-dd32, [@JustinyAhin]gh-JustinyAhin, [@jrfnl]gh-jrfnl, [@rmccue]gh-rmccue, #440, #441, #448)
Manage "Expect" header with cURL transport
By default, cURL adds a Expect: 100-Continue header to certain requests. This can add as much as a second delay to requests done using cURL. This is discussed on the cURL mailing list.
To prevent this, Requests now adds an empty "Expect" header to requests that are smaller than 1 MB and use HTTP/1.1.
(props [@carlalexander]gh-carlalexander, [@schlessera]gh-schlessera, [@TimothyBJacobs]gh-TimothyBJacobs, #453, #454, #469)
Update bundled certificates as of 2021-02-12
The bundled certificates were updated. A small subset of expired certificates are still included for legacy reasons (and support).
(props [@ozh]gh-ozh, [@patmead]gh-patmead, [@schlessera]gh-schlessera, [@todeveni]gh-todeveni, #385, #398, #451)
Add required Content-* headers for empty POST requests
Sends the Content-Length and Content-Type headers even for empty POST requests, as the length is expected as per RFC2616 Section 14.13:
Content-Length header "SHOULD" be included. In practice, it is not
used for GET nor HEAD requests, but is expected for POST requests.
(props [@dd32]gh-dd32, [@gstrauss]gh-gstrauss, [@jrfnl]gh-jrfnl, [@soulseekah]gh-soulseekah, #248, #249, #318, #368)
Ignore locale when creating the HTTP version string from a float
The previous behavior allowed for the locale to mess up the float to string conversion resulting in a GET / HTTP/1,1 instead of GET / HTTP/1.1 request.
(props [@tonebender]gh-tonebender, [@Zegnat]gh-Zegnat, #335, #339)
Make verify => false work with fsockopen
This allows the fsockopen transport now to ignore SSL failures when requested.
(props [@soulseekah]gh-soulseekah, #310, #311)
Only include port number in the Host header if it differs from the default
The code was not violating the RFC per se, but also not following standard practice of leaving the port off when it is the default port for the scheme, which could lead to connectivity issues.
(props [@amandato]gh-amandato, [@dd32]gh-dd32, #238)
Fix PHP cross-version compatibility
Important fixes have been made to improve cross-version compatibility of the code across all supported PHP versions.
implode() arguments.$url property to string in Requests::parse_response().$body property to an empty string in Requests::parse_response().$callback in the FilteredIterator is callable before calling it.(props [@aaronjorbin]gh-aaronjorbin, [@jrfnl]gh-jrfnl, #346, #370, #425, #426, #456, #457)
Improve testing
Lots of improvements were made to render the tests more reliable and increase the coverage.
And to top it all off, all tests are now run against all supported PHP versions, including PHP 8.0.
(props [@datagutten]gh-datagutten, [@jrfnl]gh-jrfnl, [@schlessera]gh-schlessera, #345, #351, #355, #366, #412, #414, #445, #458, #464)
Improve code quality and style
A whole swoop of changes has been made to harden the code and make it more consistent.
The code style has been made consistent across both code and tests and is now enforced via a custom PHPCS rule set.
The WordPress Coding Standards were chosen as the basis for the code style checks as most contributors to this library originate from the WordPress community and will be familiar with this code style.
Main differences from the WordPress Coding Standards based on discussions and an analysis of the code styles already in use:
A more detailed overview of the decisions that went into the final code style rules can be found at #434.
(props [@jrfnl]gh-jrfnl, [@KasperFranz]gh-KasperFranz, [@ozh]gh-ozh, [@schlessera]gh-schlessera, [@TysonAndre]gh-TysonAndre, #263, #296, #328, #358, #359, #360, #361, #362, #363, #364, #386, #396, #399, #400, #401, #402, #403, #404, #405, #406, #408, #409, #410, #411, #413, #415, #416, #417, #423, #424, #434)
Replace Travis CI with GitHub Actions (partial)
The entire CI setup is gradually being moved from Travis CI to GitHub Actions.
At this point, GitHub Actions takes over the CI from PHP 5.5 onwards, leaving Travis CI as a fallback for lower PHP versions.
This move will be completed after the planned minimum version bump to PHP 5.6+ with the next release, at which point we will get rid of all the remaining Travis CI integrations.
(props [@dd32]gh-dd32, [@desrosj]gh-desrosj, [@jrfnl]gh-jrfnl, [@ntwb]gh-ntwb, [@ozh]gh-ozh, [@schlessera]gh-schlessera, [@TimothyBJacobs]gh-TimothyBJacobs, [@TysonAndre]gh-TysonAndre, #280, #298, #302, #303, #352, #353, #354, #356, #388, #397, #428, #436, #439, #461, #467)
Update and improve documentation
README.md file.(props [@desrosj]gh-desrosj, [@jrfnl]gh-jrfnl, [@JustinyAhin]gh-JustinyAhin, [@tnorthcutt]gh-tnorthcutt, #334, #367, #387, #443, #462, #465, #468, #471 )
Release 1.5.0, our initial version!
Add support for HHVM and PHP 7
Requests is now tested against both HHVM and PHP 7, and they are supported as first-party platforms.
Transfer & connect timeouts, in seconds & milliseconds
cURL is unable to handle timeouts under a second in DNS lookups, so we round those up to ensure 1-999ms isn't counted as an instant failure.
Rework cookie handling to be more thorough.
Cookies are now restricted to the same-origin by default, expiration is checked.
(props @catharsisjelly, @rmccue, #120, #124, #130, #132, #156)
Improve testing
Tests are now run locally to speed them up, as well as further general improvements to the quality of the testing suite. There are now also comprehensive proxy tests to ensure coverage there.
(props @rmccue, #75, #107, #170, #177, #181, #183, #185, #196, #202, #203)
Support custom HTTP methods
Previously, custom HTTP methods were only supported on sockets; they are now supported across all transports.
Add byte limit option
Support a Requests_Proxy_HTTP() instance for the proxy setting.
Add progress hook
Add a before_redirect hook to alter redirects
Pass cURL info to after_request
rmccue/requests package on ComposerHow can I help you explore Laravel packages today?