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

Support Content Negotiation and view rendering in ResponseEntityExceptionHandler #31936

Closed
bclozel opened this issue Jan 3, 2024 · 1 comment
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) theme: web-error-handling An issue related to web error handling type: enhancement A general enhancement
Milestone

Comments

@bclozel
Copy link
Member

bclozel commented Jan 3, 2024

See #31569 (comment) for background

@bclozel bclozel added in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement theme: web-error-handling An issue related to web error handling labels Jan 3, 2024
@bclozel bclozel added this to the 6.2.x milestone Jan 3, 2024
@rstoyanchev
Copy link
Contributor

Prior to RFC 7807, we didn't have an opinion on the format of an error response, and provided an abstract ResponseEntityExceptionHandler that leaves it to sub-classes to choose the error details format. Boot added such an opinion, but its error handling was only meant as a fallback for unresolved exceptions.

In 6.0 we added support for RFC 7807 and that allows ResponseEntityExceptionHandler to handle all exceptions with error details rather than leaving them to Boot's error handling.

In 6.1 with #29491 and #30930 we also started handling static resource exceptions, but ResponseEntityExceptionHandler, but that doesn't support HTML error responses as reported in #31569.

We need an equivalent of ResponseEntityExceptionHandler that supports browser requests, but there is currently no good way to create @ExceptionHandler variants with ResponseEntity vs ModelAndView return values, based on the requested content type. That's something Boot's error handling supports but using @RequestMapping methods on an ERROR dispatch.

We should consider some content negotiation mechanism for @ExceptionHandler methods. The equivalent of the produces attribute on @RequestMapping.

@bclozel bclozel modified the milestones: 6.2.x, 6.2.0-M3 May 16, 2024
bclozel added a commit that referenced this issue May 23, 2024
Prior to this commit, gh-31936 enabled content negotiation for
`@ExceptionHandler` annotated methods in Spring MVC and WebFlux.
In the case of WebFlux, HTTP clients sending invalid media types in the
"Accept" request header would fail with a `NotAcceptableStatusException`
This exception would be handled with an HTTP 406 response status,
instead of processing the original exception.

This commit ensures that invalid media types are ignored during the
exception handling phase and that we fall back to "*/*".

Fixes gh-32878
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) theme: web-error-handling An issue related to web error handling type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants