CSS Not Loading

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install
2. Setup a ServerAlias on Virutal Hosts
3. Try both URLs, one will not load the CSS file.

What is the expected output? What do you see instead?
Expected: It to load the CSS file.
Instead: The CSS file seems to be empty.

What version of the product are you using? On what operating system?
I'm using the latest revision as of 2:15 CST 3 Nov. 2010 on a Debian Linux 5.0.

Please provide any additional information below.
I am running Virtual Hosts with ServerAliases for "www." That's where this is 
failing. I did add domains as:
ModPagespeedDomain *.example.net

Original issue reported on code.google.com by lurous.productions on 3 Nov 2010 at 7:17

[GoogleCodeExporter]

To add to this: The CSS file it creates seems to be interpreted as a 404 error.

Original comment by lurous.productions on 3 Nov 2010 at 7:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The apache log says:
[Wed Nov 03 13:54:56 2010] [notice] 
[1103/135456:INFO:net/instaweb/apache/serf_url_async_fetcher.cc(632)] 
Initiating async fetch for 
http://www.example.net/templates/dark_theme/_css/style.css
[Wed Nov 03 13:54:56 2010] [warn] 
[1103/135456:WARNING:net/instaweb/util/google_message_handler.cc(32)] Failed to 
create or read input resource /templates/dark_theme/_css/style.css
[

Original comment by lurous.productions on 3 Nov 2010 at 7:24

[GoogleCodeExporter]

It also seems to work always on the first way you access the files.
For instance:
I can access the same files 3 ways.
1. www.example.com/templates/dark_theme/_css/style.css
2. example.com/templates/dark_theme/_css/style.css
3. 1.2.3.4/templates/dark_theme/_css/style.css

The first one I access works as cached. The second and third don't always work 
as cached but sometimes they do.

Original comment by lurous.productions on 3 Nov 2010 at 7:43

[GoogleCodeExporter]

The first time mod_pagespeed accesses a resource, it initiates an asynchronous 
fetch of that resource and does not rewrite it, so the behavior you're seeing 
(no trouble until the second access) is consistent with how the module works.

Nonetheless, you shouldn't be getting 404s.  I'd be interested to hear if there 
are unusual log entries pertaining to this css file, or log entries that might 
indicate that one of your Apache processes has crashed.  

Original comment by jmaes...@google.com on 8 Nov 2010 at 12:51

• Changed state: Accepted

[GoogleCodeExporter]

It seems to be doing it on any files, JS, CSS and even sometimes images.

Original comment by lurous.productions on 8 Nov 2010 at 2:24

[GoogleCodeExporter]

Issue 16 has been merged into this issue.

Original comment by jmara...@google.com on 8 Nov 2010 at 3:03

[GoogleCodeExporter]

Original comment by jmara...@google.com on 8 Nov 2010 at 3:04

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Think I am getting a similar problem. I use RapidWeaver to make my web site and 
I upload it to my domain (virtual domain?) at dreamhost.com. If I enable Page 
Speed, the page design is broken, looks very basic and unordered, as if it 
seems to default to a default style and not load my custom 'theme' CSS files.

Original comment by michael....@gmail.com on 8 Nov 2010 at 7:00

[GoogleCodeExporter]

We're at a bit of a loss trying to reproduce this problem, and would love to 
get more information about what's going on.  A few things to try:
  * Look at the page source for rewritten URLs associated with broken resources (such as the broken CSS, js, or images mentioned above).  Can you fetch these resources in isolation (using wget, curl, or just typing them into the address bar of your browser)?
     * If you can, do the resulting files look reasonable?  If you run a tool such as FireBug on your page, does it indicate any new errors with the rewritten content?
     * If you can't, what do the logs look like when you attempt to fetch the rewritten data?
  * Try enabling filters one at a time.  What filter causes the problems in your page?  For css, I'd suspect cache_extend, css_filter, css_combine, or outline_css.

Until we can reproduce this, it's going to be tricky to figure out how to fix 
the bug.

Original comment by jmaes...@google.com on 9 Nov 2010 at 4:38

[GoogleCodeExporter]

You can find in www.zip a very simple html page with two images to reproduce 
this case.

I use the same image in different path.

In file system, only one file: 
./cache/http,3A/,/xx.xx.xx.xx/dir1/ce.4b9606a40bd81e8a047d2f74fa167e35.logo,2Cp.
png,

The second image in log: [Tue Nov 09 21:22:35 2010] [info] Fetch succeeded for 
http://xx.xx.xx.xx/dir2/ce.4b9606a40bd81e8a047d2f74fa167e35.logo,p.png, 
status=404

Original comment by tanguy.c...@gmail.com on 9 Nov 2010 at 8:33

Attachments:

• www.zip
• Image1.png

[GoogleCodeExporter]

It's quite bizarre, but it seems that, for instance:
the file is here:
http://www.lurous.com/media/system/js/ce.f6490edc31bf9c25ba507f41ce614def.mootoo
ls,l.js

and it works.

However, if I use the ServerAlias for it (which, as it is a serveralias, it 
should serve the same directory) it does not work. It returns a 404 error:
http://lurous.com/media/system/js/ce.f6490edc31bf9c25ba507f41ce614def.mootools,l
.js

Original comment by lurous.productions on 9 Nov 2010 at 9:30

[GoogleCodeExporter]

However, on the CSS, in /var/mod_pagespeed/cache folder, the CSS on the page is
ce.ffe41e99f797f8830111fe10f4213910.style,s.css

The actual file in the cache folder is:
ce.a5440a7cb2e785e0ca281188c3065bcd.style,2Cs.css

Original comment by lurous.productions on 9 Nov 2010 at 9:42

[GoogleCodeExporter]

@tanguy.coeury: Thanks for the nicely-distilled test case.  I've been able to 
reproduce this on my system by fiddling with cache extension:
  http://.../?ModPagespeed=on&ModPagespeedFilters=rewrite_images,extend_cache
  http://.../?ModPagespeed=on&ModPagespeedFilters=extend_cache
both break, but the following works:
  http://.../?ModPagespeed=on&ModPagespeedFilters=rewrite_images

It looks like there's a bug in our cache extension code that shows up when 
identical content resides at different paths (or perhaps different urls).  
We'll look into this and find a fix.

Original comment by jmaes...@google.com on 9 Nov 2010 at 9:42

[GoogleCodeExporter]

Yep, as soon as I added
ModPagespeedDisableFilters extend_cache

It stopped. (Because it wasn't caching things anymore.)

Original comment by lurous.productions on 9 Nov 2010 at 9:47

[GoogleCodeExporter]

The test case given by @tangey.couery above is now fixed in head.  Can folks 
please take a look at the latest svn release and see if it fixes the problem?  
If not we may have multiple issues here.

Original comment by jmaes...@google.com on 12 Nov 2010 at 12:05

• Changed state: Fixed

[GoogleCodeExporter]

Please remember if you build from source and want this fix now, you must build 
from trunk, not from the branch.

Original comment by jmara...@google.com on 12 Nov 2010 at 12:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It fixes the problem in my case also in my real web site. 
Thank's a lot.

Original comment by tanguy.c...@gmail.com on 12 Nov 2010 at 6:08