This is an old revision of the document!
PHP RFC: Server-Side Request and Response
- Version: 0.1
- Date: 2016-09-27
- Author: Paul M. Jones, firstname.lastname@example.org
- Status: Draft
- First Published at: http://wiki.php.net/rfc/request_response
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
Proposed PHP Version(s)
Next PHP 7.x.
To Existing Extensions
TBD: Please explain how you have verified your RFC's compatibility with opcache.
Make sure there are no open issues when the vote starts!
Unaffected PHP Functionality
The remainder of PHP should remain unaffected.
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
- the version(s) it was merged to
- a link to the git commit(s)
- a link to the PHP manual entry for the feature
Links to external references, discussions or RFCs
Keep this updated with features that were discussed on the mail lists.