[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.
While risking to confuse the whole thing even more by my
misunderstanding, this is the chain of events as I understand it:
- original URI from the browser (in whichever form, out of server
control)
- decoded URI by Apache (in order to avoid security problems)
- encoded URI by mod_jk (this introduces %3b and doesn't match the
original URI)
- encoded URI goes into Tomcat
> 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)
Although TC 3.3 is not supposed to be 2.3 spec compliant but rather 2.2
complaint (which doesn't mention this explicitly), what is considered
'original' might be the question to ask. Is it:
- as coming from the browser
- as coming into Tomcat
If the answer is 'as coming into Tomcat', then I'd say option 3 would be
a pretty safe bet.
Bojan
