Mark, When I'm talking about path parameters, it is in the context of how Open API/Swagger defined them: https://swagger.io/docs/specification/v3_0/describing-parameters/
The OS is AWS Linux running in a Docker container. On Fri, Jan 17, 2025, 3:52 AM Mark Thomas <ma...@apache.org> wrote: > James, > > A comment and a question. > > You are talking about the servlet path here. Path parameters are > something different > (.../path-segment;path-param-name=path-param-value/...) > > Which operating system are you using? > > Mark > > > > 16 Jan 2025 15:38:50 James Matlik <james.mat...@gmail.com>: > > > Thank you for responding, Chris. > > > > An example URL that causes this issue has a format like the following: > > http://localhost:8080/group/{groupName} > > > > A URL like this works just fine and is able to set the groupName to > > "(ON/QC) LOCAL": > > http://localhost:8080/group/%28ON%2FQC%29%20LOCAL > > When I call `request.getServletPath()` it returns "/group/(ON%2FQC) > > LOCAL" > > > > However, this does not work when the '\' character exists. For example, > > when expecting the groupName to be set to "(ON\QC) LOCAL": > > http://localhost:8080/group/%28ON%5CQC%29%20LOCAL > > When I call `request.getServletPath()` it returns "/group/(ON/QC) > > LOCAL". > > This splits the path parameter in 2, causing my application to return a > > 404. > > I would prefer the behavior be similar to the '/' when > > encodedSolidusHandling PASS_THROUGH config is set, so calling > > `request.getServletPath()` would return "/group/(ON%5CQC) LOCAL" > > > > My use case is only concerned with the path portion of the URL, but I > > don't > > believe the query portion of the URL is impacted by this same issue. > > For these tests: > > * allowBackslash = true, otherwise the '\' case would generate a 400 > > * encodeSolidusHandling = PASS_THROUGH, otherwise the '/' case would > > generate a 400 > > * The application is written in Spring WebMVC using the embedded > > Tomcat, so > > I was able to place a breakpoint at the end of > > CoyoteAdapter.postParseRequest(...) to interrogate the > > org.apache.catalina.connector.Request before passing on to the Spring > > code > > just to be sure Spring didn't muddy the water somehow, though it > > doesn't > > appear to manipulate anything as the results are the same. > > > > From what I can tell, any work-around to my issue will either need to > > be > > applied at or before the call to CoyoteAdapter.postParseRequest(...). > > -James > > > > On Wed, Jan 15, 2025 at 4:26 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> James, > >> > >> On 1/15/25 2:39 PM, James Matlik wrote: > >>> I have an API that needs Tomcat to accept both the escaped forward > >>> slash > >>> '/' (%2F) and escaped backslash '\' (%5C) and pass them through to > >>> the > >>> servlet (Spring application). This need exists to support path > >>> parameters > >>> with special URL relevant characters. I've been able to successfully > >>> get > >>> the forward slash to work by setting encodedSolidusHandling to true > >>> as > >> this > >>> stops the escaped forward slash from becoming unescaped. > >>> Unfortunately, > >>> this does not have the same effect on the backslash, so the UDecoder > >> still > >>> converts "%5C" to '\'. Despite this, I was hoping I could work with > >>> the > >>> decoded '\' if it were passed through without being treated as > >>> special, > >> but > >>> then the URL is normalized. When I set allowBackslash to true, > >>> Tomcat's > >>> normalization no longer generates a 400 response, but transforms the > >>> '\' > >>> character to a '/'. > >>> > >>> To me, this looks like a bug in Tomcat since it treats '\' (when > >>> allowed) > >>> as an alias for '/' but does not support the same passthrough > >>> behavior > >> when > >>> escaped. Additionally, unless I am missing something, I don't see any > >>> reasonable extension points or further configuration to change this > >>> behavior. > >>> > >>> Relevant source files: > >>> * UDecoder: > >>> > >> > >> > https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/buf/UDecoder.java#L80-L172 > >>> * CoyoteAdapter: > >>> > >> > >> > https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/connector/CoyoteAdapter.java#L629-L646 > >>> and > >>> > >> > >> > https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/connector/CoyoteAdapter.java#L1132-L1144 > >>> > >>> It seems as if the change I need would be best implemented via a 1 > >>> line > >>> code change to UDecoder on line 133 of the linked file: > >>> if (res == '/') { > >>> becomes: > >>> if (res == '/' || res == '\') { > >>> > >>> Any suggestions on how to work through this issue? > >> > >> How about some examples of URLs which contain these characters? > >> > >> It would be great to see examples along with what you expect each kind > >> of HttpServletRequest.getFoo call o return. > >> > >> You mentioned path parameters; are all these issues related to the > >> encoding of path parameters specifically, or are some of these > >> characters also in other parts of the URL? > >> > >> -chris > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
