Last modified: 2009-06-02 01:52:34 UTC
Not all HTTP responses are getting compressed. Those that aren't I mark with "!": # tcpflow -i lo # firefox mysite #here on localhost #find -name 127.000.000.001.00080\* -newer /tmp/d|xargs -r ls -t|xargs strings -n 11| perl -nwe 'next unless /Content-(Encoding|Length|Type)|HTTP/;chomp; $g=1 if /: gzip/;if(/HTTP/){$g=0;print"\n";next}; if(/Content-(Length|Type)/){print $g?" ":"!"}else{print" "};print"$_\n"' Content-Encoding: gzip Content-Length: 64 Content-Type: text/css; charset=UTF-8 !Content-Length: 1078 !Content-Type: image/png Content-Encoding: gzip Content-Length: 81 Content-Type: text/css; charset=UTF-8 !Content-Length: 923 !Content-Type: image/gif Content-Encoding: gzip Content-Length: 20 Content-Type: text/html; charset=utf-8 Content-Encoding: gzip Content-Length: 3809 Content-Type: text/html; charset=UTF-8 !Content-Length: 8973 !Content-Type: text/css !Content-Length: 4852 !Content-Type: text/css !Content-Length: 27564 !Content-Type: text/css Content-Encoding: gzip Content-Length: 70 Content-Type: text/css; charset=UTF-8 !Content-Length: 50 !Content-Type: image/gif Content-Encoding: gzip Content-Length: 92 Content-Type: text/css; charset=UTF-8 !Content-Length: 1933 !Content-Type: image/png !Content-Length: 7881 !Content-Type: image/jpeg Running the above thru an additional grep Content-Type|sort -ubd !Content-Type: image/gif !Content-Type: image/jpeg !Content-Type: image/png !Content-Type: text/css Content-Type: text/css; charset=UTF-8 Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=utf-8 shows none of the images, only some of the CSS, and all of the HTML is compressed. We also note the varying capitalization of "UTF". # apt-show-versions apache2 apache2/unstable uptodate 2.2.11-5
The images are already compressed. gzipping PNG, GIF, or JPEG files would provide no noticeable decrease in size. E.g., one PNG on my computer is 1690090 bytes raw, and 1689871 bytes piped through gzip, a savings of 219 bytes or 0.01%. The CSS should be compressed, and I'm pretty sure there's a bug open for that somewhere.
Oops. fixing Summary. See also bug 15944.
Which files aren't compressed? Only the static .css files, right? If so, this is a Wikimedia configuration issue, not a MediaWiki issue. It needs a change to Apache config.
I was using vanilla MediaWiki 1.16 with vanilla # apt-show-versions apache2 apache2/unstable uptodate 2.2.11-5 totally offline, so no Wikimedia involved. $ find mediawiki/ \( -size 4852c -o -size 27564c -o -size 8973c \)|fgrep -v .svn|xargs ls -og -rw-r--r-- 1 4852 2009-03-12 05:18 mediawiki/skins/common/commonPrint.css -rw-r--r-- 1 27564 2009-05-31 07:56 mediawiki/skins/monobook/main.css the third one must have changed size recently...
This is a web server configuration issue. MediaWiki is not involved in serving static files, it just provides them for the web server to serve however it likes. You have to configure your web server to compress .css/.js files it serves. For instance, on lighttpd, this instructive would work with mod_compress enabled: compress.cache-dir = "/var/cache/lighttpd/compress/" compress.filetype = ("text/plain", "text/html", "application/x-javascript", "text/css", "text/javascript", "text/xml")
Wait, I think I found out why... this is not an area for junior programmer me, bye! $ sed 's/^/>/' /etc/apache2/mods-available/deflate.conf ><IfModule mod_deflate.c> > # these are known to be safe with MSIE 6 > AddOutputFilterByType DEFLATE text/html text/plain text/xml > > # everything else may cause problems with MSIE 6 > AddOutputFilterByType DEFLATE text/css > AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript > AddOutputFilterByType DEFLATE application/rss+xml ></IfModule>
