When passing %{HTTP_HOST} as the key to a RewriteMap the lookup function only passes the path of the page «/test/tespage» and not the host «test.example.com» The URL sent to Tomcat is: http://test.example.com/test/testpage In our example the %{HTTP_HOST} returns test.example.com which is ok. But referenced inside RewriteRule with input to map function it fails. rewrite.conf: RewriteMap portals org.apache.catalina.valves.rewrite.EPSMapPage /usr/local/tomcat/easier-conf/portals.txt RewriteRule .* ${portals:%{HTTP_HOST}} The EPSMapPage is a rewrite map class we have made according to tomcat valve documentation and we have checked that this class works correct. So this portion of the RewriteRule ${portals:%{HTTP_HOST}} should feed in test.example.com (%{HTTP_HOST}) to map portals but actually it feeds in /test/testpage not the hostname. org.apache.catalina.valves.rewrite.EPSMapPage public String lookup(String key) { System.out.println("Key: " + key); return map.get(key.substring(1)); } console output: Key: /test/testpage When using RewriteRule .* %{HTTP_HOST} it works at expected And redirects to test.example.com/test.example.com
There's no code to handle %{} in that location. Is it supposed to be supported at all ? Also, since r1676615, I not sure a simple dumb static key works (probably nobody uses it). Actually, the only thing supported at the moment is a back reference (which is useful so it's ok I guess).
IMHO httpd mod_rewrite does full resolution via do_expand() of the key used to look up in the map. So any use of variables, back references etc. seems to be supported in that module. I haven't tried it though.
We have tried it in Apache httpd and it works there. So if we could get this working in tomcat we do not need Apache httpd!
Ok, thanks for the feedback. Rainer, does it need to be fully recursive, or is it ok to just handle the simple case (= the vaule is either static, $n or %{variable}) ?
httpd mod_rewrite code seems to be recursive, but it contains the following a little cryptic comment: To make rewrite maps useful, the lookup key and default values must be expanded, so we make recursive calls to do the work. For security reasons we must never expand a string that includes verbatim data from the network. The recursion here isn't a problem because the result of expansion is only passed to lookup_map() so it cannot be re-expanded, only re-looked-up. Another way of looking at it is that the recursion is entirely driven by the syntax of the nested curly brackets. Regards, Rainer
Ok, so adding recursion works. I suppose maps are the only thing that need it, right ?
I added the "feature"/bugfix for 9.0.12 and 8.5.34. I have no idea what the language from the comment "For security reasons we must never expand a string that includes verbatim data from the network." means since well, that's the point and this BZ asks for ${portals:%{HTTP_HOST}} (%{HTTP_HOST} is clearly verbatim network data). Comments ? Maybe it means you shouldn't parse network data (only evaluate), but that's not the case here obviously: the configuration is parsed on valve start and that's it.
(In reply to Remy Maucherat from comment #6) > Ok, so adding recursion works. I suppose maps are the only thing that need > it, right ? Yes, I think so. I didn't find another way to trigger recursion in mod_rewrite.
(In reply to Remy Maucherat from comment #7) > I added the "feature"/bugfix for 9.0.12 and 8.5.34. > > I have no idea what the language from the comment "For security reasons we > must never expand a string that includes verbatim data from the network." > means since well, that's the point and this BZ asks for > ${portals:%{HTTP_HOST}} (%{HTTP_HOST} is clearly verbatim network data). > Comments ? Maybe it means you shouldn't parse network data (only evaluate), > but that's not the case here obviously: the configuration is parsed on valve > start and that's it. I would read it so that data sent from client should not be expanded any further. So for example a user sends "%{HTTP_HOST}" as the value of the host header, this would/could result in a infinite loop. There are probably more malicious examples that could be thought of.
Ok, then it's fine as there's no dynamic parsing. If "%{HTTP_HOST}" evaluates to "%{HTTP_HOST}", then it's the final result.
Hi, seems like you did a patch to fix this and that is really great. Then we can test it when next release is available. Today we have a .htaccess file with some URL rewriterules used in Apache httpd that we want to convert to use in Tomcat Valve rewrite.config. But we find it very difficult to debug it. Is there any way to enable logging to actually see what rewrite valve is doing when parsing/rendering the rewrite.config file. Since it is many regular expressions it is very hard to find out what is going on. Thank you! Best Regards Frode
BZ is for reporting issues and not discussions or support. If you would like additional help, you can move this to the Tomcat user mailing list. If you think about a specific issue, you can file a BZ,