[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 dd32):

 > I'm not able to reproduce this even using E_ALL. What setup are you
 using?

 E_ALL (Well, that doesn't really matter, !WordPress's WP_DEBUG overrides
 the PHP error reporting level) with zlib PHP compression enabled.
 ob_get_level() will return > 1, and ob_end_flush() can't turn off that
 style of output buffer. 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

 > Changed the patch to just emit <!-- -> a bunch of times instead.
 Personally I prefered `<!-- NULLNULL.. -->` as that way the browsers I
 tested don't include a tonne of extra markup in the source view (Since the
 null byte character can't be displayed). As long as it's within a HTML
 tag/comment browsers seem to handle it properly.

 > Fixed. Does WP generate documentation anywhere?
 http://xref.wordpress.org/

 > I did come across a case of chromium doing some buffering up to 512
 bytes before rendering.
 Might be worth checking that the headers of the plugin upgrader iframes
 have at least 512bytes of length before it outputs the steps then, but
 it's an old bug, so hopefully doesn't affect any current generation
 browsers.

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