-
Task
-
Resolution: Won't Fix
-
Minor
-
3.0.8
-
None
-
None
Following fallout in linked tickets we should audit our remaining flush calls to make sure they are necessary and are correctly implemented.
The following are rules and notes regarding flush calls:
1. We cannot flush if output buffering is active, instead ob_flush must be called to flush to the output buffer. Output buffering may be enabled through a variety of means such as ob_start, output_buffering php.ini directive, ob_gzhandler in php.ini, etc.
2. ob_flush sends output up to the next outer level of output buffering. If ob_flush is called at the topmost output buffering level, headers may no longer be set via header() calls.
3. The sequence of ob_start -> ob_flush -> ob_get_clean sends output to browser. Even if no output was generated so far the empty output buffer is "flushed" such that headers can no longer be sent (PHPBB3-10245).
Some specific aspects to investigate:
1. Does cron properly call ob_flush when output buffering is enabled, instead of flush?
2. Does cron properly flush output all the way to the browser when output buffering is enabled in php.ini via any of the possibilities listed above?
3. The uncommenting of flush that happened as part of 3.1 cron should probably be backported to 3.0.
- is related to
-
PHPBB-10225 on a fresh install just as it finishes before you click the login button these errors come up
- Closed
-
PHPBB-10188 Broken compressed output when errors/warnings are handled by phpbb and output_buffering is set to 4096 and phpbb gzip is enabled
- Closed
-
PHPBB-10245 Messenger uses output buffering for error collection, should use error collector instead
- Unverified Fix
-
PHPBB-10191 Duplicate output when output_handler is set in php.ini
- Closed