Thanks! I'll take a look at the mod_jk C sources and see about submitting a patch. Thanks again for pointing out the problem. -Mike
----- Original Message ----- From: "Larry Isaacs" <[EMAIL PROTECTED]> To: "'Tomcat Developers List'" <[EMAIL PROTECTED]> Sent: Thursday, November 01, 2001 12:32 PM Subject: RE: Does anyone see anything wrong with this fix? > It isn't a matter of how the '*' is interpreted, but that > mod_jk will put a null terminator following the '*' if the > next character isn't a '.'. Thus: > > JkMount /*something ... > > and > > JkMount /* ... > > end up being equivalent. So far no one has found time to > add more sophisticated string matching. Feel free to > submit a patch, though this should be against mod_jk > in jakarta-tomcat-connectors. > > There was an earlier attempt in Tomcat 3.3 to have mod_jk > work with Handler directives in the httpd.conf. This would > allow Apache's pattern matching abilities to be used to > map requests to Tomcat. It wasn't feasible to finish this > approach, so it was removed from Tomcat 3.3. It may still > get implemented in the jakarta-tomcat-connectors version > of mod_jk, assuming a better approach doesn't present itself. > > Larry > > > -----Original Message----- > > From: Michael Jennings [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, November 01, 2001 3:14 PM > > To: Tomcat Developers List > > Subject: Re: Does anyone see anything wrong with this fix? > > > > > > Thanks for the feedback. > > > > So "/path/*.something" > > will handle URI's like "/path/sub1/sub2/file.something" > > "/path/sub1/sub2/anotherfilename.something" > > > > but "/path/*something" will NOT handle URI's like > > "/path/sub1/sub2/here_is_something" > > or > > "/path/moreofsomething" > > or > > "/path/sub1/sub2/sub3/something" > > > > So the asterisk can only be used in conjunction with a dot as in > > "*.something" as far as URI mapping is concerned? > > > > So the real wildcard sequence is actually "*." and "*xyz" is > > interpreted as > > "*"? > > > > Wouldn't it be better to make mod_jk deal with wildcards a > > little bit more > > intelligently, or am I missing something? (which is more likely) > > > > -Mike Jennings > > > > ----- Original Message ----- > > From: "Larry Isaacs" <[EMAIL PROTECTED]> > > To: "'Tomcat Developers List'" <[EMAIL PROTECTED]> > > Sent: Thursday, November 01, 2001 10:42 AM > > Subject: RE: Does anyone see anything wrong with this fix? > > > > > > > I believe mod_jk's JkMount currently only accepts mappings in the > > > form: > > > > > > JkMount /path/* > > > JkMount /path/*.ext > > > > > > Something like: > > > > > > JkMount /path/*something > > > > > > is another way of saying: > > > > > > JkMount /path/* > > > > > > which makes the other settings written irrelevant since all > > > requests will be mapped to Tomcat. See the: > > > > > > /* context based */ > > > asterisk[1] = '\0'; > > > > > > in jk_uri_worker_map.c file. > > > > > > Tomcat 3.3 deals with this by having the generated mod_jk.conf > > > use the "JkMount /path/*" approach by default. If you add > > > forwardAll="false" to the ApacheConfig line in server.xml, > > > it will write a mod_jk.conf similar to that of Tomcat 3.2.x, > > > but with additional mappings. These additional mappings for > > > the context will include one like the following: > > > > > > JkMount /examples/jsp/security/login/j_security_check ajp13 > > > > > > If you want "j_security_check" to work in Tomcat 3.2.x without > > > mapping all requests to Tomcat, you will need to add mappings > > > like this. It is beyond the scope of Tomcat 3.2.x development > > > to back port Tomcat 3.3's behavior to Tomcat 3.2.x. > > > > > > Cheers, > > > Larry > > > > > > > > > > -----Original Message----- > > > > From: Michael Jennings [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, November 01, 2001 12:35 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Does anyone see anything wrong with this fix? > > > > > > > > > > > > As far as I can tell, the following modification to the > > > > ApacheConfig.java class will > > > > enable form-based authentication to work for people using > > > > mod_jk.conf-auto > > > > with Apache. > > > > > > > > > > > > mod_jk needs to be told to handle requests of the form > > > > "/webapproot/somedir/j_security_check" > > > > > > > > since a login.jsp page (for form-based authentication) > > may exist at > > > > "/webapproot/somedir/login.jsp" and may specify "j_security_check" > > > > as the target of a form submission. In order for the > > > > form-based authentication > > > > machinery to work, it needs to get the POST request that > > is going to > > > > "/webapproot/somedir/j_security_check" > > > > which means that pattern has to be present in the mod_jk.conf-auto > > > > > > > > ie: the following line must be in the mod_jk configuration file: > > > > JkMount /webapproot/*j_security_check ajp12 > > > > > > > > Does anyone see any potential problems with this? > > > > > > > > -Mike Jennings > > > > > > > > Index: > > > > jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java > > > > > > =================================================================== > > > > RCS file: > > > > /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas > > > > k/Attic/ApacheConfig.java,v > > > > retrieving revision 1.12.2.2 > > > > diff -r1.12.2.2 ApacheConfig.java > > > > 202a203 > > > > > mod_jk.println("JkMount /*j_security_check ajp12"); > > > > 289a291 > > > > > mod_jk.println("JkMount " + path > > +"/*j_security_check ajp12"); > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
