Home  >  Article  >  Backend Development  >  PHP output control

PHP output control

巴扎黑
巴扎黑Original
2016-11-11 10:04:101154browse

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.


Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn