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.
DecodeInterceptor.diff
