Hi, A new bug has surfaced in mod_pagespeed that we understand, but would welcome advice on the best way to fix. The problem is tracked in http://code.google.com/p/modpagespeed/issues/detail?id=234.
Briefly, mod_pagespeed<http://code.google.com/speed/page-speed/docs/using_mod.html>seeks to improve the performance of web sites by rewriting them while being served from Apache. mod_pagespeed transforms the HTML text in an output filter. To do this correctly, mod_pagespeed needs to know what URL that browser thinks it has when it is displaying a site. The failure scenario is when a site has a RewriteRule in an .htaaccess file. The request->unparsed_uri gets rewritten by mod_rewrite, so by the time mod_pagespeed runs it has the wrong idea of where the page is. This makes mod_pagespeed resolve relative URLs embedded in the HTML in a manner inconsistent from the browser. We thought we had a solution to this problem by putting in an early-running hook that saves the original request->unparsed_uri in request->notes. That seems to work in some cases, but, we've found, not when the RewriteRule is in an .htaccess file. In that case, mod_rewrite triggers an "internal redirect", which causes an entirely new 'request' to be allocated, which does *not* have a copy of the original request->notes. It does make a hacked version of request->subprocess_env however, prepending "REDIRECT_" to each key. It also seems that the new request has a pointer to the original request (which has the note) in request->prev. But this new request, without the notes, is the one that's passed to mod_pagespeed's output filter, with request->unparsed_uri pointing to the rewritten URL, which is not consistent with the browser's URL bar. So I'm writing to this group to get suggestions on the most robust way to fix this. Here are some ideas: 1. Add an early 'create_request' hook and use that to copy the 'notes' that we care about from request->prev. 2. Change from storing notes in request->notes to request->subprocess_env. When we go to do the lookup with our key, we can look up REDIRECT_key if a note with our original key is not found. This strikes me as a brittle hack. 3. Follow the request->prev chain when looking up notes. This strikes me as risky because I have no idea what happens to the ->prev chain through all the modules in the Apache eco-system, or how far down the chain I might have to go. So I like #1 best. Any other opinions or ideas? -Josh
