tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <hgo...@slib.fr>
Subject RE: TC 3.3: getRequestURI()
Date Fri, 28 Sep 2001 21:50:45 GMT
Ok for 2 :)

-
Henri Gomez                 ___[_]____
EMAIL : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-----Original Message-----
>From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
>Sent: Friday, September 28, 2001 10:49 AM
>To: 'tomcat-dev@jakarta.apache.org'
>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
>> >
>>
>

Mime
View raw message