This is intentional. the "random characters" is a MD5 hash of the contents used 
to cache-extend the resource followed by a simple encoding of the original 
filenames.

Were the links broken for you? That would be a bug.

Please see examples on http://www.modpagespeed.com/ and look at the source of 
the before and after links for examples of how this is supposed to work.

Thanks,
-Shawn

Weird... I re-enabled it to make sure the files loaded and such, and it's 
working just fine. Well it's good to know that is expected. Thank you for the 
quick response!

Yay

Ok I might have lied... sort of. The main page I was looking at works now, but 
another, on the same server, does not now that I've enabled this.

http://omg.stage.digdug.me/

The css file loads up blank.
http://omg.stage.digdug.me/css/cf.d41d8cd98f00b204e9800998ecf8427e.ce,od5e8ef952
74a54ebd45e0df007651893,ostyle,,s,s.css

versus

http://omg.stage.digdug.me/css/style.css

Yep, that looks like a CSS minifier issue, I've attached the offending CSS and 
give it a look.

Is that the same as mine? Or should I try replacing mine with that?

I just attached your CSS file so that I can reference a fixed version in case 
your site's version changed.

seems to be working now.... no idea what changed (nothing in the style sheet 
that I know of). Might be some kind of initial caching issue? I dunno.

I'm suspicious about the doubly-rewritten uri; it looks like we're cache 
extending, *then* minifying (we ought to do the reverse, causing cache 
extension to be a no-op).  Either the filters are strangely re-ordered, or 
we're encountering a really strange loopback problem during resource lookup.  
That might mean that you need to request the resource 2-3 times before you get 
correctly rewritten data back (and you may get a 404 in the mean time).  I'm 
hoping we can reproduce this locally and figure out what's going on and why.

good luck. let me know if I can be any help

One plausible cause for the doubly-rewritten URLs is if the mod_pagespeed 
output-filter winds up the Apache filter-chain more than once.

This could happen in a virtual hosting setup where mod_pagespeed is configured 
twice:

Instance 1:  enabled_filters=extend_cache
Instance 2:  enabled_filters=rewrite_css,extend_cache

This could account for URLs like those pasted above.  dojohnso, is this 
possible in your setup?


One thing we can do in our system is to scan the response-headers for 
X-Mod-Pagespeed and skip the second rewriting pass if the header is already 
present.

I tried the CSS file in the stand-alone CSS parser, and it seems to work fine, 
so I'm guessing the issue here is with running through mod_pagespeed twice.

I'm not sure about the setup. I'm on a DreamHost VPS, and they added the 
optional setting per domain for PageSpeed. Should I submit a ticket to them 
with this thread?

Yes, that would be great, thanks.

ticket submitted to DreamHost

the response from DH:

One our dev's checked this out and he mentioned "I'm pretty sure it's
just a bug in pagespeed. We just turn on the core filters plus
collapse_whitespace and remove_quotes, and I don't see a way for it to be
turned on twice."

I'm not worried about it at this point. I'm actually switching hosts for some 
of my sites that would use this, so I'm good here.

We're curious if anyone is still experiencing this problem with recent versions 
of mod_pagespeed.  We have not been able to reproduce the issue, and will 
reopen it if we can get a reproducible test case on a recent release.

I think I have the same issue.

http://ianstormtaylor.com/designs

Everything is showing up as those weird filenames, and it all works fine except 
for 3-4 of the images. (Open the developer console and see where it gives 
errors for a couple of them.)

Not sure what to do... been trying everything.

Thanks for any help.

Ian - Looks like you're running 0.9.10.1; is there any chance you could try 
0.9.11.5 (the current binary release on the site) to see if this resolves the 
problem?  We took a crack at this problem two weeks ago and I'd like to know if 
it's still causing trouble.

I've re-opened pending confirmation.

Ah ok. I'll talk to Dreamhost and see why they're serving a later version.

Thanks and I'll r back with an update.

This problem has been fixed for some time.