On 14/07/2016 00:22, Christopher Schultz wrote: > Mark, > > On 7/11/16 4:40 PM, Mark Thomas wrote: >> This was triggered by a thread on the users list. [1] >> >> Tomcat does not, and hasn't as far back as at least 4.1.x, decoded the >> path provided in the call to getRequestDispatcher(path). >> >> I think this might be incorrect. My logic for this is as follows. >> >> The servlet spec is clear (see 9.1.1) that path can include a query string. >> >> The query string is delimited by '?'. >> >> '?' is a valid character in the path if it is encoded. >> >> Users may want to use '?'in the path. >> >> Therefore users need to be able to provide an encoded path. >> >> Therefore the RequestDispatcher needs to decode the path. >> >> >> Given how long this has been as it is, I'm worried that changing to >> decoding the paths will break something. If we agree that this does need >> to change, I think we'll need a configuration option to restore the >> "don't decode" behaviour. I'm thinking a context attribute as that can >> be set globally in conf/context.xml but over-ridden per Context if >> necessary. Defaults TBD. We can worry about those if we agree that the >> current behaviour is wrong. >> >> Thoughts? > > +1 on this change > > Just to be clear, this won't impact any existing code that does > something like the following: > > String target = "/foo/bar?a=b&c=d"; > request.getRequestDispatcher(target).forward(request, response); > > The only thing it might break was if someone tried to use a URL > containing a % sign that wasn't encoded: > > String target = "/foo/bar?percent=%&hash=#"; > request.getRequestDispatcher(target).forward(request, response); > > Right?
Right. > I think that case is quite rare, so I'm also +1 to introducing this new > behavior as the *default* with an option to revert back to the previous > behavior. I'm leaning that way too but I won't be in a position to do anything about it for a couple of weeks. That should be fine since that would be in time for the next monthly release cycle. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
