respondProblem

Responds with problem, the problem itself deciding the HTTP status.

A null status is treated as 500 and written back into the body, so the response never disagrees with its own document. RFC 9457 §3.1 calls the member advisory only, but still requires generators to make it match the actual HTTP status.

Samples

routing {
    get("/orders/{id}") {
        // `status` decides the HTTP status, and `instance` is filled from the request path.
        call.respondProblem(
            problem {
                status = 404
                title = "Order not found."
                detail = "No order with that id exists."
            },
        )
    }
}

Responds with problem at status, the response deciding the status.

The form the StatusPages status path needs, where the status is already chosen and only the body is being swapped in. A provider that hardcoded a different status gets corrected here instead of shipping the self-contradictory document §3.1 forbids.

Problem.instance is filled from the request path when left unset. §3.1 defines the member as identifying this occurrence, which the path does at no cost. An instance the caller already set is never overwritten.

The query string is deliberately excluded (path(), not uri()). A problem document gets logged and forwarded on both ends, and §5 warns against putting anything in one the recipient shouldn't have. Query strings carry tokens and search terms often enough that echoing them by default is the wrong trade. Set Problem.instance explicitly for the full target.