The RFC is at https://wiki.php.net/rfc/request_response.
\nThe message opening discussion on Internals is at http://news.php.net/php.internals/97461.
\nThe extension itself is available at https://pecl.php.net/package/request, with documentation at https://gitlab.com/pmjones/ext-request.
\n(Many thanks to John Boehr for doing the actual heavy lifting of writing the C code.)
\nNearly every PHP framework and library-collection since 2000 has had classes to encapsulate the \u201crequest\u201d and \u201cresponse\u201d elements of a PHP application. A handful of examples include:
\nThere are many others. They all do essentially the same things:
\nCopy the $_GET, $_POST, $_SERVER, etc. superglobals into a \u201crequest\u201d object. Some make them available through a method that standardizes the logic to get a default value when a key is not present, a la return (isset($_GET[$key]) ? $_GET[$key] : $defaultValue).
Add convenience methods to the \u201crequest\u201d object so that you can determine the HTTP method, the values of various headers, and so on.
\nThe \u201cresponse\u201d object is a place to hold headers, cookies, status, and content, so they can all be inspected and modified before sending, and to make testing easier. (This is because the header(), setcookie(), etc. functions in PHP are not especially amenable to inspection, modification, and testing \u2013 at least, not without being wrapped somehow.)
The \u201cresponse\u201d object often has some convenience methods to send JSON content, send files for download, and so on.
\nWhy do framework and library-collection authors write these request and response objects? Because PHP, even though it is a web-centric programming language, and even though it provides all sorts of classes for all sorts of functionality, it has never had classes for server-side requests and responses. This RFC helps to improve this situation in PHP 7 and later.
\nRead the Reddit discussion about this post here.
\n" }