HTTP request pattern matching refinements [SPR-14544] #19112
Labels
in: web
Issues in web modules (web, webmvc, webflux, websocket)
type: enhancement
A general enhancement
Milestone
Brian Clozel opened SPR-14544 and commented
Proposed changes
"/te?t" or "/user/**/something"
(/) Yes
"/files/{*path}"
(/) Yes
"/user/*/repositories" becomes "/user/{name}/repositories"
(x) Those are interchangeable
"/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
// externalized constraints in method params: http headers, request params, etc
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
Affects: 5.0 M1
Issue Links:
@RequestMapping
("supersedes")2 votes, 8 watchers
The text was updated successfully, but these errors were encountered: