Matrix variables aren't read when path variable has regex restriction [SPR-11879]

[spring-projects-issues]

Emerson Farrugia opened SPR-11879 and commented

I need to support a URI which looks like

/user/5/foo;a=1;b=2

where "foo" is a literal string. Since MVC only allows matrix variables on path variables, the corresponding request mapping looks like

/user/{userId}/{foo}

Since that would allow the foo variable to be anything, I restricted it using a regular expression, and the mapping became

/user/{userId}/{foo:foo}

At which point, my matrix variables stopped working. I've attached a Gist showing how matrix variables don't work when the path variable has a regex restriction. In that Gist, /withoutRegex/3 works with both matrix variables and without matrix variables. /withRegex/3 works without matrix variables, but when I specify matrix variables, I get the error

No mapping found for HTTP request with URI [/withRegex/3;q=10] in DispatcherServlet with name 'dispatcherServlet'

---

Affects: 4.0.5

Reference URL: https://gist.github.com/emersonf/d656611d174e32a3d9d3

Issue Links:

• @PathVariable & @MatrixVariable do not work as documented when "=" is in the path variable value part (pre ";") [SPR-11897] #16516 @PathVariable & @MatrixVariable do not work as documented when "=" is in the path variable value part (pre ";")

[spring-projects-issues]

Rossen Stoyanchev commented

This should work:

/user/{userId}/{fooPath:foo}{fooVars}

[spring-projects-issues]

Emerson Farrugia commented

Thanks for the workaround. It didn't occur to me that the path variable could be blank. This is even simpler

/user/{userId}/foo{fooVars}

Although it's easy to work around it, I think it violates the principle of least astonishment that this

`/user/\{userId:\d+\`}

doesn't match

/user/4;foo=bar

[spring-projects-issues]

Rossen Stoyanchev commented

The challenge with path variables is that there are different ways of using ";" in a path segment. See for example the last paragraph of section 3.3 of the URI spec:

Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax.  URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents.  For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment.  The comma (",") reserved character is often used for
similar purposes.  For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same.  Parameter types may be defined by scheme-specific
semantics, but in most cases the syntax of a parameter is specific to
the implementation of the URI's dereferencing algorithm.

So you can do "name;v=1.1" or "name,1.1" or "name;1.1". Here is for example the StackExchange API using URLs such as "/answers/{ids}" where ids is a semicolon separated list of ids. So we can't really take a single URI variable such as your "userId" example and assume that it represents only content up to the first semicolon. Instead a URI variable is just that, it represents some opaque content in the URI.

[spring-projects-issues]

Rossen Stoyanchev commented

To summarize given "/user/{userId}", the URI variable "userId" matches the entire path segment. We will then attempt to parse out a path variable and matrix variables from that, which is typically the content before vs after the first semicolon.

If you include a regular expression, that narrows down what the URI variable targets, and requires an extra URI variable for the rest of the content in the path segment, e.g. "/user/{userId:\d+}{params}".