"Rainer Jung" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Jean-Frederic wrote: >> On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote: >>> Before I answer, let me first ask a question: What's wrong withg my >>> suggestion? >> >> Well thinking to it I am not very happy with the change: >> +++ >> -#define JK_OPT_FWDURIDEFAULT JK_OPT_FWDURICOMPATUNPARSED >> +#define JK_OPT_FWDURIDEFAULT JK_OPT_FWDURIESCAPEDMINIMAL >> +++ >> Because that is what the SPEC's says. > > The Servlet SPEC says, that the web container should not decode > RequestURI. So if the reverse proxy tries to come close to this > requirement, it needs to send the URI as unencoded as it can. > > Now the reverse proxy should have the ability to modify the URI (in the > sense of mod_rewrite). If we accept, that mod_rewrite in httpd 1.3-2.2 is > only able to operate on the decoded URI, we have no chance of making this > interoperable with forwarding the original undecoded URI. >
Yes, RFC 2616 permits *any* intermediate proxy to alter the URI in *any* way before passing it on. So to be meaningful, the Servlet spec requirement can only apply to the URI that TC receives from the last proxy in the chain. > Using the encoding from mod_proxy_ajp we at least try to produce a URI > which is as close to the original one, as we can achieve. At least > logically the new URI is fine. > > All in all I think that "compat unparsed" will result in more user > problems as default then the new proposed way. > > The whole discussion is: > > 1) At the moment all options have a problem (mod_rewrite, sessions, > security) > > 2) My proposal should be checked if it is secure. If so, it fixes > mod_rewrite, sessions and security. This seems to have some value. If you > (community) agree on that value, I find it correct to add this option. The > answers might depend on > > - encode only '%' > - encode '%' and '+' (easy, performing, but needs some thinking about > correctness) We pass the original query string to TC, so there is no point in worrying about '+' (since it only means ' ' in the qs). > - encode like in mod_proxy_ajp (not as performing but more complete) > > 3) Yes, it will influence how well the container can obey the spec (as two > of the three existing options also do). So we could discuss, if the value > is huge enough, that we make it the default (and thus need no more > explicit option name), or we keep "compat unparsed" the default and add a > new option. > > Regards, > > Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
