On 12/07/2016 11:11, Vincent Massol wrote: > Hi Mark, > > I’ve seen your mail on the devs list. IMO you have only 2 choices:
You are welcome to comment on the dev list thread. > * Option 1: decode the path passed to RD > * Option 2: revert the changes brought by > http://svn.apache.org/viewvc?view=revision&revision=1741019 and > http://svn.apache.org/viewvc?view=revision&revision=1741024 (or at least part > of it) so that the path passed to RD is not encoded (i.e. same as before). > > Any other choice will result in Tomcat having an important regression > compared to before and XWiki won’t be able to use those new Tomcat versions > (and I suspect a lot of others webapps will be in the same situations). > > Now I understand the problem with option 1. Users who were passing undecoded > paths to RD will get broken too. However if they were doing since Tomcat was > not encoding the path, I believe that they would have resulted in invalid > URLs generated by the forward(), no? So maybe it’s not an issue after all. Option 2 isn't going to happen. That would be a clear breach of the Servlet spec. My guess is that we'll implement option 1 but make the behaviour configurable. Defaults TBD, possibly varying by version. It is worth keeping in mind that decoding the path is not the same as requiring it to be encoded. If you decode "/foo bar" and "/foo%20bar" you end up with the same result. This should reduce the risk of application breakage if the default becomes to decode the path. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
