Don't mangle files that start with the gzip magic bytes.

[jmarantz]

From mod-pagespeed-discuss thread: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mod-pagespeed-discuss/nehDfeYxlTQ/NKWKLLFPCAAJ

A site is using the GD Star Rating plugin, and the CSS for that plugin gets garbled by mod_pagespeed. I suspect this is because the plugin gzips its CSS output but does not give it content-encoding:gzip header. So mod_pagespeed attempts to parse the gzip output as plain CSS and reports lots of encoding warnings.

The output is also broken -- the CSS coming out of mod_pagespeed is not readable.

I think this is the fault of the plugin, but I can't prove it because the download link for the plugin is broken: http://www.gdstarrating.com/index.html . The customer is using GD Star 1.9.22.

As far as I can tell from that site, that whole gd-star system has not had an update in 5 years. However, the problem is avoided by telling mod_pagespeed not to touch it:
ModPagespeedDisallow */gdsr.css.php*

[DoctorLai]

Thanks for your efforts! I have zipped the plugin folder and put it here: https://helloacm.com/data/gd-star-rating.zip

[jeffkaufman]

A gzipped resource should start with the magic bytes 1f8d:

$ curl -sS -H 'Accept-Encoding: gzip' www.google.com | head -c 2 | xxd
00000000: 1f8b

We should be aware of this, and avoid touching anything that starts with that. Maybe we should be like browsers and treat it as telling us that we're processing gzipped data if it then gunzips without errors, but we definitely shouldn't proceed as if it's text.

[jeffkaufman]

Looking at the plugin, gdsr-config.php is an ordinary-looking php file, and nothing in the plugin mentions compression. So this is more likely to be a webserver misconfiguration than a problem with the plugin.

[jeffkaufman]

I'm not able to reproduce combining or mangling with gzipped data, just inlining it, so I'm going to send out a CL that just blocks the inlining.

[jeffkaufman]

Fixed by 703060b