Last modified: 2012-11-03 08:39:05 UTC
It looks like the export function doesn't create a right encoding header, so mod_gzip doesn't recognise it as already gziped and gzip it again. The result is a non readable text, because browsers only unzip once. The produced encoding header looks like this: Content-Encoding: , gzip At the moment I only found a workaround by commenting some parts in includes/GlobalFunctions.php: function wfResetOutputBuffers( $resetGzipEncoding=true ) { while( $status = ob_get_status() ) { if( $status['type'] == 0 /* PHP_OUTPUT_HANDLER_INTERNAL */ ) { echo 'status 0'; // Probably from zlib.output_compression or other // PHP-internal setting which can't be removed. // // Give up, and hope the result doesn't break // output behavior. break; } /* Commented because of encoding errors if( !ob_end_clean() ) { // Could not remove output buffer handler; abort now // to avoid getting in some kind of infinite loop. break; } if( $resetGzipEncoding ) { if( $status['name'] == 'ob_gzhandler' ) { // Reset the 'Content-Encoding' field set by this handler // so we can start fresh. header( 'Content-Encoding:' ); } } */ } }
I forgot: This bug was first in subversion revison 15101 (between Release 1.6 and 1.7) as gzip compression was introduced for exports.
(If possible, please provide Apache version and the configuration of mod_gzip.) We try to disable buffering (and hence PHP-level compression) on Special:Export so a long export job won't eat too much buffered memory... not 100% sure if that's the best thing though. Looks like there's some weird combination of things on your setup and it's not resetting correctly.
Mass compoment change: <some> -> Export/Import