Don't call flush() when emitting responses
Summary: Fixes T7620. I don't fully understand exactly what's going on here, but we don't actually need to call `flush()`. Test Plan: - Put timing code around the `echo`. - Made a fake page that emitted a lot of data. - Saw the `echo` block proportionate to data size under `curl --limit-rate ...`. - See T7620. - Downloaded a large file, got a reasonable progress bar and no obvious memory use issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: jlarouche, rbalik, epriestley Maniphest Tasks: T7620 Differential Revision: https://secure.phabricator.com/D12127
This commit is contained in:
		@@ -22,10 +22,11 @@ final class AphrontPHPHTTPSink extends AphrontHTTPSink {
 | 
				
			|||||||
  protected function emitData($data) {
 | 
					  protected function emitData($data) {
 | 
				
			||||||
    echo $data;
 | 
					    echo $data;
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    // Try to push the data to the browser. This has a lot of caveats around
 | 
					    // NOTE: We don't call flush() here because it breaks HTTPS under Apache.
 | 
				
			||||||
    // browser buffering and display behavior, but approximately works most
 | 
					    // See T7620 for discussion. Even without an explicit flush, PHP appears to
 | 
				
			||||||
    // of the time.
 | 
					    // have reasonable behavior here: the echo will block if internal buffers
 | 
				
			||||||
    flush();
 | 
					    // are full, and data will be sent to the client once enough of it has
 | 
				
			||||||
 | 
					    // been buffered.
 | 
				
			||||||
  }
 | 
					  }
 | 
				
			||||||
 | 
					
 | 
				
			||||||
  protected function isWritable() {
 | 
					  protected function isWritable() {
 | 
				
			||||||
 
 | 
				
			|||||||
		Reference in New Issue
	
	Block a user