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

[thirsch]

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

[cmb69]

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.

[cmb69]

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.

[bukka]

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.

[schneems]

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?

[schneems]

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.

[bukka]

Fix in #19333