This is an old revision of the document!

PHP RFC: Server-Side Request and Response Objects

Quoting Rasmus:

PHP is and should remain:
1) a pragmatic web-focused language
2) a loosely typed language
3) a language which caters to the skill-levels and platforms of a wide range of users

This RFC should move PHP forward following his vision. As said by Zeev Suraski “Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases […] Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring.”


From time to time we've all heard the complaint that PHP has no built-in request object to represent the execution environment. Userland ends up writing these themselves, and those are usually tied to a specific library collection or framework. The same is true for a response object, to handle the output going back to the web client. I've written them myself more than once, as have others here.

After doing some library and framework research (linked later) it looks like there is a reasonably common subset of request/response functionality across all the userland implementations. That functionality also appears useful to non-framework users.


I wrote up a userland implementation for that limited subset of functionality, and John Boehr then used that as a reference point for the C version. It is PHP 7.x only, and you can see the result at:


The userland reference implementation is at https://gitlab.com/pmjones/phprequest/tree/master/refimpl, and the research subjects are in https://gitlab.com/pmjones/phprequest/tree/master/refimpl/notes.

The extension provides server-side request and response objects for PHP. They are *not* HTTP message objects proper. They are more like wrappers for existing global PHP variables and functions, with some limited additional convenience functionality. There are only two classes:

- StdRequest, essentially a read-only struct composed of PHP superglobals and some other commonly-used values

- StdResponse, essentially a wrapper around (and buffer for) response-related PHP functions, with some additional convenience methods, and self-sending capability

Backward Incompatible Changes

None expected.

Proposed PHP Version(s)

Next PHP 7.x.

RFC Impact


None expected.

To Existing Extensions

None expected.

To Opcache

TBD: Please explain how you have verified your RFC's compatibility with opcache.

New Constants


php.ini Defaults


Open Issues

Make sure there are no open issues when the vote starts!

Unaffected PHP Functionality

The remainder of PHP should remain unaffected.

Future Scope

Support for HTTP/2 and server push.

Proposed Voting Choices

Include these so readers know where you are heading and can discuss the proposed voting options.

No language changes, so only 50%+1 should be needed.

Patches and Tests

The C code for the extension and tests are at https://gitlab.com/pmjones/phprequest/tree/master .


After the project is implemented, this section should contain

  1. the version(s) it was merged to
  2. a link to the git commit(s)
  3. a link to the PHP manual entry for the feature


Links to external references, discussions or RFCs

Rejected Features

Keep this updated with features that were discussed on the mail lists.

rfc/request_response.1475022049.txt.gz · Last modified: 2017/09/22 13:28 (external edit)