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

Sigh. I’ve removed original-data folders from all instances, and ran the support tool again in the temp/test instance. Once it finished, it output this id:

4bee5ae6-039d-f99d-28d0-61358d700e39

but now I don’t see any original-data folder in the /opt/bitnami/bnsupport dir.

Thinking there might be something wrong with the tool, I’ve decided to update it. The previous version might have been 0.9.3. After update, I believe it’s 0.9.9. Ran the tool again. It warned me about some issues:

? Apache: Found possible issues
✓ Connectivity: No issues found
? Resources: Found possible issues
✓ Mysql: No issues found
✓ Php: No issues found

[Apache]
... AH01071: Got error 'PHP message: PHP Warning: POST Content-Length of 2440971 bytes exceeds the limit of 2097152 bytes in Unknown on line 0', referer: http://3.67.74.111/single.php

[Resources]
total used free shared buff/cache available Mem: 478 295 61 5 121 164 Swap: 634 293 341

I don’t suppose they’re related to the problem at hand. Then gave me an id:

af884d22-af8f-07b4-24cc-a1c0f53f5380

I still don’t see any original-data folder in the /opt/bitnami/bnsupport dir. So I’m not sure if you get any report.

Hi @akinoreh,

Thanks for your messages. The original-data folder was created at some point for the bnsupport tool to find changes in the config files. It is created when we build the image as a snapshot of the initial status, and not generated by the bnsupport tool. It is not possible to recover it, but we will try to fix your issue without using that information.

The bnsupport tool will get only the current information in your instance, without us knowing the original status of some config files. When I mentioned in my previous message that I didn’t see any change in php.ini it was because the information in the original-data/php.ini file and the php.ini in use on your instance when the bnsupport bundle was created was exactly the same.

I see the changes in the new code though, then I understand you were running the tool in a different machine or you did the changes after running the tool for the first time. Anyways, I see some weird data in the tool, as the ctlscript.sh is not detecting the services running, but there are some processes in the system related to Bitnami. Did you have any chance to run the commands I asked for in my previous message?

Keywords: LAMP/MAMP/WAMP - AWS - Technical issue - Other
bnsupport ID: 19f709d3-925c-05a3-9674-6da7e3403799
Description:
I’ve set LimitRequestBody 2097152 in httpd.conf along with the appropriate changes in the php.ini. When I upload a file larger than 2MB, I get a 200 OK response and can see the form page. Shouldn’t I be getting a 413 Request Entity Too Large error?

I’m not sure what the support id provides you or if it’s enough to inspect the problem, but I’ve setup a test page where one can upload a file and see the result. I can share the URL if it’ll help/speed up the process.

Hello @akinoreh,

I cannot see changes in your php.ini. Could you try to update these values?

post_max_size
upload_max_size 

I hope it helps

Really? I just checked the /opt/bitnami/php/etc/php.ini, and I have the following in the specified lines:

695 post_max_size = 2M
848 upload_max_filesize = 2M

and also in /opt/bitnami/apache/conf/httpd.conf:

535 LimitRequestBody 2097152

This is the test page: http://3.67.74.111/single.php. If I upload a file less than 2 MB, I can see page/files. If I upload a file greater than 2 MB, I can’t see the file (in $_FILES) as expected, but I can see the page. The server returns 200 OK. I’d expect the server to return 413 Request Entity Too Large.

It seems there might be some issues. I didn’t really inspect how the support tool works. Just ran it, got the id, and posted it. Now I realize that it takes a snapshot of some configuration files.

So if you can’t see the modified php.ini file, that might be because the files/report you’ve received are not up to date. Although I dediced to post a question here after I made sure that there’s a problem with the file upload. So the report should’ve been up to date anyway.

Regardless, the current configuration is exactly as I mentioned in my previous reply. Three changes in two files.

Either LimitRequestBody doesn’t work as expected, or I have wrong assumptions about the ways LimitRequestBody directive works.

I can run the support tool again if it’ll help.

@gongomgra Okay, recap. I might have ran the tool (the first time) in the wrong instance because of PuTTY misconfiguration. So the initial report you got is irrelevant to this situation. I believe this covers the missing changes in the php.ini and the service not running statuses.

I did not run the commands you’ve mentioned because when I checked, the instance in question did not produce service not running output. However, another instance did. I restarted the services on the other instance, and it’s fixed.

Now, I’m checking the instance in question again, and when I checked the status, it says the services are not running, but the server is running. I mean, I can visit the /single.php page and interact with it just fine.

