Apache ErrorDocument subrequest fails horribly

[2020-12-28 16:44 UTC] problembug at speed dot 1s dot fr

Description:
------------
Reproducible on Amazon Linux, Slackware and others with various combinations of (recent) PHP and Apache. When httpd.conf is configured with an ErrorDocument to a PHP script and an error is deliberately introduced with a faulty header, the mere presence of a flush() changes the graceful error handling (via a subrequest) in to a confusing and bizarre situation that introduces secondary bugs.

These include:
o PHP no longer honours previous require_once include guard
o Apache not sending back any output to the client
o Misleading messages in the PHP error log about other modules
o Misleading messages in the PHP error log about ini_set (?) which is never used
o PHP error log messages repeated multiple times

The presence of a single flush() changes the graceful error handling ($test = 2) in to a confusing mess ($test = 3) and introduces seemingly unrelated bugs.

Steps to reproduce:
1. Edit an Apache VirtualHost config in to include the following:
  ErrorDocument 500 /error.php
2. Place the 3 attached scripts in the VirtualHost's DocumentRoot:
  test.php error.php library.php
3. Restart Apache
4. Access https://somesite/test.php
5. Alter test.php to try $test = 2 and $test = 3
6. Observe all the unexpected and secondary problems the flush() introduces

Test script:
---------------
https://pastebin.com/MBQEEb5Q

Expected result:
----------------
Expected result for test 3 is same as test 2:

----

PHP error log:
No new entries.

----

$ curl -i https://somesite/test.php

HTTP/1.1 500 Internal Server Error
Date: Sun, 27 Dec 2020 14:05:47 GMT
Server: Apache
Content-Type: text/html; charset=UTF-8

I will deal with a 500 error and show a pretty error message

Actual result:
--------------
Actual result for test 3:

----

PHP error log:

[27-Dec-2020 13:49:41 UTC] PHP Warning:  flush(): Headers already sent. You cannot change the session module's ini settings at this time in /www/test.php on line 22
[27-Dec-2020 13:49:41 UTC] PHP Warning:  flush(): Headers already sent. You cannot change the session module's ini settings at this time in /www/test.php on line 22
[27-Dec-2020 13:49:41 UTC] PHP Warning:  flush(): Headers already sent. You cannot change the session module's ini settings at this time in /www/test.php on line 22
[27-Dec-2020 13:49:41 UTC] PHP Warning:  flush(): Headers already sent. You cannot change the session module's ini settings at this time in /www/test.php on line 22
[27-Dec-2020 13:49:41 UTC] PHP Fatal error:  Cannot redeclare foo() (previously declared in /www/library.php:4) in /www/library.php on line 4

----

$ curl -i https://somesite/test.php

curl: (52) Empty reply from server

[2020-12-28 17:46 UTC] rtrtrtrtrt at dfdfdfdf dot dfd

just put ob_start() as first line of your error-script and/or remove linebreaks after ?> which is the reason for *not* use ?> at the end of the file

for sure not a php bug

[2020-12-28 21:00 UTC] problembug at speed dot 1s dot fr

@rtrtrtrtrt at dfdfdfdf dot dfd
There were no characters (including \n after the closing tags), I verified this before submitting the bug report. It seems like you're guessing rather than recreating the actual issue.

[2020-12-28 21:21 UTC] rtrtrtrtrt at dfdfdfdf dot dfd

> seems like you're guessing rather than recreating the actual issue

and you are sure that no single include has a linebreak too much?
and you are sure that you start with ob_start() as first instruction of the first file?

i doubt!

"Headers already sent" is pretty always a user error

[2020-12-28 22:21 UTC] problembug at speed dot 1s dot fr

@rtrtrtrtrt at dfdfdfdf dot dfd

Yes certain and I think you've missed the point of the bug report that other bizarre PHP behaviours are exhibited when switching from test 2 to 3. Again you seem to be guessing rather than recreating and confirming. My examples are fully reproducible even without the closing tags (just verified).  This is not a whitespace issue and I am not a novice PHP developer.

ob_start is not necessary to reproduce the behaviours so it is not included in my minimal viable test case.

How do you explain messages about calls to ini_set?  Or that the include guard in require_once stops functioning?

[2020-12-28 22:25 UTC] rtrtrtrtrt at dfdfdfdf dot dfd

> ob_start is not necessary to reproduce the behaviours 

but it is pretty sure the solution

use it in the *first* executed script and you are done
unless you are dumb enough to use flush() and something similar

again: that is a user error

i deal with dynamic error-pages for two decades for hundrets of domains

[2020-12-28 22:39 UTC] problembug at speed dot 1s dot fr

@rtrtrtrtrt at dfdfdfdf dot dfd

> i deal with dynamic error-pages for two decades for hundrets of domains

I've been doing it longer and on more domains.

You've demonstrated you've COMPLETELY missed the point of the test case so it's clear you're not able to add any value to this bug.  Plus after insulting me rather than confirming or refuting my actual test case I'm just going to ignore you now as my time is precious.  All the best.

[2020-12-28 22:52 UTC] requinix@php.net

-Block user comment: No +Block user comment: Yes

[2025-01-31 20:30 UTC] bukka@php.net

-Status: Open +Status: Assigned -Assigned To: +Assigned To: bukka

[2025-01-31 20:30 UTC] bukka@php.net

Apology for long delay. This is actually related to the global sharing that I was just looking in the context of virtual. ErrorDocument is also subrequest so this is pretty much the same but in this case (test 3), there are actual 2 subrequest and bailouts in them - that makes things properly wrong. I will be looking more into it hopefully next week. For the reference related issues are

https://github.com/php/php-src/issues/17655
https://github.com/php/php-src/issues/17509