Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107360
To: Rasmus Lerdorf <rasmus@lerdorf.com>,
 Benjamin Morel <benjamin.morel@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
References: <CAG9XoMQp5wzs6msh_q33z1JEcMs2cNwWH+HmW4C9vYf+xLYeiA@mail.gmail.com>
 <CACXBjuimGBre6NwFmZ8cajscK=a0QB2LqpHy6arm6nEHd45RGw@mail.gmail.com>
 <CAG9XoMSbx1cRnka7zZyvkPmLYTocAEPP4+G_quz-Cxa-EsO4xA@mail.gmail.com>
 <CACXBjuj823HdUJofYgjkWuC8peWZ5Fm4=QkPg1C33CfYhdyYBw@mail.gmail.com>
 <CAG9XoMSFdaFcfV4sOss=5Uyg5H3yrhhywBRjkk-8JDZTe_gXMQ@mail.gmail.com>
 <CACXBjug8qxtkkhY4eng+Heqw5y--uMe_SkK_6Uj1sRJL=JkdHg@mail.gmail.com>
Message-ID: <866ac36c-ddb5-80db-1ac2-56ff3f49cd81@cubiclesoft.com>
Date: Tue, 1 Oct 2019 14:39:29 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327
 Thunderbird/11.0.1
MIME-Version: 1.0
In-Reply-To: <CACXBjug8qxtkkhY4eng+Heqw5y--uMe_SkK_6Uj1sRJL=JkdHg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Error when POST / upload limits are exceeded
From: thruska@cubiclesoft.com (Thomas Hruska)

On 10/1/2019 1:26 PM, Rasmus Lerdorf wrote:
> On Tue, Oct 1, 2019 at 8:25 AM Benjamin Morel <benjamin.morel@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.
> 
> -Rasmus

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.

-- 
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/