Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118623
Message-ID: <7e250e89-c18e-9e1a-222a-60521dd2babb@nunninger.info>
Date: Wed, 14 Sep 2022 16:44:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Content-Language: en-US
To: internals@lists.php.net
References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
In-Reply-To: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: thomas@nunninger.info (Thomas Nunninger)

Hi,

> In summary, I believe this can only be solved inside of PHP itself, by 
> allowing to configure a way for `max_input_vars` to abort the request 
> 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 
> to 1, will abort the request if there are more input variables than 
> allowed.
> - A method to reliably detect whether the input vars were truncated (eg. 
> `function has_post_been_truncated(): bool`), so the application can 
> decide whether to abort or not.
> - Deciding that `max_input_vars` is not relevant anymore and should be 
> handled by the likes of Apache and NGINX, thus changing the default to 
> `0` and removing the setting
>      over a deprecation period.
> 
> I am leaning towards the first option, but would be open to either outcome.

I'd prefer that PHP aborts such requests. Then data loss/inconsistency 
is prevented for everybody and people can fix their applications. (So no 
need for an ini setting that allows acting in "danger mode".)

If you'd like to give developers more options to choose from, I'd go for 
max_input_vars_abort (default 1) plus has_post_been_truncated(): That 
way the behavior is safe from the start. And people who opt in for 
"danger mode" can reliably detect if there was some data loss and can 
deal with it.

Regards
Thomas