tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Creighton Kirkendall <ckirkend...@hobsons-us.com>
Subject RE: Problem with URLPatternMatcher
Date Mon, 25 Jun 2001 21:54:40 GMT
Well, I was but noticed it had this problem.  I did fix the code, however I
am not sure whether or not I am going to use it.  I do need a URLMatcher.
If you have any suggestions as to a fast one that would be great.  What is
tomcat using to do its security path constraint matching now.

Creighton


-----Original Message-----
From: Marc Saegesser [mailto:marc.saegesser@apropos.com]
Sent: Monday, June 25, 2001 5:47 PM
To: tomcat-dev@jakarta.apache.org
Subject: RE: Problem with URLPatternMatcher


Yep, it looks like this code is broken, but it isn't actually used anywhere
within Tomcat.  In fact it has been removed in 3.3.  Are you trying ot use
this class directly in your code?

> -----Original Message-----
> From: Creighton Kirkendall [mailto:ckirkendall@hobsons-us.com]
> Sent: Monday, June 25, 2001 8:57 AM
> To: 'tomcat-dev@jakarta.apache.org'
> Subject: Problem with URLPatternMatcher
>
>
> I have noticed that there is a problem in URLPatternMatcher.  It
> seems that
> in the match function we do not update the length. This is a
> problem because
> it causes the pattern matcher not to return the longest pattern.
> I noticed
> this some time ago but thought it was fixed in latter releases
> but it turns
> out it is still a problem in 3.2.2.  I have included the source
> with the fix
> in this email.
>
>
>  * <http://www.apache.org/>.
>  *
>  * [Additional notices, if required by prior licensing conditions]
>  *
>  */
>
> package org.apache.tomcat.util.pattern;
>
> import java.util.Enumeration;
>
> /**
>  * A form of pattern matching for URLs in which the object corresponding
>  * to the longest matching pattern is returned.
>  *
>  * @author Harish Prabandham
>  */
> public class URLPatternMatcher implements PatternMatcher {
>     private ImplicationTable itable = new ImplicationTable();
>
>     public URLPatternMatcher() {
>     }
>
>     public void set(String pattern, Object value) {
>         itable.put(new WildcardPattern(pattern), value);
>     }
>
>     public void remove(String pattern) {
>         itable.remove(pattern);
>     }
>
>     public Object match(String key) {
>         // Since we want the longest pattern match, we cannot use the
>         // itable.get(key)...
>         int len =0;
>         Object val = null;
>
>         for(Enumeration e = itable.keys(key); e.hasMoreElements(); ){
>             Object thiskey = e.nextElement();
>             String pattern = thiskey.toString();
>             if(pattern.length() > len){
>                 val = itable.getValue(thiskey);
>
> 		    /*********************
> 		     *Update 6-25-001
> 		     *********************/
> 			len=pattern.length();
> 		}
>         }
>
>         return val;
>     }
>
>     public static void main(String[] args) {
>         PatternMatcher p = new URLPatternMatcher();
>         try {
>             p.set("*", "default");
>             p.set(args[0], "works");
>             System.out.println("Match: " + p.match(args[1]));
>         }catch(Exception e) {
>             e.printStackTrace();
>         }
>     }
> }
>
>
>
> Creighton Kirkendall
> Senior Software Engineer
> Hobsons
> ckirkendall@hobsons-us.com
>
>
>
> -----Original Message-----
> From: kevin seguin [mailto:seguin@motive.com]
> Sent: Monday, June 25, 2001 9:36 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: cvs commit:
> jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33Ajp14Intercepto
> r.java
>
>
> cmanolache@yahoo.com wrote:
> >
> > On Sun, 24 Jun 2001, kevin seguin wrote:
> >
> > > i've been thinking about this, and, well, isn't this
> BaseRequest you're
> > > talking about kind of what org.apache.coyote.Request is?  does it make
> > > sense to have two of these kinds of objects hanging around?  is
> > > o.a.c.Request roughly equivalent to core.Request in tomcat 3??
> >
> > Certainly not for the second part - the core.Request in tomcat3
> has a lot
> > of tomcat3-specific code ( Container, ContextManager, calls to hooks to
> > get special info like encoding, etc ).
> >
> > The BaseRequest ( or o.a.c.Request ) is focused on the
> > "basic" information associated with a request, as received by
> the protocol
> > adapter.
> >
> > For the first part - that's true, AjpRequest is very similar in
> goal with
> > o.a.c.Request ( thanks to the refactoring you did :-).
> >
> > As I said, I like o.a.coyote, but right now my goal is to see Ajp14
> > working, and using the existing (working) AjpRequest is easier. Also,
> > coyote has more than the base request - I would let this settle down.
> >
>
> i hear that :)  my immediate goal is ajp13 for tomcat 4 :)  i've checked
> in an intial version of BaseRequest.  it may need some further work...
>
> -kevin.

Mime
View raw message