Hello. We used Apache 2.0.54 as a reverse proxy for an internet webmail access with the following rewrite rule: AllowEncodedSlashes On RewriteEngine on RewriteRule /(.*)/MessagePart/(.*)/(.*)/(.*)-H.txt http://127.0.0.1:8100/$1/MessagePart/$2\%2F$3/$4-H.txt [P] It is essential for the mailserver to get the %2F character instead of an /. Otherwise the request results in an "404 not found error". The ruleset worked well until we upgraded to 2.0.58. Suddenly the rewrite produced another URL string. What before was an %2F now results in an %252F. We could track down that problem to the following patch that came with version 2.0.55: http://svn.apache.org/viewvc?view=rev&revision=227435 Obviously the old (but for us correct) url translation worked in three steps: step 1: mod_rewrite: .../... -> ...%2F... step 2: mod_proxy: ...%2F... -> ...%252F... step 3: mod_proxy: ...%252F... -> ...%2F... With the patch step 3 is now obsolete and we have no possibility to encode an / character into an %2F because mod_proxy will always replace any % charachter with the %25 chars. Is this patch meant to be this way. If yes what other way will there be to transform a single / in the calling URL to an proxied %2F. Best regards. Markus Stockhausen
Hi, I've seen similar behavior when upgrading from 2.0.53 to 2.2.2. I'm using mod_rewrite, i.e. first apply the unescape map, followed by an escape map ( in other words reescape incorrect escaped urls). Since the upgrade an % gets escaped to %25. So I suppose a bug is introduced between 2.0.53 and 2.2.2. kind regards, Pieter
We hit the same bug, is there any workaround?
Does AllowEncodedSlashes solve your issues?
No, because I've a problem with the encoding of the % character, using mod_rewrite (not mod_proxy), but I'll try to better understand if I'm doing something wrong
Nice to see that there comes a little bit of movement into this issue. We tried several things to get araound this bug but AllowEncodedSlashes will not solve the problem. As I wrote in my first post the failure occurs in mod_proxy. The mod_rewrite rule works perfectly - it translates the / characters into a %2F. If mod_proxy forwards this request afterwards it must definitly preserve the input url. As far as I understood the behaviour of mod_proxy it translates a % char into a %25 because it does not know that the original sequence is a %2F that should never be separated. So at last we have a %252F. This was never a problem at all as long as we had the third step that fixed the sequence back to %2F. But the apache fix 227435 will always eleminate step 3 if we have a reverse proxy. I guess there was a wise intention to build this fix but exactly for our szenario it will not work at all. So my colleagues are alwas forced to turn back the patch whenever they need a new apache version. Best regards. Markus
From my point of view reverting the patch would open a security hole similar to CVE-2007-1860 (see http://tomcat.apache.org/security-jk.html and http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1860). So it is needed that the proxy code encodes the URL again before passing it to the backend to avoid unexpected double decodings.
If you expect to get a security hole when reverting the patch then you have to redesign the encoding/decondig process of mod_proxy. When you define a double decoding as an error, I can only define an encoding from %2F to %252F as an error. So it will be better when you investigate the encoding behaviour of mod_proxy so that an apache switch (maybe AllowEncodedSlashes) will allow the module to read over %2F or just any special sequences. Another solution may be a mod_rewrite rule that will fill in escape characters before any char that you don't want mod_proxy to change. mod_proxy could afterwards eleminate the escape chars leaving the char behind untouched. Best regards. Markus
I just tested: the patch in Comment #27 of PR#34602 fixes this problem. I'm now reviewing that patch, with a view to whether it's suitable for committing to /trunk/ as a permanent fix. Anyone else watching either of these bugs: you could help by trying the patch yourselves and reporting back. *** This bug has been marked as a duplicate of 34602 ***
*** Bug 41614 has been marked as a duplicate of this bug. ***