I'd like to add PHP_INI_PERDIR to max_file_uploads before 5.4.0 and also
in the next 5.3 release. This setting is very similar in scope to
max_input_vars and other POST-related limiters like upload_max_filesize,
and post_max_size all of which are PHP_INI_SYSTEM|PHP_INI_PERDIR.
The main reason is that our default for max_file_uploads is rather low
and since we count empty uploads against this limit it is easy for apps
to hit this. So if you have more than 20 type="file" fields in a form,
even if the user only actually uploads a single file, it will hit this
limit and fail.
The change it trivial and since it eases a restriction and doesn't
tighten one, it isn't going to break anything:
http://svn.php.net/viewvc/php/php-src/trunk/main/main.c?r1=323245&r2=323296
Any objections from anyone?
Stas on the 5.4.0 merge?
Johannes on the 5.3.11?
One example of pain this is currently causing:
http://allinthehead.com/retro/349/the-curse-of-max_file_uploads
-Rasmus
Hi!
I'd like to add PHP_INI_PERDIR to max_file_uploads before 5.4.0 and also
in the next 5.3 release. This setting is very similar in scope to
I think the change is good, I just want to understand - why before
5.4.0? I understand the change itself - though the problem has rather
easy workaround, as it seems: don't put that many file uploads on the
page if you're not using them - but why the urgency?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I'd like to add PHP_INI_PERDIR to max_file_uploads before 5.4.0 and also
in the next 5.3 release. This setting is very similar in scope toI think the change is good, I just want to understand - why before
5.4.0? I understand the change itself - though the problem has rather
easy workaround, as it seems: don't put that many file uploads on the
page if you're not using them - but why the urgency?
Mostly because if we put it into 5.3.11 it creates a weird gap in the
expectations. We would have to document that it is there as of 5.3.11,
but not 5.4.0, but then again in 5.4.1.
-Rasmus
Hi Stas,
with HTML5 you can also do <input type="file" multiple="multiple" /> and
thereby upload many files with just one file upload element.
Regards
Jannik
Am 17.02.2012 23:41, schrieb Stas Malyshev:
Hi!
I'd like to add PHP_INI_PERDIR to max_file_uploads before 5.4.0 and also
in the next 5.3 release. This setting is very similar in scope toI think the change is good, I just want to understand - why before
5.4.0? I understand the change itself - though the problem has rather
easy workaround, as it seems: don't put that many file uploads on the
page if you're not using them - but why the urgency?
On Fri, 17 Feb 2012 22:59:20 +0100, Rasmus Lerdorf rasmus@lerdorf.com
wrote:
The main reason is that our default for max_file_uploads is rather low
and since we count empty uploads against this limit it is easy for apps
to hit this. So if you have more than 20 type="file" fields in a form,
even if the user only actually uploads a single file, it will hit this
limit and fail.
This is not true since PHP 5.3.4. See request #50692 (don't count 0-bytes
files towards the max_file_uploads limit).
--
Gustavo Lopes
The main reason is that our default for max_file_uploads is rather low
and since we count empty uploads against this limit it is easy for apps
to hit this. So if you have more than 20 type="file" fields in a form,
even if the user only actually uploads a single file, it will hit this
limit and fail.This is not true since PHP 5.3.4. See request #50692 (don't count 0-bytes files towards the max_file_uploads limit).
That's good, but it still doesn't make sense to me that the scope of this is different from those other related settings.
-Rasmus