On Tue, Oct 1, 2019 at 5:39 PM Thomas Hruska <thru...@cubiclesoft.com> wrote:
> On 10/1/2019 1:26 PM, Rasmus Lerdorf wrote: > > On Tue, Oct 1, 2019 at 8:25 AM Benjamin Morel <benjamin.mo...@gmail.com> > > wrote: > > > >>> Perhaps a more generic $_SERVER['PHP_REQUEST_STATUS'] or something > along > >> those lines where you'd put the error message from > >> https://www.php.net/manual/en/features.file-upload.errors.php as well. > >> And add new states for these exceeded limits that aren't caught there. > It > >> would be nice if you just needed a single check instead of having to > look > >> for multiple things. > >> > >> Those are per-file error codes, that belong in each $_FILES entry, while > >> the errors I'm talking about affect the whole request, so I'm afraid you > >> cannot put these errors in the same place, nor can you extend the > existing > >> error codes, as they do not have the same scope! > >> > > > > I know they are per-file errors. I wrote that code :) > > > > But you could still have a global status that specifies whether an error > > occurred or not. Then you can go look for which file it occurred on in > the > > $_FILES array. The idea is to have a single check that tells you if > > everything was fine on the request. > > I agree this is needed. The problem I've encountered is that if there > are any more variables after a limit is hit, then some of the submitted > vars don't exist in the superglobals. Specifically, the variables > before the limit do exist while the ones after don't. There's a LOT of > userland code that *assumes* all expected non-file POST vars exist and > then DO things with the non-existent variables in this scenario. Is it > poorly written, lazy userland code? Sure, but it's certainly unexpected. > > In the past, I've seen all kinds of weird behaviors happen due to > missing vars in userland ranging from looping, WSODs, and altering PHP > sessions. The data gets submitted to the server but the PHP input > parser ignores it once a limit is reached. One of the first things I do > on a new system is to bump up the default limits considerably to avoid > hitting the limits. > > The ability to globally detect that processing of input variables was > early-terminated by the parser would allow userland startup sequences to > detect the problem globally and cleanly terminate the request BEFORE the > core application logic is encountered. This shouldn't just be for > files, it should be for any time the parser early-terminates input > processing but then proceeds to start executing userland code as if > nothing is wrong. > It's possible, in a limited fashion, to detect and react to some startup errors: $ cat index.php <?php var_dump(error_get_last()); $ php -n -d max_input_vars=1 -S 127.0.0.1:8000 index.php & $ curl 'http://127.0.0.1:8000/?a=1&b=2' array(4) { ["type"]=> int(2) ["message"]=> string(92) "Unknown: Input variables exceeded 1. To increase the limit change max_input_vars in php.ini." ["file"]=> string(7) "Unknown" ["line"]=> int(0) } Obviously this only gets the last one, and it doesn't handle situations like "the file pointed to by auto_prepend_file doesn't exist", but it seems a reasonable first step to assert error_get_last is null on script invocation. That said, I would prefer a function to a server/environment variable: error_get_startup() or something similar.
