Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108512
MIME-Version: 1.0
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
In-Reply-To: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
Date: Wed, 12 Feb 2020 19:20:56 +0100
Message-ID: <CANUQDCiP31aEqULqeGpN66ESHarKxWuXgQt_CqWeCLZc+1L-fA@mail.gmail.com>
To: "Paul M. Jones" <pmjones@pmjones.io>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: me@kelunik.com (Niklas Keller)

> Hi Internals,
>
> After a couple of years of incubation, I am happy to offer a second versi=
on of this RFC:
>
>   https://wiki.php.net/rfc/request_response
>
> It proposes an object-oriented approach around request and response funct=
ionality already existing in PHP, in order to reduce the global-state probl=
ems that come with superglobals and the various response-related functions.
>
> The SQLite "about" page says, "Think of SQLite not as a replacement for O=
racle but as a replacement for fopen()." <https://www.sqlite.org/about.html=
>  Likewise, think of this RFC not as a replacement for HttpFoundation or P=
SR-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'] =3D> $request->method
and $_SERVER['REQUEST_METHOD'] =3D> $request->method, how can I get the
original  (actual) method?

Given 'echo $content; =3D> $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