While working on ProblemDetail support for error views in Spring Boot (See https://github.com/spring-projects/spring-boot/issues/19525), I have noticed that the org.springframework.web.reactive.result.method.annotation.ResponseEntityExceptionHandler handles all NoResourceFoundException instances as Problem Detail JSON/XML responses.
This exception is thrown for all 404s in the application, meaning that a browser requesting a missing page will always get a JSON response.
In the current error handling support for Spring Boot, the application can contribute an ErrorWebExceptionHandler which can render errors as JSON payloads or HTML views. Because it is ordered after the ResponseEntityExceptionHandler, there is no chance for Spring Boot to render HTML error pages for 404s.
I don't think there is a way to really understand the intent of the client here in Spring Framework. Spring Boot does that by checking that the client requests "text/html" explicitly.
This is an important change to consider in 6.2.x, but I'm wondering how we can unlock this use case for Spring Boot. Isn't handling
Comment From: rstoyanchev
Spring Boot has been able to do content negotiation for error handling through @RequestMapping methods, but the same was not possible with just @ExceptionHandler methods. Now that #31936 has made that capability available, we can revisit the ResponseEntityExceptionHandler setup, which is intended only for HTTP services, and provide something similar that would apply to "text/html" requests. That way we can provide handling of the same exceptions for HTTP services and browser clients similar to what Boot does.
Comment From: bclozel
I've considered this a bit and I have a few questions:
- browsers send accept headers like
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. The "/" part means that the ordering of exception handlers is key. - does this mean that Spring Boot should then extend/replace this HTML error handling in the future? Spring Boot has a quite evolved mechanism that renders static pages and views.
- if we want to move things forward, https://github.com/spring-projects/spring-boot/issues/19525 needs to happen for Spring Boot 3.5 (which is Framework 6.2 based). That puts a lot of pressure on this issue.
Comment From: bclozel
After discussing this with Rossen, we have decided to consider #34272 first, before we work on Spring Boot alignment.