https://bugzilla.wikimedia.org/show_bug.cgi?id=28069

           Summary: MediaWiki fails streaming files when mod_deflate and
                    ob_gzhandler are also set ("Content-Encoding:  ,
                    gzip")
           Product: MediaWiki
           Version: 1.18-svn
          Platform: All
               URL: http://thread.gmane.org/gmane.org.wikimedia.mediawiki/
                    36969
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: General/Unknown
        AssignedTo: platoni...@gmail.com
        ReportedBy: platoni...@gmail.com


Dan Nesset reports in mediawiki-l that when serving files from ConfirmAccount,
the response contains "Content-Encoding:  , gzip", which "befuddles
some browsers, such as FF, IE and Safari and they fail to decompress the
file."

This comes as a combination of mod_deflate, PHP's 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).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to