Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118615
MIME-Version: 1.0
References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
In-Reply-To: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at>
Date: Tue, 13 Sep 2022 20:06:54 +0200
Message-ID: <CADK1yXK5zXShfwz_LxTz1W4ZKZB5DNroiv4sBmWm68Wp-yrL5g@mail.gmail.com>
To: Mel Dafert <mel@dafert.at>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000022e74705e892e1b7"
Subject: Re: [PHP-DEV] Error behaviour for max_input_vars
From: deleugyn@gmail.com (Deleu)

--00000000000022e74705e892e1b7
Content-Type: text/plain; charset="UTF-8"

On Tue, Sep 13, 2022, 7:58 PM Mel Dafert <mel@dafert.at> wrote:

> 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.


Creating more ini settings is not very exciting. I do really like option 2
though.

--00000000000022e74705e892e1b7--