Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108628
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <52c24f76-570a-8541-1d62-555f2a0582f5@gmail.com>
Date: Sun, 16 Feb 2020 19:45:26 -0500
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <F8A96229-5D9C-4DF2-9A76-F65517177FA0@newclarity.net>
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <5DEE5A6E-2587-432D-9651-320DF42A7732@newclarity.net>
 <A988787C-9EB6-4BF2-90DF-68F0D3BAC494@pmjones.io>
 <DC294D91-AA70-45C4-A3A5-32454675F42A@newclarity.net>
 <D3BABA50-AE6A-4711-A595-878CA8A8175F@pmjones.io>
 <C0EED521-5C75-40F0-9723-2B6D5FFA799E@newclarity.net>
 <52c24f76-570a-8541-1d62-555f2a0582f5@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: mike@newclarity.net (Mike Schinkel)



> On Feb 16, 2020, at 6:34 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 13/02/2020 20:31, Mike Schinkel wrote:
>> If I had a vote I would vote I would enthusiastically vote for the =
RFC if it includes filter_input() functionality. But I would vote =
against this RFC if it omits filter_input() functionality because it =
would mean another subsystem in core that does not actually address =
day-to-day concerns.
>=20
> I think you are over-estimating how central the filter API is to most =
people's workflow with requests. I think that's partly because designing =
a good validation API is hard, but also because filter_input in =
particular is a combination of three different concerns:

I think your latter points are orthogonal to this.  And that you are =
taking my advocacy for adding filtering to apply too literally to only =
the specific implementations in filter_input().

I can see addressing your comments below *and* having a filtering method =
built into these objects.  Possibly even with applicable method names as =
opposed to a 2nd type parameter, like:

$request->getInt('db_id');
$request->getJson('package');
$request->getUrl('return_url');


> 1) Fetching the raw information about the incoming HTTP request from =
the web server (the "SAPI")
> 2) Parsing that raw information into individual fields
> 3) Validating those fields against expected type constraints
>=20
> The superglobals already combine concerns 1 and 2, and the filter API =
adds concern 3; but to do so they all assume that the user is basically =
writing a CGI wrapper for some HTML forms.
>=20
> The modern reality is rather different, and step 2 in particular is =
much more variable:
>=20
> - Rather than query string parameters, it might involve extracting =
parameters from an SEO URL like "/products/123-acme-thingummy" or a =
RESTish URL like "/products/123/description/en-GB"
> - Rather than submitted form data, it might involve parsing JSON from =
an AJAX request or API call
>=20
>=20
> I would love to see new APIs that take a step back from the legacy, =
and tackle each of these concerns separately, based on modern =
requirements.
>=20
> For concern 1, getting data out of the web server, I'd love to see:
>=20
> - A more intuitive way to get the raw request body than =
file_get_contents('php://input')
> - A more reliable way to get the URL the user requested than checking =
5 different variables in $_SERVER to handle different deployment methods =
(see e.g. [1] and [2] for the lengths libraries go to for this)
> - A proper distinction between HTTP headers, server status variables, =
and environment variables, because CGI name-mangling is legacy cruft =
that users shouldn't need to learn
>=20
> For concern 2, parsing that data, I'd love to see:
>=20
> - A better API than parse_str for parsing arbitrary strings in =
application/x-www-form-urlencoded format
> - A way to parse data in multipart/form-data format decoupled from the =
current HTTP request
> - Tools for working with Content-Type strings, such as a function for =
correctly parsing things like "text/html;charset=3DUTF-8", and constants =
for common MIME types
>=20
> Concern 3, filtering / sanitising / validating, I think is a really =
hard problem space, and I don't think there will ever be one =
implementation that suits all cases.
>=20
> A similar "shopping list" could probably be made for responses, but if =
we decoupled the pieces, we wouldn't have to perfect them all at once; =
instead, we could provide building blocks that make userland =
implementations easier.

Decoupling is a valid approach.

But given how much work it is get to an RFC over the line, it feels like =
decoupling would end up with a lot more work, lengthen the timeline to =
achieve base level functionality, and add uncertainty to whether it will =
even happen whereas handling the 20% now that we need 80% of the time =
would mean the API would be mostly fully usable out of the gate.

-Mike=