Since my two questions/topics are merged, let’s list the problems again. I had two problems, but it seems there’s another one.

  1. sudo /opt/bitnami/ctlscript.sh status command says the services are not running, but the server is functioning fine. What’s with that?

  2. The changes I make to php.ini or httpd.conf do not take effect until I manually reboot the instance from the Lightsail panel. sudo /opt/bitnami/ctlscript.sh restart doesn’t seem to work.

  3. I want to prevent large file upload, and set a custom error document for 413 Request Entity Too Large error. In order to do that, I set/change the limits in the php and apache configuration files. Then check the result in the /single.php page. It doesn’t work. File upload fails, but I get a 200 OK response, not 413 Request Entity Too Large error. (I’ll be setting a custom error document after I make sure the 413 error works fine.)

Now, how do we solve these?

If it helps, I can create a new instance if this one seems not so clean anymore.

Again, the page I’m doing the upload checks is http://3.67.74.111/single.php, and the current configuration is exactly as I stated in a previous reply. I’ll refrain from making further changes by myself. So, what do I now?

Hi @akinoreh,

Thanks for the detailed information. Yes, we merged both tickets because they seems to be related to the same instance and to be similar issues (new php config not being properly detected by the services).

Taking a look at the list of issues, I think we should handle the ctlscript.sh issue first. Can you run the commands into this server? I think it is better using the current instance.

Allright. Ran them one by one, and noted the outputs.

user@ip:~$ sudo /opt/bitnami/ctlscript.sh status
apache not running
mysql not running
php-fpm not running

user@ip:~$ sudo /opt/bitnami/ctlscript.sh restart
Restarting services..
user@ip:~$ sudo /opt/bitnami/ctlscript.sh status
apache already running
mysql already running
php-fpm already running

user@ip:~$ sudo gonit status

Uptime                         91h0m46s
Last Check                     2021-06-02 09:54:15.681415366 +0000 UTC m=+327600.449126632
Next Check                     2021-06-02 09:56:15.681415366 +0000 UTC m=+327720.449126632
Pid                            1074
Pid File                       /var/run/gonit.pid
Control File                   /etc/gonit/gonitrc
Socket File                    /var/run/gonit.sock
Log File                       /var/log/gonit.log
Process 'apache'
  status                                        Running
  pid                                              5425
  uptime                                          3m34s
  monitoring status                           monitored

Process 'mysql'
  status                                        Running
  pid                                              5763
  uptime                                          3m34s
  monitoring status                           monitored

Process 'php-fpm'
  status                                        Running
  pid                                              5399
  uptime                                          3m34s
  monitoring status                           monitored

