Look, what I'm saying is that we should simplify all the JkOptions ForwardURI* . IMHO they all originate from the fact that uri in the Apache can come from multiple pre-processing stages that modify the original URI. The solution is very simple but it would require that we write the URI decoder. When the uri comes to the mod_jk before doing any mapping or anything else we should decode that uri and then use it, and send that uri to the Tomcat (the one we rewrote).
OK Mladen, I understand that, but I think it's not correct. I read the discussion threads from 2001 which let to those options and they come from the fact, that different Tomcat version handle the forwarded URIs in different ways. I think this part of the discussion is in fact only historic and yes I agree we don't actually need those options any more.
But: none of the existing options does the right thing. That's why I suggested another way of handling the forward. I think my sugeggested variant "forward r->uri with encoded '%'" is the right way of handling it.
And no: I don't think we need our own decoder. Apache http decoder is OK (as long as we talk about httpd). It does nothing wrong. For instance it would be very bad to instead decode iteratively until not more '%' are in the URL, that's definitely wrong.
Decoding and forwarding the result to Tomcat is exactly our default until 1.2.22 and produces the security problem. There's nothing wrong with the decoder, only with decoding two times, once in mod_jk and a second time in Tomcat.
Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
