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
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
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
MediaWiki-l mailing list