Jeff Kaufman

Yes, this doesn't sound like what we want to happen, but I think I see how it could happen. PageSpeed has an "output cache" where it stores optimized resources. http://www.XYZ.no/skin/frontend/moero/clean/gtl,_blog,_css,_style.css+,_gtl,_blog,_css,_mediaquery.css.pagespeed.cc.1EUVqRsEkS.css...

Some discussion on the dev mailing list: https://groups.google.com/forum/#!msg/pagespeed-dev/clp0OTLIZ8Q/F3HdmHkNAgAJ

> Did it somehow assume it would exist in the filesystem and not fall back to http when it didn't? Yes, that's a thing we'll do. If IPRO is on,...

Summary: this is a bug, and it's on our list of things to fix.

Thinking about how to test this: 1) make sure you're not running any sort of in-memory http cache 2) fetch a page with a resource until you see it optimized...

I'm now thinking this is lower priority than I had thought: it only applies when a resource disappears from disk but the html continues to reference it, which should be...

That actually sounds like the bug we fixed in 1.9.32.14 / 1.10.33.7. Have you seen it on those or later versions?

> I'm now thinking this is lower priority than I had thought: it only applies when a resource disappears from disk but the html continues to reference it, which should...

Things we could do when we have to 404 a resource: - issue a redirect to the original resource (but this doesn't fix combiners) - clear the corresponding metadata cache...

Talking to @jmarantz here's a robust but slightly hackish way we could fix this. On failing to reconstruct a .pagespeed. resource either: 1) Issue a redirect to the underlying resource....