Requests - a HTTP library written in PHP, for human beings

Overview

Requests for PHP

CS Lint Test codecov.io

Requests is a HTTP library written in PHP, for human beings. It is roughly based on the API from the excellent Requests Python library. Requests is ISC Licensed (similar to the new BSD license) and has no dependencies, except for PHP 5.6+.

Despite PHP's use as a language for the web, its tools for sending HTTP requests are severely lacking. cURL has an interesting API, to say the least, and you can't always rely on it being available. Sockets provide only low level access, and require you to build most of the HTTP response parsing yourself.

We all have better things to do. That's why Requests was born.

body); // string(26891) "[...]"">
$headers = array('Accept' => 'application/json');
$options = array('auth' => array('user', 'pass'));
$request = WpOrg\Requests\Requests::get('https://api.github.com/gists', $headers, $options);

var_dump($request->status_code);
// int(200)

var_dump($request->headers['content-type']);
// string(31) "application/json; charset=utf-8"

var_dump($request->body);
// string(26891) "[...]"

Requests allows you to send HEAD, GET, POST, PUT, DELETE, and PATCH HTTP requests. You can add headers, form data, multipart files, and parameters with basic arrays, and access the response data in the same way. Requests uses cURL and fsockopen, depending on what your system has available, but abstracts all the nasty stuff out of your way, providing a consistent API.

Features

  • International Domains and URLs
  • Browser-style SSL Verification
  • Basic/Digest Authentication
  • Automatic Decompression
  • Connection Timeouts

Installation

Install with Composer

If you're using Composer to manage dependencies, you can add Requests with it.

composer require rmccue/requests

or

{
    "require": {
        "rmccue/requests": "^2.0"
    }
}

Install source from GitHub

To install the source code:

$ git clone git://github.com/WordPress/Requests.git

Next, include the autoloader in your scripts:

require_once '/path/to/Requests/src/Autoload.php';

You'll probably also want to register the autoloader:

WpOrg\Requests\Autoload::register();

Install source from zip/tarball

Alternatively, you can fetch a tarball or zipball:

$ curl -L https://github.com/WordPress/Requests/tarball/stable | tar xzv
(or)
$ wget https://github.com/WordPress/Requests/tarball/stable -O - | tar xzv

Using a Class Loader

If you're using a class loader (e.g., Symfony Class Loader) for PSR-4-style class loading:

$loader = new Psr4ClassLoader();
$loader->addPrefix('WpOrg\\Requests\\', 'path/to/vendor/Requests/src');
$loader->register();

Documentation

The best place to start is our prose-based documentation, which will guide you through using Requests.

After that, take a look at the documentation for \WpOrg\Requests\Requests::request(), where all the parameters are fully documented.

Requests is 100% documented with PHPDoc. If you find any problems with it, create a new issue!

Testing

Requests strives to have 100% code-coverage of the library with an extensive set of tests. We're not quite there yet, but we're getting close.

To run the test suite, first check that you have the PHP JSON extension enabled. Then simply:

$ phpunit

If you'd like to run a single set of tests, specify just the name:

$ phpunit Transport/cURL

Contribute

  1. Check for open issues or open a new issue for a feature request or a bug.
  2. Fork the repository on Github to start making your changes to the develop branch (or branch off of it).
  3. Write one or more tests which show that the bug was fixed or that the feature works as expected.
  4. Send in a pull request.

If you have questions while working on your contribution and you use Slack, there is a #core-http-api channel available in the WordPress Slack in which contributions can be discussed.

