Last modified: 2010-12-10 17:24:19 UTC
I just did an svn switch from REL_1_16 to trunk, ran update.php and went to the main page, only to get a whole bunch of garbled output. To cut a long story short, I tracked this down to the fact that the output was being compressed twice. I have the following line in my LocalSettings.php: ---------------------- if ( $wgCommandLineMode ) { if ( isset( $_SERVER ) && array_key_exists( 'REQUEST_METHOD', $_SERVER ) ) { die( "This script must be run from the command line\n" ); } } elseif ( empty( $wgNoOutputBuffer ) ) { ## Compress output if the browser supports it if( !ini_get( 'zlib.output_compression' ) ) @ob_start( 'ob_gzhandler' ); } ---------------------- This line enables output buffering if it is not already enabled. The important thing to note here, is that this was automatically created by the installer script at the point I first installed MW, whenever that was. It is therefore very likely that a lot of users have this line in their LocalSettings.php, and will therefore suffer this same breakage when they upgrade to 1.17 unless this issue is fixed! I tracked the problem down to r72349, where the logic for starting output buffering was changed in WebStart.php. The old logic realised that buffering was started, and did nothing. The new logic does not correctly detect this situation, so output buffering/compression is started, resulting in double-compression.
Note that I experienced this on PHP 5.2.4, in case that makes a difference to anything. The bug is easy to fix, simply by reverting the changes made to WebStart.php in r72349, though I don't know enough about the reason those changes were made to say whether different breakages will occur if you do that...
*** Bug 25667 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > The bug is easy to fix, simply by reverting the changes made to WebStart.php in > r72349, though I don't know enough about the reason those changes were made to > say whether different breakages will occur if you do that... The changes to WebStart in that revision turned out to be useless, so I reverted them (functionally; left code flow cleanup and descriptive comment) in r77908. Please confirm that this fixes the bug.
I'm afraid not :-( Having upgraded to r77908, if I re-enable the ob_start() line in my LocalSettings.php I no longer get the double-encoding on the HTML page that I was experiencing before. However CSS/JS files are not working with this line enabled. Here's what's in the header for the main page: <link rel="stylesheet" href="/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%7Cmediawiki.legacy.shared%7Cskins.monobook&only=styles&skin=monobook" /> <link rel="stylesheet" href="/load.php?debug=false&lang=en&modules=site&only=styles&skin=monobook&version=20101103T234320Z" /> <style>@media all{a.new,#quickbar a.new{color:#ba0000}}</style> Both of those URLs give the following error in Firefox: > Content Encoding Error > The page you are trying to view cannot be shown because it uses > an invalid or unsupported form of compression. I also get the same error for the JS inclusions at the bottom of the page. If I comment-out the ob_start() then everything seems to work fine. Also tested on HEAD (r78066), which has the same problem.
Was caused by a bug in ob_gzhandler, see http://bugs.php.net/bug.php?id=36514 . Worked around this and another bug in ob_gzhandler (not directly related to this issue) in r78199.
