{*path} pattern (CaptureTheRestPathElement) includes undocumented leading slash in @PathVariable path

[astiob]

Affects: Spring Framework 5.2.15, 5.3.8

---

In both Web MVC and WebFlux, @RequestMapping via PathPattern supports a pattern like foo/bar/{*restOfThePath}. WebFlux docs additionally explain:

The syntax {*varName} declares a URI variable that matches zero or more remaining path segments. For example /resources/{*path} matches all files under /resources/, and the "path" variable captures the complete relative path.

and give a specific example:

"/resources/{*file}" matches "/resources/images/file.png" and captures file=images/file.png

However, this example is wrong.

In reality, file is assigned /images/file.png, with a leading slash. The pattern matches other request paths like this:

Request path	Captured file
/resources/images/file.png	"/images/file.png"
/resources/images/	"/images/"
/resources/images	"/images"
/resources/	"/"
/resources	""

This contradicts documentation and can only be discovered via testing. Either the documentation should be corrected to match the behaviour, or the behaviour should be adjusted to match the documentation.

Side note: this behaviour is somewhat unintuitive given that the pattern /a/{*b} appears to require a slash after a but in reality makes it optional. In particular, it can be surprising or undesirable that this allows a /a match at all. However, other people may find this desirable (and likely treat it as an alias for /a/), so it should be sufficient simply to document this behaviour.

[rstoyanchev]

This is an error indeed. As for allowing /a to match, it is a catch-all that captures any number of segments, 0 included.

[yichanggeng]

This problem still exists in version 5.3.9。
"/a/spring/io" match "/a/{*var}" result is var="/spring/io" , the "/" still exists

[astiob]

That’s (apparently) intentional and documented. This problem report was resolved by fixing the documentation (adding the missing slash), not changing the behaviour.