On Thu, 10 Mar 2011 01:29:15 +0100, Platonides wrote: It was a good question. I hadn't tried to bypass squid. However, when I do, I get the same result.

Iirc we originally used Content-encoding: identity but found this broke some clients. Probably worth pulling out the old bugs to check if the issue is still present. -- brion On Mar 15, 2011 3:25 PM, "Platonides" <Platonides(a)gmail.com> wrote: > Dan Nessett wrote: >> On Thu, 10 Mar 2011 01:29:15 +0100, Platonides wrote: >> >>> Looks very odd. >>> >>> Do you get the same Content-Encoding if performing the from the >>> squid? And if sent directly to the apache? >> >> It was a good question. I hadn't tried to bypass squid. However, when >> I do, I get the same result. > > > Ok, I have been able to reproduce it. This comes as a combination of > mod_deflate, ob_gzhandler and mediawiki. > > When serving files, mediawiki clears any gzipping layer, including its > own one. You seem to have at php.ini output_handler=ob_gzhandler. When > mediawiki detects that ob_gzhandler is active, performs ob_end_clean() > and does header( 'Content-Encoding:' ); in order to clean the > Content-Encoding field (otherwise you would get plain data with header > saying it's in gzip). > Then, you also have mod_deflate into the mix. It detects an existing > Content-Encoding header, and apr_table_mergen "merges" adding ', gzip' > despite the header being empty. > > Where is the bug? > mod_deflate shouldn't concatenate if the field is empty. php could skip > passing Content-Encoding to other modules if empty. MediaWiki could use > the header( 'Content-Encoding: identity' ); instead of header( > 'Content-Encoding:' ); > > How can _you_ fix it right now? > You don't need having three compressing layers. I'd deactivate > mod_deflate and output_handler=ob_gzhandler, letting mediawiki compress > the pages automatically for you. > Just disabling mod_deflate or output_handler=ob_gzhandler would work > too, but note that keeping mod_deflate with your current configuration > will compress streamed files, which is likely to be inefficient. > > > rfc2616 section 14.11 defines Content-Encoding header as > "Content-Encoding" ":" 1#content-coding The #rule (see section 2) > requires at least one content-coding to be present, which MediaWiki is > currently violating (yes, the empty header does arrive at the user > browser). > > I have explicitely set the Content-Encoding as identity in r84060, > using header_remove if available. > > Opened it as bug 28069 > https://bugzilla.wikimedia.org/show_bug.cgi?id=28069 > > > _______________________________________________ MediaWiki-l mailing > list > MediaWiki-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l