post_max_size evaluates .user.ini too late in php-fpm?

Description

We are trying to modify the value for post_max_size per directory through a .user.ini-file running on php-fpm behind an Apache webserver using proxy_fgci_module. As mentioned in the docs, the setting should be a per-dir setting and we are able to see the correct values using $value = ini_get('post_max_size'); but sending a bigger value using the POST method results in a log message using the default value of 8M and the data is not submitted to the script:

NOTICE: PHP message: PHP Warning:  POST Content-Length of 10746083 bytes exceeds the limit of 8388608 bytes in Unknown on line 0

By changing the value in the php.ini, it's working as expected. Also using PUT instead of POST let me pass and receive the data.

I'd guess, the POST content size is evaluated too early, before the value of the .user.ini is set?

The upload_max_filesize value is working fine and we are able to upload bigger files than the limit, only POST-requests with content bigger than 8M are affected.

PHP Version

Tested on 7.4 and 8.1

Operating System

No response

That might be caused by post_max_size being a SAPI global, while upload_max_filesize is a core global. It might affect other SAPIs as well.

This issue does not affect (F)CGI, so this would be an FPM only issue; however, I'm not sure what exactly is wrong, since the docs state;

These files are processed only by the CGI/FastCGI SAPI.

Either the docs are wrong (should mention FPM as well), and the setting in .user.ini should work, or the docs are right, and .user.ini should be ignored altogether by FPM.

This is basically the same as https://bugs.php.net/bug.php?id=75741 . The ordering will be most likely the issue. I have got this on my list but might take few months to get there as there are higher priority items.

fix for phpGH-8157, activate sapi module before POST handling

Thanks for the report and for linking the related post.

If this can't be easily fixed, perhaps we could annotate the docs (https://www.php.net/manual/en/ini.core.php#ini.post-max-size) with a warning like:

WARNING: Despite being listed as INI_PERDIR, the order of SAPI loading prevents this value, post_max_size, from being used in .user.ini file with PHP-FPM, even though php -i and phpinfo() will report the values from that file.

The other value in the linked forum from 2017 mentioned enable_post_data_reading not working. Are these the only values that behave in this way or are there more? We could add a warning to each of them until (if) the behavior is fixed.

Tested on 7.4 and 8.1

Do we know if this value post_max_size in a .user.ini worked previously? If this is a regression, do we know when it regressed? What changed?

I was able to reproduce the issue using PHP 7.1 with docker https://github.com/schneems/post_max_size_php_71?tab=readme-ov-file. If someone can validate they're seeing the same thing and that I'm checking the right thing etc. (validate the reproduction) I would appreciate it (people make mistakes or omit details sometimes).

If validated, that suggests this has been here for years longer than reported and may have never worked. If someone wants to go back further, feel free. I figured 7.1 (2016) was old enough.

Storming on my prior suggestion, if we know that this value can never have any effect and can't find an acceptable way to work around the "bug" we could instead have SAPI warn and/or on this value:

WARNING value post_max_size found in /path/to/.user.ini this value has no effect on $_POST limits.

As an alternative: Would it be possible to special case when .user.ini is found in the DOCUMENT_ROOT to read in ini settings earlier in the SAPI load process. We still have the per-dir problem, but it would at least allow someone to configure this value without having to over-write their entire primary ini file.

Fix in #19333

Wanted try out the fix in #19333 and in the process realized that for me, modifying both post_max_size and upload_max_filesize works just fine in a .user.ini.

And then as I was fiddling with it (commenting out lines etc), I suddenly had things in a weird state where some workers were accepting the uploads and others were not.

And I realized that... maybe in all the cases where people are testing this, they're simply not seeing their config changes take effect because of user_ini.cache_ttl defaulting to 300?

they're simply not seeing their config changes take effect because of user_ini.cache_ttl defaulting to 300?

Can you share what you changed in my reproduction to observe those results? I tried and couldn't. I also added this schneems/post_max_size_php_71@42ab8fa

== Outputting settings 'php -ini | grep user_ini'
user_ini.cache_ttl => 1 => 1
user_ini.filename => .user.ini => .user.ini

And I'm seeing the same behavior as before.

modifying both post_max_size and upload_max_filesize works just fine in a .user.ini.

Can you share your exact reproduction so we can validate what you're seeing?

@schneems

@schneems see #19333 (comment) . David was using different content type that is not processed in the previously skipped part (post data read).

Fix phpGH-8157: post_max_size evaluates .user.ini too late in php-fpm

Navigation Menu

Repository navigation

post_max_size evaluates .user.ini too late in php-fpm? #8157

Description

PHP Version

Operating System

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

post_max_size evaluates .user.ini too late in php-fpm? #8157

Description

Description

PHP Version

Operating System

Activity

cmb69 commented on Mar 1, 2022

cmb69 commented on Mar 8, 2022

bukka commented on Apr 23, 2022

schneems commented on Jul 23, 2025

schneems commented on Jul 25, 2025

bukka commented on Jul 31, 2025

dzuelke commented on Jul 31, 2025

schneems commented on Aug 1, 2025

bukka commented on Aug 1, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions