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]

Reply via email to