mod_pagespeed does not optimize gzipped content that lacks 'gzip' header about incubator-pagespeed-mod HOT 6 CLOSED

Thanks for the report.

It looks like mod_pagespeed is receiving gzipped content from the upstream 
output filter, but not realizing that it's gzipped.  Is it possible that "wp 
total cache" is not properly supplying "Content-encoding: gzip"?  Is it 
possible for you to check this?

We can also change mod_pagespeed to check the first few incoming bytes for the 
'gzip' signature and inflate accordingly, so that you don't get all these error 
messages.

However, I think you will get the best performance if you serve unzipped HTML 
to mod_pagespeed, which will add the 'deflate' filter (if available in the 
binary) to run after mod_pagespeed.

Hope this helps.

This is not completely fixed, but in the latest version in SVN we will avoid 
trying to parse gzipped HTML by scanning the first few bytes before invoking 
the parser.

This will be completely fixed when we actually recognize the stream as gzipped 
and gunzip it and optimize it.

As the main symptom is now fixed I'm changing this from 'defect' to 
'enhancement'.

Subject was: Lots of warnings in log file while handling gziped files

This symptom has been fixed, and the subject adjusted to indicate the open issue


To re-cap: some upstream content generators, such as WP Total Cache, generate 
gzipped content but rely on mod_headers, which runs downstream of 
mod_pagespeed, to detect the content encoding and add the proper header.

mod_pagespeed now recognizes that the incoming text is not HTML and avoids 
spewing syntax warnings, but it will act as a pass-through and will not 
currently optimize such content.

can mod_headers logic to detect compressed content be emulated so that 
mod_pagespeed:

- uncompresses
- optimizes
- recompresses

i expect this may be a tad bit cpu-expensive but nonetheless, after the first 
round, we wouldn't do it again since we'd have optimized it?

I think it's time to admit we are not going to do this.  We certainly *can* do 
it, but it works around a misconfiguration by wasting CPU.