Re: Error behaviour for max_input_vars

From: Date: Wed, 14 Sep 2022 12:05:32 +0000
Subject: Re: Error behaviour for max_input_vars
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-118622@lists.php.net to get a copy of this message
Hello, Le mardi 13 septembre 2022, 19:58:42 CEST Mel Dafert a écrit : > 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 > first 1000, and issue a E_WARNING. I also ran into this a few years ago and it is really annoying. I agree we need a reliable way of catching this error. > 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. All 3 solutions seems a nice improvement from current situation. Côme

Attachment: [application/pgp-signature] This is a digitally signed message part. signature.asc
« previous php.internals (#118622) next »