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.
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:
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
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.
The modern reality is rather different, and step 2 in particular is much
more variable:
- 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
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.
For concern 1, getting data out of the web server, I'd love to see:
- 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
For concern 2, parsing that data, I'd love to see:
- 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=UTF-8", and constants
for common MIME types
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.
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.
[1]
https://github.com/symfony/symfony/blob/9acb06041cc88b5c14d40f8cd9a74dd14d7ac786/src/Symfony/Component/HttpFoundation/Request.php#L1741
[2]
https://github.com/laminas/laminas-diactoros/blob/b36d6bf376b03dfc3190b1065630090e57f2e20d/src/functions/marshal_uri_from_sapi.php
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
