Version 2.0.1

Overview of changes

• Update bundled certificates as of 2022-02-01. #670
• Bug fix: Hook priority should be respected. #452, #647
• Docs: the Hook documentation has been updated to reflect the current available hooks. #646
• General housekeeping. #635, #649, #650, #653, #655, #658, #660, #661, #662, #669, #671, #672, #674

Props @alpipego, @costdev, @jegrandet @jrfnl, @schlessera

Version 2.0.0

BREAKING CHANGES

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.

Overview of changes

• 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.

  ⚠️ 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 to true when 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:

  • A 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.
  • A 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.
  • A 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.
  • A 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.
  • An WpOrg\Requests\Exceptions\InvalidArgument class. This class is intended for internal use only.
  • An 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

  • The WpOrg\Requests\Requests::decompress() method has been fixed to recognize more compression levels and handle these correctly.
  • The method signature of the 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.
  • The 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.
  • The WpOrg\Requests\Transport\Curl::request() method will no longer set the CURLOPT_REFERER option.
  • The default value of the $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() instead

  A 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 ❤️ and available on the website.
  For the time being, the Requests 1.x API documentation will still be available on the website as wel...

Version 1.8.1

Overview of changes

• The Requests::VERSION constant has been updated to reflect the actual version for the release. @jrfnl, #485
• Update the .gitattributes file to include fewer files in the distribution. @mbabker, #484
• Added a release checklist. @jrfnl, #483
• Various minor updates to the documentation and the website. @jrfnl, @schlessera, #477, #478, #479, #481, #482

Version 1.8.0

IMPORTANT NOTES

Last release supporting PHP 5.2 - 5.5

Release 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.

Last release supporting PEAR distribution

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.

Overview of changes

• [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][gh-421], [#422][gh-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][gh-440], [#441][gh-441], [#448][gh-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][gh-453], [#454][gh-454], [#469][gh-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][gh-385], [#398][gh-398], [#451][gh-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][gh-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.

  • Use documented order for implode() arguments.
  • Harden type handling when no domain was passed.
  • Explicitly cast $url property to string in Requests::parse_response().
  • Initialize $body property to an empty string in Requests::parse_response().
  • Ensure the stream handle is valid before trying to close it.
  • Ensure the $callback in the FilteredIterator is callable before calling it.

  (props [@aaronjorbin][gh-aaronjorbin], [@jrfnl][gh-jrfnl], #346, [#370][gh-370], [#425][gh-425], [#426][gh-426], [#456][gh-456], [#457][gh-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][gh-355], [#366][gh-366], [#412][gh-412], [#414][gh-414], [#445][gh-445], [#458][gh-458], [#464][gh-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:

  • No whitespace on the inside of parentheses.
  • No Yoda conditions.

  A more detailed overview of the decisions that went into the final code style rules can be found at [#434][gh-434].

  (props [@jrfnl][gh-jrfnl], [@KasperFranz][gh-KasperFranz], [@ozh][gh-ozh], [@schlessera][gh-schlessera], [@TysonAndre][gh-TysonAndre], #263, #296, #328, [#358][gh-358], [#359][gh-359], [#360][gh-360], [#361][gh-361], [#362][gh-362], [#363][gh-363], [#364][gh-364], [#386][gh-386], [#396][gh-396], [#399][gh-399], [#400][gh-400], [#401][gh-401], [#402][gh-402], [#403][gh-403], [#404][gh-404], [#405][gh-405], [#406][gh-406], [#408][gh-408], [#409][gh-409], [#410][gh-410], [#411][gh-411], [#413][gh-413], [#415][gh-415], [#416][gh-416], [#417][gh-417], [#423][gh-423], [#424][gh-424], [#434][gh-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][gh-356], [#388][gh-388], [#397][gh-397], [#428][gh-428], [#436][gh-436], [#439][gh-439], [#461][gh-461], [#467][gh-467])

• Update and improve documentation

  • Use clearer and more inclusive language.
  • Update the GitHub Pages site.
  • Update content and various tweaks to the markdown.
  • Fix code blocks in README.md file.
  • Add pagination to documentation pages.

  (props [@desrosj][gh-desrosj], [@jrfnl][gh-jrfnl], [@JustinyAhin][gh-JustinyAhin], [@tnorthcutt][gh-tnorthcutt], #334, [#367][gh-367], [#387][gh-387], [#443][gh-443], [#462][gh-462], [#465][gh-465], [#468][gh-468], [#471][gh-471] )

...

Version 1.7

• 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.

  (props @rmccue, #106, #176)

• 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.

  (props @ozh, @rmccue, #97, #216)

• 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.

  (props @ocean90, #227)

• Add byte limit option

  (props @rmccue, #172)

• Support a Requests_Proxy_HTTP() instance for the proxy setting.

  (props @ocean90, #223)

• Add progress hook

  (props @rmccue, #180)

• Add a before_redirect hook to alter redirects

  (props @rmccue, #205)

• Pass cURL info to after_request

  (props @rmccue, #206)

View all changes or the release post.

Version 1.6.1

• Fix compatibility with HHVM - Using HHVM with Requests would
  previously cause either exceptions with SSL or segfaults with the cURL
  handler. Props Ozh for his work here.

Version 1.6

• Add multiple request support - Send multiple HTTP requests with both
  fsockopen and cURL, transparently falling back to synchronous when
  not supported.
• Add proxy support - HTTP proxies are now natively supported via a
  high-level API. Major props to Ozh for his fantastic work
  on this.
• Verify host name for SSL requests - Requests is now the first and only
  standalone HTTP library to fully verify SSL hostnames even with socket
  connections. Thanks to Michael Adams, Dion Hulse, Jon Cave, and Pádraic Brady
  for reviewing the crucial code behind this.
• Add cookie support - Adds built-in support for cookies (built entirely
  as a high-level API)
• Add sessions - To compliment cookies, sessions
  can be created with a base URL and default options, plus a shared cookie jar.
• Add PUT, DELETE, and PATCH request support
• Add Composer support - You can now install Requests via the
  rmccue/requests package on Composer

Version v1.5.0

Release 1.5.0, our initial version!