httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: %{REQUEST_URI} inconsistency
Date Sun, 02 Oct 2005 17:47:30 GMT
On Sun, Oct 02, 2005 at 12:49:07PM +0200, Ruediger Pluem wrote:
> >     RewriteRule ^/common-cgi/php_wrapper http://foo.com%{REQUEST_URI} [P]
> 
> Have you tried
> 
> RewriteRule ^/common-cgi/php_wrapper http://foo.com%{REQUEST_URI}?%{QUERY_STRING} [P]
> 
> instead?

No, because it wouldn't do what I needed. Once a request has been through
mod_rewrite several times, I want to be able to get hold of the original URI
for the request, not the one which started the last round of mod_rewrite
operation. This is what REQUEST_URI gives you in a CGI environment, but not
what %{REQUEST_URI} gives you in mod_rewrite.

Query strings are a separate problem which I didn't mention. I've discovered
that mod_rewrite/mod_proxy also adds back the query string even when you
don't want it. For example, if you have

    RewriteRule /foo.html /bar.php?id=6

then if you later do

    RewriteRule ^ /foo.html [P]

then it actually proxies to /foo.html?id=6. So to fix this, any initial
query which does not contain a question mark needs one adding: in this case
I would do

    RewriteRule ^ /foo.html? [P]

to stop mod_proxy adding the query string.

The actual magic I'm using is:

RewriteCond %{THE_REQUEST} "^[^ ]+ +(https?://[^/]+)?(/[^ ]*)"
RewriteRule ^ - [E=REQUEST_URI:%2]

RewriteCond %{ENV:REQUEST_URI} !\?
RewriteRule ^ - [E=REQUEST_URI:%{ENV:REQUEST_URI}?]

But that wasn't the point I was trying to make: the point is that
mod_rewrite's %{REQUEST_URI} is significantly different from a CGI
environment REQUEST_URI, this is non-obvious, and I consider it a bug in the
documentation that this is not made clear.

Regards,

Brian.

Mime
View raw message