Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118614
Message-ID: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
Date: Tue, 13 Sep 2022 19:58:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Content-Language: en-US
To: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Error behaviour for max_input_vars
From: mel@dafert.at (Mel Dafert)

Hi internals,

I recently ran into issues with the ini setting `max_input_vars`.
By default, it will truncate input variables in `$_POST` etc. to the=20
first 1000, and issue a E_WARNING.

The form I was using had an extremely big multiselect, where in one case=20
around 1000 options were actively selected,
each selected option being sent to the server as a separate=20
`my_select[]` POST variable.
The select was the final field in the form, thus is was not immediately=20
noticed when `max_input_vars` truncated options from the select.

I have since changed `max_input_vars` to a higher value, but there was=20
nevertheless an unknown amount of data loss in the meantime.

I would have strongly preferred if the request had been aborted with an=20
error, instead of issuing a warning and continuing with incomplete
data.
However, I could not find a way to reliably detect a way that input=20
variables had been truncated. There are some suggested solutions in [1],=20
but all of them have downsides:
- Counting variables inside `$_POST`:
 =C2=A0=C2=A0=C2=A0 If there are multiple variables with the same name (w=
ithout `[]` at=20
the end), they will be counted for `max_input_vars`, but only show up=20
once in `$_POST`.
 =C2=A0=C2=A0=C2=A0 (This happens in the legacy application I am working =
on, I do not=20
see it changing anytime soon.)
- Checking `php://input`:
 =C2=A0=C2=A0=C2=A0 This is not possible if the request uses `multipart/f=
orm-data`.
- Checking `error_get_last()` for the warning:
 =C2=A0=C2=A0=C2=A0 This seems extremely brittle - even if currently ther=
e is no other=20
warning thrown at startup, if that changes in the future, this might brea=
k.
- Custom error handler using `set_error_handler()`:
 =C2=A0=C2=A0=C2=A0 This is not possible, as the warning is thrown before=
 any PHP code=20
can run (and register the handler).

If I missed a reliable method, I would be thankful, and this email can=20
be ignored.

In summary, I believe this can only be solved inside of PHP itself, by=20
allowing to configure a way for `max_input_vars` to abort the request=20
instead of truncating the input.
The options I see feasible are:
- A new ini setting `max_input_vars_abort` (default to 0), which, if set=20
to 1, will abort the request if there are more input variables than allow=
ed.
- A method to reliably detect whether the input vars were truncated (eg.=20
`function has_post_been_truncated(): bool`), so the application can=20
decide whether to abort or not.
- Deciding that `max_input_vars` is not relevant anymore and should be=20
handled by the likes of Apache and NGINX, thus changing the default to=20
`0` and removing the setting
 =C2=A0=C2=A0=C2=A0 over a deprecation period.

I am leaning towards the first option, but would be open to either outcom=
e.

Regards,

Mel Dafert

[1]:=20
https://stackoverflow.com/questions/12169818/in-php-how-can-i-detect-that=
-input-vars-were-truncated-due-to-max-input-vars-be