|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #70501 MAX_FILE_SIZE does not abort upload
Submitted: 2015-09-15 11:06 UTC Modified: 2016-06-24 18:46 UTC
Avg. Score:4.0 ± 1.0
Reproduced:1 of 2 (50.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: olafvdspek at gmail dot com Assigned:
Status: Open Package: *Web Server problem
PHP Version: 5.6.13 OS: *
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: olafvdspek at gmail dot com
New email:
PHP Version: OS:


 [2015-09-15 11:06 UTC] olafvdspek at gmail dot com
> This form element should always be used as it saves users the trouble of waiting for a big file being transferred only to find that it was too large and the transfer failed.

As far as I know this bit is incorrect. It does NOT avoid a too-large file from being uploaded as the value is only checked AFTER the file was uploaded completely.

IMO MAX_FILE_SIZE is useless and should be dropped entirely.

Test script:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-09-15 11:54 UTC]
-Status: Open +Status: Feedback
 [2015-09-15 11:54 UTC]
The sentence before that is
> The MAX_FILE_SIZE hidden field (measured in bytes) must precede the file input
> field, and its value is the maximum filesize accepted by PHP.

If you have a repro script that has this field appearing before the file input and the value is still ignored, please share it so the problem can be fixed.
 [2015-09-15 11:57 UTC] olafvdspek at gmail dot com
-Status: Feedback +Status: Open
 [2015-09-15 11:57 UTC] olafvdspek at gmail dot com
The value isn't ignored, but it's checked AFTER the entire file was uploaded.
 [2015-09-15 21:38 UTC]
As far as I can tell the intention of MAX_FILE_SIZE was to abort the upload, so the fact that files continue to be uploaded (which I've confirmed happens with PHP 5.5 + Apache 2.4 + mod_php) seems to be a bug. Perhaps rather than getting rid of something deemed useless, it can be fixed to work as expected.
 [2016-06-24 18:45 UTC]
-Summary: MAX_FILE_SIZE docs incorrect +Summary: MAX_FILE_SIZE does not abort upload -Package: Documentation problem +Package: *Web Server problem
 [2016-06-24 18:45 UTC]
Indeed, this is quite certainly not a doc bug, see
 [2016-06-24 18:46 UTC]
-Type: Documentation Problem +Type: Bug
 [2018-11-25 22:14 UTC]
Confirming this bug also here. The MAX_FILE_SIZE post data value check is never reached since the upload_max_file size ini directive is always set (no matter if you comment it out of php.ini it will be by default 2MB). This hidden value will only work if you set upload_max_filesize to 0 or -1 (like unsetting it). On top of that, edge case is vulnerable to changing the value on the user side (it is a hidden field after all and not a setting in the code).

Considering that it has been used in only an extreme edge case for the past several PHP versions and frameworks don't use it anymore it might be a good idea to remove it or better yet refactor it in the core code to something that works. Because with current PHP versions the only check that is done is the upload_max_filesize ini directive on the php side. And, preferably, also a manual check inside the code on the server side comparing a manual configuration value to a file size of the uploaded file.
 [2018-11-26 18:59 UTC]
Correcting my explanation above: When using MAX_FILE_SIZE, it will be used in two cases. One, if you unset the upload_max_filesize (to 0 or -1) (bad idea anyway, or two, if you set upload_max_filesize to be bigger than MAX_FILE_SIZE.

Actually, the MAX_FILE_SIZE option is useful after all because some app might set the ini directive upload_max_filesize to some setting for all files in the app, and additionally manually set different MAX_FILE_SIZE for multiple upload forms in the same app (let's say one for images and one for videos).

And it does stop the upload, but differently than reader might expect on the first glance. Uploading will be stopped when the MAX_FILE_SIZE is reached on the server (not at the beginning of the upload process). With extremely large files, for example hundreds of MB or GBs, this still is relevant today actually. However, for better user experience all decent forms might want to think about adding form client side validation as well (even file size can be determined at the time of this writing by the browser and JavaScript).

So, I was wrong a bit here and too hasty with previous comment conclusions. However, relying on this feature is not something that is secure since it can be spoofed on the client (browser) side easily.

Probably this would be better fixed with a better explanation in the documentation instead.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon May 20 06:01:34 2024 UTC