Anomalie #838
closedBug: Incomplete sending of body: bad ob_flush optimization for php > 5.4.0
100%
Description
In www/public/index.php there is this piece of code:
// ob_start has changed the way is works for PHP version > 5.4.0
if (version_compare(PHP_VERSION, '5.4.0', '>=')) {
ob_start('optimize', 0, PHP_OUTPUT_HANDLER_STDFLAGS ^ PHP_OUTPUT_HANDLER_REMOVABLE);
} else {
ob_start('optimize');
}
It should be (without the `^ PHP_OUTPUT_HANDLER_REMOVABLE` part):
// ob_start has changed the way is works for PHP version > 5.4.0
if (version_compare(PHP_VERSION, '5.4.0', '>=')) {
ob_start('optimize', 0, PHP_OUTPUT_HANDLER_STDFLAGS);
} else {
ob_start('optimize');
}
I'm pretty sure this comes from a copy paste from http://php.net/manual/fr/function.ob-start.php, but the version adding the PHP_OUTPUT_HANDLER_REMOVABLE part was about the uneraseable type of buffer, which is not the case here.
Effects of this bugs are multiple, for example with Nginx + php-fopm some pages were rejected by Nginx (502/503) because of mismatchs in the HTTP response size from php.
Seen on version 2.0.
Updated by Simon over 6 years ago
- Assignee set to Simon
- Target version set to 2.2
I'll maybe have some tests to do regarding this issue. According to the documentation :
http://php.net/manual/fr/outcontrol.constants.php#constant.php-output-handler-removable
PHP_OUTPUT_HANDLER_REMOVABLE (integer)
Contrôle si un tampon de sortie créé par la fonction ob_start() peut être supprimée avant la fin du script.
Disponible depuis PHP 5.4.
That also means that PHP_OUTPUT_HANDLER_REMOVABLE should be passed to call `ob_end_flush()` function, as explicitly mentioned in the doc : http://php.net/manual/fr/function.ob-end-flush.php
Right now, `ob_end_flush()` function is called by the app. I should check if it still necessary.
I would say this is a Nginx bug more that Linea21's bug. What do you think ?
Updated by Régis over 6 years ago
That's not an Nginx issue, because php-fpm's response was incomplete on various cases (especially on compression cases, from my memories). By using `^ PHP_OUTPUT_HANDLER_REMOVABLE` you were preventing some manipulations of the buffer. So, a web server receiving an incomplete response and still pushing that to the browser may take some risks with the security of HTTP communications (especially on http pipelines). I'm pretty sur Apache would also reject the respons efrom php-fpm, when apache is a reverse proxy in front of php-fpm.
When Apache uses mod_php -usually the default), Apache has no control on php's reponse, and cannot block it. So the bug may not be visible (but some browsers or even curl may trigger some warning about teh http response).
The fact is using the current code the php output buffer manipulations are wrong.
So, to get the same behavior as before you must not add this tag. Unless you want to review the whole output buffer process on the application -- which you can do, but that's another problem--.
Updated by Simon over 6 years ago
- Status changed from Nouveau to Fermé
- % Done changed from 0 to 100
Applied in changeset linea21|r3338.