Re: [PHP-DEV] Error behaviour for max_input_vars

2022-09-13 Thread juan carlos morales
El mar., 13 de septiembre de 2022 20:01, Derick Rethans escribió: > On 13 September 2022 19:36:15 BST, juan carlos morales < > dev.juan.mora...@gmail.com> wrote: > >El mar., 13 de septiembre de 2022 15:33, juan carlos morales < > >dev.juan.mora...@gmail.com> escribió: > > > >> > >> > >> El mar.,

Re: [PHP-DEV] Error behaviour for max_input_vars

2022-09-13 Thread Derick Rethans
On 13 September 2022 19:36:15 BST, juan carlos morales wrote: >El mar., 13 de septiembre de 2022 15:33, juan carlos morales < >dev.juan.mora...@gmail.com> escribió: > >> >> >> El mar., 13 de septiembre de 2022 14:58, Mel Dafert >> escribió: >> >>> >>> In summary, I believe this can only be solve

Re: [PHP-DEV] Error behaviour for max_input_vars

2022-09-13 Thread Mel Dafert
On 13.09.22 20:29, Jordan LeDoux wrote: On Tue, Sep 13, 2022 at 10:59 AM Mel Dafert wrote: (This happens in the legacy application I am working on, I do not see it changing anytime soon.) All of these solutions would be available in some future version of PHP. While your

Re: [PHP-DEV] Error behaviour for max_input_vars

2022-09-13 Thread juan carlos morales
El mar., 13 de septiembre de 2022 15:33, juan carlos morales < dev.juan.mora...@gmail.com> escribió: > > > El mar., 13 de septiembre de 2022 14:58, Mel Dafert > escribió: > >> >> In summary, I believe this can only be solved inside of PHP itself, by >> allowing to configure a way for `max_input_v

Re: [PHP-DEV] Error behaviour for max_input_vars

2022-09-13 Thread juan carlos morales
El mar., 13 de septiembre de 2022 14:58, Mel Dafert escribió: > > 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 setti

Re: [PHP-DEV] Error behaviour for max_input_vars

2022-09-13 Thread Jordan LeDoux
On Tue, Sep 13, 2022 at 10:59 AM Mel Dafert wrote: > > (This happens in the legacy application I am working on, I do not > see it changing anytime soon.) > > All of these solutions would be available in some future version of PHP. While your situation highlights something that might be broad

Re: [PHP-DEV] Error behaviour for max_input_vars

2022-09-13 Thread Deleu
On Tue, Sep 13, 2022, 7:58 PM Mel Dafert 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

[PHP-DEV] Error behaviour for max_input_vars

2022-09-13 Thread Mel Dafert
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. The form I was using had an extremely big multiselect, where in one case around 1000 options were actively se

Re: [PHP-DEV] RFC [Discussion]: Improve unserialize() error handling

2022-09-13 Thread Tim Düsterhus
Hi On 9/12/22 21:46, Nicolas Grekas wrote:>> unserialize() is a generic function that will also call arbitrary callbacks. You already have no guarantees whatsoever about the kind of exception that is thrown from it. I am unable to think of a situation where the input data is well-defined enough