Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
astiob opened this issue Jul 5, 2021 · 5 comments
Assignees
Labels
type: bug A general bug
Milestone

Comments

@astiob
Copy link

astiob commented Jul 5, 2021

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.

@astiob astiob changed the title {*path} pattern (CaptureTheRestPathElement) includes undocumented leading / in @PathVariable path {*path} pattern (CaptureTheRestPathElement) includes undocumented leading slash in @PathVariable path Jul 5, 2021
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jul 5, 2021
@rstoyanchev rstoyanchev self-assigned this Jul 9, 2021
@rstoyanchev rstoyanchev added type: bug A general bug type: documentation A documentation task and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jul 9, 2021
@rstoyanchev rstoyanchev added this to the 5.3.9 milestone Jul 9, 2021
@rstoyanchev
Copy link
Contributor

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

@snicoll snicoll removed the type: documentation A documentation task label Jul 14, 2021
Zoran0104 pushed a commit to Zoran0104/spring-framework that referenced this issue Aug 20, 2021
lxbzmy pushed a commit to lxbzmy/spring-framework that referenced this issue Mar 26, 2022
@yichanggeng
Copy link

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

@astiob
Copy link
Author

astiob commented Mar 31, 2022

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

@yichanggeng
Copy link

yichanggeng commented Mar 31, 2022 via email

@yichanggeng
Copy link

yichanggeng commented Apr 1, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

5 participants