problemJson
Turns a recognized application/problem+json response into the same ProblemException that application code throws on the server side and problem-details-ktor answers.
The XML half of RFC 9457 is a separate registration in a separate artifact, problem-details-ktor-client-xml, exactly as problemXml() is on the server. Registering both is order-independent here. Each gates on a Content-Type the other never matches, unlike the server's ContentNegotiation pair, where order decides an absent or wildcard Accept.
Ktor's own default response validation always runs first and throws ClientRequestException/ ServerResponseException for a non-2xx status before this handler gets a chance to run. This cannot replace that exception by validating the response early; it has to intercept the exception Ktor already threw and decide whether to replace it. expectSuccess must be true for that exception to exist in the first place; HttpClientConfig.expectSuccess defaults to false, and a client left at that default can still opt in per request: client.get(url) { expectSuccess = true }.
application/problem+json and a plain application/json (only matched when acceptPlainJson is true) are trusted differently on a decode failure: a problem+json-labeled body that fails to parse is a broken promise and propagates as SerializationException; a plain-JSON-labeled body was never a promise about shape, so a decode failure there falls back silently to Ktor's own exception, unchanged.
Every status Ktor raises a ResponseException for qualifies, redirects included. A 3xx answered with a problem document is replaced just like a 4xx or 5xx.
Ktor runs exception handlers in reverse registration order, so a handler the application registers after this one runs before it and may keep this one from ever seeing the exception.
Parameters
also matches responses whose Content-Type is plain application/json. It reads that response header and says nothing about the Accept header. This module never touches outgoing requests. Defaults to false, unlike problem-details-ktor's own acceptPlainJson = true: it governs bodies from servers this project does not control, not this project's own well-formed output.
governs parsing only; the document's shape comes from the serializer attached to Problem.
Samples
expectSuccess = true
HttpResponseValidator {
problemJson()
}