Repository navigation
Exceeding max_file_uploads causes an apparently unrelated "cannot modify headers" warning before script execution #10654
Description
Description
The following code:
<?php
if (!empty($_POST))
echo "Done.";
else {
?><!DOCTYPE html>
<html>
<head><title>xxxx</title></head>
<body>
<form method="post" enctype="multipart/form-data">
<div>Lalalala</div>
<input type="file" multiple name="diocane[]">
<input type="hidden" name="something" value="1">
<button type="submit">Upload</button>
</form>
</body>
</html>
<?php
}when uploading 21 files (one more than the value of max_file_uploads), resulted in this output:
Warning: Maximum number of allowable file uploads has been exceeded in Unknown on line 0
Warning: Cannot modify header information - headers already sent in Unknown on line 0
Done.
But I expected this output instead:
Warning: Maximum number of allowable file uploads has been exceeded in Unknown on line 0
I am not attempting to set any header, and yet I get the "cannot modify header information" error. I understand that headers cannot be set because of the output that was generated because of the warning, but again, my code did not attempt to send any header.
It seems that PHP is trying to set some headers, during the startup phase (i.e. before my script gets executed), but:
- I'm not sure there's a good reason for that
- if there is, do it before you handle uploaded files, or maybe silence the "cannot modify header information" warning when you do.
- give more information in the error message so that I can at least figure out what headers failed to be sent.
PHP Version
PHP 7.4.11
Operating System
Debian 10
Activity
damianwadley commentedon Feb 21, 2023
Works for me in 8.1, which I have immediately available.
Do you have any extensions installed? Error handlers? Is output buffering enabled? On pages that work, any response headers besides the ones that PHP itself creates?
KapitanOczywisty commentedon Feb 21, 2023
session.auto_startenabled?github-actions commentedon Mar 22, 2023
No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.
php4fan commentedon Mar 22, 2023
(NOTE: I have edited the test code, it was missing a
[]at the end of the name of the file input, which was present in my tests and it's crucial to triggering the issue).That's a pretty wild assumption, and no, that is not the case. I am still experiencing the problem.
I'll attach phpinfo below.
No.
Several.
I don't think so. Is there a way for an error handler to somehow be there without me registering one in the code (which as you can see I am not doing)?
I don't think so, not entirely sure. Phpinfo shows "no value" for output_buffering and output_handler.
When I do a GET request to the above test script, which doesn't trigger the error, I get these headers in the response:
When I do a POST request with less than (or up to) 20 files which does not trigger the error, I get the exact same headers.
And when I do a POST request with more than 20 files, triggering the error, I get the exact same headers, too.
When you say "works for me", do you mean you get the expected warning about exceeding the allowed number of uploads, but don't get the warning about failing to set headers? If that is the case, then it works for you. If you are not getting any warning at all, it does not mean it "works for you", you are just not meeting the test case.
Note there was a missing [] at the end of the name of the file input in my code (now corrected). Also in order to reproducte you need to have:
(some lesser value of error_reporting may be enough).
Here's the output of
phpinfo():damianwadley commentedon Mar 22, 2023
That was a very helpful answer 💯
Do you still have problems if you disable all non-standard extensions? Notably newrelic?
php4fan commentedon Mar 22, 2023
I attached the output of phinfo, from which you should be able to tell which extensions I have.
Hmmmm, I can't (reasonably easily) test that without affecting other production websites on the same server.
I have tried on another unrelated server with PHP 7.4 where I don't have the New Relic extension, and indeed it doesn't reproduce the issue.
It's a slightly different version of PHP with a completely different set of installed extensions, though, so this doesn't necessarily narrow the issue down to New Relic. It is one suspect, though. I'll see if I can try disabling specific features.
Here's the phpinfo() of this other server not reproducing the issue:
damianwadley commentedon Mar 22, 2023
I suspect the newrelic extension, as this wouldn't be the first time I've seen it create some problems - as have many other third-party kitchen-sink extensions, to be fair.
If you can't remove, can you change its settings? Like the global
enabledflag, of course, but I would be even more interested in trying theerror_collector.*settings themselves.php4fan commentedon Mar 23, 2023
Bingo! Disabling that removes the issue.
I'll report this to NewRelic, as it seems very likely to be a bug of theirs.