Re: Does anyone see anything wrong with this fix?
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] > > >
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/so
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]>
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:
For additional commands, e-mail:
