rfc:request_response
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:request_response [2020/02/22 19:45] – add userland counterargument 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 Objects ====== | ====== PHP RFC: Server-Side Request and Response Objects ====== | ||
- | * Version: 2.1 | + | * Version: 2.2 |
- | * Date: 2020-02-19 | + | * Date: 2020-03-17 |
* Author: Paul M. Jones, pmjones@pmjones.io | * Author: Paul M. Jones, pmjones@pmjones.io | ||
- | * Status: | + | * Status: |
* First Published at: [[http:// | * First Published at: [[http:// | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | This RFC proposes an object-oriented approach around request and response functionality already existing in PHP, in order to reduce the global-state problems that come with superglobals and the various response-related functions. | + | This RFC proposes an object-oriented approach around request and response functionality already existing in PHP, in order to reduce the global |
The SQLite " | The SQLite " | ||
Line 19: | Line 19: | ||
This RFC proposes an extension to declare three new classes and one interface in the root namespace: | This RFC proposes an extension to declare three new classes and one interface in the root namespace: | ||
- | * ServerRequest, composed of immutable read-only copies of PHP superglobals, | + | * SapiRequest, composed of immutable read-only copies of PHP superglobals, |
- | * ServerResponse | + | * SapiResponse |
- | * ServerResponseSender, to emit the ServerResponse | + | * SapiResponseSender, to emit the SapiResponse |
The full README, working code, and all tests are available at [[https:// | The full README, working code, and all tests are available at [[https:// | ||
Line 33: | Line 33: | ||
< | < | ||
- | Instead of the superglobal ... ... use ServerRequest: | + | Instead of the superglobal ... ... use SapiRequest: |
--------------------------------------- --------------------------------------- | --------------------------------------- --------------------------------------- | ||
$_COOKIE | $_COOKIE | ||
$_GET | $_GET | ||
- | $_GET[' | + | $_GET[' |
$_FILES | $_FILES | ||
$_POST | $_POST | ||
Line 49: | Line 49: | ||
$_SERVER[' | $_SERVER[' | ||
- | Instead of parsing ... ... use ServerRequest: | + | Instead of parsing ... ... use SapiRequest: |
--------------------------------------- --------------------------------------- | --------------------------------------- --------------------------------------- | ||
$_FILES to look more like $_POST | $_FILES to look more like $_POST | ||
Line 62: | Line 62: | ||
$_SERVER[' | $_SERVER[' | ||
- | Instead of emitting ... ... buffer with ServerResponse: | + | Instead of emitting ... ... buffer with SapiResponse: |
--------------------------------------- --------------------------------------- | --------------------------------------- --------------------------------------- | ||
header(' | header(' | ||
Line 72: | Line 72: | ||
echo $content; | echo $content; | ||
- | Instead of sending with ... ... send with ServerResponseSender: | + | Instead of sending with ... ... send with SapiResponseSender: |
--------------------------------------- --------------------------------------- | --------------------------------------- --------------------------------------- | ||
echo, header(), setcookie(), | echo, header(), setcookie(), | ||
Line 182: | Line 182: | ||
=== Other Questions And Comments === | === Other Questions And Comments === | ||
- | Q: Does ServerRequest hold references to the superglobals, | + | Q: The proposal compares and contrasts with HttpFoundation and the various PSR-7 implementations; |
- | A: Copies, made at instantiation time. Changes to `$_GET` after the ServerRequest | + | A: See this message for a starting point: [[https:// |
- | Q: Since the $get, $post etc. properties are the same as $_GET and $_POST, does that mean they retain the same name mangling scheme? | + | Q: Are these global single-instance objects? |
- | A: They do; that is, ServerRequest | + | 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 | ||
Q: Readonly properties are unusual for PHP. | Q: Readonly properties are unusual for PHP. | ||
- | A: Granted, though not unheard of. PdoStatement:: | + | A: Granted, though not unheard of. PdoStatement:: |
Q: Does this has any performance impact? | Q: Does this has any performance impact? | ||
Line 198: | Line 214: | ||
A: Compared to userland, probably greater performance, | A: Compared to userland, probably greater performance, | ||
- | Q: Why is ServerRequest | + | Q: Why is SapiRequest |
- | 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. | + | 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 ServerRequest | + | Q: Why is SapiRequest |
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(), | 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? | + | Q: Why not write (PSR-7|HttpFoundation|OtherImplementation) in C, instead of your own version? |
A: This is not "my own version." | A: This is not "my own version." | ||
Line 216: | Line 232: | ||
Q: Does it support async? | Q: Does it support async? | ||
- | A: It supports async exactly as much as PHP itself does. | + | 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 ==== | ==== Changes From The 1.x Version ==== | ||
Line 222: | Line 242: | ||
Based on user feedback over the past couple of years, this proposal differs from the earlier 1.x version in the following substantial ways: | Based on user feedback over the past couple of years, this proposal differs from the earlier 1.x version in the following substantial ways: | ||
- | * Some users objected | + | * The " |
- | * The ServerRequest object no longer has the immutable application-related functionality represented by withInput(), | + | * Some users objected on principle |
- | * The ServerResponse | + | * The SapiRequest |
- | * ServerResponse | + | * The SapiResponse object |
- | * To address some concerns from an earlier round of discussion, all ServerResponse 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 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 |
- | * ServerResponse:: | + | * 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 much closer to PHP as-it-is. | In all, these removals and changes bring the proposal much closer to PHP as-it-is. | ||
Line 238: | Line 260: | ||
==== Open Questions ==== | ==== Open Questions ==== | ||
- | 1. Are the more appropriate names other than ServerRequest, | + | 1. Should these classes go into an existing extension, rather than one of their own? Or should they go into " |
- | + | ||
- | 2. Should these classes go into an existing extension, rather than one of their own? | + | |
- | + | ||
- | 3. ??? | + | |
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
- | Userland code that declares classes named ServerRequest, ServerResponse, or ServerReponseSender | + | Userland code that declares classes named SapiRequest, SapiResponse, or SapiReponseSender |
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
Line 325: | Line 342: | ||
[[https:// | [[https:// | ||
- | [[https:// | + | [[https:// |
+ | |||
+ | [[https:// | ||
+ | |||
+ | [[https:// | ||
===== Rejected Features ===== | ===== Rejected Features ===== | ||
- | Add filter_input integration to ServerRequest. | + | Add filter_input integration to SapiRequest. |
Add .ini setting(s) to disable superglobals, | Add .ini setting(s) to disable superglobals, | ||
Line 335: | Line 356: | ||
Add .ini setting(s) to disable response-related functions, and/or warn on their use. | 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 | + | Expand the number of classes provided, to allow for various |
+ | |||
+ | Provide builder and locking methods for SapiRequest. | ||
+ | |||
+ | Make the SapiRequest properties mutable. | ||
+ | |||
+ | Add a SapiResponse:: | ||
- | Provide builder | + | Embed the PHP multipart/ |
- | Make the ServerRequest properties mutable. | + | ===== Vote ===== |
- | Add a ServerResponse:: | + | <doodle title=" |
+ | * Yes | ||
+ | * No | ||
+ | </ | ||
rfc/request_response.1582400755.txt.gz · Last modified: 2020/02/22 19:45 by pmjones