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? 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. -chris
signature.asc
Description: OpenPGP digital signature
