You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Craig R. McClanahan" <Cr...@eng.sun.com> on 2000/09/18 06:17:09 UTC
Re: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util
RequestUtil.java
Geoff Soutter wrote:
> Craig,
>
> FYI, this method is actually buggy, it doesn't follow the decoding rules for
> URLs set down in the RFCs. From memory, I think it it decodes +'s in URLs
> before the ?, which is a no-no.
>
In this particular patch, I'm only applying it to the "name" and "value" that
has been parsed out already -- the entire request URI is no longer decoded as a
unit. Thus, I don't think there's a problem with how it's being used here. Are
there any case where this new code misbehaves?
Craig
>
> Cheers
>
> Geoff
>
> ----- Original Message -----
> From: <cr...@locus.apache.org>
> To: <ja...@apache.org>
> Sent: Sunday, September 17, 2000 11:11 AM
> Subject: cvs commit:
> jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util
> RequestUtil.java
>
> > craigmcc 00/09/16 18:11:38
> >
> > Modified: catalina/src/share/org/apache/catalina/util
> RequestUtil.java
> > Log:
> > Put the try/catch blocks around URLDecoder.decode() calls back -- the
> Sun
> > JDK compiler complains about not catching Exception otherwise, because
> > "throws Exception" is in the method declaration. However, this time use
> > Throwable as the thing to be caught, so that Jikes won't complain
> either.
> >
> > Revision Changes Path
> > 1.7 +14 -6
> jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.j
> ava
> >
> > Index: RequestUtil.java
> > ===================================================================
> > RCS file:
> /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/Req
> uestUtil.java,v
> > retrieving revision 1.6
> > retrieving revision 1.7
> > diff -u -r1.6 -r1.7
> > --- RequestUtil.java 2000/09/16 23:57:06 1.6
> > +++ RequestUtil.java 2000/09/17 01:11:37 1.7
> > @@ -1,7 +1,7 @@
> > /*
> > - * $Header:
> /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/Req
> uestUtil.java,v 1.6 2000/09/16 23:57:06 stefano Exp $
> > - * $Revision: 1.6 $
> > - * $Date: 2000/09/16 23:57:06 $
> > + * $Header:
> /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/Req
> uestUtil.java,v 1.7 2000/09/17 01:11:37 craigmcc Exp $
> > + * $Revision: 1.7 $
> > + * $Date: 2000/09/17 01:11:37 $
> > *
> > * ====================================================================
> > *
> > @@ -79,7 +79,7 @@
> > * General purpose request parsing and encoding utility methods.
> > *
> > * @author Craig R. McClanahan
> > - * @version $Revision: 1.6 $ $Date: 2000/09/16 23:57:06 $
> > + * @version $Revision: 1.7 $ $Date: 2000/09/17 01:11:37 $
> > */
> >
> > public final class RequestUtil {
> > @@ -259,10 +259,18 @@
> >
> > // Decode the name and value if required
> > if ((name.indexOf('%') >= 0) || (name.indexOf('+') >= 0)) {
> > - name = URLDecoder.decode(name);
> > + try {
> > + name = URLDecoder.decode(name);
> > + } catch (Throwable t) {
> > + ;
> > + }
> > }
> > if ((value.indexOf('%') >= 0) || (value.indexOf('+') >= 0))
> {
> > - value = URLDecoder.decode(value);
> > + try {
> > + value = URLDecoder.decode(value);
> > + } catch (Throwable t) {
> > + ;
> > + }
> > }
> >
> > // Create or update the array of values for this name
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util
RequestUtil.java
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Geoff Soutter wrote:
> "Craig R. McClanahan" <Cr...@eng.sun.com> wrote:
> > Geoff Soutter wrote:
> >
> > > Craig,
> > >
> > > FYI, this method is actually buggy, it doesn't follow the decoding rules
> for
> > > URLs set down in the RFCs. From memory, I think it it decodes +'s in
> URLs
> > > before the ?, which is a no-no.
> > >
> >
> > In this particular patch, I'm only applying it to the "name" and "value"
> that
> > has been parsed out already -- the entire request URI is no longer decoded
> as a
> > unit. Thus, I don't think there's a problem with how it's being used
> here. Are
> > there any case where this new code misbehaves?
>
> Ah, sorry, I was thinking you'd just cut and pasted the 3.3 version of this
> method/class. I had a look properly and it looks fine...
>
As our London hosts for ApacheCon Europe would say it, "not bloody likely" :-)
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util RequestUtil.java
Posted by Geoff Soutter <ge...@whitewolf.com.au>.
"Craig R. McClanahan" <Cr...@eng.sun.com> wrote:
> Geoff Soutter wrote:
>
> > Craig,
> >
> > FYI, this method is actually buggy, it doesn't follow the decoding rules
for
> > URLs set down in the RFCs. From memory, I think it it decodes +'s in
URLs
> > before the ?, which is a no-no.
> >
>
> In this particular patch, I'm only applying it to the "name" and "value"
that
> has been parsed out already -- the entire request URI is no longer decoded
as a
> unit. Thus, I don't think there's a problem with how it's being used
here. Are
> there any case where this new code misbehaves?
Ah, sorry, I was thinking you'd just cut and pasted the 3.3 version of this
method/class. I had a look properly and it looks fine...
You might add a comment to URLDecode to indicate that it's not useful in a
general sense just in case someone was thinking of using for that in the
future sometime ...? :-)
Cheers
Geoff