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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]]
> > 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" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > 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: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
fileutil.patch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
