Bug 23295

URI's are unescaped when processing starts but aren't escaped before being passed to the proxy.  
The query string needs to be escaped in addition to the filename.  Here are my diffs for 2.0.48:

*** new_mod_rewrite.c   Mon Mar  1 10:49:17 2004
--- mod_rewrite.c       Fri Mar  5 10:23:26 2004
***************
*** 1245,1250 ****
--- 1245,1257 ----
                                            "?", r->args, NULL);
              }
  
+             if (rulestatus != ACTION_NOESCAPE && ((skip = is_absolute_uri(r->filename+6)) > 0)) {
+                 r->filename = escape_absolute_uri(r->pool, r->filename, skip+6);
+                 if (r->args != NULL) {
+                     r->args = ap_escape_uri(r->pool, r->args);
+                 }
+             }
+             
              /* now make sure the request gets handled by the proxy handler */
              r->proxyreq = PROXYREQ_REVERSE;
              r->handler  = "proxy-server";

Ignore that code.  Escaping of URL parts and query terms is happening OK.

For me, the problem was occurring when I moved a piece of text from the path to
the query string.  For example:

RewriteRule ^foo/(.*)   http://another.host.name/foo?page=$1 [qsappend,P]

In this case, $1 will not be escaped correctly for the query string: it could
still contain unescaped ampersands, question marks or equals.  To fix this, one
can easily encode $1 using an external program (or hack the source to use a
form-encoder natively, as I did.)

This looks like a probable duplicate of Bug 13577.

Since that is down as probably fixed in recent patches to mod_proxy, can you
check whether this one is still reproducable with the updates?  The key to it is
the June 29th mod_proxy patch which fixed bug 15207 (mod_proxy mangling URLs in
a very similar manner to this bug).  Need mod_rewrite+proxy users to test
whether it fixes this case too.

At least, 2.0.54 has same problem.
After per-dir context rewriting ,the request doesn't
handled by canonicalise handler of proxy-http.
then mod_rewrite needs to canonicalise url on the case,
such like redirection case.
I thik that hook-fixup() needs a patch.

*** Bug 32328 has been marked as a duplicate of this bug. ***

The problem still occurs in Apache 2.0.59. mod_rewrite with a [P] RewriteRule 
removes the percent-encoding for umlaut characters from the URL.

It turns out that the problem only occurs when the RewriteRule is defined 
inside a location. Outside of locations the encoding is correct.

Looks as if the patch for PR #34602 should fix this.  Please reopen if I'm wrong
(and if it's still a bug).

*** This bug has been marked as a duplicate of 34602 ***

For comment #0

------------------------------------------------
RewriteEngine on
RewriteRule (.*) http://backend/somedir/$1 [P]
------------------------------------------------

I think this work correctly.
If you need to pass the url encoded to the proxied web server, you need to do
this  :

------------------------------------------------------------
First, add this line to the server config :
RewriteMap encode int:escape

Second, use this rewrite rule to your .htaccess file :
RewriteRule (.*) http://backend/somedir/${encode:$1} [P]
------------------------------------------------------------

I'm using a similar configuration and rules to proxy all php files to another
server.
My configuration is :

In server config file :
<IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteMap encode int:escape
</IfModule>

And to process php files on backend server, i also added this to server config
file :
<Files *.php>
        RewriteEngine On
        RewriteOptions inherit
        RewriteCond %{SCRIPT_FILENAME} -f
        RewriteRule (.*)$ http://%{SERVER_NAME}:81${encode:%{REQUEST_URI}} [P]
</Files>