On Wed, Jan 22, 2025 at 3:11 PM Mark Thomas <ma...@apache.org> wrote: > > As a result of a user request, I am looking at Tomcat's handling of %2f > (encoded '/') and %5c (encoded '\'). > > I have already added a new attribute (encodedReverseSolidusHandling) to > the Connector to align options for %5c handling with options for %2f > handling. > > I am now looking at the RequestDispatcher. > > Some time ago, the RequestDispatcher switched to expect an encoded path. > The reasoning for this was that the path could contain a query string so > it would have to be encoded to differentiate between a '?' in the path > and the query string delimiter. > > I am now reviewing the code in ApplicationContext.getRequestDispatcher() > > While the code comments state that the processing is in the same order > as InputBuffer/CoyoteAdapter it isn't. That order is: > - remove query string > - remove path parameters > - decode > - normalize > > In getRequestDispatcher() the order is > - remove query string > - remove path parameters > - normalize > - decode > - normalize and check nothing changes > > I have been trying to work out why this is different. The comments > indicate the second normalize is making sure no /../ sequences appear > after decoding. > > Given that applications control the path that is passed to > getRequestDispatcher(), I don't currently see what this check is > intended to achieve. Anything this checks stops the application doing > could be achieved by moving the first decode to before normalize and > dropping the second normalize. > > Can anyone see a reason not to move the first decode to before normalize > and drop the second normalize?
Yes, I don't see any reason to not do that. > With that change implemented the next step would be to add > encodedReverseSolidusHandling and encodedSolidusHandling options to the > Context (there is no way to determine which Connector is in use for the > request that is calling getRequestDispatcher()) and use them to control > the decoding. +1, let's try that then. Rémy > Thanks, > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
