Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108511
Message-ID: <DC294D91-AA70-45C4-A3A5-32454675F42A@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0EDAB170-7F2F-46CA-93B2-DA8F28BD31E8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 12 Feb 2020 13:21:58 -0500
In-Reply-To: <A988787C-9EB6-4BF2-90DF-68F0D3BAC494@pmjones.io>
Cc: internals@lists.php.net
To: "Paul M. Jones" <pmjones@pmjones.io>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <5DEE5A6E-2587-432D-9651-320DF42A7732@newclarity.net>
 <A988787C-9EB6-4BF2-90DF-68F0D3BAC494@pmjones.io>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_0EDAB170-7F2F-46CA-93B2-DA8F28BD31E8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Feb 12, 2020, at 7:47 AM, Paul M. Jones <pmjones@pmjones.io> wrote:
>=20
> That is essentially what it does now; the difference is that you mimic =
the $GLOBALS array at construction time, and the instance locks =
automatically:
>=20
>    $request =3D new ServerRequest([
>        '_GET' =3D> ['foo' =3D> 'bar'],
>        '_COOKIE' =3D> ['id' =3D> 123],
>        '_SERVER' =3D> $_SERVER,
>    ]);
>    // $request is now locked
>=20
> The class that contains ServerRequest would then build up that array =
for the constructor.
>=20
> Do you feel that's close enough to what you're asking for?

No.  IMO it should not lock until explicitly locked. =20

Why?  Take a look at WordPress.  It does a lot of "fixup" to $_SERVER` =
variables =E2=80=94 to deal with badly implemented web servers =E2=80=94 =
to ensure all known variables have a value and that the format of the =
value is consistent. =20

If you always lock on instantiation then WordPress would have to default =
to continue using $_SERVER.  Or subclass it, but that would generate =
copying overhead and it would be too easy for programmers to just call =
ServerRequest() again.

Another option actually would be to allow changes to $_SERVER prior to =
instantiating ServerRequest() the first time.

Frankly though, none of those options should ideal, include your current =
proposed solution.  Basically making a copy of $_SERVER so =
ServerRequest() is not authoritative, but alternately your solution does =
not allow frameworks to fix the inconsistency across servers.

Maybe what would be needed is a single ServerRequest::initialize( =
$closure ) where the ciosure can do the fixup. This would need to be =
called before new ServerRequest() is called after which ServerRequest =
would be locked for changes.

> First, I'd have to decline adding request() (or $request) at all; my =
opinion is that one ought to be reading from $get, $post, $cookies, etc. =
specifically, not from a pool of those values.

That's definitely fair.  I almost did not include request() in my =
suggestion but did because PHP has $_REQUEST.

> Second, if I understand you correctly, I much prefer the property =
access over the method getter; it just "looks and feels better":
>=20
>    $request->get['foo']
>    vs
>    $request->get()['foo'];
>=20
> Let me know if that makes sense to you or not.

I was actually proposing a third option:

$request->get('foo');

Or as I like to do in my own code (to indicate where it comes from):

	$request->GET('foo');

Why a method is important is to support filters (I guess I assumed that =
was obvious but realize now it was not.) For example:

	$request->get('redirect', FILTER_SANITIZE_URL);
	$request->get('product_id', FILTER_SANITIZE_NUMBER_INT);
	$request->get('email', FILTER_SANITIZE_EMAIL);

You could potentially even have scoped, easier to remember constants =
that can work with autocomplete:

	$request->get('redirect', ServerRequest::URL);
	$request->get('product_id', ServerRequest::INT);
	$request->get('email', ServerRequest::EMAIL);


> incorporate the functionality of filter_input().  Otherwise we have to =
bypass the objects to get filtering.
>=20
> I don't think you'd have to bypass the objects to get filtering; =
unless I am missing something, this ...
>=20
>    $foo =3D filter_input(INPUT_GET, 'foo', =
FILTER_SANITIZE_SPECIAL_CHARS);
>=20
> ... would easily become this:
>=20
>    $foo =3D filter_var($request->get['foo'], =
FILTER_SANITIZE_SPECIAL_CHARS);
>=20
> There might be behavioral nuances between the two, but the point is =
that you can still do filtering.


But wouldn't it be 1000% easier to write and easier to read code like =
this?

$foo =3D $request->get( 'foo', ServerRequest::SPECIAL_CHARS);


Since filtering $_GET elements is 100% done when accessing them it makes =
sense to streamline the operation.  But if a developer does not want to =
filter, they just do this:

$foo =3D $request->get( 'foo' );


>> Would you not also add an option to generate a warning when using =
them for those who want to deprecate their use in their own code =
(deprecating across the board would be too extreme give how much CMS and =
framework code uses them intimately.)
>=20
> That seems a bit much at this point. ;-)

Really?  Seems like this and some guard code is all it would take:

ini_set( "disallow_superglobals", true);

-Mike=

--Apple-Mail=_0EDAB170-7F2F-46CA-93B2-DA8F28BD31E8--