Affects: 5.1.8.RELEASE

The AntPathMatcher does not match strings containing newlines \n or \r when encoded as %0A or %0D for template URI variables. This is due to AntPathMatcher using defaulting matching regex of (.*), which matches all characters except newline characters.

For instance the controller (using spring boot):

@RestController
public class Controller {

    @RequestMapping("/foo/x\ny")
    public String fooNewline() {
        return "From fooNewline()";
    }

    @RequestMapping("/foo/x\ry")
    public String fooCarriageReturn() {
        return "From fooCarriageReturn()";
    }

    @RequestMapping("/bar/{param1}")
    public String bar(@PathVariable("param1") String param1) {
        return "From bar(). Passed in " + param1;
    }

}

Would match

GET /foo/x%0Ay
GET /foo/x%0Dy

but

GET /bar/x%0Ay
GET /bar/x%0Dy

would return HTTP 404 Not Found with no context on the error with no opportunity to give a more helpful error message. Specifically from the default ErrorController:

{
  "timestamp": "2019-07-09T03:05:04.285+0000",
  "status": 404,
  "error": "Not Found",
  "message": "No message available",
  "path": "/bar/x%0Ay"
}

This can be worked around by manually specify a DOTALL modifier flag in every path param.

E.g.

@RequestMapping("/bar/{param1:(?s:.*)}")

But I think it would make sense if the AntPathMatcher did this by default, and I consider it a bug as normal path matching behavior, outside of template variables, would happily match newline or carriage returns.

Comment From: peter-ponzel

Hello, I just ran into the same issue - has there been any update on this ? Regards

Comment From: rstoyanchev

It sounds like we just need to update the DEFAULT_VARIABLE_PATTERN expression in AntPathMatcher to use the embedded (?s) flag as documented on Pattern.DOTALL. As this pattern is only used for URI template variables, it shouldn't impact anything outside of web request mappings.