PHP file upload limit change doesn't take effect until reboot

Hi @akinoreh,

First, accept my apologies for the previous message, I had a typo in the html file when I reproduced the 413 error message. I investigated this further, and I found that I get the 413 error code and the message on browser when the upload.html has a typo. For example, when the form definition points to a non-existent file. In my case, I originally created a uploads.php file instead of upload.php as mentioned in the HTML.

<form action="upload.php" method="post" enctype="multipart/form-data">

Can you check that if you make this typo on purpose, you get the 413 error code as well?

Apart from that, I reproduced your issue on Apache returning 200 ok even if the file is larger than expected. However, I’m getting an error in the Apache log for this.

==> apache2/logs/error_log <==
[Tue Jun 08 09:08:14.824315 2021] [proxy_fcgi:error] [pid 2773:tid 140241646069504] [client MY_IP_ADDRESS:52007] AH01071: Got error 'PHP message: PHP Warning:  POST Content-Length of 5243179 bytes exceeds the limit of 2097152 bytes in Unknown on line 0PHP message: PHP Notice:  Undefined index: fileToUpload in /opt/bitnami/apache/htdocs/upload.php on line 3PHP message: PHP Notice:  Trying to access array offset on value of type null in /opt/bitnami/apache/htdocs/upload.php on line 3PHP message: PHP Notice:  Undefined index: fileToUpload in /opt/bitnami/apache/htdocs/upload.php on line 26PHP message: PHP Notice:  Trying to access array offset on value of type null in /opt/bitnami/apache/htdocs/upload.php on line 26', referer:

==> apache2/logs/access_log <==
MY_IP_ADDRESS - - [08/Jun/2021:09:08:14 +0000] "POST /upload.php HTTP/1.1" 200 94

After that, I disabled PHP-FPM following the next guide plus adding an additional code snippet at the end of the httpd.conf file

The snippet is

# PHP 7 module specific configuration
<IfModule php7_module>
    AddType application/x-httpd-php .php
    AddType application/x-httpd-php-source .phps
    <IfModule dir_module>
        DirectoryIndex index.html index.php

Then, restart Apache. It now returns 413 error when the file is larger than the configured value, and 200 ok when it is smaller. Can you check if you reproduce the same behavior?

I suspect the 200 ok when using PHP-FPM is due to the Apache and PHP-FPM connection being properly done. Unfortunately, I don’t know how to raise an error in the case of using PHP-FPM and uploading a bigger file. I guess you can check it from the PHP code and return a 413 error in that case.

Right. If I change the action attribute and set it to a non-existent file, it works as you described. I get a 413 error.

And yes, I get the same logs in those log files.

I disabled the php-fpm, and also added the snippet at the end of httpd.conf. Now I get the 413 error when the uploaded file exceeds the limit.

There is still one problem, though. The connection doesn’t break when I upload a large file. It waits for the upload to complete, and then return 413 error. Shouldn’t the connection immediately break once the uploaded data (request body) reaches the limit set by LimitRequestBody?

LimitRequestBody Directive page doesn’t say anything about the connection, just states that it returns an error. We got that covered now. But what about the connection? Returning an error was just one part of the actual problem. What do I do if someone tries to upload gigabytes of data? Will the server wait for the whole upload to complete just to return an error afterwards? This would be silly.

I’m using XAMPP 8.0.6 on Windows 10 x64, and the way it works is when I upload a large file (e.g. 100+ MB) without the LimitRequestBody directive, the server waits for the upload to complete and then gives a warning in the page:

Warning: POST Content-Length of 118511697 bytes exceeds the limit of 2097152 bytes in Unknown on line 0

If I set the LimitRequestBody directive, the connection immediately breaks and I get a 413 error. So I’d assume it would work the same way on bitnami stack/live server.

Is my assumption wrong? If so, what’s the solution? How would one prevent (break the connection) uploading unexpected large files and return an error?

About php-fpm, how would I solve this while using php-fpm? Handing the error in PHP is a no-no. AFAIK, if the request reaches PHP, that means the upload was complete (doesn’t matter if it was valid or not). Returning an error in PHP defeats the whole purpose of preventing large file uploads. So I think it should be done in Apache.

If I were to look for solutions making it work while using php-fpm, where should I do it? Does bitnami community cover it?

I noticed that the page/form that I’m using to write this reply allows me to upload a file. What if I now upload an unexpectedly large file? Let’s test it.

I tried to upload 109 MB file. It’s using AJAX to upload a file at After 30 seconds, it returned 413 Request Entity Too Large and show a popup in tha page saying:

Sorry, that file is too big (maximum size is 5120kb). Why not upload your large file to a cloud sharing service, then paste the link?

It uploaded about 74 MB / %67 (I monitor my network usage), and then broke the connection. Although, in the UI, it said Uploading 61% before the error.

Isn’t the current way of this upload is wasteful? It’s wasting my and the server’s bandwidth, and the server’s resources. It should break the connection as soon as the uploaded data reaches 5120kb.

Also, I don’t understand how the server breaks the connection while the upload is 60+ % completed. I would expect it to break either very early (because the limit is 5 MB), or very late (after the upload is complete).

