After submitting the code recently, I found that Firephp had another problem in other people's environments. The prompt: 'Headers already sent in...' is different from the last time the Nginx buffer exceeded. Checking the Nginx error log, no errors were found, and some students found that Apache did the same, and suspected that it was a PHP problem. But I also use Apache and there is no problem! I accidentally found a page that did not display an error message. I found that the output content of the page was about 1KB in size. I suspected that when PHP's output buffer exceeded, it automatically sent the buffer data, causing subsequent Firephp to fail to send debugging information through the Http header and ended. php script execution.
Comment out the output statement after template rendering, and the error will no longer be prompted. It is determined that there is a problem with the buffered output of PHP. Comparing php.ini in different environments, I found that the values of output_buffering are different. My value is On, while others have the default value of 4096.
Php code
Output buffering is a mechanism for controlling how much output data (excluding headers and cookies) PHP should keep internally before pushing that data to the client. If your application's output exceeds this setting, PHP will send that data in chunks of roughly the size you specify. Turning on this setting and managing its maximum buffer size can yield some interesting side-effects depending on your application and web server. You may be able to send headers and cookies after you've already sent output through print or echo. You also may see performance benefits if your server is emitting less packets due to buffered output versus PHP streaming the output as it gets it. On production servers, 4096 bytes is a good setting for performance reasons. Note: Output buffering can also be controlled via Output Buffering Control functions. Possible Values: On = Enabled and buffer is unlimited. (Use with caution) Off = Disabled Integer = Enables the buffer and sets its maximum size in bytes. Note: This directive is hardcoded to Off for the CLI SAPI Default Value: Off Development Value: 4096 Production Value: 4096 http://php.net/output-buffering output_buffering = On
According to the above explanation, when output_buffering is On or 4096, in each request, when we use echo or print, php does not actually output immediately but saves it to the buffer first. When it reaches a certain size (such as 4KB) or when the script execution ends, the buffer content is output to the browser and cleared.
When the HTTP protocol transmits content, the response header is transmitted first. Once the content starts to be output, the response header can no longer be changed. When output_buffering is On, PHP will cache all output and wait for the request to end before outputting the content to the browser. Therefore, there will still be no problem if Firephp changes the Http response header at the last moment, because no content is still output at this time; when When output_buffering is 4096 (or other fixed value), every time the PHP buffer is full, it will be output to the client. At this time, the content has been output, and the response header can no longer be changed. If you try to set the header, it will prompt: 'Headers already sent' …'.
Controlling the buffer output of the Webserver can bring a better user experience, such as Facebook and Sina's Bigpipe.
This time we found that because most pages have a lot of debugging information, the HTTP response header is large (much larger than 4KB, and some reach 36KB), so the automatic output mechanism is triggered. Solution: Change output_buffering to On; manually ob_start() in the code; change output_buffering to a larger value; reduce log debugging information.