Hi Mike,
I confirm the bug. In case of empty output HTTP headers are sent to
stdout or stderr instead of FastCGI stream.
To reproduce I configured nginx to use PHP FastCGI server on UNIX
socket, then launched (sapi/cgi/php-cgi -b /tmp/fcgi-php5) and performed
several request to empty PHP file. The HTTP headers were printed in
console running PHP.
[dmitry@tpl2 CGI-DEBUG]$ sapi/cgi/php-cgi -b /tmp/fcgi-php5
X-Powered-By: PHP/5.4.0RC7-dev
Content-type: text/html
X-Powered-By: PHP/5.4.0RC7-dev
Content-type: text/html
I afraid Yoram's patch is too radical and may have side effects.
Mike, could you please think about a safer way of fixing.
Thanks. Dmitry.
On 01/30/2012 07:29 PM, yoram bar haim wrote:
I Debugged the issue described here by lior.
the problem is :
in php_request_shutdown() we call
sapi_send_headers() after
php_output_deactivate().
at this point,
in main/output.c,
OG(flags)& PHP_OUTPUT_ACTIVATED is false so
php_output_write_unbuffered() calls
php_output_stderr() instead of
sapi_module handler.
the following patch solves the issue but It might be a wrong solution (because
other thins are dependent on this order) so I'm not suggesting it as fix.
--- main/main.c.orig 2012-01-30 17:25:44.000000000 +0200
+++ main/main.c 2012-01-30 17:09:05.000000000 +0200
@@ -1738,12 +1738,13 @@
} else {
php_output_end_all(TSRMLS_C);
}
+ sapi_send_headers(TSRMLS_C);
php_output_deactivate(TSRMLS_C);
} zend_end_try();
/* 4. Send the set HTTP headers (note: This must be done AFTER
php_output_discard_all() / php_output_end_all() !!) */
zend_try {
- sapi_send_headers(TSRMLS_C);
+/* sapi_send_headers(TSRMLS_C); */
} zend_end_try();
/* 5. Reset max_execution_time (no longer executing php code after
response sent) */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
