Thanks. The restored mod_jk behavior is the same as Tomcat 3.3.x with <DecodeInterceptor ... safe="true"/>, the default. Unsafe escapes give 403's. We can add a similar option to mod_jk to turn off the checking. Though, I can't image a situation where it would make sense to accept the risks to gain access to these escapes.
Cheers, Larry > -----Original Message----- > From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 05, 2003 5:02 PM > To: 'Tomcat Developers List' > Subject: RE: cvs commit: > jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c > > > Larry, > > > > > I wouldn't see it as a step forward where we increase > > the vulnerability of the majority, and the effort needed > > to deal with that, in favor of satisfying a small minority > > that insist on using inherently unsafe escape sequences. > > > > Maybe this new behavior should be an option like it is in > > Tomcat 3.3.x. The default is to err on the side of safety. > > Operating in this less safe envrionment could be specifically > > requested via an option, and the user is responsible for > > dealing with the impact. How does that sound? > > > > Ok, no problem, but there must be a middle ground. > > Perhaps the tests (jk_req_util.c/jk_requtil_unescapeUrl) now > overreact a > bit, maybe we can tone down the code, just now it barfs on > any embedded > '/' %2F, tomcat deals without problems with this issues, and > later there > is an agressive uri filtering on ./ and combinations.. maybe is better > to let this pass without problems to tc, and let tomcat deal with it.. > tested and it works very well.. > > How about this way? > > In the mean time i'll revert the change.. > > Saludos, > Ignacio J. Ortega > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
