> On Feb 16, 2020, at 6:34 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> 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:
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
>
> 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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
