Issue 1044 in modpagespeed: Intermittend CSS/JS corruption after rewriting

[modpag...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 1044 by marc....@gmx.net: Intermittend CSS/JS corruption after
rewriting
https://code.google.com/p/modpagespeed/issues/detail?id=1044

What steps will reproduce the problem?
1. The hoster has mod_pagespeed installed and enabled by default
2. the site get's intermittend broken
3. Debugging has shown that there seems to be some binary code inside the
CSS and JS files
4. All settings are default I guess what means CSS/JS rewriting and
combining is active.

What is the expected output?
- No corrupted CSS and JS files.

What do you see instead?
- CSS code rewritten and combined with some binary/destroyed CSS code that
breaks the site than as the file itself is invalid than.

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

On what operating system?
Debian 6.x

Which version of Apache?
2.2.0

Which MPM?
Unknown

URL of broken page:
Random


Any idea what happens here and why this happens? Is this a known bug? The
hoster is highly unwillingly to help and comments only the way - it runs
for an extended time and there are no known issues. However I have proven
that there are issues. I attached two sceenshots. one from Firefox firebug
and one from chrome developer tools that show how the CSS files look like.
I have seen the same with one single JS file added to page footer. One
major issue is that this is intermittent and I cannot reproduce it. When it
happens I have no idea how to debug. The CSS files are already combined and
compressed by Drupal 7 when mod_pagespeed get the files.

As a workaround I have added this to the htaccess files of Drupal 7, but I
think this bug should be fixed.

<IfModule pagespeed_module>
ModPagespeed off
</IfModule>

Hopeful you can share some details or just point me to a closed defect that
fixed this bug already. So I can point the hoster to this case and tell him
to upgrade the broken version installed on the server.

Attachments:
2015-01-25_213825_b.png 98.8 KB
2015-01-25_214127_b.png 194 KB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[modpag...@googlecode.com]

Comment #1 on issue 1044 by jmara...@google.com: Intermittend CSS/JS

corruption after rewriting
https://code.google.com/p/modpagespeed/issues/detail?id=1044

This is likely a character encoding issue. Can you supply a URL to
reproduce please? If I type "random" as my URL I just get a 404 :)

Also of interest would be the full response headers of:
1. the HTML response headers without mod_pagespeed
2. the HTML response headers with mod_pagespeed
3-6 the CSS & JS response headers with & without mod_pagespeed

[modpag...@googlecode.com]

Comment #2 on issue 1044 by marc....@gmx.net: Intermittend CSS/JS

corruption after rewriting
https://code.google.com/p/modpagespeed/issues/detail?id=1044

The site is http://www.tibethunde-ktr.de/ and works without any issues
normally. The issue happened to anonymous users on the frontpage.

The JS file that is added in footer was corrupted. This file has not
changed for about 2-3 years or so.

This are the frontpage (html) headers without mod_pagespeed:

HTTP/1.1 200 OK
Date: Sat, 31 Jan 2015 22:03:08 GMT
Server: Apache/2.2.0 (Fedora)
X-Powered-By: PHP/5.3.3-7+squeeze23
X-Drupal-Cache: HIT
Etag: "1422734562-1"
Content-Language: de
X-Generator: Drupal 7 (http://drupal.org)
Link: <http://www.tibethunde-ktr.de/de>; rel="canonical"
X-UA-Compatible: IE=Edge,chrome=1
Cache-Control: public, max-age=43200
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Vary: Cookie,Accept-Encoding
Content-Encoding: gzip
Last-Modified: Sat, 31 Jan 2015 20:02:42 GMT
Keep-Alive: timeout=5, max=10
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8


and this the frontpage (html) with mod_pagespeed:

HTTP/1.1 200 OK
Date: Sat, 31 Jan 2015 22:04:55 GMT
Server: Apache/2.2.0 (Fedora)
X-Powered-By: PHP/5.3.3-7+squeeze23
X-Drupal-Cache: HIT
Etag: "1422734562-1"
Content-Language: de
X-Generator: Drupal 7 (http://drupal.org)
Link: <http://www.tibethunde-ktr.de/de>; rel="canonical"
X-UA-Compatible: IE=Edge,chrome=1
Cache-Control: public, max-age=43200
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Vary: Cookie,Accept-Encoding
X-Mod-Pagespeed: 1.9.32.3-4448
Content-Encoding: gzip
Cache-Control: max-age=0, no-cache
Content-Length: 12400
Keep-Alive: timeout=5, max=10
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8


The hashed footer JS file name
(sites/default/files/js/js_BSu0jYTi1hhxferiVdqvenYcV8QOHR-Bk6nTxZPRthc.js)
is a temp copy of the original file (2012-01-05 23:56:54) and has a file
date of 11. January. The site got broken on 25th and the issue disappeared
for unknown reason. The headers of this JS file
(js_BSu0jYTi1hhxferiVdqvenYcV8QOHR-Bk6nTxZPRthc.js) are:

HTTP/1.1 200 OK
Date: Sat, 31 Jan 2015 22:14:56 GMT
Server: Apache/2.2.0 (Fedora)
Last-Modified: Sun, 11 Jan 2015 16:38:04 GMT
ETag: "5060391-42d-50c630395c166"
Accept-Ranges: bytes
Content-Length: 1069
Cache-Control: max-age=1209600
Expires: Sat, 14 Feb 2015 22:14:56 GMT
Content-Encoding: gzip
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=8
Connection: Keep-Alive
Content-Type: text/javascript

and with mod_pagespeed it is made inline JS so it has no headers :-)


Please note that I'm currently not able to repro the situation by enabling
mod_pageview. This is totally intermittent. The footer js and html code has
for sure not changed since 2012-01-05 23:56:54. These JS file is UTF8
wihtout BOM.

One more thing that may come in mind is that Drupal is gzip'ing the CSS/JS
files under the hood. The gzip is not done by Apache in this case. As I
have no idea how to reproduce this issue - this is just one more guess
about possible reasons. Just to make sure you have the full picture about
this detail I'm posting the Drupal .htaccess file that shows you how the
static GZIP JS file is send to the client.


# Rules to correctly serve gzip compressed CSS and JS files.
# Requires both mod_rewrite and mod_headers to be enabled.
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist and the client accepts
gzip.
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

# Serve gzip compressed JS files if they exist and the client accepts
gzip.
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header set Content-Encoding gzip
# Force proxies to cache gzipped & non-gzipped css/js files
separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
</IfModule>

That means if the client accept gzip
the "js_BSu0jYTi1hhxferiVdqvenYcV8QOHR-Bk6nTxZPRthc.js.gz" GZ-file is send
and if not "js_BSu0jYTi1hhxferiVdqvenYcV8QOHR-Bk6nTxZPRthc.js" is send.

[modpag...@googlecode.com]

Comment #3 on issue 1044 by jcro...@google.com: Intermittend CSS/JS

corruption after rewriting
https://code.google.com/p/modpagespeed/issues/detail?id=1044

this issue has been migrated to github:
https://github.com/pagespeed/mod_pagespeed/issues/1044