Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109005
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <71A325BA-3F53-4C9D-BE6A-D9A068A42AEA@koalephant.com>
Date: Fri, 13 Mar 2020 15:59:39 -0400
Cc: "Paul M. Jones" <pmjones@pmjones.io>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8A04B273-B298-4A2F-B0A5-8DF1F1D129A9@newclarity.net>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <D2321EFF-6D87-422A-BCC3-875820ADF8E2@pmjones.io>
 <C2A122BA-052B-4AFB-900E-93858BF50F7E@koalephant.com>
 <0B40E6E5-342F-4D81-9CAA-A0C0739A7718@pmjones.io>
 <C3C15896-923D-4386-A991-329D0FCE7CC9@koalephant.com>
 <102D234E-BC5D-42B2-ABC4-93980C1F76A4@pmjones.io>
 <C7DFAE61-258A-4525-8946-6FA057CE431F@newclarity.net>
 <71A325BA-3F53-4C9D-BE6A-D9A068A42AEA@koalephant.com>
To: Stephen Reay <php-lists@koalephant.com>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: mike@newclarity.net (Mike Schinkel)

> On Mar 13, 2020, at 3:23 PM, Stephen Reay <php-lists@koalephant.com> =
wrote:
>=20
> Hi Mike,
>=20
> (I realise some of these points are possibly more addressed to Paul =
than yourself, this is just where my brain went when I dug into what you =
were mentioning)

(after responding to your reply I think I was commenting on the RFC and =
I think it is possible that you may have missed as few aspects of the =
RFC such as a 'server' property on the ServerRequest variable. If that =
is the case then we might be saying the same things. See =
https://github.com/pmjones/ext-request#superglobal-related)=20

Yes, I should have made it more explicit. As author of the RFC I was =
speaking to Paul in suggesting that if we are going to name the proposed =
objects to be more specific to requests and response that we move the =
server-specific aspects out and into their own object. =20

Otherwise I feel that dropping the "Server" from the name the object =
clarifies one aspect and obfuscates another, albeit clarifying the =
larger part.  Better to make it all clear with another object named for =
what it represents; server information.

> I apologise if I=E2=80=99ve missed part of the discussion but what do =
you mean by =E2=80=9Cmake sure it matches *exactly*.

I was referencing your comments where my takeaway from reading what you =
wrote is that you were asking that the naming match exactly what you =
were viewing the objects to be doing, and that is to work with HTTP:

     "This extension and the classes it provides are inherently about =
HTTP requests made to a php =E2=80=98server=E2=80=99, and the response =
it sends back - and yet it=E2=80=99s called =
Server{Request,Response,Buffer} etc=E2=80=A6. The =E2=80=9Cserver=E2=80=9D=
 part is superfluous in the context of a php web application, because =
it=E2=80=99s all =E2=80=9Cserver=E2=80=9D side, and while uncommon =
it=E2=80=99s not impossible to write *other* types of network server =
using PHP."

     "TLDR: if you aren=E2=80=99t concerned about the concept of =
php-initiated outgoing HTTP requests, I think =
`HTTP{Request,Response,Buffer}` is quite clear in terms of naming. If =
you wanted to be more explicit about their purpose (and/or prevent =
possible confusion with either user land or potential future extensions =
handling outgoing requests), `IncomingHTTPRequest` and =
`OutgoingHTTPResponse` are very explicit, if a bit verbose."

My point is simply that the server-specific aspects have nothing to do =
with HTTP requests or HTTP responses, and if Paul was to rename his =
classes to more closely align with HTTP requests and HTTP responses then =
he should extract the server aspects out into their own class.


> Do you mean how `->server` is listed as being a copy of the `$_SERVER` =
super global? If so, can someone point me to the specific logic behind =
that, given how many parts of it are already exposed via =E2=80=98dedicate=
d=E2=80=99 properties of the proposed class?  =46rom what I can see (and =
I may have missed some) the parts of $_SERVER not exposed in some way =
=E2=80=9Cdirectly=E2=80=9D on ServerRequest (nee CurrentRequest) are the =
actual =E2=80=9Cserver=E2=80=9D parts: the `SERVER_*` keys, doc root, =
PHP_SELF; and the =E2=80=98client=E2=80=99 parts: REMOTE_*; plus few =
random stragglers like PATH_INFO, and for some reason =
REQUEST_TIME[_FLOAT]?

I don't think direct exposure is required; indirect exposure via an =
array still means that aspects not related to HTTP requests and HTTP =
responses are currently contained in the ServerRequest->server which to =
me is okay if it is called "ServerRequest" but not okay if it is called =
"HttpRequest," "WebRequest," "IncomingRequest," or "CurrentRequest."

> Can those two things not be organised as a hash of those values, under =
`server` and `client` (or `remote` if you want to keep the terminology - =
yes I know it will be the originating TCP connection host not =
necessarily the browser host)? As I said, I=E2=80=99ve missed some of =
the discussion but I fail to see the benefit of a class to make all the =
details of a web request and it=E2=80=99s response available=E2=80=A6. =
And then just stick the existing superglobals in it untouched.

Your response is confusing me. =20

You may actually be saying the same thing I am saying.  I am referring =
to the current state of the RFC where this would be possible:

$request =3D new ServerRequest();
echo $request->server['HOME'];  // Output the server's home directory.

I am saying that it might be better to have those properties in a =
different object:

$info =3D new ServerInfo();
echo $info->home;  // Output the server's home directory.
print_r( $info->properties );   // Output everything found in $_SERVER =
object

> Things like the query params and body params make sense to be =
accessible essentially (albeit with better names) as-is, because =
they=E2=80=99re a hash of unknown shape by their very nature - but the =
keys in _SERVER (barring http headers, which are already special cased) =
are known, and have pretty clear definition of their meaning.

Agreed.

> Is the proposal really suggesting that a developer would still need to =
do `if(!empty($request->server[=E2=80=98HTTPS=E2=80=99]) && =
$request->server[=E2=80=98HTTPS=E2=80=99] !=3D=3D =E2=80=98off=E2=80=99) =
{=E2=80=A6}` rather than just providing a `secureTransport` property (or =
`https` if you prefer)?=20

Not sure. Paul needs to answer that.

> One last point, regarding the =E2=80=98break out a server specific =
class=E2=80=99 part. I don=E2=80=99t think it=E2=80=99s =E2=80=9Cwrong=E2=80=
=9D to access these properties from something that is ostensibly related =
to the =E2=80=9Ccurrent request=E2=80=9D, but it feels quite =E2=80=98wonk=
y=E2=80=99 to me, the way it=E2=80=99s proposed with the full ->server =
array just copied as-is, AND exposed via dedicated properties
> Cheers

Yes, I was saying that it is wrong *if* we are going to fine-tune the =
name to a as closely as possible mirror what is contained within it. As =
I said above having `server' in ServerRequest class does not both me but =
it would bother me if  `server' were in a HttpRequest class.

Does this clarify?

-Mike=