On 08/08/2016 21:25, Wang, Andy wrote: > On Thu, 2016-07-14 at 21:11 +0200, Mark Thomas wrote: >>> 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. > > We just ran into the problem this was intended to fix, and I'm trying > to understand the impact of the fix. > > So with the fix in place and the behavior as default, any url with a > standalone % in it would break.
Yes. > With the default behavior disabled, the RequestDispatcher would not > decode the provided path, correct? Yes. > There is no scenario where both a standalone % and the > requestdispatcher decoding the provided path would both be possible? Correct. Decoding the path means any % is treated as the start of a %nn sequence. Standalone % would need to be encoded as %25 Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
