RE: [users@httpd] mod_rewrite & mod_proxy & %2F in URL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I thought there was a flag blocking URL escaping in rewrite rules, but I am actually unable to find it in the module documentation. Checking the code, however, I found the following:

bash-2.03$ grep -n NOESCAPE mod_rewrite.h
125:#define RULEFLAG_NOESCAPE           1<<13
128:#define ACTION_NOESCAPE             1<<1
bash-2.03$ 

from mod_rewrite.c

    else if (   strcasecmp(key, "noescape") == 0
        || strcasecmp(key, "NE") == 0       ) {
        cfg->flags |= RULEFLAG_NOESCAPE;
    }

Could you try adding the NE flag to your rewrite rule and see what happens ?? 

-ascs

-----Original Message-----
From: Markus Stockhausen [mailto:markus.stockhausen@xxxxxxxxxxx] 
Sent: Tuesday, June 13, 2006 5:57 AM
To: users@xxxxxxxxxxxxxxxx
Subject: [users@httpd] mod_rewrite & mod_proxy & %2F in URL

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 it finds with the %25 chars.

Has anyone an idea of how to come around this problem. The only solution we found was to disable the patch and to force the behaviour as it was before.

Best regards.

Markus Stockhausen

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx



[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux