Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-14544

HTTP request pattern matching refinements

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: 5.0 M1
    • Fix Version/s: 5.0 M5
    • Component/s: Reactive, Web
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      Proposed changes

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

      Yes

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

      Yes

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

      Those are interchangeable

      4. 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?

      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

      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)
      

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              bclozel Brian Clozel
              Reporter:
              bclozel Brian Clozel
              Last updater:
              Spring Issuemaster
              Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 36 weeks, 5 days ago