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?
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.
Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
