# 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>
```