No warning when uploading media that is larger than limit (HTTP code 413)

The media add form will be refactored in #3023802: Show media add form directly on media type tab in media library and this specific issue is fixed in that patch. If you could help test and confirm that, that would be really helpful!

I am experiencing this issue not only for this media form but also any file upload. It doesn't matter if it is a file field or uploading inline images on the wysiwyg.

I think the best solution is a message for the user that reads something like:

The file you are trying to upload is too big. Reduce the size or contact the site administrator to raise the limit.

As far as I know we can only read what is configured on PHP as a limit but if the 413 comes from the server there is no method to read that configuration.

Posting my comment here from drupal.slack.com:#media chan per SeanB's request :-)

"IMO that would be out of scope for the app layer (to handle this this type of notification), unless you can parse the file size prior to the upload (requires some JS I assume) and evaluate it against "known" environment config before proceeding with the upload event. When I did my stint at Acquia (5 years) we ran into this on several occasions and the only real solution was to just conditionally tune the environment config based on paths..." Meaning for upload paths that we knew could have large file sizes, we conditionally set upload limits. Not ideal, but this is what environment tuning is all about.

Now that I have had "some" sleep and a half cup of coffee in me, I can say that I think this is doable as long as the environment variables are known and accessible. A simple Apache or NGINX hosted environment can be easily setup to do this. But for more complex environment configurations this is not so easy.

I know of one particular Drupal managed host that has CDN (optional) -> NGINX -> Varnish -> Apache before you bootstrap PHP. In each of those environments you could have file upload limits defined, but you would need these settings to be exposed and passed to the next layer for you to be able to do any proper evaluation via the app.

Here I think we should get the error code (sans error message) pass it back to the user to then contact their administrator to manage environment configuration.

Now that I think about this a little further (finished the cup of coffee). In the more complex scenarios, this event might fail quietly and you would not have an error message to parse (think about how Varnish handles things).

Maybe we need just a general message that says.. "File upload failed, page your SysOp with this request URI: {uri_path}".

So is not possible to read the 413 Ajax response and display a message based on that?

I encounter the same problem, it is very annoying for users who have no warning message.

https://drupal.stackexchange.com/questions/286978/what-is-the-cause-of-a...

Hope this is correct with Drupal 8.7

Hi, this is not a drupal problem but a bad configuration of Nginx after an upgrade.

You just have to add this in your Nginx configuration, it works for me :

server {
    #...
    client_max_body_size 10m;
    #...
}

Suggestion #10 worked for me, however...

I had to add the directive in two locations, the main server block and also the Location PHP block.

I tested this on 8.9.x, 9.5.x, and 10.1.x before finding this issue. At first I thought this was a regression, because we have a test for it (MaximumFileSizeExceededUploadTest.php) which was added in #1489692: Incorrect handling of file upload limit exceeded - file widget disappears. However the test seems to not catch this (I couldn't get it to run locally on my Apple M1 chip under ddev).

This is easy to reproduce with standard core + media module, try to upload a document that is more than the max upload size (100M by default if using ddev). The upload fails silently. A page refresh shows no warnings.

The comment about it being a bad configuration in #10 is wrong IMO. Someone will always try to upload a file that's larger than the configured system, and we shouldn't fail silently. Additionally, there are many hosts where you can't increase this value, and it will never be unlimited. A previous posted mentioned that Acquia frequently had this problem. We have this problem on Pantheon with a 150M file and a 100M limit. I think it's reasonable to have a limit but not reasonable to fail silently to the user.

I like the idea of an ajax capturing the 413 response and overlaying it with an option to view full raw response string.

An issue was recently committed that shows messages for AJAX errors:

• #2987444: Ajax errors are not communicated through the UI
• https://www.drupal.org/node/3350215

Can we verify if this helps resolve the issue, or can serve as a foundation/example for improvement here

We had the same issue while uploading the large files. The culprit was the client_body_buffer_size setting. It was set to 200MB. Basically, the buffer was too big and nginx was not able to allocate so much memory for keeping the file inside it. We had to lower the buffer to a normal value, so that file is buffered to a temp file during upload and the issue was resolved. Here is a detailed explanation.

The issue generally occurs when you try to upload a file that exceeds the post_max_size setting in PHP configuration. Here’s a summary:

• If UploadedFileSize <= upload_max_filesize, the file will upload successfully.
• If upload_max_filesize < UploadedFileSize <= post_max_size, a validation error message will appear.
• If UploadedFileSize > post_max_size, nothing happens (which is the current issue being discussed).