Comments
  • 'Uncaught Requests_Exception: cURL error 60: SSL certificate problem: certificate has expired' error

    'Uncaught Requests_Exception: cURL error 60: SSL certificate problem: certificate has expired' error

    Summary

    Having doing no change on my website, I now get an error related to certificate expiracy :

    
    
    Fatal error: Uncaught Requests_Exception: cURL error 60: SSL certificate problem: certificate has expired in /home/xxx/app/vendors/Requests/library/Requests/Transport/cURL.php:422 Stack trace: #0 /home/xxx/app/vendors/Requests/library/Requests/Transport/cURL.php(177): Requests_Transport_cURL->process_response('', Array) #1 /home/xxx/app/vendors/Requests/library/Requests.php(379): Requests_Transport_cURL->request('https://data.en...', Array, NULL, Array) #2 /home/xxx/app/vendors/Requests/library/Requests.php(231): Requests::request('https://data.en...', Array, NULL, 'GET', Array) #3 /home/xxx/app/php/process-prod-history.php(86): Requests::get('https://data.en...') #4 {main} thrown in /home/xxx/app/vendors/Requests/library/Requests/Transport/cURL.php on line 422
    

    Can someone tell me more about this error ? and is there any workaround ?

    Do you think this is due to webserver certificate - which seems to be fine - or remote certificate on API I am targeting ?

    Thanks for your help,

    Type: support 
    opened by simogeo 18
  • Full proxy support

    Full proxy support

    Close #37 and consider this instead. Things for curl are obvious, and for streams I stole everything from WP's class-http.php :-Þ

    My tests GET and POST are conclusive using random open proxies from http://hidemyass.com/proxy-list/. I will be able to test at work next week to make sure authentication works too.

    Regarding unit tests, I'm not sure how this can be even implemented, unless you set up on your server a proxy dedicated to this, or know a public proxy that could be used ?

    opened by ozh 18
  • Fix/Rationalize transports

    Fix/Rationalize transports

    Hey!

    This PR rationalizes/fixes some issues I encounter with the curl/fsockopen transports + add some new features.

    Context

    I'm currently integrating this library in an http adapter (See egeloen/ivory-http-adapter#80). This library has a pretty robust test suite which have spotted some issues. This PR tries to fix all of them :)

    Issues

    • The curl transport initializes a curl resource at initialization. Then, if this resource is closed, the transport is not usable anymore. Instead of creating it at initialization, I have moved it in the setup_handle method which fixes the issue.
    • The curl transport merges the data in the uri for DELETE request but some service like AWS needs some extra info in DELETE request which needs to be passed by message body. According to #91, I have added the data_as_query option and updated the transport accordingly.
    • The fsockopen transport added arbitrary headers without looking for existence in the passed headers. This result of a duplication of headers.

    New features

    • Added support for the OPTIONS and TRACE http verbs.
    • Added support for 1.0 and 1.1 protocol versions in request/response.

    Btw, this PR fixes #133, #137, #142 and #91.

    Waiting your feedbacks!

    Component: Transports 
    opened by egeloen 17
  • PHP 7.4 compatibility fix / implode argument order

    PHP 7.4 compatibility fix / implode argument order

    implode() takes two parameters, $glue and $pieces. For historical reasons, implode() accepted these parameters in either order, though it was recommended to use the documented argument order of implode( $glue, $pieces ).

    PHP 7.4 is slated to deprecate the tolerance for passing the parameters for implode() in reverse order. PHP 8.0 is expected to remove the tolerance for this completely.

    Refs:

    • https://wiki.php.net/rfc/deprecations_php_7_4#implode_parameter_order_mix
    • https://php.net/manual/en/function.implode.php
    opened by jrfnl 16
  • Add support for parsing common/alt names

    Add support for parsing common/alt names

    This appears to follow both the specification and browser behaviour, but this should be double-checked before merge.

    Pinging @mdawaffe for a review on this. Appears to follow both the RFC and Firefox's implementation.

    Notably, doesn't support double wildcards (*.*.x.com), but I'm not sure that browsers support this any more. Google has migrated away from it for App Engine, I believe due to browser support.

    opened by rmccue 16
  • RFC / WIP (do not merge): surface cURL errors

    RFC / WIP (do not merge): surface cURL errors

    This is a work in progress, but I wanted to get comments sooner rather than later, since this is mostly complete.

    I have a couple use cases involved here:

    1. I have a need to detect different kinds of cURL errors from multi-requests, specifically CURLE_OPERATION_TIMEDOUT (28), since I have subrequests using timeouts. These currently manifest as 'requests.no_crlf_separator' due to nothing being returned from curl_multi_getcontent in request_multiple resulting in a parse error. These are detectable from the code in $done['code'], but none of this is exposed anywhere I can get to.
    2. I want to be able to capture the time when an error has finished, and have the code available there. I've added this as a separate hook to not break existing parse_response implementations, but I'm open to suggestions here.

    Please take a look and tell me what you think.

    opened by Stelminator 14
  • GET Request problem

    GET Request problem

    Hey,

    first of all thank you for your awesome php lib :)

    But I think I've found a bug... Using a GET Request the header is empty, if I load the same URL in a Browser it displays the response correctly. I have the latest version, but I tested it also with 1.5, in both it isn't working. I debugged a little bit (I don't have much time) and the problem is between line number 320 and 323 (and the functions in them). https://github.com/kurtextrem/ge.tt-PHP-API/blob/master/gett.class.php#L100 That's the line where it's called and because the header is empty this exception occurs "Missing header/body separator"

    Hope you can help me or fix it.

    Regards, Jacob

    opened by kurtextrem 13
  • Requests 2.0.0: introduce namespaces

    Requests 2.0.0: introduce namespaces

    TL;DR:

    This PR:

    • Introduces PSR-4 namespacing to all classes in the Requests library.
      • The namespaced versions of the classes are located in the src directory.
      • The library directory and the remaining files in it are deprecated and marked as such.
      • Naming conventions used (to be documented in a CONTRIBUTING.md file once that is added):
        • Directory and class names use CamelCaps.
        • Acronyms are "proper cased", i.e. first character uppercase, the rest of the acronym lowercase.
    • Adds a backward compatibility layer to both the Composer autoload entry point as well as the Requests native custom autoloader entrypoint. This BC-layer:
      • Offers full support for the old PSR-0 class names.
      • Will throw a deprecation notice the first time during a "page load" when a PSR-0 Requests class name is requested.
      • Supports silencing these deprecation notices by setting a REQUESTS_SILENCE_PSR0_DEPRECATIONS constant with the value true.
        • The deprecation notice silencing via this constant will be supported throughout the life cycle of Requests 2.x.
        • Support for the deprecation notice silencing via the constant will be removed in Requests 3.0.0.
        • The backward compatibility layer (class aliases in the WpOrg\Requests\Autoload class and the whole of the library folder) will be removed in Requests 4.0.0.
    • Updates all Requests native code, including the documentation and code samples to use the new namespaced class names.
    • Adds a documentation page to the docs folder with an upgrade guide to Requests 2.0.0 based on the changes made in this PR.

    Related to #460

    QA

    As part of the QA for this PR, a draft upgrade of the Requests library for WordPress has been executed and pulled and the unit tests pass: https://github.com/WordPress/wordpress-develop/pull/1624 ~~(there is still an issue with the E2E tests which is related to the interaction with WPCLI being investigated)~~

    To do

    1. Once this PR has been merged, an issue against the 3.0.0 milestone should be opened to remove support for the deprecation silencing constant and a second issue against the 4.0.0 milestone to remove support for the PSR-0 class names completely.
    2. Once this PR has been merged, open PRs may need to be rebased and/or updated to use the new namespaced name and become mergable again.

    Commit Details

    PHPCS: few tweaks

    ... to allow for files in the src directory to be scanned based on the same rules as before.

    Requests: move autoload functionality to separate class

    Includes:

    • Adding a safeguard against the autoloader being registered multiple times.
    • Registering the autoloader via prepending it to the autoload queue to prevent potential conflicts with a Requests 1.x autoloader.
    • Deprecating the old methods in the original Requests class, while still safeguarding that they will continue to work for now.
    • Minor adjustments to the code to allow for the change in directory.

    Update autoloading to allow for PSR-4 class names

    This commit:

    • Adds a PSR-4 directive for the src directory to the composer.json file to support autoloading of the new classes when users use the vendor/autoload.php file to handle the class loading.
    • Adds support for PSR-4 based class loading to the WpOrg\Requests\Autoload class for users who use the custom autoload functionality provided by Requests.

    Notes:

    • The autoloader will now always return a boolean value, which improves compatibility with autoloader chaining.
    • The old Requests class is special cased. While it is probably rare for this class to be requested for autoloading via the new autoloader, it should still be handled correctly if it is. As the class in the new structure will be split into two classes: WpOrg\Requests\Requests and this WpOrg\Requests\Autoload class, the file which will be loaded will be the old Requests class which will extend the WpOrg\Requests\Requests class and will use the WpOrg\Requests\Autoload class for the autoloading, maintaining the old functionality without BC break.
    • When PSR-0 class names which are no longer in use are requested, the new PSR-4 class name will be aliased to the PSR-0 class name for backward compatibility.
      • The first time during a "page load" such an alias is created, a deprecation notice will be thrown.
      • Only one deprecation notice per "page load" will be thrown.
      • Users of this library, which need to support both Requests 1.x as well as 2.x, can declare a REQUESTS_SILENCE_PSR0_DEPRECATIONS constant (before the autoloader is invoked for the first time) to silence these deprecation notices. This constant will be supported throughout the lifetime of Requests v 2.x and will be removed in Requests 3.0.0.
    • As quite a few directory names and class names will have changes in the letter case they use between PSR-0 and PSR-4 and there have also been changes in the class names for the HTTP status exceptions, I'm choosing to implement the matching of the PSR-0 classes to the PSR-4 class names via a case-insensitive lookup table. While the logic behind the renames is transparent and can be encoded in a function, using a lookup table provides optimal speed, especially as the list of classes for which aliasing is provided is limited and will not change.

    Requests: update all code samples using the custom autoloader

    .. to use the new WpOrg\Requests\Autoload class instead of the old Requests class with the register_autoloader() method.

    Tests: temporarily silence deprecation warnings

    ... while the classes are being namespaced.

    Requests: move the real functionality to a namespaced Requests class

    Move the real Requests class - with the exception of the autoload functionality - to the src directory and namespace it.

    Includes updating the reference to this class in the release checklist.

    Requests: update all references to the class

    • Update references and code samples in the documentation.
    • Update code samples in the example files.
    • Update existing use statements referencing the class.
    • Add use import statements to all non-namespaced classes using the Requests class.

    Requests: deprecate the remaining class

    Deprecate all functionality which remains in the old non-namespaced Requests class and add a deprecation notice for when people would still require the class directly.

    Includes:

    • Preventing the new WpOrg\Requests\Autoload file from throwing a duplicate deprecation notice during a page load, when the Requests class was loaded as well as a class which is being aliased.

    Move certificates file to src directory

    Requests_Auth/Requests_Hooker/Requests_Proxy/Requests_Transport: change to namespaced interfaces

    Includes:

    • Moving the namespaced version of the interfaces to the src directory.
    • [Custom autoload] Adding the interfaces to the $deprecated_classes array in the WpOrg\Requests\Autoload class.
    • [Composer autoload] Adding the interfaces to a new Deprecated.php file. Same as the custom autoloader when encountering deprecated interfaces/classes, loading this file will also trigger a deprecation notice. And again, same as the custom autoloader, the deprecation notice can be silenced by setting a REQUESTS_SILENCE_PSR0_DEPRECATIONS constant.
    • Adding the new Deprecated.php file to the Composer autoload directive to be indexed to a classmap.
    • Updating all references to the interfaces.
    • Adding an exclusion to the PHPCS file to allow the Deprecated.php file to contain multiple class declarations.

    Requests_[...] (all classes): change to namespaced class

    Includes:

    • [Where applicable] Using CamelCaps for the class name, as well as the test class.
    • Moving the namespaced version of the class to the src directory.
    • [Custom autoload] Adding the class to the $deprecated_classes array in the WpOrg\Requests\Autoload class.
    • [Composer autoload] Adding the class to the Deprecated.php file.
    • Updating all references to the class.
    • Various tweaks to the PHPCS config file to align with these changes.

    Note 1: As the Requests_Exception_InvalidArgument class has only been introduced in Requests 2.0.0, the original class name has not been added to the class alias list or the deprecated classes file.

    Note 2: The class names of the Requests_Exception_HTTP_* classes, have been Prefixed with Status as purely numeric class names are not allowed in PHP. Note: while Unknown would have been allowed, I've elected to prefix this with Status as well for consistency.

    Remove support for PSR-0 autoloading

    ... as Requests now no longer contains any PSR-0 classes.

    PSR-0 classes are still supported in the backward-compatibility layer, which means that:

    • When using Composer for the autoloading, the PSR-0 classes will be made available via a classmap.
    • When using the Requests native custom autoloading, the PSR-0 classes will be aliased to their PSR-4 equivalent.

    Tests: undo the temporarily silencing of deprecation warnings

    ... as all classes are now properly namespaced.

    Also: switch to the new WpOrg\Requests\Autoload class for the autoloading of the files when using a PHPUnit PHAR file to run the tests.

    Document the library directory

    Documentation: add page about upgrading to Requests 2.0

    Code coverage: update configuration

    ... to point to the src instead of the library directory.

    README: update external class loader example code

    Note: the Symfony Class Loader package is deprecated and was removed from Symfony in version 4.0, so we may want to replace this example with one using a still maintained external library.


    Added three more commits after the initial PR was pulled:

    🆕 Deprecated classes classmap file: wrap each class/interface declaration in an "exists" check

    This fixes a potential fatal "class already exists" error when during one "page load":

    • Two projects both using Requests are used.
    • Neither of these projects uses Requests with a custom namespace/prefix as can be done via PHP_Scoper.
    • The first of these projects loaded is still using Requests 1.x and is using Composer autoload.
    • The second project is using Requests 2.x and is also using Composer autoload,

    In that case, depending on the order of the registered autoloaders, the Deprecated.php file may be called while some Requests 1.x have already been autoloaded, but not all.

    Bulk declaring the deprecated classes will then lead to a "Fatal error: Cannot declare interface/class Requests_..., because the name is already in use" error.

    Using class_exists() wrappers will prevent this.

    🆕 ~~WpOrg\Requests\Autoload: prepend the new autoloader~~

    This commit has been merged into the "Requests: move autoload functionality to separate class" commit

    🆕 Tests: add minimal test to verify that deprecation notices are thrown

    ... when the old PSR-0 classes are being autoloaded.


    🆕 🆕 Tests: rename the namespace

    ... from Requests\Tests to WpOrg\Requests\Tests for consistency.

    Type: documentation Type: breaking change Type: enhancement Type: meta 
    opened by jrfnl 11
  • detected a problem with the transmission of cookies between subdomains domain

    detected a problem with the transmission of cookies between subdomains domain

    if the server has set a cookie type .domain.com, it should work on all subdomains of the domain, for example test.domain.com. however, in your script you have a condition that prevents this work (cut off point at the beginning of a domain):                      // Domain normalization, as per RFC 6265 section 5.2.3                      if ($ value [0] === '.') {                           $ value = substr ($ value, 1);                      }

    As a result, the cookie is only to domain.com, even if it has been assigned to all subdomains of the domain.

    Type: support 
    opened by blizzardkem 11
  • Next major release

    Next major release

    Hi there, I'm a big fan of the project and have been using it for a long time now. I wanted to use it in one of my latest projects, only to find out that the main class Requests is a static class which doesn't exactly lend itself to DI methodologies. Also, it's not namespaced, which I assume is to keep PHP 5.2 compatibility.

    I've cracked on with it and got it mostly working on my fork. Right now I'm having issues getting the tests running because of problems with requests/test-server.

    I was thinking perhaps you could release 1.7, which drops compatibility for PHP5.2 and adds namespaces, but otherwise maintains feature parity. Then we can work on 2.0, which drops compatibility for PHP5.3.

    I've got a list of things that need to be done before a candidate for 1.7 is ready:

    • [ ] Get tests running at same level as master
    • [ ] Rewrite requests/test-server to use PHP 5.3 only
    • [x] Fix specialised exception classnames

    The list for 2.0 is longer, but I'm sure we can flesh it out :smile:

    opened by hassankhan 11
  • Try to fix GitHub Actions

    Try to fix GitHub Actions

    Pull Request Type

    • [X] I have checked there is no other PR open for the same change.

    This is a:

    • [ ] Bug fix
    • [ ] New feature
    • [X] Code quality improvement

    Detailed Description

    The issue in https://github.com/WordPress/Requests/runs/4614423459?check_suite_focus=true might be related to https://github.com/composer/composer/issues/10389, which was fixed/released in https://github.com/composer/composer/releases/tag/2.2.4.

    Unfortunately I could not get the tests to run locally, but the error message disappeared after downgrading to Composer 2.1.14.

    I am actually trying to work on https://github.com/WordPress/Requests/issues/475 and maybe add a Dockerfile and a shell script to the repository to make it easier to run the tests locally.

    Quality assurance

    • [ ] This change does NOT contain a breaking change (fix or feature that would cause existing functionality to change).
    • [ ] I have commented my code, particularly in hard-to-understand areas.
    • [ ] I have added unit tests to accompany this PR.
    • [ ] The (new/existing) tests cover this PR 100%.
    • [ ] I have (manually) tested this code to the best of my abilities.
    • [ ] My code follows the style guidelines of this project.

    Documentation

    For new features:

    • [ ] I have added a code example showing how to use this feature to the examples directory.
    • [ ] I have added documentation about this feature to the docs directory. If the documentation is in a new markdown file, I have added a link to this new file to the Docs folder README.md file.
    Type: testing/chores/QA Status: triage 
    opened by simonhammes 10
  • Change

    Change "Request" to "Requests" in deprecation message.

    There is a minor typo in library/Requests.php, src/Autoload.php and the test file tests/Autoload/AutoloadTest.php.

    The PSR-0 Requests_... class names in the Request library are deprecated.

    "Request" should be "Requests".

    Pull Request Type

    • [x] I have checked there is no other PR open for the same change.

    This is a:

    • [ ] Bug fix
    • [ ] New feature
    • [x] Code quality improvement

    Quality assurance

    • [x] This change does NOT contain a breaking change (fix or feature that would cause existing functionality to change).
    Type: testing/chores/QA 
    opened by costdev 2
  • CI: move away from Heroku for HTTPS tests

    CI: move away from Heroku for HTTPS tests

    Also see #782

    A Heroku service was used to run an app to generate HTTPS responses for the tests. However, Heroku no longer offers the Free tier.

    See:

    • https://blog.heroku.com/next-chapter
    • https://devcenter.heroku.com/changelog-items/2461
    • https://help.heroku.com/8GD2AVBW/app-down-or-not-working-after-the-termination-of-free-tier-plans-on-heroku

    For the time being, the HTTPS tests will be skipped until this issue is resolved.

    We'll need to look for an alternative to Heroku, preferably one to which we can automatically deploy using GH Actions from the https://github.com/RequestsPHP/test-server server.

    An initial investigation of alternatives, showed Render as a likely candidate to replace Heroku.

    As Render doesn't offer PHP natively, we'll need to add a Docker configuration to the test server package to get this working.

    Type: testing/chores/QA 
    opened by jrfnl 0
  • Add PSR-7 support

    Add PSR-7 support

    This PR will add PSR-7 HTTP message support to Requests. This means that Requests will be able to process any PSR-7 Psr\Http\Message\RequestInterface implementation and response with a PSR-7 Psr\Http\Message\ResponseInterface implementation.

    Pull Request Type

    • [x] I have checked there is no other PR open for the same change.

    This is a:

    • [x] New feature

    Context

    @jrfnl stated in https://github.com/WordPress/Requests/issues/320#issuecomment-1236301755 that PSR-7 support would be a useful addition. Therefore I started with the implementation as a draft. Since I don't have any experience in contributing to Requests yet (I've read the .github/CONTRIBUTING.md), I appreciate early feedback to avoid gross errors early on.

    Detailed Description

    The plan is that the PSR-7 implementation will be built as a wrapper around the existing classes in the WpOrg\Requests\Psr namespace. This way there should be no breaking changes and the usage is optional. This is also important because PSR-7 has some limitations, such as missing multible requests.

    Long term goal is as I mentioned here a PSR-18 implementation to be able to use Requests as a PSR-18 HTTP client. However, this will require PHP 7.0+ and is therefore not part of this PR. Nevertheless, this PR already includes a class that is compatible with PSR-18 and PSR-17 RequestFactory, but does not yet rely on the interfaces. This must be implemented in a future PR after bumping the PHP version to 7.0+.

    Work progress

    • [x] Implement request factory compatible to Psr\Http\Message\RequestFactoryInterface
    • [x] Implement Psr\Http\Message\UriInterface
    • [x] Implement Psr\Http\Message\RequestInterface
    • [x] Implement Psr\Http\Message\StreamInterface
    • [x] Implement stream factory compatible to Psr\Http\Message\StreamFactoryInterface
    • [x] Implement Psr\Http\Message\ResponseInterface
    • [x] Implement HTTP client compatible to Psr\Http\Client\ClientInterface

    Quality assurance

    • [x] This change does NOT contain a breaking change (fix or feature that would cause existing functionality to change).
    • [x] I have commented my code, particularly in hard-to-understand areas.
    • [x] I have added unit tests to accompany this PR.
    • [x] The (new/existing) tests cover this PR 100%.
    • [x] I have (manually) tested this code to the best of my abilities.
    • [ ] My code follows the style guidelines of this project.

    Documentation

    For new features:

    • [x] I have added a code example showing how to use this feature to the examples directory.
    • [ ] I have added documentation about this feature to the docs directory. If the documentation is in a new markdown file, I have added a link to this new file to the Docs folder README.md file.
    opened by Art4 4
  • Executable Docker container for `mitmproxy` to make running the tests easier

    Executable Docker container for `mitmproxy` to make running the tests easier

    Is your feature request related to a problem?

    Right now, if you want to run the tests for the project, you need to install Python 3 on your system as a prerequisite to then install mitmproxy via its pip3 package manager.

    Describe the solution you'd like

    Adding an executable Docker container that bundles Python3 would remove the requirement for Python 3 on your host system (trading it for Docker, which is more common), and will allow a more automated approach to onboarding for running the tests.

    • [x] I intend to create a pull request to implement this feature myself.
    Type: testing/chores/QA 
    opened by schlessera 0
  • [Task] Audit whether I18n domains are handled correctly everywhere

    [Task] Audit whether I18n domains are handled correctly everywhere

    Verify whether there are any code paths which could be reached where an international (multi-byte) domain would not have been translated to its ASCII value yet and non-multibyte-safe functions are being used.

    This audit should, of course, safeguard this for the future with additional integration tests if/when needed.

    Note: this audit should only verify this for the officially supported API. Not officially supported entry points can be disregarded.

    Type: testing/chores/QA Status: help wanted 
    opened by jrfnl 2
Releases(v2.0.5)
  • v2.0.5(Oct 11, 2022)

  • v2.0.4(Jul 25, 2022)

  • v2.0.3(May 10, 2022)

  • v2.0.2(Mar 28, 2022)

  • v2.0.1(Feb 7, 2022)

  • v2.0.0(Nov 24, 2021)

    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.

      :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 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 :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][gh-495], #526, #528, #532, #543, #562, #578, #590, #606, #607, #608, #618, #622, #625, #626, #630, #642)

    • General housekeeping

      (props @jrfnl, @schlessera)

    Source code(tar.gz)
    Source code(zip)
  • v1.8.1(Jun 4, 2021)

    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
    Source code(tar.gz)
    Source code(zip)
  • v1.8.0(Apr 27, 2021)

    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, @desrosj, @jrfnl, @peterwilsoncc, @SergeyBiryukov, @whyisjake, @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, @JustinyAhin, @jrfnl, @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, @schlessera, @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, @patmead, @schlessera, @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, @gstrauss, @jrfnl, @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, @Zegnat, #335, #339)

    • Make verify => false work with fsockopen

      This allows the fsockopen transport now to ignore SSL failures when requested.

      (props @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, @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, @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, @jrfnl, @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:

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

      (props @jrfnl, @KasperFranz, @ozh, @schlessera, @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, @desrosj, @jrfnl, @ntwb, @ozh, @schlessera, @TimothyBJacobs, @TysonAndre, #280, #298, #302, #303, #352, #353, #354, #356, #388, #397, #428, #436, #439, #461, #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, @jrfnl, @JustinyAhin, @tnorthcutt, #334, #367, #387, #443, #462, #465, #468, #471 )

    Source code(tar.gz)
    Source code(zip)
  • v1.7.0(Oct 13, 2016)

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

    Source code(tar.gz)
    Source code(zip)
  • v1.6.1(May 18, 2014)

  • v1.6.0(Oct 6, 2013)

    • 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
    Source code(tar.gz)
    Source code(zip)
  • v1.5.0(Mar 21, 2021)

Requests for PHP is a humble HTTP request library. It simplifies how you interact with other sites and takes away all your worries.

Requests for PHP Requests is a HTTP library written in PHP, for human beings. It is roughly based on the API from the excellent Requests Python librar

null 3.5k Dec 31, 2022
Requests for PHP is a humble HTTP request library. It simplifies how you interact with other sites and takes away all your worries.

Requests for PHP Requests is a HTTP library written in PHP, for human beings. It is roughly based on the API from the excellent Requests Python librar

null 3.5k Dec 31, 2022
PHP Curl Class makes it easy to send HTTP requests and integrate with web APIs

PHP Curl Class: HTTP requests made easy PHP Curl Class makes it easy to send HTTP requests and integrate with web APIs. Installation Requirements Quic

null 3.1k Jan 5, 2023
↪️ Bypass for PHP creates a custom HTTP Server to return predefined responses to client requests

Bypass for PHP provides a quick way to create a custom HTTP Server to return predefined responses to client requests.Useful for tests with Pest PHP or PHPUnit.

CiaReis 101 Dec 1, 2022
🐼 Framework agnostic package using asynchronous HTTP requests and PHP generators to load paginated items of JSON APIs into Laravel lazy collections.

Framework agnostic package using asynchronous HTTP requests and generators to load paginated items of JSON APIs into Laravel lazy collections.

Andrea Marco Sartori 61 Dec 3, 2022
PHP Curl - This package can send HTTP requests to a given site using Curl.

PHP Curl This package can send HTTP requests to a given site using Curl. It provides functions that can take several types of parameters to configure

Mehmet Can 1 Oct 27, 2022
Application for logging HTTP and DNS Requests

Request Logger Made by Adam Langley ( https://twitter.com/adamtlangley ) What is it? Request logger is a free and open source utility for logging HTTP

null 13 Nov 28, 2022
librestful is a virion for PocketMine servers that make easier, readable code and for async http requests.

librestful is a virion for PocketMine servers that make easier, readable code for async rest requests.

RedMC Network 17 Oct 31, 2022
Provides an easy interface for performing Hyper-Text Transfer Protocol (HTTP) requests

laminas-http provides the HTTP message abstraction used by laminas-mvc, and also provides an extensible, adapter-driven HTTP client library.

Laminas Project 33 Aug 27, 2022
Declarative HTTP Clients using Guzzle HTTP Library and PHP 8 Attributes

Waffler How to install? $ composer require waffler/waffler This package requires PHP 8 or above. How to test? $ composer phpunit Quick start For our e

Waffler 3 Aug 26, 2022
LittleProxy is a high performance HTTP proxy written in Java atop Trustin Lee's excellent Netty event-based networking library

LittleProxy is a high performance HTTP proxy written in Java atop Trustin Lee's excellent Netty event-based networking library

null 1.9k Dec 26, 2022
Express.php is a new HTTP - Server especially made for RESTful APIs written in PHP.

express.php Express.php is a new HTTP - Server especially made for RESTful APIs written in PHP. Features Fast The Library is handles requests fast and

null 5 Aug 19, 2022
Unirest in PHP: Simplified, lightweight HTTP client library.

Unirest for PHP Unirest is a set of lightweight HTTP libraries available in multiple languages, built and maintained by Mashape, who also maintain the

Kong 1.3k Dec 28, 2022
The Library for HTTP Status Codes, Messages and Exception

This is a PHP library for HTTP status codes, messages and error exception. Within the library, HTTP status codes are available in classes based on the section they belong to. Click this link for more information.

Sabuhi Alizada 5 Sep 14, 2022
HTTP header kit for PHP 7.1+ (incl. PHP 8) based on PSR-7

HTTP header kit for PHP 7.1+ (incl. PHP 8) based on PSR-7 Installation composer require sunrise/http-header-kit How to use? HTTP Header Collection Mor

Sunrise // PHP 63 Dec 31, 2022
Guzzle, an extensible PHP HTTP client

Guzzle, PHP HTTP client Guzzle is a PHP HTTP client that makes it easy to send HTTP requests and trivial to integrate with web services. Simple interf

Guzzle 22.3k Jan 2, 2023
A Chainable, REST Friendly, PHP HTTP Client. A sane alternative to cURL.

Httpful Httpful is a simple Http Client library for PHP 7.2+. There is an emphasis of readability, simplicity, and flexibility – basically provide the

Nate Good 1.7k Dec 21, 2022
PHP's lightweight HTTP client

Buzz - Scripted HTTP browser Buzz is a lightweight (<1000 lines of code) PHP 7.1 library for issuing HTTP requests. The library includes three clients

Kris Wallsmith 1.9k Jan 4, 2023
HTTPlug, the HTTP client abstraction for PHP

HTTPlug HTTPlug, the HTTP client abstraction for PHP. Intro HTTP client standard built on PSR-7 HTTP messages. The HTTPlug client interface is compati

The PHP HTTP group 2.4k Dec 30, 2022