Http.Error.BadStatus loses response body on non-success HTTP statuses

Answer

The Http.Error.BadStatus constructor cannot be configured or extended to include the response body. To retrieve the server-sent body during a non-2xx response, you must use Http.expectStringResponse. This shifts the responsibility of status validation and decoding from the library to your application logic, allowing you to capture the raw payload and decode it using Json.Decode.

Technical Explanation

In the standard elm/http flow, helpers like expectJson only execute the provided decoder if the server returns a 2xx status code. If the status is non-success, the library short-circuits and returns a BadStatus containing only the integer code, discarding the body to maintain a strict type definition for Http.Error.

Trade-offs of using expectStringResponse

• Benefit: Full access to the response body regardless of the HTTP status code, enabling the display of server-side validation errors.
• Cost: You lose the automatic routing provided by expectJson. You must manually handle the Result, check the status code (if using a response-aware helper), and manage the decoding process for both success and error cases.

Implementation Pattern

To preserve the original Http.Error while adding decoded error details, define a custom error union type:

type MyError
    = NetworkError Http.Error
    | ServerError Int MyErrorPayload
    | DecodeError String

-- Use expectStringResponse to get the raw body
-- Then manually decode based on the status code
case result of
    Ok bodyStr ->
        case Decode.decodeString errorDecoder bodyStr of
            Ok payload -> Err (ServerError 400 payload)
            Err _ -> Ok (Decode.decodeString successDecoder bodyStr)
    Err err ->
        Err (NetworkError err)

Verification Steps:

1. Configure a test endpoint to return a 400 status with a JSON body (e.g., {"error": "Invalid input"}).
2. Replace expectJson with expectStringResponse.
3. Verify that the Ok branch of the result now contains the JSON string instead of triggering a BadStatus error.
4. Pass that string through your Json.Decode logic to confirm the payload is recoverable.

Missing Diagnostic Detail

Does your server consistently return application/json for all non-2xx statuses? If the server occasionally returns HTML error pages (e.g., from a load balancer or 500 Internal Server Error), you must include a fallback in your decoding logic to prevent the application from crashing or showing a generic "Decode Error" when the body is not JSON.