Skip to content

Path parameters snippet uses *name as the name of a {*name} capture variable - #1079

Open
chuuminggg wants to merge 1 commit into
spring-projects:4.0.xfrom
chuuminggg:path-parameter-catch-all
Open

chuuminggg wants to merge 1 commit into
spring-projects:4.0.xfrom
chuuminggg:path-parameter-catch-all

Conversation

@chuuminggg

Copy link
Copy Markdown
Contributor

PathPattern supports capturing the rest of a path into a variable with {*name}, for example:

@GetMapping("/files/{*path}")
String file(@PathVariable("path") String path) { … }

When such a request is documented with pathParameters, PathParametersSnippet takes the variable's name to be *path rather than path:

this.mockMvc.perform(RestDocumentationRequestBuilders.get("/files/{*path}", "a/b.txt"))
	.andDo(document("capture", pathParameters(parameterWithName("path").description("File path"))));
org.springframework.restdocs.snippet.SnippetException: Path parameters with the following names were not documented: [*path]. Path parameters with the following names were not found in the request: [path]

The only way to document the parameter is currently parameterWithName("*path"), which then appears as *path in the snippet.

getParameterName already removes a :regex suffix from the variable. This PR also removes a leading *, so the parameter is named path, matching the name that's used with @PathVariable. I've checked this end to end with MockMvc and a @GetMapping("/files/{*path}") controller as well as with the new unit test in PathParametersSnippetTests.

This is a change in behavior for anyone who's worked around the problem by documenting *path. They'd need to document path instead.

Previously, the name of a path variable that captures the rest of the
path, such as {*path}, was determined to be *path rather than path.

Signed-off-by: chuuminggg <rorrxr@naver.com>
@chuuminggg
chuuminggg force-pushed the path-parameter-catch-all branch from d4ea280 to e7ccb77 Compare October 16, 2026 10:37
@wilkinsona wilkinsona added type: bug A bug and removed status: waiting-for-triage Untriaged issue labels Oct 19, 2026
@wilkinsona wilkinsona added this to the 4.0.x milestone Oct 19, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants