Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118620 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 59675 invoked from network); 13 Sep 2022 23:01:27 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Sep 2022 23:01:27 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 08DC0180210 for ; Tue, 13 Sep 2022 16:01:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_NEUTRAL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS30827 82.113.144.0/20 X-Spam-Virus: No X-Envelope-From: Received: from xdebug.org (xdebug.org [82.113.146.227]) by php-smtp4.php.net (Postfix) with ESMTP for ; Tue, 13 Sep 2022 16:01:23 -0700 (PDT) Received: from [127.0.0.1] (unknown [148.252.129.215]) by xdebug.org (Postfix) with ESMTPSA id 5DD4110C035; Wed, 14 Sep 2022 00:01:22 +0100 (BST) Date: Wed, 14 Sep 2022 00:01:19 +0100 To: internals@lists.php.net, juan carlos morales , Mel Dafert CC: PHP Internals List User-Agent: K-9 Mail for Android In-Reply-To: References: <8479bc9a-6ed6-0cf1-c727-123e2b87a8d6@dafert.at> Message-ID: <9BAED6E7-E2ED-4CA1-977C-3A0C751B288F@php.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Error behaviour for max_input_vars From: derick@php.net (Derick Rethans) On 13 September 2022 19:36:15 BST, juan carlos morales wrote: >El mar=2E, 13 de septiembre de 2022 15:33, juan carlos morales < >dev=2Ejuan=2Emorales@gmail=2Ecom> escribi=C3=B3: > >> >> >> El mar=2E, 13 de septiembre de 2022 14:58, Mel Dafert >> escribi=C3=B3: >> >>> >>> 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=2E >>> The options I see feasible are: >>> - A new ini setting `max_input_vars_abort` (default to 0), which, if s= et >>> to 1, will abort the request if there are more input variables than >>> allowed=2E >>> - A method to reliably detect whether the input vars were truncated (e= g=2E >>> `function has_post_been_truncated(): bool`), so the application can >>> decide whether to abort or not=2E >>> - 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=2E >>> >>> I am leaning towards the first option, but would be open to either >>> outcome=2E >>> >> >> >> We should not delete the ini setting "max_input_vars"=2E=2E=2E Is a bre= aking >> change very hard=2E >> >> I Am in favour of adding More flexibility about how to handle this >> situation=2E=2E=2E And I also think that options 1 and 2 can coexist sm= oothly=2E >> >> I suggest you write and RFC for this and continue the discussion on thi= s >> e-mail list but with the RFC already created=2E >> > > >Check this out > >https://wiki=2Ephp=2Enet/rfc/howto That's quite a condescending thing to say, considering that Mel has alread= y successfully passed an RFC (https://wiki=2Ephp=2Enet/rfc/intldatetimepatt= erngenerator)=2E cheers Derick