New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 7 users
Status: Fixed
User never visited
Closed: May 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: ----
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment
When page uses Implict Flush - or manual flush - no output sent till buffer fills up
Reported by, Jan 1 2010 Back to list
Chrome Version :
OS + version : Ubuntu 9.04 Fully Patched upto 19Dec
CPU architecture (32-bit / 64-bit): 32bit
window manager : Gnome
Behavior in Firefox 3.x (if applicable): As expected

What steps will reproduce the problem?
1.Page (PHP) uses implicit flush, or commands flush();ob_flush(); to output 
results as tasks get completed on the server

What is the expected result?
Output should appear on the browser as it's being sent by server.

What happens instead?
Output gets buffered in the browser until one of two conditions are met: 
- 1 - buffer gets filled up
- or 2 - page finishes rendering

Please provide any additional information below. Attach a screenshot
and backtrace if possible.

Sample php code attached. 

93 bytes View Download
Comment 1 by, Jan 2 2010
Labels: -OS-Linux OS-All
Labels: -Area-Undefined Area-Internals
Status: Untriaged
  Hostname: macintosh-00145168447a-2.local
  Mac OS X Version 10.6.3 (Build 10D538)
  Processor: 1 Intel 1.50 GHz
  RAM: 1024 MB

  Chrome version: 5.0.307.1 r37331  <<<Release/Debug>>>
  QuickTime Player: 7.6.6
  QuickTime PlayerX: 109
  Flash Player:

Comment 3 by, Feb 9 2010
Labels: Internals-Network
Comment 4 by, Feb 16 2010
Labels: -Area-Internals -Internals-Network Area-WebKit
Moved the issue from Areas:Internals/Internals:Network to Area:WebKit, the
next component processing data received from the network.

The network stack passes any received data to the next component as soon
as they are received and decrypted/decompressed.  The only buffering in
the network stack is for decryption (SSL) and decompression (HTTP
content decoding).
Comment 5 by, Feb 16 2010
Labels: Area-Internals
[Adding back the internals label]

The culprit here is mime-sniffing.

Chrome pretty much always buffers responses before sending them to the renderer, in order to 
sniff the mime type.

In fact, EVEN when the mime-type is explicitly set to "text/html" by the response headers (as in 
the case of PHP), chrome will still wait until 256 bytes have been received before passing the data 

Simply put, it takes 18 iterations of that loop to reach an output of 256 bytes, hence it takes 18 
seconds until anything is even sent to the renderer.

(And in fact, the renderer then does its own delaying once it gets the data. sigh).

In the worst case, Chrome's mime sniffing will gobble up 512 bytes of response.

One work-around you can do is stick in 256 bytes of goop at the beginning of the response.

There is probably some other hack you can do to sidestep the mime sniffing (specify some non-
html content type).
Comment 6 by, Feb 16 2010
Labels: -Area-WebKit Internals-Network
per eroman comment, this is a network issue
Comment 7 by, Feb 16 2010
Labels: Mstone-X
Status: Assigned
The buffering happens at the ResourceDispatcherHost level (which means part of 
Internals:Network), and I think we should change the code to not buffer if an explicit 
mime type that we support is specified.

No need to block a specific milestone for this bug.  Over to abarth for input on what 
we should change (if anything).
Comment 8 by, Feb 16 2010
Here is the relevant code that gets hit (content-type in this case is "text/html"):


bool BufferedResourceHandler::ShouldBuffer(const GURL& url,
                                           const std::string& mime_type) {
  // We are willing to buffer for HTTP and HTTPS.
  bool sniffable_scheme = url.is_empty() ||
                          url.SchemeIs(chrome::kHttpScheme) ||
  if (!sniffable_scheme)
    return false;

  // Today, the only reason to buffer the request is to fix the doctype decoding
  // performed by webkit: if there is not enough data it will go to quirks mode.
  // We only expect the doctype check to apply to html documents.
  return mime_type == "text/html";
Comment 9 by, Feb 16 2010
I think the best fix here is to make WebKit's doctype decoding smarter so that it
only buffers data when it doesn't know whether to enter quirks mode.  We can then
remove the browser-side buffering for text/html and life will improve.

Note: we need to make sure we don't need the buffing for our feed-or-HTML sniffing.
Comment 10 by, Feb 16 2010
I think the feed sniffing was removed (?)
Use this function to get around the issue:

function buffer_flush(){

    echo str_pad('', 512);
    echo '<!-- -->';




these are all workarounds which will eventually impact website loading performance, when will it be fixed in the chromium core?
We should be able to remove this code now.  Our fancy new HTML parser is more robust to incomplete data.  There might be other problems, but I don't know of any off-hand.
Status: Started
Actually, there's a bunch of junky code that we can delete now.  Yay!
Status: Fixed
The fix is in the commit-queue.
Project Member Comment 18 by, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 19 by, Mar 10 2013
Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network
Sign in to add a comment