This makes me think if there are things that I’m not aware of, yet, about uploading.

Previously, I came across only two questions on StackOverflow about this issue, and both seem to not have a valid answer. Also I’d expect this to be a more common issue/practice. Seeing that it isn’t so, am I trying to do an impossible thing here? Is this prevention really not that necessary? But then that means I can abuse the server, do uploads that fail over again and again. Why should the server be ok with that?

How to stop a oversize file upload while upload is in process?
Close Apache connection with too large file uploads

Hi @akinoreh,

Thanks for the detailed information. Our engineering team will take a look for the Apache configuration when not using PHP-FPM to try to stop the upload process immediately. They will post any update in this thread.

About PHP-FPM, I think you would need to ask in a more specialized forum, where other users with more knowledge can help you.

Best regards,

That’s great to hear. If we can manage to get it working without PHP-FPM, then I can start looking for solutions that will also work with PHP-FPM.

I think that it’s better if I have something that fully works, something that can be used as a base, an example, before I start looking for PHP-FPM solutions. So I’ll do that once we’re done with the problem at hand.

Thank you, so far. I look forward to hear more.

Hi @akinoreh, this is expected because Apache is unable to limit request sizes (even with LimitRequestBody) when serving as a proxy, in this case to PHP-FPM.

To do that, you would need to use mod_security. Read more about the required configuration for your use case here:

(Note: beware of open discussions about mod_security versions in new Bitnami VMs)

Hi @marcos, I gave your suggestion a try, but failed. These were the steps I took:

  1. Created a new instance (at
  2. Loaded modules in httpd.conf.
    • Uncommented LoadModule unique_id_module modules/ at line 118
    • Uncommented LoadModule security3_module modules/ at line 160
  3. Enabled modsecurity in httpd.conf.
    • IFAIK, there are no virtual hosts in the stack. So, added the two lines at the bottom of <Directory "/opt/bitnami/apache/htdocs">.
<Directory "/opt/bitnami/apache/htdocs">
    modsecurity on
    modsecurity_rules_file "conf/modsecurity.conf"
  1. Then restarted the apache: sudo /opt/bitnami/ restart apache

Next, I checked the status, but it seems the apache isn’t working.

apache not running
mysql already running
php-fpm already running

So I restarted all services (sudo /opt/bitnami/ restart) and got an error?

Job for bitnami.service failed because the control process exited with error code.
See "systemctl status bitnami.service" and "journalctl -xe" for details.

What am I doing wrong?

I’m doing all these tests (now and before) on newly created instances. So I’d appreciate if you managed to get it working yourself/the team, and then give me directions about the solution, and then, prefably, update the documentation. As I’m doing these tests on “fresh” instances, I see no reason for me to do these “experiments” myself to get things working, because the issues are about the LAMP stack, not my application. The directions in the documention(s) don’t seem to apply to the stack/instances. They are either incomplete/wrong, or not detailed enough.

I believe you can understand/excuse my frustration as I’ve been dealing with this issue for more than two weeks now. I’m creating a RESTful API server, and the server should be able to handle this issues (prevent large file uploads (break the connection), return custom (e.g. JSON) error messages, etc.). I can’t depend on the client to follow rules or make checks. This needs to be solved at the server side.

During our communication (with gongomgra), we managed to get the 413 Request Entity Too Large error if the uploaded file is larger than the limit, but this works without the PHP-FPM, and the connection doesn’t break. The server still waits for the upload to complete.

So, the ideal result/situation requires two criteria. If a user uploads a file that’s larger than the limit (either set in php.ini or httpd.conf)

  1. the server should break the connection immediately (there’s no reason to wait for upload to complete if the file is too large and won’t be processed because of that)
  2. the server should return 413 Request Entity Too Large error (this will be changed and set to a custom error page later)

The LAMP stack, as it is, doesn’t satisfy these criteria. If I turn of PHP-FPM, the second criterion (413 Request Entity Too Large error) seems to work, but that’s not enough.

We noticed an issue in the documented modsecurity configuration to be enabled, it should be:

    modsecurity on
    modsecurity_rules_file "/opt/bitnami/apache/conf/modsecurity.conf"

That said, I have currently tested this configuration with mod_security3 and it does not see to be fully supported yet. As per the discussion in this other thread, we are going to include mod_security2 in VMs as well, and we will document it appropriately.

Therefore, I recommend you to base your application on mod_php right now if this is critical for you, and disable PHP-FPM.

Unfortunately I cannot give an ETA for when mod_security2 would be included in new Bitnami VMs.

Please note that the issue you are experiencing is not related to a misconfiguration of the Bitnami LAMP stack, but a “feature” of the Apache server. You would find such issue in any Apache server with a PHP-FPM proxy.

I believe my instructions in the previous post are very clear: It is not currently possible to limit such behavior with Apache and PHP-FPM, so you need to rely on mod_security to achieve that. And the current mod_security3 module is not yet production-ready (pending on our side to add mod_security2 again).

If you use mod_php (instead of a PHP-FPM proxy) it does indeed work because requests are not made through a proxy. So my recommendation is for you to use mod_php for now.