[wp-trac] [WordPress Trac] #18525: zlib.output_compression "on" in server conflicts with autoupdate

[WordPress Trac]

#18525: zlib.output_compression "on" in server conflicts with autoupdate
------------------------------------+------------------------------
 Reporter:  avidre                  |       Owner:
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  General                 |     Version:  3.2.1
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------------------

Comment (by kurtpayne):

 Replying to [comment:6 dd32]:
 > Any reason for ob_get_flush() over ob_end_flush()?

 Thanks, good catch.  This was from an earlier version of the code.

 > Despite what I thought, it appears that `ini_set('zlib.output_handler',
 '');` does indeed do what the packet says, and it can be called at any
 point of the pageload too.

 As long as you're not currently buffering output.  Otherwise, you can
 never clear the output buffer properly.  This is from my own experience
 and from the first comment [http://php.net/ob_end_clean here].

 > as for $disable_compression, we should be able to process that once per
 page load, if the function's called, we want to flush now, no need for it
 to be a variable.. If we use a static variable within the function, we can
 make sure that we only do that extra processing once per pageload too.

 This function is registered as a shutdown hook, though.  We don't always
 want to use the `$disable_compression` flag, right?  Just when it's
 absolutely necessary to give instant feedback?

 > Do you have a document/reference which explains the 4k null bytes? Given
 that'll be output during the middle of the pageload, I'm not entirely sure
 what that achieves? or is it to just push it over the block boundary so a
 chunk is sent to the browser rather than waiting for the next?

 Glad you questioned this.  I can use eyes on it.  From my research, it
 looks like apache2 uses [http://en.wikipedia.org/wiki/Chunked_encoding
 chunked encoding] for any HTTP 1.1 response and you can't turn it off
 unless you specify a content-length header.  Since the output isn't known
 before-hand, this isn't possible.

 http://serverfault.com/questions/222148/how-to-disable-chunking-in-apache
 http://bytes.com/topic/php/answers/10395-chunked-encoding-php-apache2

 From my testing (apache2 / mod_php), it does ''seem'' like the output is
 being buffered, even pulling out all of the other tricks in this patch.
 Sending a 4K block of null bytes shouldn't have any affect on the output,
 but does make the responses ''feel'' snappier.

 There ''could'' also be a buffer in the browser that needs to be filled
 before output is rendered.  As [http://php.net/flush noted on php.net]:

   Some versions of Microsoft Internet Explorer will only start to display
 the page after they have received 256 bytes of output, so you may need to
 send extra whitespace before flushing to get those browsers to display the
 page.

 Generally, for WordPress pages, the 256 byte limit will be reached, but
 browser-buffering is a concept I wanted to keep in mind.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18525#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software