-
Notifications
You must be signed in to change notification settings - Fork 40.8k
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
Consider using RFC 7807 problem details for error responses #19525
Comments
My two cents regarding JSON errors in general: in basically every project using Spring Boot for HTTP services, and a JavaScript framework (such as Angular or Vue), I always need to customize the JSON error sent by Spring Boot in order to
I haven't read the RFC very carefully yet, but if Spring Boot could provide a standard way to support this common (in my experience) need, it would be great. Or at least not lose the possibility to do it ourselves, and maybe document what the best strategy is to do it by respecting the standard. |
I like to map exceptions to rfc-7807 compliant bodies on the server side and/or back to exceptions on the client side (note: they don't have to be the same exception, they only have to be compatible). I defined an API and wrote an implementation where you can rely on useful defaults for the fields or annotate your exceptions when you have specific requirements: https://github.com/t1/problem-details I’ve blogged about the topic in more detail: https://blog.codecentric.de/en/2020/01/rfc-7807-problem-details-with-spring-boot-and-jax-rs/ I also created a PR for Microprofile Sandbox, as I think it should be a common standard. I would be glad to contribute the Spring Boot implementation. In order to make the client side feel more organic, maybe we would need to scan for all exceptions? Any feedback (except for silence ;-) is welcome! |
Yes agreed. A spring implementation of rfc 7807 would be great! |
Currently I'm looking into error handling in Spring Boot applications and found RFC 7807 to be very interesting. I like that by default it allows me to give meaningful and helpful Problem responses while hiding implementation details like stacktraces or class names for advanced security. So I would also welcome this in Spring (Boot). @t1 thank you for the detailed and practical article |
Spring HATEOAS provides basic support for RFC-7807 since 1.1, see spring-projects/spring-hateoas#1057 and the relevant chapter of reference manual. Now, this might not mean too much for Spring (Boot) users that don't use Spring HATEOAS, but since RFC-7807 is IMO a generally very useful spec, I wonder whether this basic support could be moved to Spring Framework proper? Because it is something that has a clear use even without the involvement of Spring HATEOAS and/or Spring Boot. Both could then leverage the Framework support and build their own extended support on top of it. WDYT @bclozel and @gregturn? Also, seeing this was twice marked as |
@vpavic I don't think there really was an outcome from the team discussions. We probably flagged it to discuss how easy it would be to get it into a release, but ultimately decided to prioritize other issues. |
Naturally I’d favor this. At least the domain types from Spring HATEOAS could be moved, giving universal access to them. But we’d need agreement between Framework and Boot on this approach. |
Also timing will be a bit tricky given that we're not expecting a Framework 5.4 release. |
Building the response |
At bol.com, the biggest online retailer in the Netherlands and Belgium, RFC 7807 is our bread and butter. Judging from the amount of work Zalando has also put into this (problem and problem-spring-web), I think we are not alone in this effort. This said, there is a significant amount of work that we needed to implement to make ModelIn our custom
There are, IIRC, at least 3 Jackson bugs one need to work around to make serialization work using annotations. For instance, if Models are published in a standalone artifact with only Jackson dependency. IntegrationWe encourage our programmers to always throw standard exceptions (e.g., Mapping exceptions to
|
I've created an issue in the Spring Framework spring-projects/spring-framework#27052 for this. |
This comment from a developer at Reddit, about why Reddit is not supporting the RFC, is another data point: https://www.reddit.com/r/api/comments/hze1i2/do_you_folks_use_rfc_7807_problem_details_in_http/ |
@dhh1128: The post has been deleted!?! What are the arguments? |
It's not the post; it's the response to the post (which still remains), that's interesting. The argument is that a standard error reporting mechanism that is rich rather than terse encourages over-disclosure in errors, which is a security risk. |
I don't find the security angle a very compelling argument against supporting RFC 7807 Problems. I've been using Problem JSON for a couple of years now in a micro services architecture with many hundreds of REST API applications, and in my experience developers that come across Problem JSON mostly start producing errors that are way clearer and easier to understand for users. Over-disclosure can happen through any format, and a plain text stack trace is generally way worse than a Problem JSON object. I don't feel that we shouldn't have nice things just because they could contain information that shouldn't be exposed. Not having a nice standard for errors isn't a way to get more secure applications. Things like training, awareness, testing, etc. are what will get you more secure applications. |
It's an old dispute going forth and back: should we prevent good things just because they can be misused? Don't get me wrong: this dispute is difficult and there is no simple answer. But in this case, I stand clearly on one side, because it's a very good thing and the risk is not seriously big. And best of all, we can even implement it in a way that doesn't reveal anything by default, so developers have to actively decide what they want to be exposed... and they do that every day with non-exceptional code — I think they can handle it. |
Additionally, there is already a precedent in the Spring Boot white label error page which can can be configured to show stack trace information. |
Just to be clear, i was posting the argument because I thought it was worth analyzing. It deserves a response. But that doesn't mean I agree with it. I think the benefits of a general mechanism outweigh the drawbacks. |
Is this fixed with spring-projects/spring-framework#27052 now? |
@StefanLobbenmeier not completely, as Spring Boot doesn't produce this format by default and Spring Boot error handling is not based on that. The Spring Framework feature can be enabled with a property but is still opt in for now. |
- ProblemDetails support in SB is not totally finished (spring-projects/spring-boot#33885, spring-projects/spring-boot#19525), stick to semi-manual implementation
using latest SB 3.1 with webflux, I can successfully use problem details when raising update: interesting thing... I managed to fix this by adding |
The problem of the different handling for Spring Framework using ControllerAdvice and Spring Boot using ErrorAttributes. Did someone consider adding a new implementation of the ErrorAttributes interface and ErrorView class to Spring Boot that handles the exceptions and converts them into a Problem JSON structure considering possible existing ProblemDetail objects? |
As RFC 7807 has been obsoleted by RFC 9457: @rstoyanchev @bclozel are there any plans to support the format defined in the new RFC 9457? I couldn't find any reference to it either in Spring Framework repository nor in this Spring Boot one. Thanks in advance |
I don't see much difference here. Am I missing something? |
I didn't see much difference either, maybe the references in documentation/code to RFC 7807 should be updated in order to reference the new RFC 9457? To highlight the support of the new non-obsoleted RFC. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Im hit by a variant of this, when using bean validation along with problem details. I get this response "Validation failure" in the $.detail field.. All the nice messages by bean validation are ignored. |
Maybe this is related also to my issue? |
When I went throught the issue list on spring boot / spring framework.. It seemed this would be fixed from sb 3.4.0.. if youre correct it's not :( |
@membersound this issue is about supporting ProblemDetail for Spring Boot error pages. In your case you are getting the problem details format, so I don't see any link. |
Right now Spring Boot is using an ad hoc format for error responses. Often, applications are configured to support JSON/XML formats and the error map is serialized with such message converters for machine clients, alternatively errors are rendered as HTML pages for browsers.
We could consider using a better defined format for Spring Boot errors, here the RFC 7807 "problem details" specification. This specification can carry error responses like the following:
This could improve error handling in several ways.
First, we could add more contextual information to error maps, like
"type"
,"title"
and"detail"
and provide application hook points to translate application exceptions to problem details (see the Zalando library for this).Also, in cases like #19522 and spring-projects/spring-framework#23421, it could allow HTTP clients to add the specific media type "application/problem+json" to their "Accept" header - and would disambiguate about the format to use when rendering errors. Right now, "application/json" and "application/xml" are the common ones but it's hard to differentiate between application payload and error payloads.
The text was updated successfully, but these errors were encountered: