tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: TC 3.3: getRequestURI()
Date Fri, 28 Sep 2001 18:08:52 GMT
+1 for option 2.  It's always been my feeling that mod_jk (at least in it's
current form) is closer to a proxy than part of the Servlet Container.
----- Original Message -----
From: <cmanolache@yahoo.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Friday, September 28, 2001 1:48 AM
Subject: RE: TC 3.3: getRequestURI()


> Based on Larry's comments, thinks are even more interesting...
>
> - IIS: provides the original 'escaped' URI.
>
> - NES: decodes the request, no way to get the unescaped URI
>
> - Apache: both, but if we're using the original URI we lose any chance
> of integration ( since all apache modules are operating on the
> decoded request ).
>
> IMHO that means the 'original uri' is out of question. It is not
> implementable, we should stop worrying about it.
>
> I'll start working on the re-encoding ( apache seems to be doing
> exactly that when creating the CGI variable ).
>
> We can do in mod_jk ( and use it on NES and Apache ), or we
> can do it in facade.
>
> Please state your option, and if you can help on any part.
>
> 1. mod_jk will send 'escaped' URIs ( containing %xx ).
>
> On IIS - we do nothing, on Apache + NES we escape the decoded uri,
> using a new function in mod_jk. On the java side we do  nothing -
> the current code is saving the escaped URI for use by facade, and
> it'll re-decode the URI as part of normal processing.
>
> Benefits:
> - probably the easiest to implement ( minimal effort ), just
> a C function, cut&paste from apache with a single change to preserve
> ';'.
> - one server ( IIS ) will implement the spec corectly
>
> Problems:
> - the uri will be decoded/encoded/decoded for apache/nes.
> - ???
>
> 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: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > > Sent: Thursday, September 27, 2001 3:10 AM
> > > To: tomcat-dev@jakarta.apache.org
> > > 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. 

Mime
View raw message