Remy Maucherat wrote:
Mark Thomas wrote:
As I see it, we have two options:
a) Prevent Tomcat from decoding the uri a second time at step 7 above
b) Re-encode the uri in mod_jk between steps 5 and 6
I think:
- it's the proxy which should have options for adapting to what the
proxied server does
- mod_jk is supposed to be a transparent proxy (and as such give Tomcat
a non decoded uri); despite what it could break in httpd, decoding the
uri at all is evil, since the character encoding used could be different
from the one used in Tomcat
So I am not in favor of a).
Agreed.
I mean the sole purpose of having a proxy in front of Tomcat
is that this proxy actually *does* something, weather its a
static content delivery, uri rewriting, load balancing, security,
its irrelevant. The uri as well as the entire request thus might
end up completely different then the one client originally issued.
It might have a different uri, different headers, etc.
However options a) and b) that Mark gave have nothing to do
with what we actually need and what was the actual problem.
The sole problem was how to prevent unwanted mappings,
and 1.2.23 solved that by passing the original client
uri thus skipping the entire httpd filter chain.
This is very bad and doesn't solve the problem, because if the
user needs thing like mod_rewrite he will need to re-enable
the original 'JkOptions ForwardURICompat' making him again
vulnerable to the CVE-2007-1860.
My patch (again does *not* double encode the uri) on the other
hand simply has a smarter JkMount detection and prevents the
requests to the Tomcat that were not explicitly defined.
The uri passed is the same one that was passed as default for
so many years.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
