What I get for trying to do this on a computer without javac installed.
Diff file with typos fixed and exceptions handled.
----- Original Message -----
From: "Bill Barker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Bill Barker"
<[EMAIL PROTECTED]>
Sent: Sunday, September 30, 2001 12:40 AM
Subject: Re: Volunteers for: - RE: TC 3.3: getRequestURI()
> Actually, my original was a straight java.net.URLEncode after stripping
out
> the session id. However, I'm easy. Attached is using UEncoder (which I
> initially felt was too expensive).
>
> I'm starting to come around to your original idea however. This is better
> done in the Facade (where there is zero hit for pages that don't ask for
> RequestURI). Currently, nobody uses unparsedURI, and it is arguably a
> protocol violation if a servlet serves different pages for equivalent URIs
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Bill Barker"
> <[EMAIL PROTECTED]>
> Sent: Sunday, September 30, 2001 1:23 AM
> Subject: Re: Volunteers for: - RE: TC 3.3: getRequestURI()
>
>
> > On Sat, 29 Sep 2001, Bill Barker wrote:
> >
> > > It seems that I must have been bad in a past life, since my Karma
isn't
> high
> > > enough.:)
> > >
> > > I've added the code to re-encode the URL to DecodeInterceptor on my
> machine.
> > > If you want it right away, I can post a diff.
> >
> > Hi,
> >
> > Could you send the diff, I'll have to merge it with my changes anyway...
> > ( I hope you found UEncoder and used it, because that's what I did ).
> >
> > I am now thinking about how to encode the context path - which is more
> > difficult than I tought.
> >
> > The problem is of course that we don't know the charset in many cases,
and
> > Context.getPath() returns the UTF version. If we encode this - it may be
> > inconsistent with the original request encoding.
> >
> > So I'll try to count the '/' and return a substring of the uri - I can't
> > think of any better way.
> >
> > Of course, I have no idea why the contextPath has to be encoded - poor
> > people using the contextPath as a key will have a bad surprise since you
> > can have multiple representations for the same context ( based on the
> > charset of the request ), but as usual we ( 8859_1 uses ) are ok.
> >
> > I can leave this the way it is, as it makes more sense ( and 2.2 doesn't
> > seem to require the context path to be encoded) - and wait until 4.0
fixes
> > that ( beeing consistent with 2.3 doesn't seem a good idea in this
case ).
> > I'm not sure, need to look deeper at the specs and impl.
> >
> > Costin
> >
> >
> >
> >
> > > ----- Original Message -----
> > > From: <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Friday, September 28, 2001 11:17 AM
> > > Subject: Volunteers for: - RE: TC 3.3: getRequestURI()
> > >
> > >
> > > >
> > > > It seems most agree on using 'decoded' URI in mod_jk. Making the
> change
> > > > is not easy, there are few places where we need to coordinate and
make
> > > > sure we're on the same page.
> > > >
> > > > I don't think I can do this alone ( if it sounded like I volunteer
to
> fix
> > > > it - well, I need help ).
> > > >
> > > > Problems:
> > > > - Someone with IIS must cut&paste the decoding stuff from Apache (
> > > > probably in jk/common ), make sure the uri sent is decoded ( so
> consistent
> > > > with Apache and NES ). That should happen in j-t and j-t-c ( with
this
> > > > ocasion we'll help Marc a bit :-)
> > > >
> > > > - One piece is to implement the java side of the decoding. I can do
> that
> > > > if nobody else wants ( I have few other bugs in work, so I'll
probably
> do
> > > > it tommorow ).
> > > >
> > > > - I'll fix DecodeInterceptor to avoid double decoding ( I'm already
> fixing
> > > > the normalization for JNI ).
> > > >
> > > > - Someone should check 4.0. Strange, even if this is a 2.3
requirement
> I
> > > > didn't see any comment so far... Well, they have cool features and
> jars to
> > > > add, so I can do that if nobody else does.
> > > >
> > > > - Revert jk/apache to use uri, remove the encode call ( again, j-t
and
> > > > j-t-c - one more week to do that, after that we'll be j-t-c only ).
> Henri
> > > > - could you do this and the next one ?
> > > >
> > > > - Build and make some jars available - so we can test.
> > > >
> > > > - Test.
> > > >
> > > > Yes, it's a long list - but at the end we might solve one of the
> trickiest
> > > > problems.
> > > >
> > > > Costin
> > > >
> > > >
> > > >
> > > > > >2. mod_jk will send the 'decoded' URI ( %xx replaced with the
real
> > > > > >char ).
> > > > > >
> > > > > >On IIS - we need to decode the URI, Apache+NES - nothing to do.
> > > > > >On java side - we do a 'canonical' encoding in the facade. All
> > > > > >the code will operate on the decoded request ( this is what
> > > > > >Apache and NES are doing ). We also need to prevent
> DecodeInterceptor
> > > > > >to re-decode the URIs from jk. ( that's trivial, just a flag )
> > > > > >
> > > > > >Benefits:
> > > > > >- consistency with Apache, all processing on decoded uris.
> > > > > >- easier to maintain ( java :-)
> > > > > >- important - servlets will get a consistently encoded uri,
> > > > > >thus preventing many security problems. With the current code
> > > > > >many tricks can be played ( see recent security problems in
> > > > > >tomcat ) using encoding - if we were vulnerable to that,
> > > > > >I suspect most servlet authors will be as well.
> > > > > >
> > > > > >Problems:
> > > > > >- a bit more work to do.
> > > > > >- the 'original' uri will not be preserved in any servers (
> > > > > >the first solution allows that for IIS and standalone ).
> > > > > >
> > > > > >
> > > > > >Your votes please, I'm ok with any of them ( with a slight
> > > > > >preference to 2 )
> > > > > >
> > > > > >Costin
> > > > > >
> > > > > >
> > > > > >On Thu, 27 Sep 2001, Larry Isaacs wrote:
> > > > > >
> > > > > >>
> > > > > >>
> > > > > >> > -----Original Message-----
> > > > > >> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > > > >> > Sent: Thursday, September 27, 2001 3:10 AM
> > > > > >> > To: [EMAIL PROTECTED]
> > > > > >> > Subject: RE: TC 3.3: getRequestURI()
> > > > > >> >
> > > > > >> >
> > > > > >> > Given this is an important change - and something will be
> broken
> > > > > >> > regardless of what we do - I think we need to coordinate
> > > > > >and make sure
> > > > > >> > we're doing it right.
> > > > > >> >
> > > > > >> > - First: Larry - what do you think ? We just had RC1, and we
> > > > > >> > have already
> > > > > >> > a simple patch ( changing SessionId to hide the problem ).
> > > > > >My proposal
> > > > > >> > is simple to implement ( just encode the URI on the facade,
and
> use
> > > > > >> > only decoded URIs internally ), but it is braking some of the
> 2.3
> > > > > >> > clarifications ( not mandatory for 2.2, of course, but
> important )
> > > > > >>
> > > > > >> I'm leaning towards your encode in facade solution. I'm
> > > > > >curious about
> > > > > >> the 2.3 clarifications you are referring to beyond the URI
being
> the
> > > > > >> "original".
> > > > > >>
> > > > > >> >
> > > > > >> > - Someone with access to NES and/or IIS, could you please
> verify
> > > > > >> > if the requestUri variable in NSAPI/ISAPI is encoded or
> > > > > >not ? Neither
> > > > > >> > of them seems to provide the choice between unencoded_uri and
> uri,
> > > > > >> > so whatever they provide is the only thing we can use.
> > > > > >>
> > > > > >> I can try IIS easily enough. I'll also try to get NES running
> and
> > > > > >> see if I can determine this one too. I'll need to do this at
> home,
> > > > > >> so I'll report my results tonight.
> > > > > >>
> > > > > >> Larry
> > > > > >>
> > > > > >> >
> > > > > >> > I think the result of the test with IIS/NES is essential
> > > > > >to resolving
> > > > > >> > this problem once and for all. If the URI they provide is the
> > > > > >> > 'original/or
> > > > > >> > encoded' - that's what we should use on Apache side.
> > > > > >> >
> > > > > >> > If not ( and the URI is decoded ) - that means the 'original
> uri'
> > > > > >> > is un-implementable, and we shouldn't worry about it anymore,
> and
> > > > > >> > using the decoded URI consistently is the best solution.
> > > > > >> >
> > > > > >> >
> > > > > >> > Please, (I know there aren't too many windows user around
:-),
> > > > > >> > could someone check this ?
> > > > > >> >
> > > > > >> > Costin
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > *----*
> > >
> > > This message is intended only for the use of the person(s) listed
above
> > > as the intended recipient(s), and may contain information that is
> > > PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
> > > you may not read, copy, or distribute this message or any attachment.
> > > If you received this communication in error, please notify us
> immediately
> > > by e-mail and then delete all copies of this message and any
> attachments.
> > >
> > >
> > > In addition you should be aware that ordinary (unencrypted) e-mail
sent
> > > through the Internet is not secure. Do not send confidential or
> sensitive
> > > information, such as social security numbers, account numbers,
personal
> > > identification numbers and passwords, to us via ordinary (unencrypted)
> > > e-mail.
> > >
> >
> >
>
>
> *----*
>
> This message is intended only for the use of the person(s) listed above
> as the intended recipient(s), and may contain information that is
> PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
> you may not read, copy, or distribute this message or any attachment.
> If you received this communication in error, please notify us immediately
> by e-mail and then delete all copies of this message and any attachments.
>
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent
> through the Internet is not secure. Do not send confidential or sensitive
> information, such as social security numbers, account numbers, personal
> identification numbers and passwords, to us via ordinary (unencrypted)
> e-mail.
*----*
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately
by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
DecodeInterceptor.diff
