[Mediawiki-l] Content-encoding header value error
Dan Nessett
dnessett at yahoo.com
Fri Mar 18 18:18:58 UTC 2011
On Wed, 16 Mar 2011 10:01:59 -0700, Brion Vibber wrote:
> 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 at 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 at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I searched for bugs with "Content-Encoding identity" in either the
summary or comments. None were returned. I then searched for only
"Content-Encoding" and only the current 28069 was returned. So, perhaps
there are other search criteria that will give us a list of the old bugs.
--
-- Dan Nessett
More information about the MediaWiki-l
mailing list