Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP request pattern matching refinements [SPR-14544] #19112

Closed
spring-issuemaster opened this issue Jul 30, 2016 · 1 comment
Closed

HTTP request pattern matching refinements [SPR-14544] #19112

spring-issuemaster opened this issue Jul 30, 2016 · 1 comment
Assignees
Milestone

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Jul 30, 2016

Brian Clozel opened SPR-14544 and commented

Proposed changes

  1. No "?" or "**" allowed within the pattern:
    "/te?t" or "/user/**/something"

(/) Yes

  1. Allow "{*foobar}" and "/**" at the end of the pattern to allow multiple segment matching until the end of the path:
    "/files/{*path}"

(/) Yes

  1. Not supporting "*" in patterns and ensure use of named tokens like "{name}" in all cases:
    "/user/*/repositories" becomes "/user/{name}/repositories"

(x) Those are interchangeable

  1. Clarify that multiple tokens should be allowed within one segment only if separated by a literal
    "/user/{id}_{name}/

(/) Yes

These are relatively straight forward changes that would allow creating a grammar and a state machine for parsing patterns. Also, ensuring single segment tokens could help with creating a more efficient matching algorithm.

Additional changes for discussion

The following makes things a bit more complex and I'm not sure it's as useful but worth considering.

Keep constraints within the pattern or externalize those?

(x) Rejected because there is no tangible benefit besides readability and even that is subjective.

// keep everything within the pattern

@RequestMapping("/user/{id:[\\d\\.]+}")

// externalized constraints in method params: http headers, request params, etc

@RequestMapping(path="/user/{id}")
String handler(@PathVariable(constraint="[\\d\\.]+") id, @RequestParam (required=true) param)

Add a new constraint based on Host

Quite useful for routers, applications managing several domains or sub-domains.
Since you can map several domains on PWS, this is quite useful.

We can also define those as patterns like "{subdomain}.example.org"

Have default values for Path variables

(x) Rejected because it creates multiple mappings (one with and one without), it does not work unless it's in the last segment, and arguably it should be expressed as a request parameter since the route does not match.

// In case the page path var is empty, instead of declaring a separate route

@RequestMapping(path="/blog/{page}")
String handler(@PathVariable(default="1") page)

Affects: 5.0 M1

Issue Links:

  • #19521 Improve nested routes API ("is depended on by")
  • #19811 PathPatternParser#parse method failed with java.lang.IndexOutOfBoundsException
  • #20090 Polish PathPattern parser
  • #18766 Wildcard mapping for path segments at the end of a @RequestMapping ("supersedes")

2 votes, 8 watchers

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Feb 13, 2017

Arjen Poutsma commented

The new PathPatternParser is now used in the server-side functional web framework. See this commit.

Unfortunately, having the parser in HandlerStrategies, as discussed during our meeting, did not work out, for the simple reason that PathPredicate.test does not have access to HandlerStrategies, just access to ServerRequest. Instead, I added a pathPredicates method which allows for customising the parser in a different way, see this test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.