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" <[email protected]> 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 >> [email protected] >> 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 _______________________________________________ MediaWiki-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
