The following rewrite rule would properly encode any special characters present in the URL in earlier versions of Apache. In Apache 1.3.26, the rewrite rule fails to encode, for example, embedded spaces in the string resulting in an error being returned. RewriteRule ^https://uea001.usigs.com/(.*)$ http://uea001.usigs.com:80/$1 [P] The rewrite log and packets captured with tcpdump showed that spaces embedded in the URL were not replaced with the encoded value %20. Temporarily enabling http for the virtual host, I reconfigured the virtual host to use the following proxy rule. ProxyPass / http://uea001.usigs.com/ This worked correctly, the same URLs that would fail using the above rewrite rule could be retrieved. The functionality of the RewriteRule may have been broken as early as 1.3.23. Merton Campbell Crockett
My apologies the left-hand expression was incorrect in the original report. It should be ^/var/www/virtual/UEA001/docs/(.*)$ The problem still exists. One of the documents that I read indicated that mod_rewrite should be listed after mod_proxy in the LoadModule and AddModule lists. This definitely doesn't work and creates additional problems.
This seems similar to 10446,,, will look into it.
Hi! I think this is a bug in mod_rewrite, which properly re-escapes the URI for external redirects, but not for proxy requests. See the attached log (RewriteLogLevel 9) for a request to: http://myhost.mydomain:8080/~gryf/encoded%2520space/ The httpd.conf contains a simple RewriteRule: RewriteRule ^(.*)$ http://myhost.mydomain$1 [P,L] (I known this special case is better done via ProxyPass, but it's just an example) The destination server instead sees a request for: http://myhost.mydomain/~gryf/encoded%20space/ I.e. the first level of URI encoding gets lost. I'll also attach a proposed fix for mod_rewrite.c, which - as far as I can tell by looking at the source - is also necessary for httpd-2.0 Ciao Thomas
Created attachment 9515 [details] RewriteLog for a request to /~gryf/encoded%2520space/
Created attachment 9516 [details] Proposed fix for mod_rewrite.c
This appears to be similar to the 2.0 bug, #15207. Is this a red herring, or could the approach used in that patch (which has already been accepted) be relevant here as well? Confirming that this issue still exists in 1.3.31, RHL 7.5. .htaccess for secure.example.com: > ProxyPass /NetStorage/ https://otherserver.example.com/NetStorage/ > ProxyPass /oneNet/ https://otherserver.example.com/oneNet/ request for: https://secure.example.com/oneNet/NetStorage/DriveI%40VOL/Shared%20Projects gets a 400 Bad Request from otherserver.example.com because the %20 was expanded to a space. (otherserver reports "The request line contained invalid characters following the protocol string", as well it should.) best, -arthur.
My comment isn't related to mod_proxy, but a general comment about rewrite rules similar to the ones shown here. It seems difficult with mod_rewrite to pass possibly-urlencoded parts of a path as a query parameter to a script.. example: RewriteRule test/(.+)$ /phpinfo.php?mytest=$1 [QSA,L] If the URL contains test/one%23two then the query string as seen by phpinfo.php will contain a literal # and thus be truncated. Urlencoded & can also cause trouble. A couple workarounds: use a RewriteCond on THE_REQUEST to pull out the still-encoded part of the path that is desired and put mytest=%1 in the rule; or, add RewriteMap escape int:escape in the server config and use mytest=${escape:$1} in the rule. The former makes for more complicated rules, the latter requires server config change and can't be done just in .htaccess.. neither seem like a great approach. Just curious, what is the "recommended" approach for a rule like this? Would be great if escape function was always available, without a special rewritemap.
See also bug 34602