[EMAIL PROTECTED] wrote:
>
> On Wed, 26 Sep 2001, Keith Wannamaker wrote:
>
> > 0x3b = ';'. Ignacio is right, SessionID doesn't remove the id
> > because it is not expecting ; to be encoded. So now it shows
> > up in the URI and has the side effect of breaking sessions
> > that depend on url rewriting. But, the spec does say the URL
> > should be encoded, so I'd rather fix SessionID with this patch.
> >
> > However, are there other places where TC is manipulating the
> > URL and assuming it is unencoded?
>
> I'm not sure this is the right solution ( but it's a good patch:-).
>
> The 'original' URI included a ';' - which is a valid
> character used in the right way. It shouldn't be encoded by
> mod_jk - the whole reason for encoding is to try to reproduce
> the original URI or something equivalent.
>
> The only use for %3B is to allow the user to specify
> some path-info ( or other path components ) that include the
> ';' character. In a URI ';' is used to pass additional
> informations about the path ( and it seems it can be attached
> to any path component ) - I never saw any server to use
> this feature.
>
> Well, we have a big nightmare here - and probably the only
> way out is to find some consistent ( and implementable )
> interpretation of the involved specs and stick with that.
>
> The encoded URI is used only to satisfy the servlet spec -
> and re-encoding the URI is an imperfect workaround.
>
> We have few choices:
>
> 1. revert to the use of unencoded_uri.
> Problems:
> - what about IIS and NES, where this is not available ?
> - what about integrating with apache, where the decoded
> uri is used for everything ( that means any attempt to
> authenticate using apache modules may create huge problems)
>
> 2. Use a different encoding function, that doesn't
> encode ';'.
> Problems:
> - encoding/decoding will result in a different URI
> ( thus the servlet spec will not be happy )
> - inconsistency between tomcat standalone and tomcat+server
>
> 3. Revert to the use of uri ( i.e. the decoded uri ), and
> change the getRequestURI ( the facade ) to generated a
> 'canonical' encoding.
> Problems:
> - again it'll not be the 'original' as required by servlet
> ( but at least this will be consistent across servers)
>
> Using 'unencoded' URIs is a huge source of security problems -
> the server and container _must_ use decoded URIs internally,
> because otherwise security constraints would be useless.
>
> On the other side, servlets that are doing any matching
> on 'unencoded' URIs are likely to be tricked easily by
> encoding tricks. So if a user is doing any security check,
> he'll likely repeat all our bugs.
>
> Using a 'canonical' encoding ( where only the chars that
> are required to be encoded are encoded ) has the benefit
> that gives a consistent output.
>
> My preference would be to do (3).
Mine also.
>
> Costin
