Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109004
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
In-Reply-To: <C7DFAE61-258A-4525-8946-6FA057CE431F@newclarity.net>
Date: Sat, 14 Mar 2020 02:23:21 +0700
Cc: "Paul M. Jones" <pmjones@pmjones.io>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <71A325BA-3F53-4C9D-BE6A-D9A068A42AEA@koalephant.com>
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>
To: Mike Schinkel <mike@newclarity.net>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: php-lists@koalephant.com (Stephen Reay)



> On 14 Mar 2020, at 01:40, Mike Schinkel <mike@newclarity.net> wrote:
>=20
>=20
>> On Mar 13, 2020, at 10:55 AM, Paul M. Jones <pmjones@pmjones.io> =
wrote:
>>=20
>> One other alternative John & I contemplated was =
`Web{Request,Response,ResponseSender}` -- do you think that might be a =
reasonable alternative to HTTP, one that is "adjacent" but not =
overly-specific? That would net us:
>>=20
>> - WebRequest
>> - WebResponse
>> - WebResponseSender
>>=20
>> I didn't like the look of it previously, and I don't think I like the =
look of it now, but ... (/me shrugs).
>>=20
>>=20
>>> However, that also may be confusing if people expect it to be a =
construct for making outgoing requests.=20
>>=20
>> Yes, that's another tricky bit in the naming -- making a distinction =
between the objects as representative of client operations (send =
request, receive response) and server operations (receive request, send =
response). Thus the current `Server` prefix (however unsatisfactory it =
may be) to indicate their operational context.
>>=20
>> Your `Incoming` and `Outgoing` prefixes, minus the HTTP, would net =
us:
>>=20
>> - IncomingRequest
>> - OutgoingResponse
>> - OutgoingResponseSender
>>=20
>> I will need to ponder on those.
>>=20
>>> The user land implementation I=E2=80=99ve been using =E2=80=99solves=E2=
=80=99 this by using a `HTTP` namespace, and then provides `Request` and =
`Response` (for an outgoing - i.e. curl - HTTP Request, and the =
corresponding HTTP Response) objects and then `CurrentRequest` and =
`CurrentResponse` for what your RFC proposes (i.e. the active request =
made to php).=20
>>=20
>> Yes, userland does operate that way. However, I think adding an HTTP =
namespace to PHP itself is something to be avoided, so emulating =
userland here is not an option.
>>=20
>>=20
>>> As with anything any of us has written, I=E2=80=99m not 100% sold on =
=E2=80=98Current{Request,Response}` even after writing it, but I think =
it=E2=80=99s at least a little more specific about what they do, when =
the namespace is taken into account.
>>=20
>> `Current{...}` is not something we had previously considered; that =
would net us, in the global namespace:
>>=20
>> - CurrentRequest
>> - CurrentResponse
>> - CurrentResponseSender
>>=20
>> I will need to ponder on those as well.
>>=20
>> Any further thoughts or opinions on this, Stephen? Or from anyone =
else?
>=20
> One issue that I have is, if we are going to fine-tune the naming to =
make sure it matches  *exactly* then I think that CurrentRequest->server =
does not make sense.
>=20
> Maybe if you choose one of these names you should break out the =
server-specific items into their own class/object?
>=20
> -Mike
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

Hi Mike,

(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)

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*. 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=98dedicated=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]?

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.

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.

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

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

Stephen=