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

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

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

Hi,

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

--

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

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