[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:12 dd32]:
 > E_ALL (Well, that doesn't really matter, !WordPress's WP_DEBUG overrides
 the PHP error reporting level)
 Ha.  Missed that, thanks.

 > with zlib PHP compression enabled. ob_get_level() will return > 1, and
 ob_end_flush() can't turn off that style of output buffer.
 The buffer flush at the top of the function ''should'' solve this.  That
 way the buffer is empty before zlib is turned off.  According to the docs
 I've seen, that's the correct order of operations.

 > You may also need to be running PHP 5.3 as I've seen other reports about
 it too, php 5.3+zlib is the only combination that i'm aware of amongst
 them
 Tried running with WP_DEBUG on on 5.3 with apache 2.2 on two different
 machines.  I cannot reproduce the notice you're seeing.  Are you running
 under a cgi/suphp/fastcgi setup?

 > Personally I prefered `<!-- NULLNULL.. -->` as that way the browsers I
 tested don't include a tonne of extra markup in the source view
 Changed.  Also added a link to this thread for anyone who reads the code
 and scratches their head.

 > Might be worth checking that the headers of the plugin upgrader iframes
 have at least 512bytes of length before it outputs the steps then
 On my test site, one plugin update generated > 11K of output in the
 iframe.  Looks like it's safe.

 I've seen some wpshell / wp-cli projects in the wild ... should this patch
 include some code to wrap the 4K echo that checks to make sure the sapi
 isn't CLI?  Or is that just ''too'' detailed?

 {{{
 if ('cli' != php_sapi_name() {
     echo '<!--' . str_repeat(chr(0), 4089) . '-->'; // 4096 bytes
 }
 }}}

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