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
The problem with b) is that we can't easily tell what characters were
previously encoded and need to be re-encoded. b) is also inefficient.
Doesn't this mean a) is really the only option?
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).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]