Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of jmarantz@google.com
 designates 74.125.121.67 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=google.com; s=beta;
        h=mime-version:from:date:message-id:subject:to:content-type;
        b=LeWni5cAQYxKQgulqpSEh+JAGZVjAyftw/owikn/RUwjFLa+iCF+dRH3jDorh7G/gR
         oXk62IZey6E4rtNkbeXA==
MIME-Version: 1.0
From: Joshua Marantz <jmarantz@google.com>
Date: Sat, 12 Mar 2011 20:15:12 -0500
Message-ID: <AANLkTikQAFhMM+vqBJvRTbL-LM7=nuCKSEUNvmWOKpOR@mail.gmail.com>
Subject: Saving the original request URI ahead of a mod_rewrite
To: modules-dev@httpd.apache.org, Naomi <nforman@google.com>
Content-Type: multipart/alternative; boundary=001636920ba777051e049e52ee4a

--001636920ba777051e049e52ee4a
Content-Type: text/plain; charset=ISO-8859-1

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

--001636920ba777051e049e52ee4a--