user@ip:~$ sudo systemctl status bitnami.service
● bitnami.service - LSB: bitnami init script
   Loaded: loaded (/etc/init.d/bitnami; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-06-02 09:51:29 UTC; 4min 20s ago
  Process: 5296 ExecStart=/etc/init.d/bitnami start (code=exited, status=0/SUCCESS)
    Tasks: 380 (limit: 558)
   Memory: 394.5M
   CGroup: /system.slice/bitnami.service
           ├─1074 /opt/bitnami/gonit/bin/gonit
           ├─5399 php-fpm: master process (/opt/bitnami/php/etc/php-fpm.conf)
           ├─5403 php-fpm: pool www
           ├─5404 php-fpm: pool www
           ├─5405 php-fpm: pool www
           ├─5406 php-fpm: pool www
           ├─5407 php-fpm: pool www
           ├─5408 php-fpm: pool www
           ├─5409 php-fpm: pool www
           ├─5410 php-fpm: pool www
           ├─5411 php-fpm: pool www
           ├─5412 php-fpm: pool www
           ├─5425 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           ├─5427 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           ├─5428 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           └─5763 /opt/bitnami/mysql/bin/mysqld --defaults-file=/opt/bitnami/mysql/conf/my.cnf --basedir=/opt/bitnami

Jun 02 09:51:21 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:21.032Z - info: Performing service start operation for
Jun 02 09:51:26 ip-__-__-__-__ bitnami[5296]: mysql 09:51:26.29 INFO  ==> mysql started
Jun 02 09:51:27 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:27.135Z - info: Starting gonit monitoring service
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:29.258Z - info: Start monitoring all services from gon
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/p
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/p
lines 1-30...skipping...
● bitnami.service - LSB: bitnami init script
   Loaded: loaded (/etc/init.d/bitnami; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-06-02 09:51:29 UTC; 4min 20s ago
  Process: 5296 ExecStart=/etc/init.d/bitnami start (code=exited, status=0/SUCCESS)
    Tasks: 380 (limit: 558)
   Memory: 394.5M
   CGroup: /system.slice/bitnami.service
           ├─1074 /opt/bitnami/gonit/bin/gonit
           ├─5399 php-fpm: master process (/opt/bitnami/php/etc/php-fpm.conf)
           ├─5403 php-fpm: pool www
           ├─5404 php-fpm: pool www
           ├─5405 php-fpm: pool www
           ├─5406 php-fpm: pool www
           ├─5407 php-fpm: pool www
           ├─5408 php-fpm: pool www
           ├─5409 php-fpm: pool www
           ├─5410 php-fpm: pool www
           ├─5411 php-fpm: pool www
           ├─5412 php-fpm: pool www
           ├─5425 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           ├─5427 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           ├─5428 /opt/bitnami/apache/bin/httpd -f /opt/bitnami/apache/conf/httpd.conf
           └─5763 /opt/bitnami/mysql/bin/mysqld --defaults-file=/opt/bitnami/mysql/conf/my.cnf --basedir=/opt/bitnami/mysql --datadir=/b

Jun 02 09:51:21 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:21.032Z - info: Performing service start operation for mysql
Jun 02 09:51:26 ip-__-__-__-__ bitnami[5296]: mysql 09:51:26.29 INFO  ==> mysql started
Jun 02 09:51:27 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:27.135Z - info: Starting gonit monitoring service
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: 2021-06-02T09:51:29.258Z - info: Start monitoring all services from gonit
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/010_bitna
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/020_bitna
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/030_updat
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/040_bitna
Jun 02 09:51:29 ip-__-__-__-__ bitnami[5296]: ## 2021-06-02 09:51:29+00:00 ## INFO ## Running /opt/bitnami/var/init/post-start/050_clean
Jun 02 09:51:29 ip-__-__-__-__ systemd[1]: Started LSB: bitnami init script.
lines 2-3/34 (END)

Hi @akinoreh,

Thanks for the info. Yes, it seems gonit is properly monitoring the services. Can you do a new test for the PHP configuration? According to the latest bnsupport bundle you shared, you have set post_max_size = 2M in php.ini. Can you check it using the phpinfo.php file below? Please visit the http://YOUR_IP_ADDRESS/phpinfo.php URL when you have created the file

<?php
phpinfo();
?>

In my case:

  • original value

  • Then I set it to 2M and restart services. You can see the Apache processes were started at a different time after the restart command

  • New value

Can you try this on your side changing only the post_max_size PHP value? As your current value is 2M, check that you get first 2M and then the new value (let’s say 8M) after editing the file and restarting the service.

Can you also run the next command before and after editing the file to double-check the value is updated?

grep post_max_size /opt/bitnami/php/etc/php.ini

Sure. I’ve set the /phpinfo.php page and it’s public.

The current value of post_max_size is 2M. Changed it to 8M. And then restarted the services. I see the updated 8M in both phpinfo and grep output. Now this leads me to question myself :slight_smile:

I’ve created another instance. Modified php settings. Restarted only php-fpm. It seems to work. So can I assume for changes only in php settings, restarting the php is enough?

Earlier, I may have overgeneralized a specific problem. The changes to httpd.conf does not seem to take effect. I set the LimitRequestBody 2097152 on the second test instance. Restarted apache. Doesn’t work. Restarted all services. Doesn’t work. What I mean by “doesn’t work” is that the connection is not terminated when the file size is larger than the limit. The server waits for the whole upload. This is wasteful.

Then I rebooted the instance from the Lightsail panel. It didn’t work. Now, this is new. It still waits for the whole upload. Next, I restart the services after I rebooted the instance. Still doesn’t work.


Argh. I’m deleting both instances. Created a new one at 3.67.159.167.

I changed the php.ini and set the sizes to 2M. Restarted the php service. The change took effect immediately. When I upload a file that exceeds the limits, the $_FILES array is empty. The problem with this setup is that the server still waits for the whole upload.

So now I set the LimitRequestBody 2097152 in httpd.conf at the end of the file. This time I’m skipping restarting only the apache, and restart all services. Doesn’t work. It still waits for the whole file/upload. Next I reboot the instance. Still doesn’t work. OMG.

Okay, this is no longer about php configuration, so the topic title won’t make sense. LimitRequestBody simply doesn’t work. Apache

  • doesn’t terminate the connection when a file larger than the limit is uploaded
  • returns 200 OK along with the original page instead of 413 Request Entity Too Large and the appropriate error document

How do I make it work? I can’t be doing something wrong, because each time I’m using a brand new instance, right? So what’s wrong?

Hi @akinoreh,

Thanks for your message. I think we have fixed 2 out of 3 problems now, right? About the LimitRequestBody directive, it is an Apache directive. I can’t find it in the Apache configuration, but you mention you are adding it at the end of the httpd.conf file. Can you add it upper in the file? Try setting it under the comment below. I think that because you are defining it as a default global value, you may add it before any DocumentRoot or VirtualHost definition.

#
# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something's not working as
# you might expect, make sure that you have specifically enabled it
# below.
#

Please try to add it below the comment above and then restart the services.

Regards,
Gonzalo

Added the directive at the place you suggested:

<Directory />
    AllowOverride none
    Require all denied
</Directory>

#
# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something's not working as
# you might expect, make sure that you have specifically enabled it
# below.
#

LimitRequestBody 2097152

#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/opt/bitnami/apache/htdocs"
<Directory "/opt/bitnami/apache/htdocs">

Restarted only apache, and it didn’t work. Restarted all services. Didn’t work. Rebooted the instance, and still, didn’t work.

Apache still waits for the whole file/upload to finish, and then return 200 OK.

On my local machine (using XAMPP), however, I get 413 Request Entity Too Large and the following when using the same setup (configurations and single.php):

Request Entity Too Large
The requested resource does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit.
Apache/2.4.47 (Win64) OpenSSL/1.1.1k PHP/8.0.6 Server at localhost Port 80

I don’t mean any disrespect, but are we going to continue this single check/test daily? There’s no reason for me to do these tests (about LimitRequestBody). I’m using a fresh instance/LAMP to eliminate any user errors. While I may have done some mistakes with the php configuration (wrong instance report, etc.) I don’t think it’s the case with this one.

I suppose you (the bitnami team) can easily verify this issue by creating an instance on AWS Lightsail yourselves. If there’s an issue with the LAMP stack, this doesn’t just concern me (a single user). So I can’t make sense of the situation we’re in right now.

Also, in light of this issue, Modify The PHP File Upload Limit page might need to be updated. Following the suggestions in the page obviously doesn’t work.

If you guys can’t/won’t test an instance on AWS Lightsail yourselves for whatever reason, I can provide access to the instance in question if it’s going to speed up the process.

Hi @akinoreh,

Thanks for your message. In this community forum, and having into account the big number of replies we get daily, we do our best to reply all threads usually in a business day.

For the LimitRequestBody directive, I did a manual test in a fresh instance and it is working for me. I configured the php settings as shown below

upload_max_filesize = 1M
post_max_size = 2M

Note according to the official PHP docs, the post_max_size value should be larger than upload_max_filesize.

https://www.php.net/manual/en/ini.core.php#ini.upload-max-filesize

I also set the LimitRequestBody directive to the same value you used and into the same place, and it is working fine after restarting services.

To do a test, I uploaded a 5 MB file, and it is returning 413 error code as you can see in the next screenshot

Also in the Apache logs

MY_IP_ADDRESS - - [07/Jun/2021:08:26:12 +0000] "POST /upload.php HTTP/1.1" 413 631

After that, I tried to upload a 1 MB file, and it ended with a 200 ok code.

MY_IP_ADDRESS - - [07/Jun/2021:08:57:13 +0000] "POST /upload.php HTTP/1.1" 200 41

I followed the next guide for testing this. Can you test it on your side?

https://www.w3schools.com/php/php_file_upload.asp

This is really weird. I deleted the current instance and created a new one. Created screenshots to record the steps and modifications I make. The result is the same. I still don’t get the 413 error.

The screenshots and the files (htdocs, php.ini, httpd.conf) are in Google Drive. This is the link:

https://drive.google.com/drive/folders/1UqKRH4vfVnPV2Gm5kHNiWXdrapvCGNQi?usp=sharing

The test/upload page: http://3.67.91.60/upload.php

I’m stuck. If it works for you, and not for me, then what’s the difference/problem?

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: http://34.65.46.163/upload.html

==> 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

https://docs.bitnami.com/aws/infrastructure/lamp/administration/disable-phpfpm/

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
    </IfModule>
</IfModule>

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 https://community.bitnami.com/uploads.json?client_id=__some_string__. 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,
Gonzalo