problem-details-ktor-xml/io.github.ilyankin.rfc9457.ktor.xml/ProblemXmlConverter

ProblemXmlConverter

class ProblemXmlConverter : ContentConverter(source)

Reads and writes application/problem+xml bodies for ContentNegotiation.

The same shape as ProblemJsonConverter, with ProblemXml in place of Json, and thin for the same reason: the encoding lives in problem-details-xml, so this only delegates.

It lives in this module, not beside its JSON twin, so that problem-details-ktor never depends on problem-details-xml. That edge is the whole point of the split. An application without the XML dependency gets a compile error at the problemXml call site instead of a runtime NoClassDefFoundError.

Unlike the JSON side there is no Json parameter to accept. ProblemXml deliberately exposes no configuration, because pinning the parser implementation, which is what keeps external entities unresolved, and accepting a caller's parser are mutually exclusive.

Constructors

ProblemXmlConverter

constructor()

Functions

deserialize

open suspend override fun deserialize(charset: Charset, typeInfo: TypeInfo, content: ByteReadChannel): Any?

Reads a Problem from the request body, or returns null if the receiving type is anything else, leaving the body to the next converter.

serialize

open suspend override fun serialize(contentType: ContentType, charset: Charset, typeInfo: TypeInfo, value: Any?): OutgoingContent?

Writes value as application/problem+xml, or returns null if it is not a Problem. That is the interface's way of saying "not mine", which lets ContentNegotiation try the next converter.