rfc:request_response
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
rfc:request_response [2016/09/28 00:06] – initial creation, template still mostly in place pmjones | rfc:request_response [2020/04/08 12:47] (current) – add epilogue link pmjones | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== PHP RFC: Server-Side Request and Response ====== | + | ====== PHP RFC: Server-Side Request and Response |
- | * Version: 0.1 | + | |
- | * Date: 2016-09-27 | + | |
- | * Author: Paul M. Jones, pmjones@php.net | + | |
- | * Status: Draft | + | |
- | * First Published at: http:// | + | |
- | This is a suggested template for PHP Request for Comments (RFCs). Change this template to suit your RFC. | + | * Version: 2.2 |
+ | * Date: 2020-03-17 | ||
+ | * Author: Paul M. Jones, pmjones@pmjones.io | ||
+ | * Status: Declined | ||
+ | * First Published at: [[http:// | ||
- | Read https:// | + | ===== Introduction ===== |
+ | This RFC proposes an object-oriented approach around request and response functionality already existing in PHP, in order to reduce the global mutable state problems that come with superglobals and the various response-related functions. | ||
- | Quoting | + | The SQLite " |
- | > PHP is and should remain: | + | Likewise, think of this RFC not as a replacement for HttpFoundation or PSR-7, or as a model of HTTP messages, but as an object-oriented alternative to superglobals, |
- | > 1) a pragmatic web-focused language | + | |
- | > 2) a loosely typed language | + | |
- | > 3) a language which caters to the skill-levels | + | |
- | Your RFC should move PHP forward following his vision. As [[http:// | + | ===== Proposal ===== |
- | every new feature, and the scope of the goodness that those new features bring." | + | |
- | ===== Introduction ===== | + | This RFC proposes an extension to declare three new classes and one interface in the root namespace: |
- | The elevator pitch for the RFC. The first paragraph in this section will be slightly larger to give it emphasis; please write a good introduction. | + | * SapiRequest, |
- | ===== Proposal | + | * SapiResponse and SapiResponseInterface, |
- | All the features | + | |
+ | * SapiResponseSender, | ||
+ | |||
+ | The full README, working code, and all tests are available at [[https:// | ||
+ | |||
+ | An earlier version of the extension is in the 1.x branch of the same repository; differences from that version are discussed later this proposal. | ||
+ | |||
+ | ==== Summary | ||
+ | |||
+ | < | ||
+ | |||
+ | Instead of the superglobal ... ... use SapiRequest: | ||
+ | --------------------------------------- --------------------------------------- | ||
+ | $_COOKIE | ||
+ | $_GET | ||
+ | $_GET[' | ||
+ | $_FILES | ||
+ | $_POST | ||
+ | $_SERVER | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | |||
+ | Instead of parsing ... ... use SapiRequest: | ||
+ | --------------------------------------- --------------------------------------- | ||
+ | $_FILES to look more like $_POST | ||
+ | $_SERVER[' | ||
+ | and | ||
+ | $request-> | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | $_SERVER[' | ||
+ | |||
+ | Instead of emitting ... ... buffer with SapiResponse: | ||
+ | --------------------------------------- --------------------------------------- | ||
+ | header(' | ||
+ | $response-> | ||
+ | header(' | ||
+ | header(' | ||
+ | setcookie(' | ||
+ | setrawcookie(' | ||
+ | echo $content; | ||
+ | |||
+ | Instead of sending with ... ... send with SapiResponseSender: | ||
+ | --------------------------------------- --------------------------------------- | ||
+ | echo, header(), setcookie(), | ||
+ | |||
+ | </ | ||
+ | |||
+ | There is more: please see the docs at [[https:// | ||
+ | |||
+ | |||
+ | ==== Criticism and Objections ==== | ||
+ | |||
+ | === Why Do This In PHP Itself? === | ||
+ | |||
+ | For a language as closely related to the web as it is, PHP has lacked core server-side request | ||
+ | |||
+ | Further, truly read-only objects in PHP userland are difficult if not impossible to achieve, especially when you take immutability of values into account. Working within an extension is the surest way of doing it, a la the request object offered here. | ||
+ | |||
+ | === What About Existing Userland Projects? === | ||
+ | |||
+ | I would prefer to discuss this proposal on its own merits, and thereby stay away from what might appear to be negative commentary on other projects. Nonetheless, | ||
+ | |||
+ | With all that in mind, I will present limited comparisons to two other major projects, hopefully hitting the high points without sounding overly-negative. If further comparison is desired, I will attempt to provide it. | ||
+ | |||
+ | == Symfony HttpFoundation == | ||
+ | |||
+ | HttpFoundation provides a very wide range of functionality, | ||
+ | |||
+ | As it happens, this proposal turns out to mimic a reduced subset of HttpFoundation functionality. The same subset is common to many userland implementations: | ||
+ | |||
+ | * a way to read the request-related superglobals such as $_GET, $_POST, etc. from an object; and, | ||
+ | |||
+ | * a way to set headers and content into an object so they can be inspected and modified before sending. | ||
+ | |||
+ | So, this proposal is in some ways a distillation and summary of widely desired functionality in userland. | ||
+ | |||
+ | Back to HttpFoundation specifically, | ||
+ | |||
+ | <code php> | ||
+ | use Symfony\Component\HttpFoundation\Cookie; | ||
+ | |||
+ | $response-> | ||
+ | </ | ||
+ | |||
+ | This is not so terrible, though it does additionally involve the HeaderBag and Cookie classes. | ||
+ | |||
+ | <code php> | ||
+ | $response-> | ||
+ | </ | ||
+ | |||
+ | HttpFoundation request and response objects are both fully mutable. In contrast, this proposal offers a request object with read-only properties; the class can be extended to add mutable or immutable properties. The response object offered here is fully mutable, though its methods are marked as final; this leaves the response object open for extension by frameworks and libraries, but closed for modification to its core functions. | ||
+ | |||
+ | == PSR-7 == | ||
+ | |||
+ | (Full disclosure: I was one of the sponsors on PSR-7.) | ||
+ | |||
+ | PSR-7 is a newer competitor to Symfony HttpFoundation. The PSR-7 interoperability interfaces, and their various competing implemementations (each with their own idiosyncrasies and additions), attempt to model HTTP messages, both for use by an HTTP client (as in Guzzle) and by server-side applications (as in Laminas). | ||
+ | |||
+ | Using PSR-7 for server-side requests and responses can be challenging. For good or bad, the specification defines a way of working that is very different from implementations pre-existing it. A number of followup PSRs have been created to relieve these issues, as have other userland helper packages. | ||
+ | |||
+ | Using the same example as with HttpFoundation above, setting a cookie in PSR-7 is no simple task. PSR-7 only provides a way to set headers, which generally means a helper library is necessary to set cookies properly. For examples of such libraries, see [[https:// | ||
+ | |||
+ | Using the FigCookies project, this is how to set a cookie into a PSR-7 Response: | ||
+ | |||
+ | <code php> | ||
+ | use Dflydev\FigCookies\SetCookies; | ||
+ | use Dflydev\FigCookies\SetCookie; | ||
+ | |||
+ | $response = $response-> | ||
+ | SetCookies:: | ||
+ | SetCookie:: | ||
+ | ); | ||
+ | </ | ||
+ | |||
+ | As such, PSR-7 is not " | ||
+ | |||
+ | In contrast, this proposal offers something much more straightforward: | ||
+ | |||
+ | <code php> | ||
+ | $response-> | ||
+ | </ | ||
+ | |||
+ | In a polar opposite of HttpFoundation, | ||
+ | |||
+ | To reiterate, this proposal offers read-only properties on the request with consistent and reliable immutability of those values. The response object remains mutable. | ||
+ | |||
+ | == Userland Availability, | ||
+ | |||
+ | (Copied, with light editing, from [[https:// | ||
+ | |||
+ | One common objection, with variations, has been: "There is a wider userland ecosystem that already performs the proposed | ||
+ | functions, with more capabilities, | ||
+ | |||
+ | The proposal authors recognize and understand the sentiment. The following counterargument, | ||
+ | |||
+ | When ext/pdo was added to core, there was already a "wider ecosystem that already performs these functions, with more capabilities, | ||
+ | |||
+ | PDO did not "add capabilities which do not or cannot exist in userland" | ||
+ | |||
+ | And yet, PDO has turned out to be of great benefit, because it brought together features into core that (figuratively speaking) everybody needed and was rewriting in userland over and over. | ||
+ | |||
+ | PDO is the strongest example here, but depending on how you count, there are 2-3 other extensions that also serve: ext/date, ext/phar, and (reaching back to antiquity) ext/ | ||
+ | |||
+ | So, there is a long history of widely-needed userland functionality being brought into core. This proposal is a pretty tame example of doing so; as presented, it is very similar to the way PHP itself already does things, just wrapped in object properties and methods, and is very similar to how things are being done across a wide swath of userland. | ||
+ | |||
+ | Now, it is possible that the above objection should have prevented PDO (et al.) from going into core. If that is the case, and (in hindsight) it was a mistake to allow them, then consistency alone makes the objection valid here as well. | ||
+ | |||
+ | However, if (in hindsight) it was not a mistake to allow those extensions, then the objection is not an especially strong argument against this RFC. That's not to say " | ||
+ | |||
+ | === Other Questions And Comments === | ||
+ | |||
+ | Q: The proposal compares and contrasts with HttpFoundation and the various PSR-7 implementations; | ||
+ | |||
+ | A: See this message for a starting point: [[https:// | ||
+ | |||
+ | Q: Are these global single-instance objects? | ||
+ | |||
+ | A: No, you can create as many instances as you like, in whatever scopes you like. | ||
+ | |||
+ | Q: Do these objects replace the superglobals? | ||
+ | |||
+ | A: No. | ||
+ | |||
+ | Q: Do these objects deal with $_SESSION and the session functions? | ||
+ | |||
+ | A: No; it is explicitly out of scope for this RFC. | ||
+ | |||
+ | Q: Does SapiRequest hold references to the superglobals, | ||
+ | |||
+ | A: Copies, made at instantiation time. Changes to `$_GET` after the SapiRequest is instantiated will not be reflected in the existing instance. | ||
+ | |||
+ | Q: Since the $query, $post etc. properties are the same as $_GET and $_POST, does that mean they retain the same name mangling scheme? | ||
+ | |||
+ | A: They do; that is, SapiRequest uses whatever is passed into it at construction time. If PHP changes its name mangling, or if different array values are passed in, SapiRequest will use those instead. | ||
+ | |||
+ | Q: Readonly properties are unusual for PHP. | ||
+ | |||
+ | A: Granted, though not unheard of. PdoStatement:: | ||
+ | |||
+ | Q: Does this has any performance impact? | ||
+ | |||
+ | A: Compared to userland, probably greater performance, | ||
+ | |||
+ | Q: Why is SapiRequest readonly, and SapiResponse mutable? | ||
+ | |||
+ | A: It makes sense that you would not want to change what you have received as a request; however, as you are in charge of creating the response, modifying it as needed seems reasonable. Further, the " | ||
+ | |||
+ | Q: Why is SapiRequest composed only of properties, and SapiResponse composed only of methods? | ||
+ | |||
+ | A: It's an outgrowth of an asymmetry that already exists in PHP: $_GET, $_POST, et al. are properties representing the request, whereas header(), setcookie(), | ||
+ | |||
+ | Q: Why not write (PSR-7|HttpFoundation|OtherImplementation) in C, instead of your own version? | ||
+ | |||
+ | A: This is not "my own version." | ||
+ | |||
+ | Q: Does it support HTTP/2? | ||
+ | |||
+ | A: It supports HTTP/2 exactly as much as PHP itself does. | ||
+ | |||
+ | Q: Does it support async? | ||
+ | |||
+ | A: Async is not in scope for the proposed API. | ||
+ | |||
+ | Q: What would a migration path look like? | ||
+ | |||
+ | A: Something like the one outlined in the later portion of this message: [[https:// | ||
+ | |||
+ | ==== Changes From The 1.x Version ==== | ||
+ | |||
+ | Based on user feedback over the past couple of years, this proposal differs from the earlier 1.x version in the following substantial ways: | ||
+ | |||
+ | * The " | ||
+ | |||
+ | * Some users objected on principle to the SapiRequest constructing itself using the superglobals internally. As a result, the constructor now requires a single array parameter; the corresponding argument is typically $GLOBALS but can be any array that mimics the $GLOBALS structure. | ||
+ | |||
+ | * The SapiRequest object no longer has the immutable application-related functionality represented by withInput(), | ||
+ | |||
+ | * The SapiResponse object no longer has setContent() convenience methods such as setContentJson() and setContentDownload(). Users found these less convenient than anticipated, | ||
+ | |||
+ | * SapiResponse no longer has a self-sending capability. It was noted that to customize sending logic, you needed a custom SapiResponse object. As a result, the sending logic has been extracted to a SapiResponseSender class. | ||
+ | |||
+ | * To address some concerns from an earlier round of discussion, all SapiResponse properties are now private, and all its methods are now final, though the class itself is not. This keeps the class open for extension but closed for modification. | ||
+ | |||
+ | * SapiResponse:: | ||
+ | |||
+ | In all, these removals and changes bring the proposal | ||
- | To [[http:// | + | ==== Open Questions ==== |
- | for inclusion in one of the world' | + | |
- | Remember that the RFC contents should be easily reusable in the PHP Documentation. | + | 1. Should these classes go into an existing extension, rather than one of their own? Or should they go into " |
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
- | What breaks, and what is the justification for it? | + | |
+ | Userland code that declares classes named SapiRequest, SapiResponse, | ||
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
- | List the proposed PHP versions that the feature will be included in. Use relative versions such as " | + | |
+ | Next PHP 7.x or 8.0. | ||
===== RFC Impact ===== | ===== RFC Impact ===== | ||
+ | |||
==== To SAPIs ==== | ==== To SAPIs ==== | ||
- | Describe the impact to CLI, Development web server, embedded PHP etc. | + | |
+ | None. | ||
==== To Existing Extensions ==== | ==== To Existing Extensions ==== | ||
- | Will existing extensions | + | |
+ | It would be convenient if the php_head_parse_cookie_options_array() function in ext/ | ||
==== To Opcache ==== | ==== To Opcache ==== | ||
- | It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP. | ||
- | Please explain how you have verified your RFC's compatibility with opcache. | + | None. |
==== New Constants ==== | ==== New Constants ==== | ||
- | Describe any new constants so they can be accurately and comprehensively explained in the PHP documentation. | + | |
+ | None. | ||
==== php.ini Defaults ==== | ==== php.ini Defaults ==== | ||
- | If there are any php.ini settings then list: | + | |
- | * hardcoded default values | + | None. |
- | * php.ini-development values | + | |
- | * php.ini-production values | + | |
===== Open Issues ===== | ===== Open Issues ===== | ||
- | Make sure there are no open issues when the vote starts! | + | |
+ | None at this time. | ||
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== | ||
- | List existing areas/ | ||
- | This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise. | + | The remainder of PHP should remain unaffected. |
===== Future Scope ===== | ===== Future Scope ===== | ||
- | This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC. | + | |
+ | This extension acts as an object-oriented wrapper around existing PHP request and response functionality; | ||
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
- | Include these so readers know where you are heading and can discuss the proposed voting options. | ||
- | State whether this project requires a 2/3 or 50%+1 majority (see [[voting]]) | + | For or against the proposal. |
===== Patches and Tests ===== | ===== Patches and Tests ===== | ||
- | Links to any external patches and tests go here. | ||
- | If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed. | + | The C code for the extension and tests are at [[https:// |
- | + | ||
- | Make it clear if the patch is intended to be the final patch, or is just a prototype. | + | |
===== Implementation ===== | ===== Implementation ===== | ||
- | After the project is implemented, | + | |
+ | After the project is implemented, | ||
- the version(s) it was merged to | - the version(s) it was merged to | ||
- a link to the git commit(s) | - a link to the git commit(s) | ||
Line 90: | Line 321: | ||
===== References ===== | ===== References ===== | ||
- | Links to external references, | + | |
+ | 1.x discussions: | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | 2.x discussions: | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | [[https:// | ||
===== Rejected Features ===== | ===== Rejected Features ===== | ||
- | Keep this updated with features that were discussed | + | |
+ | Add filter_input integration to SapiRequest. | ||
+ | |||
+ | Add .ini setting(s) to disable superglobals, | ||
+ | |||
+ | Add .ini setting(s) to disable response-related functions, and/or warn on their use. | ||
+ | |||
+ | Expand the number of classes provided, to allow for various SapiRequest-related value objects. | ||
+ | |||
+ | Provide builder and locking methods for SapiRequest. | ||
+ | |||
+ | Make the SapiRequest properties mutable. | ||
+ | |||
+ | Add a SapiResponse:: | ||
+ | |||
+ | Embed the PHP multipart/ | ||
+ | |||
+ | ===== Vote ===== | ||
+ | |||
+ | <doodle title=" | ||
+ | * Yes | ||
+ | * No | ||
+ | </ |
rfc/request_response.txt · Last modified: 2020/04/08 12:47 by pmjones