[VOTE] Server-Side Request and Response Objects (v2)

  109161
March 20, 2020 13:31 pmjones@pmjones.io ("Paul M. Jones")
Hi all,

I have opened the vote on Server-Side Request and Response Objects at <https://wiki.php.net/rfc/request_response>.

The voting period will close two weeks from today on Fri 03 Apr 2020.


-- 
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
  109162
March 20, 2020 14:35 marandall@php.net (Mark Randall)
On 20/03/2020 13:31, Paul M. Jones wrote:
> I have opened the vote on Server-Side Request and Response Objects at <https://wiki.php.net/rfc/request_response>. To practice what I preach:
I have voted against, as I don't believe this proposal offers anything which isn't already possible using much more comprehensive and well-supported userland libraries. At best, adding in yet another mechanism risks further fragmenting the ecosystem to the major detriment of ecosystem interoperability. This RFC should be revisited if PHP ever gets native support for long-running multi-request processes, as at that time there would be a clear need for a self-contained request-specific request / response object. Mark Randall
  109168
March 20, 2020 17:02 ben@benramsey.com (Ben Ramsey)
> On Mar 20, 2020, at 08:31, Paul M. Jones <pmjones@pmjones.io> wrote: > > Hi all, > > I have opened the vote on Server-Side Request and Response Objects at <https://wiki.php.net/rfc/request_response>. > > The voting period will close two weeks from today on Fri 03 Apr 2020.
Paul, I apologize for not speaking up more on the list during the discussion phase. The one issue I did raise -- regarding the use of value objects instead of arrays -- hits at one of the reasons why I’m voting “no” on this proposal. Others raised similar concerns on the list, which is why it wasn’t necessary for me to jump in and restate the same concerns. I appreciate the desire to keep this RFC small. Surely, it could grow astronomically into a huge library with tons of classes and interfaces, and being in core would be a detriment to it, since developers could not iterate as quickly and users could not upgrade as often. For this reason, I think this functionality is best provided by userland libraries for now. And now, a tangent… From the RFC:
> PHP has lacked core server-side request and response objects for > its entire existence
PHP hasn’t had these objects in core because of the way the SAPIs work. In fact, I think the objects could be confusing because of this. Python’s WSGI defines request and response objects for Python as a way for the web application and the web server to communicate, while remaining implementation-agnostic. If PHP were to implement something of this sort, I think it should explicitly adopt PSR-7 and PSR-15 interfaces and a modified form of PEP-3333 (WSGI)[1] to work with the various SAPIs. In simplified terms, one could specify a callable that the SAPI would invoke, passing it a PSR-7 ServerRequestInterface object and PSR-15 RequestHandlerInterface object. It might look something like this: use Psr\Http\Message\ResponseInterface; use Psr\Http\Message\ServerRequestInterface; use Psr\Http\Server\RequestHandlerInterface; function application( ServerRequestInterface $request, RequestHandlerInterface $handler ): ResponseInterface { // Do stuff... $response = $handler->handle($request); // Do more stuff... return $response; // SAPI handles response object. } // Tell the SAPI what callable to invoke. ini_set('sapi.handler', 'application'); This is already an approach that many PHP frameworks have adopted, and I think there is a lot of value in codifying this server communication at the core, while remaining light on the definition of the objects, and even allowing applications to provide and define their own implementations. As another pointed out, I think this will become more important as PHP gets stronger support for long-running processes. For now, I think this problem is best handled in userland. Cheers, Ben [1]: https://www.python.org/dev/peps/pep-3333/
  109366
March 26, 2020 23:22 mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)
Hi,

To justify my "no" vote. I agree that it would be nice if PHP would provide
these objects out of the box, but there are some inconsistencies in the
object properties that made me oppose this. For instance, not all headers
are treated equally, while some become properties of the request object,
others must be accessed in the headers array. And the line that divides
them seems a bit arbitrary. For instance, CONTENT_MD5 gets special
treatment in this object while it was never special in the $_SERVER
superglobal. Some other values are missing like REQUEST_TIME (it's missing
at least from the proposal and the linked README). Finally, making
decisions like overwriting method if a HTTP_X_HTTP_METHOD_OVERRIDE header
is present seem too opinionated for an object that should be more agnostic.
It does make sense, but it hides away information from the user in an
attempt to be helpful.

In conclusion, I do think PHP should offer an OOP oriented way to deal with
requests and responses, but those objects should be more consistent and
less opinionated.

Regards,
Pedro
  109520
April 3, 2020 15:12 pmjones@pmjones.io ("Paul M. Jones")
> On Mar 20, 2020, at 08:31, Paul M. Jones <pmjones@pmjones.io> wrote: > > Hi all, > > I have opened the vote on Server-Side Request and Response Objects at <https://wiki.php.net/rfc/request_response>. > > The voting period will close two weeks from today on Fri 03 Apr 2020.
The vote is now closed; at 11 in favor to 35 against, the RFC is not accepted. I will try to put together an after-action/lessons-learned message next week. Thanks to all who participated. -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php