Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118617 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 31646 invoked from network); 13 Sep 2022 18:33:13 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Sep 2022 18:33:13 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7E1AB180210 for ; Tue, 13 Sep 2022 11:33:12 -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=-0.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 13 Sep 2022 11:33:11 -0700 (PDT) Received: by mail-ua1-f53.google.com with SMTP id e3so4670524uax.4 for ; Tue, 13 Sep 2022 11:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=UDoXe3PRql5nzBwpsOK+HEEkkgkjeiu8/a9n8ZX/03k=; b=OUlfO3FIcEhpFvvusu/+AXs82PpK2iaJM17oMO3UonQ3Fav2KTFKGeKLeMjy7hX4Qh 2v+aKWulObv6dzW7Z2QHbDoOYBwSIM26nv1m61a+1P/tErlMhX7GqmEqYJjXU09ORNxM t4S+/EfBMpEQgswOaK9jGClWnkiiT8k+QcpOJ7OnSd8rehudQObMQQmxVApiGu31Jjd3 6EYqEYhhpCFgncrvKJgh4QDu/I1RmMMg8iGWtV5slpLm/ZqP6B8HoUG4eYUmoJc1T3bY 59F5qTI4TC8p4wj/qutNBgzu1dh4sXKxCRqn/pScdKcZwTOOxghEXDYRFNdklmPScacS n2IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=UDoXe3PRql5nzBwpsOK+HEEkkgkjeiu8/a9n8ZX/03k=; b=t3HhF9jsixC3cC3khfNaOwkiMJw9g+ZO+A3layaL1/ikx2gQjitqXUN+PeK2TawSgc L56JmpAeM5uKh8GQx137hImX39Tab+fzu0yk1ebsSSEDbZvACbQHV3Fx2KYn41V8SZXp dwwh3Rsp9wkv3rmDh6kJqZMMx23YKIDVP0h5y0Zn/X2bR6u5v+Xef/YsBZH5+zYkmaGm 9vkxte+UIEpHPI/gG4rkMjBuvthzVc5FDqG060D93i8Ps5zpojJJmSSX463igqgmKKlR 8HZUm5dhripk1OqTXw+Z+PD+MGTvEVthcYh+RWKo2AYx70uP1fX0ZsI4wbaD35ovUG+P AZtg== X-Gm-Message-State: ACgBeo1LLpgm/u3D3pRXO8NSDX7Po9I6nHv9fXRUZ8dKjLMZ1SLPIYsO XCfSDxAWW88qKkVPZ/9mj394UdyaAfIdZBZFKvR7PdMo X-Google-Smtp-Source: AA6agR4sAHEYczqp/n2c5tSpkxNXk2jy06NrXpU0hKTx7odCnAcTugwpifktvzdbyBj/TFZLM+e41rPdaEg3lLPSZYQ= X-Received: by 2002:ab0:5711:0:b0:3b5:13e0:23b4 with SMTP id s17-20020ab05711000000b003b513e023b4mr8786067uaa.101.1663093991294; Tue, 13 Sep 2022 11:33:11 -0700 (PDT) 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 15:33:00 -0300 Message-ID: To: Mel Dafert Cc: PHP Internals List Content-Type: multipart/alternative; boundary="00000000000094497e05e8933e8e" Subject: Re: [PHP-DEV] Error behaviour for max_input_vars From: dev.juan.morales@gmail.com (juan carlos morales) --00000000000094497e05e8933e8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El mar., 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. > 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 outcom= e. > We should not delete the ini setting "max_input_vars"... Is a breaking change very hard. I Am in favour of adding More flexibility about how to handle this situation... And I also think that options 1 and 2 can coexist smoothly. I suggest you write and RFC for this and continue the discussion on this e-mail list but with the RFC already created. > --00000000000094497e05e8933e8e--