asmhatre/spring-boot-demo
1
0
Fork 0
Code Activity

Add problem-details: global exception handling with RFC 9457

Browse Source 
Companion code for "Global Exception Handling with ProblemDetail (RFC 9457)
in Spring Boot 4". Thirteen failures under five handling setups (Boot
defaults, the Boot flag, a ResponseEntityExceptionHandler advice, advice
plus an ErrorController, a catch-all ordered first), validation errors,
i18n, content negotiation, Security's 401/403, silent 500s and decoding
on the client. 16 tests pin the behaviour.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01C3TETMrqVUWeFkNtz3Jbo3
This commit is contained in:
asmhatre
2026-09-11 17:12:22 +00:00
co-authored by Claude Opus 5
parent a065696478
commit 926250e1a9
63 changed files with 2414 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
problem-details/docs/05-content-negotiation.md
+27
View File
@@ -0,0 +1,27 @@
# 5. Content negotiation: why `Accept: application/xml` gets JSON
[← 4. Types and message codes](04-i18n-and-types.md) · [Index](../README.md) · Next: [6. Outside Spring MVC →](06-outside-mvc.md)
With `jackson-dataformat-xml` on the classpath a successful response honours `Accept:
application/xml`. An error response to the same request does not
([`content-negotiation.txt`](output/content-negotiation.txt)):
| `Accept` | `GET /orders/1` (200) | `GET /orders/999` (404) |
|---|---|---|
| `application/json` | `application/json` | `application/problem+json` |
| `application/xml` | `application/xml` | **`application/problem+json`** |
| `application/problem+xml` | - | `application/problem+xml` |
| `text/html` | - | `application/problem+json` |
| `image/png` | - | `application/problem+json` (still 404, not 406) |
For a `ProblemDetail` body the producible types are `application/problem+json` and
`application/problem+xml`. `application/xml` is compatible with neither - `problem+xml` is a
different subtype, not a specialisation - so negotiation finds no match and Spring falls back to
JSON rather than failing the error response with a 406. The fallback is the right call; the
surprise is that an XML client must ask for `application/problem+xml` by name to get XML errors.
The XML body uses the RFC's namespace, which RFC 9457 kept from 7807:
```
<problem xmlns="urn:ietf:rfc:7807"><detail>Order 999 does not exist</detail><instance>/orders/999</instance><status>404</status><title>Order not found</title><type>https://ankurm.com/problems/order-not-found</type><orderId>999</orderId></problem>
```