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

> Hi Internals, > > After a couple of years of incubation, I am happy to offer a second version of this RFC: > > https://wiki.php.net/rfc/request_response > > It 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. > > The SQLite "about" page says, "Think of SQLite not as a replacement for Oracle > but as a replacement for fopen()." > <https://www.sqlite.org/about.html> Likewise, think of this > RFC not as a replacement for HttpFoundation or PSR-7, or as a model of HTTP messages, but as an > object-oriented alternative to superglobals, header(), setcookie(), setrawcookie(), and so on. > > Thanks in advance for your time and consideration while evaluating it. Hey Paul, I think the request / response API is entirely fine being solved in userland instead of in php-src. However, since you already made such a proposal, I want to give some feedback: Naming I think we shouldn't take over the naming of the super globals, e.g. $_GET really contains the query parameters and has nothing to do with GET or POST, so $request->getQueryParameter(...) would be a better name. Type Safety I think the API should be type safe. Currently $request->get['key'] can be null | string | string[] | ... Most parameters only appear a single time, so a method returning the first parameter value or null could be used instead. API Issues I don't see any reason to keep specials such as $_SERVER['HTTP_X_REQUESTED_WITH'] vs. $request->requestedWith, which is just another HTTP header. If there's $_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE'] => $request->method and $_SERVER['REQUEST_METHOD'] => $request->method, how can I get the original (actual) method? Given 'echo $content; => $response->setContent($content);', shouldn't this rather be something like addContent()? How does streaming responses work? There's ServerResponseSender, but I think this should be part of the Response API. The Request object should be mutable, e.g. you might want to change the client IP to be based on a x-forwarded-header instead of the TCP source address. Other Commentary > A: It supports async exactly as much as PHP itself does. Not really. PHP has built-in stream_select / non-blocking streams, so supports the tools required for async out of the box. Regards, Niklas