Paul M. Jones

The RFC is at https://wiki.php.net/rfc/request_response.

The message opening discussion on Internals is at http://news.php.net/php.internals/97461.

The extension itself is available at https://pecl.php.net/package/request, with documentation at https://gitlab.com/pmjones/ext-request.

(Many thanks to John Boehr for doing the actual heavy lifting of writing the C code.)

Nearly every PHP framework and library-collection since 2000 has had classes to encapsulate the “request” and “response” elements of a PHP application. A handful of examples include:

• Aura\Web\Request and Response.
• Cake\Network\Request and Response.
• Code Igniter Input (request) and Output (response).
• Horde_Controller_Request_Http and Horde_Controller_Response.
• Joomla\Input\Input (request) and Joomla\Application\AbstractWebApplication (response handling).
• lithium\action\Request and Response.
• MediaWiki WebRequest and WebResponse (though the latter does not encapsulate content).
• Phalcon\Http\Request and Response.
• Symfony\Component\HttpFoundation\Request and Response (Drupal and Laravel extend from these).
• Yaf_Request_Http and Response.
• yii\web\Request and Response.
• Zend\PhpEnvironment\Request and Response

There are many others. They all do essentially the same things:

• Copy the $_GET, $_POST, $_SERVER, etc. superglobals into a “request” 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 “request” object so that you can determine the HTTP method, the values of various headers, and so on.

• The “response” 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 – at least, not without being wrapped somehow.)

• The “response” object often has some convenience methods to send JSON content, send files for download, and so on.

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

Read the Reddit discussion about this post here.