Resolved Nginx: 413 Request Entity Too Large

[LionKing]

Server operating system version

Ubuntu Linux

Plesk version and microupdate number

18.048

Hello
I'm attempting to upgrade our CRM system on our company server and I'm receiving this error (Never had it before and done upgrades in the past with no issues):


I've tweaked both the:

• php.ini and user.ini files in the public_folder
• PHP Settings in home --> domains --> PHP Settings
• Just to test also the main ini file in /opt/plesk/php/8.0/etc/phi.ini

Php info does show 100M upload in:

• post_max_size
• upload_max_filesize

max_execution_time and max_input_time is temporally set to 500 (Just to test. Will revert the change back later to default).

I also read and followed the Pleask support guide and advise in this article regarding the error:
https://support.plesk.com/hc/en-us/articles/12377537186711

It still fails with the Nginx server error above...

Any idea how this can be resolved?

Thanks in advance!

 

[kpushkarev]

Hi! That's not a PHP error, so PHP settings doesn't matter. Please check the value of client_max_body_size parameter in nginx configs.

 

[LionKing]

Hi and thank you for your reply @kpushkarev

Please check the value of client_max_body_size parameter in nginx configs.

Is it this setting that controls it?

Thanks..

 

[MarkM]

Should be under; Domains > example.com > Apache & Nginx settings > Additional nginx directives:

client_max_body_size 128m;

Adding the above should do the trick.

 

[LionKing]

Thanks everybody, I appreciate the help.

I have solved it now.

 

[nazamm1]

How did you solve it? I have the same issue

 

[LionKing]

How did you solve it? I have the same issue

We didn't un fortunately.
I thought for a second that we found a solution, thus marked it here as solved.

Still trying to figure it out.

But in our case we running SuiteCRM and its complicated because we in our case we trying to figure out if it is database queries or web server queries that is triggering this.

No clear result of yet of what is causing is. all we know if that a specific text description field (Where the sales reps writes in their call log/prospect details about a lead) has a max allowed characters and if we attempt to add more text we are served with the error "Nginx: 413 Request Entity Too Large".

 

[UltraPyromane]

After this increase, "Session token has expired" how do I solve it?

 

[Peter Debik]

If "client_max_body_size 128m;" doesn't do it, why not try 1G instead?

 

[Peter Debik]

"Session token has expired" is normally an issue with the PHP session management, not the webserver. Closing and re-opening the browser might solve it.

 

[UltraPyromane]

"Session token has expired" is normally an issue with the PHP session management, not the webserver. Closing and re-opening the browser might solve it.

I've already done all this, but I get the error message again and again...

Just can't find a solution that I get a backup to the mentioned size again on Plesk.

 

[UltraPyromane]

Is it much more due to my browser than Plesk?

 

[Peter Debik]

What is the value of session.gc_maxlifetime when you display phpinfo()?

 

[LionKing]

Thanks @Peter Debik for your reply and question.

What is the value of session.gc_maxlifetime when you display phpinfo()?

It is currently set to 3000.





Kind regards

 

[jesussuarez]

In my case, I was using Plesk to host a PrivateBin instance. When uploading files, I noticed in the logs that it was failing with an error similar to this:

[client IP] ModSecurity: Request body no files data length is larger than the configured limit (1048576).. Deny with code (413) [hostname "website.com"] [uri "/"] [unique_id "asdlkawlwqerewrwe"]

After some research, I found that the issue was related to an Apache configuration combined with Imunify360, which was blocking these transactions even if ModSecurity was disabled at the domain level.

I solved it by adding the following configuration under "Additional Apache directives" in Plesk:

<IfModule mod_security2.c>
SecRequestBodyLimit 4294967296
SecRequestBodyNoFilesLimit 4294967296
</IfModule>

Additionally, I adjusted the "Maximum allowed size of the HTTP request body" (client_max_body_size) in the same section to 4G. After saving the changes, I restarted Apache (Ubuntu 22 server).
This completely fixed the problem.