Prefer problem detail media type independent of ordering in Accept header

[osiegmar]

While replacing a custom implementation of Problem Details by the new one that came with Spring 6 I was puzzled by how content negotiation is implemented. I'm currently using Spring Boot 3.0.0 with Spring 6.0.2.

I'm getting a Content-Type application/problem+json as expected when sending no accept header or Accept: */* or Accept: application/problem+json, application/json.

I also expected to receive a Problem Details JSON with Content-Type application/problem+json when sending Accept: application/json. But that might be correct - it doesn't seem to be clearly defined by RFC 7807.

Clearly a bug, seems that I'm still getting Content-Type application/json when sending Accept: application/json, application/problem+json. See also:

Message converters and encoders indicate a preference for application/problem+json when ProblemType is serialized. This ensures application/problem+json is preferred when the client is flexible or has no preference.

from: #28189 (comment)

There's the problem. If not already existing, I could make a PR with a solution.

[rstoyanchev]

I wouldn't call it broken. We're returning JSON after, but we can refine the behavior.

There're multiple problems with the current behavior:

• It does not match API guidelines that require the problem-specific content-type (e.g. https://adidas.gitbook.io/api-guidelines/rest-api-guidelines/message/error-reporting)
• There're further issues, e.g. with a given Accept request header of application/problem+json,application/json, the response will return a Content-Type header of application/problem+json in the case of the successful request handling.
• I have written further tests, see the details in the image. I'll try to make a PR for that.

[rstoyanchev]

@ralf-ueberfuhr-ars, thanks for your time and feedback, and for the attached draft PR. Note that I have local changes in progress too, but before implementation details, we should discuss desired behavior.

For the Adidas API guidelines, I presume you're referring to:

Problem Detail is intended for use with the HTTP status codes 4xx and 5xx. Problem Detail MUST NOT be used with 2xx status code responses.

This is not something we consider explicitly because there should never be a 2xx response with ProblemDetail. Any such response is a programming error, illegal state essentially. At best we can turn it into a 500 error.

[rstoyanchev]

@osiegmar, thinking further about:

I also expected to receive a Problem Details JSON with Content-Type application/problem+json when sending Accept: application/json.

Clearly a bug, seems that I'm still getting Content-Type application/json when sending Accept: application/json, application/problem+json.

We compare Accept header media types to supported media types (i.e. those supported by each HttpMessageConverter), and the outer loop is by Accept header, so the order of acceptable has priority over the order of supported media types.

For ProblemDetail the Jackson converter lists application/problem+json first, followed by application/*+json and application/json. This is why problem+json is favored when the client has no preference. But if the client requests json as the first and/or only media type, then json is used.

I think you are proposing to always use problem+json or problem+xml when ProblemDetails is rendered, and never application/json or application/xml. We can do that by changing the Jackson converter to return problem+json as the only supported media type for ProblemDetail, and hence jsonis never selected. I think it's okay to do that, so if the client understandsproblem+json` it can recognise the response reliably, or otherwise if it doesn't understand it, it can still see that it is kind of JSON.

It means we would mostly ignore the Accept header for ProblemDetail, unless it has problem+json and problem+xml, potentially influencing in what order they are selected.