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

On 20/03/2020 13:31, Paul M. Jones wrote:

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

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 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/

Hi,

First of all I'd like to thank you for all the efforts put into the RFC! I noticed I haven't when I opined before. I've voted against for pretty much the same reasons Mark mentioned above. Best, Ekin H. Bayar https://ekins.space https://heap.space

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

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.