IPRO on reverse proxy can capture gzipped content and serve it to users without content-encoding:gzip

[GoogleCodeExporter]

What steps will reproduce the problem?
1. open http://www.trideal.in/?ModPagespeed=on in browser as we have disabled 
pagespeed for now
2.try different options through URL

What is the expected output? What do you see instead?
we tried enabling different options as suggested on pagespeed faq page and page 
breaks on extend_cache and inline_css 

we tried putting below line in our pagespeed.conf and restarted apache but it 
still broke
ModPagespeedDisableFilters extend_cache,inline_css

What version of the product are you using (please check X-Mod-Pagespeed
header)?
1.6.29.7-3566

On what operating system?
Linux ip-10-144-81-158 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 
2013 x86_64 x86_64 x86_64 GNU/Linux

Which version of Apache?
Server version: Apache/2.4.6 (Ubuntu)
Server built:   Dec  5 2013 18:32:22

Which MPM?
prefork

URL of broken page:
http://www.trideal.in
http://www.trideal.in/?ModPagespeed=on&PageSpeedFilters=extend_cache
http://www.trideal.in/?ModPagespeed=on&PageSpeedFilters=inline_css

Original issue reported on code.google.com by sameer.s...@trideal.in on 27 Feb 2014 at 7:07

[GoogleCodeExporter]

I've narrowed this down slightly more.  styles.css looks like garbage -- most 
likely a character encoding problem, when served via the extend_cache filter.

wget --save-headers -O - -q http://www.trideal.in/css/customer/style.css | head 
-20

  versus

wget --save-headers -O - -q 
http://www.trideal.in/css/customer/style.css.pagespeed.ce.Rb9GvHx5FF.css | head 
-20

I don't see any character-encoding response header on the origin style.css.  
Should there be one?

Original comment by jmara...@google.com on 27 Feb 2014 at 9:35

• Changed state: RequestClarification

[GoogleCodeExporter]

That looks gzipped.
$ wget -O dump 
http://www.trideal.in/css/customer/style.css.pagespeed.ce.Rb9GvHx5FF.css
$ file dump
dump: gzip compressed data, from Unix

Original comment by morlov...@google.com on 27 Feb 2014 at 9:37

[GoogleCodeExporter]

I'm guessing the origin is being sent gzipped but lacks its header.  I have a 
hunch.  Do you have ModPagespeedInPlaceResourceOptimization on?

Original comment by jmara...@google.com on 27 Feb 2014 at 10:02

[GoogleCodeExporter]

thanks guys for pointing to right direction, it was just white space and 
declaration on top of style.css

i followed below steps
- removed white line space and declaration from style.css
- cleared pagespeed cache
- restarted apache with pagespeed on

and it worked like charm :)

Original comment by sameer.s...@trideal.in on 28 Feb 2014 at 10:04

[GoogleCodeExporter]

I am concerned that your apparent success was achieved through cache flush and 
timing luck and that the problem could reappear.  So I am still wondering if 
you have in place resource optimization enabled.

Original comment by jmara...@google.com on 28 Feb 2014 at 5:46

[GoogleCodeExporter]

Summary was: Upgrading to latest version of mod_pagespeed broke the website

I've confirmed by observation that http://www.trideal.in/ has 
InPlaceResourceOptimization on.  So I think this is a real problem, and I think 
it occurs when Apache/mod_pagespeed are used in a reverse-proxy, where the 
origin is gzipping origin content.

I think we might capture the gzipped content in InPlaceDataRecorder and somehow 
lose the fact that it's gzipped.

Whether this breaks the site is dependent on request-ordering.  If 
mod_pagespeed parses the HTML, loopback-fetches styles.css, and puts the result 
in cache, then things will work fine, as the loopback-fetch path will unzip if 
needed.  But if a browser-initiated fetch for styles.css reaches Apache first, 
then we'll capture the gzipped content from the in-place-data-recorder.

This works fine for sites where MPS is installed on the origin server, since 
MPS runs before gzip.  However if it's running on a reverse proxy I think we'll 
be vulnerable to this bug.

I'll try to repro & fix ASAP.

Original comment by jmara...@google.com on 28 Feb 2014 at 7:57

• Changed title: IPRO on reverse proxy can capture gzipped content and serve it to users without content-encoding:gzip
• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Note that we don't need to immediately lose the fact that it's gzip'ed to screw 
up.
If we write a gzip'd thing to the cache we are screwed, since none of the 
filters or framework will do anything with that encoding header, the assumption 
is pretty much that fetcher layer will gunzip, after all.

... And I don't see anything in InPlaceResourceRecorder preventing us from 
writing down gzip'd stuff.

Original comment by morlov...@google.com on 28 Feb 2014 at 9:05

[GoogleCodeExporter]

Original comment by hui...@google.com on 4 Mar 2014 at 1:08

[GoogleCodeExporter]

Fixed by r3829

Original comment by morlov...@google.com on 7 Mar 2014 at 7:00

• Changed state: Fixed

[GoogleCodeExporter]

ModPagespeedEnableFilters rewrite_javascript
ModPagespeedEnableFilters inline_javascript

above parameters create junk characters from few of js scripts like this one 
http://www.trideal.in/scripts/guider/guider.js (this is the original one)

Original comment by sameer.s...@trideal.in on 12 Mar 2014 at 1:16

[GoogleCodeExporter]

Just to clarify, Sameer, you are describing another scenario in which you've 
seen the bug reproduced.  Is that right?

The bug is already fixed in our 'trunk' source code, and we will soon release 
it as a patch to 1.7, the beta stream.

Original comment by jmara...@google.com on 12 Mar 2014 at 1:50

[GoogleCodeExporter]

sure, i ll wait for the same.in the mean time this is another example

http://www.trideal.in/scripts/tabs/viewDealTabs.js.pagespeed.ce.WSUw4GNkuI.js

Original comment by sameer.s...@trideal.in on 13 Mar 2014 at 6:21

[GoogleCodeExporter]

Hi Guys
is that patch available now? 

Original comment by sameer.s...@trideal.in on 24 Mar 2014 at 8:43

[GoogleCodeExporter]

Yes, the latest 1.7 beta has this issue fixed.

Original comment by jmara...@google.com on 24 Mar 2014 at 12:51