io.eezo.http.client

Request-side credentials, as the header pair they are.

A request body once it has been encoded for the wire: bytes that know their media type.

The two travel together because a body and its Content-Type written apart can disagree, and the server reads the bytes by the type it is told. The constructor is closed for the same reason: an application gets a Content from an encoder such as Http.form and hands it to post, so the type it carries is always the one its bytes were written in. The bytes are the array that will be sent, so two Contents are not compared by what they hold.

The outbound HTTP client: direct style on the JDK's own HttpClient, so eezo's runtime classpath stays Jetty and the Postgres driver and nothing else. A blocking send on a virtual thread parks rather than pins, which is why there is no async variant here — the live layer's Async[S] supplies the thread, and everything else calls from wherever it already is.

Redirects follow the JDK's NORMAL policy: followed, never from HTTPS down to HTTP, and the JDK strips Authorization when a redirect changes origin. A body is either text the caller has already written, sent under the type the caller names, or a Content an encoder made, which carries its own type so the two cannot disagree. A JSON encoder belongs to the future public derives Json design, not here (design/live.md M6).

What was received: the status, the headers, the bytes. Named for what it is rather than Response, so a file that also handles eezo's own io.eezo.http.Response never has two meanings for one word.

What one outbound call came back as: a closed set the caller matches exhaustively.

Four arms and no more. Denied (401/403) is first-class because it is the arm with a different action attached — refresh a token, surface a login — so the compiler asks every caller what happens when credentials die, which is the whole point of matching a total function over this enum rather than a PartialFunction that swallows what it does not name. Unreachable is separate from Failed because "the server answered badly" and "no HTTP happened at all" recover differently. Nothing here throws for an ordinary failure; a Reply is a value, whatever happened.