-
Notifications
You must be signed in to change notification settings - Fork 38.5k
Consumes condition support for optional content [SPR-17478] #22010
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
Comments
Rossen Stoyanchev commented This is the same as #21955. I am scheduling for 5.2 tentatively to explore a potential solution to this, where the consumes condition checks the "content-length" and/or "transfer-encoding" headers for cases when there is no body. We'll probably need to decide what to do if two methods both match the request (e.g. one json, one xml) and there is no content. Perhaps rejecting that as ambiguous mapping might not be so bad, or maybe that's how it already behaves today. |
I am having a similar issue. I would add that this bug will also affects @RestController
@RequestMapping(path="/widgets", consumes= "application/vnd.mywidgets+json")
class WidgetController {
@PostMapping("/find")
List<Widget> query(@RequestBody WidgetQuery) {
}
@GetMapping("/find")
List<Widget> query() {
}
} Calling |
@shollander, in your case the consumes condition at the controller level is declared too broadly. |
@rstoyanchev, why is the consumes condition declared too broadly? If I have multiple methods that all have the same consumes condition, then I would like to be able to declare it at the class level instead of duplicating it for every method. The framework should be smart enough to figure out that if there is no |
Vitalii Ishchenko opened SPR-17478 and commented
Request validation behaves badly for cases when RequestBody is optional and not provided, but consumes is specified in RequestMapping annotation
i.e. having following method in controller, annotated with PostMapping, request will fail with empty body and no Content-Type. Sending dummy content type will resolve the issue
Fails:
Succeeds:
Sample Spring Boot app is attached
Affects: 5.1.2
Attachments:
Issue Links:
@RequestBody
(required=false) and no Content-Type Header Issue ("duplicates")The text was updated successfully, but these errors were encountered: