Re: RFC: Server-Side Request and Response Objects (v2)

> On Feb 15, 2020, at 3:01 AM, Larry Garfield <larry@garfieldtech.com> wrote: > > Data point: > > In PSR-7, the names used are: > > - queryParams: The query string values. > - parsedBody: The body of the message, converted to a meaningful value. If the request type is > a form, then it MUST be equivalent to $_POST. If not, it's up to the particular implementation > to determine what "parsed" means. (Eg, parsing a JSON body of a POST into some domain > object, or whatever.) > - The raw body is a stream called "body", or rather an OOP wrapper around a stream > since PHP's native stream interface is fugly. > - There's specific handling for uploadedFiles, too. > > cf: https://www.php-fig.org/psr/psr-7/ > > To the earlier point about existing implementations, while there are a myriad of older, custom > implementations of abstractions around superglobals, there's only two that are not decade-old > proprietary implementations: HttpFoundation and PSR-7. Those are, realistically, the only > implementations that matter. Anything else would be on the same order of magnitude effort to port > to one of those as to port to this proposal. In a meaningful sense, those are the only > "existing competition". Both also have robust ecosystems that make leveraging them in an > entirely custom app pretty straightforward. > > (Whatever your feelings of the technical merits of either design, that's the current > state-of-the-market.) > > Which therefore begs the question, is this proposal intended to supplant HttpFoundation and > PSR-7, or to become a common underpinning that both of them wrap, or to be a third cohabitating > implementation in the ecosystem? > > It doesn't seem robust enough to supplant both of them entirely, there's little value > to either HttpFoundation or PSR-7 to rewrite their guts to wrap this object (though it's easier > for PSR-7, as an interface, for someone to write a new implementation of it than for > HttpFoundation), which would mean we'd end up with a 3rd in-the-wild implementation for user > space to keep track of. > > I am unclear how that is a market win. The win is it allows developer to provide a simple to use object oriented interface *in core*. IOW, without having to bring in an external PHP-code implementation that may or may not break in the future. Another big win would be to allow developers to deprecate use of superglobals in their own apps. However Paul do not want to add an ini setting to disable the use of superglobals. But how could disabling superglobals be done in HttpFoundation or PSR-7? Maybe Paul will reconsider adding such an capability to his RFC because it is something we cannot get with HttpFoundation and PSR-7. Or maybe we should be looking at is a core implementation of PSR-7 instead; one that would allow us to disable access to the superglobals? One that people could subclass, of course. If we did that, we might hash out why some developers do not use PSR-7 and possibly fix its (perceived?) faults in a new PSR to amend PSR-7. -Mike