-
Notifications
You must be signed in to change notification settings - Fork 38.3k
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
Comments
This is an error indeed. As for allowing |
This problem still exists in version 5.3.9。 |
That’s (apparently) intentional and documented. This problem report was resolved by fixing the documentation (adding the missing slash), not changing the behaviour. |
已经收到您的邮件!谢谢
|
ok , thank you!
…------------------ 原始邮件 ------------------
发件人: "Oleg ***@***.***>;
发送时间: 2022年3月31日(星期四) 晚上6:32
收件人: ***@***.***>;
抄送: ***@***.***>; ***@***.***>;
主题: Re: [spring-projects/spring-framework] {*path} pattern (CaptureTheRestPathElement) includes undocumented leading slash in @PathVariable path (#27132)
That’s intentional and documented. This problem report was resolved by fixing the documentation (adding the missing slash), not changing the behaviour.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
Affects: Spring Framework 5.2.15, 5.3.8
In both Web MVC and WebFlux,
@RequestMapping
viaPathPattern
supports a pattern likefoo/bar/{*restOfThePath}
. WebFlux docs additionally explain:and give a specific example:
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: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 aftera
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.The text was updated successfully, but these errors were encountered: