go to bug id or search bugs for
Suggestion: Don't count 0-bytes files (that comes from <input type="file"> elements that don't have any file specified) towards the max_file_uploads limit. (And don't create a blank temporary file for them to avoid the problems with file-system overload mentioned in CVE-2009-4017.)
Reason for suggestion: That way a small limit for max_file_uploads will cause less website restrictions. For example: I have seen some designs with lists of 40 or 50 rows where every row has a <input type="file"> for the sake of the design of the page. But where typically only one or two files are submitted in a POST because the majority of the <input type="file"> elements has no file specified. Currently all these designs will be limited (to for example 20 rows with the default settings) because even 0-byte files count towards the max_file_uploads limit.
HTML POST request with <input type="file"> elements where the value is blank (no file specified) so that $_FILES[#]['size'] is 0 (and $_FILES[#]['tmp_name'] is blank).
<input type="file"> elements where no file is specified doesn't count towards the max_file_uploads limit
<input type="file"> elements where no file is specified counts towards the max_file_uploads limit
Add a Patch
Add a Pull Request
Those people with websites showing 40 input boxes could just as easy increase the value of the limit in the php.ini or pass it on a case by case basic through .htaccess (if possible, i don't know)
Don't see the point of this...
This is an issue for me as well.
It can't be adjusted with ini_set or in .htaccess :
Automatic comment from SVN on behalf of cataphract
Log: - Implemented FR #50692, not uploaded files don't count towards
- As a side improvement, temporary files are not opened for
empty uploads and, in debug mode, 0-length uploads.
Implemented for trunk and PHP 5.3.