tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Weinrich" <dwei...@home.com>
Subject [PATCH]: Bugrat report 723 ( unescaping/unencoding URLs ) was 'Re: 3.2.2 Release?'
Date Sat, 03 Feb 2001 07:18:30 GMT
  Thanks to everyone, that cleared things up quite a bit. Here is the patch
for bugrat report 723 ( tomcat 3.2.x not unescaping escaped urls ). The
patch is extremely short, and implemented a tiny bit different from the one
I sent in for 3.2.x a while ago, the unencoding is done before the path is
checked for other issues/security concerns to prevent unencoded stuff from
causing these after the fact.
  Note: I haven't yet mastered the art of Watchdog/internal tomcat tests so
this will need to be tested a bit more thoroughly. So far the following urls
work correctly:

http://localhost:8080/index%20%23%24.jsp
http://localhost:8080/index%20%23%24.html

corresponding to the following filenames in the ROOT webapp dir:

'index #$.jsp' and
'index #$.html'

If an error occurs in unencoding, null is returned which ends up sending a
Not Found(404) message instead of a stack trace. This seemed to be the most
sane way to handle the issue of improperly encoded urls. This is usually the
result of having a value after a % that isn't two hex digits or having an
unencoded % in the url like:

http://localhost:8080/index%%20%23%24.jsp or
http://localhost:8080/index%zz%23%24.jsp

One last remaining concern I have: the current implementation of RequestUtil
allows control characters to pass through without raising an exception, I am
assuming this could possibly raise problems, and is fairly undesired. If I
interpret http://www.ietf.org/rfc/rfc2396.txt correctly, control characters
should not be included in URLs. If it is agreeable, I will make a patch to
RequestUtil.URLDecode tomorrow to block characters in the ranges of 00-1f
and 7f-9f to prevent this from being a potential problem. Thanks again!


David

----- Original Message -----
From: "Marc Saegesser" <marc.saegesser@apropos.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Friday, February 02, 2001 12:44
Subject: RE: 3.2.2 Release?


> You are correct, tomcat_32 is the appropriate tag.  tomcat_32 is a branch
> tag so if you use cvs to check out jakarta-tomcat like
>
> cvs co -r tomcat_32 jakarta-tomcat
>
> then you'll get the latest version of all files on this branch.  This is
> referred to as the "tip" of the branch.
>
> The labels like tomcat_32_final and tomcat_321_final label a particular
> version of a file so the command
>
> cvs co -r tomcat_321_final jakarta-tomcat
>
> will retrieve the versions of all the files that make up the Tomcat 3.2.1
> release.
>
> The code that is (most likely) destined to become Tomcat 3.3 is the main
> branch of the repository, often referred to as the "HEAD".  To get this
code
> from cvs use a command like
>
> cvs co jakarta-tomcat
>
> When Tomcat 3.3 is released a new branch will be created called tomcat_33
> and this will form the basis for all bug fixes and patches for the 3.3
> release.  The HEAD will then become the code base for any new feature
> development of the 3.x repository.
>
> > -----Original Message-----
> > From: David Weinrich [mailto:dweinr1@home.com]
> > Sent: Friday, February 02, 2001 2:31 PM
> > To: Tomcat Dev List
> > Subject: Re: 3.2.2 Release?
> >
> >
> > On a somewhat unrelated note...
> >   I noticed a bugrat report this morning on an urlencoding that I had
> > submitted a patch for a little while back ( which was
flawed/incomplete ).
> > In the process of redoing the patch and grabbing the source from
> > cvs I came
> > up against this issue: what the heck tag is appropriate to use to submit
> > bugfixes against for the 3.2.x version of Tomcat? I am assuming that
> > tomcat_32 is the appropriate place but...
> >
> >
> >
> > ----- Original Message -----
> > From: "Marc Saegesser" <marc.saegesser@apropos.com>
> > To: <tomcat-dev@jakarta.apache.org>
> > Sent: Friday, February 02, 2001 11:04
> > Subject: RE: 3.2.2 Release?
> >
> >
> > > One thing I don't see listed here, and is the biggest reason I
> > don't think
> > I
> > > have the time to manage the release, is determining what bugs
> > still exist
> > in
> > > the tomcat_32 branch and which of those, if any, should be fixed
before
> > > releasing 3.2.2.  This was an issue that Jon raised regarding the 3.3
> > > release plan.  What is the feeling of the Tomcat development
community?
> > Can
> > > we get away with just releasing the tip of tomcat_32 as-is or
> > would such a
> > > release *require* a complete review of open bugs and should the
> > release be
> > > held until these bugs are all addressed.
> > >
> > > I've been trying to make just such a review but it has been very time
> > > consuming.  Maybe, since this is just a minor point release to
> > an existing
> > > product, we can go with what we have.
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
>


Mime
View raw message