Hi internals,
The filter_var functionality is one of the most efficient and well-known ways
in PHP to validate and sanitize inputs for many use cases
(e.g. FILTER_VALIDATE_INT for checking if a string is well-formed decimal input
(or other bases),
FILTER_VALIDATE_BOOL for user input/configs (cli/server api),
FILTER_VALIDATE_URL, FILTER_VALIDATE_EMAIL).
The filter_var functionality is something that you can disable with
--disable-filter, and I've often encountered code with
a few dependencies or source files that assume that filter_var is always
available when building php from source.
```
# Composer version 2.0.4 2020-10-30 22:39:11
sapi/cli/php ~/bin/composer.phar
Fatal error: Uncaught Error: Call to undefined function
JsonSchema\Uri\filter_var() in
phar:///path/to/bin/composer.phar/vendor/justinrainbow/json-schema/src/JsonSchema/Uri/UriResolver.php
# public function resolve($uri, $baseUri = null)
# {
# if (!is_null($baseUri) && !filter_var($baseUri, \FILTER_VALIDATE_URL) &&
....
```
For me, the main reason why a developer/admin/hosting provider may want to
disable the 'filter' module is
1. The filter_input() functionalities that allow direct access to the original
POST/GET/COOKIE/ENV data.
e.g. this makes code harder to test if the code or third party libraries it
uses harder to unit test because $_GET/$_POST/$_COOKIE/$_ENV can't be
replaced in filter_input.
2. The php build steps may have been carried over from PHP 5.2 when 'filter'
was brand new and much less code used filter.
3. Desire for slightly smaller installations
4. Unaware of it since phpxyz-core and phpxyz-filter are different modules in
an OS's package manager
The filters themselves(https://www.php.net/manual/en/filter.constants.php) seem
to be free of side effects
glancing at the descriptions and implementation.
The fact that filter_var isn't enabled by default may lead to
1. Application/library authors unconditionally using intval()/floatval() or
other functions in core that don't check for unexpected suffixes (e.g. '10MB')
Many languages have a function like atoi() that detects invalid integers
2. Applications skipping filtering steps if the function filter_var doesn't
exist, e.g. allowing any string to be used as a url/email
3. Dependencies failing to run due to throwing Errors on rare configurations
where filter_var is unavailable.
It seems like filter is useful enough to already be statically compiled into
the Windows builds published on windows.php.net
-----
What are your thoughts on the following:
Move the following functions into core and statically build them:
(and all global `FILTER_*` constants but not `INPUT_*` from
https://www.php.net/manual/en/filter.constants.php)
- filter_has_var — Checks if variable of specified type exists
- filter_id — Returns the filter ID belonging to a named filter
- filter_list — Returns a list of all supported filters
- filter_var_array — Gets multiple variables and optionally filters them
- filter_var — Filters a variable with a specified filter
Keep the following remaining functions in the 'filter' extension, continue
enabling them by default and allowing --disable-filter to disable them:
- filter_input_array — Gets external variables and optionally filters them
- filter_input — Gets a specific external variable by name and optionally
filters it
Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
