Clarify Content-Type behavior for HttpResponse::body and json

[yorkin-bot]

Summary

Mocket's ordinary 200-response examples return a String, Json, or another responder directly, which lets dispatch apply both Responder::options and Responder::output. Using HttpResponse::new(OK).body("hello") as the primary example is therefore artificial and not the idiomatic case.

The repository's official examples do use HttpResponse::body when a custom status is needed:

• Bad Request responses with a text body
• a Not Found response with an HTML body

In these representative cases, the current implementation preserves the requested status and serialized body but does not apply the body responder's automatic Content-Type.

This may be intentional: HttpResponse may own all response metadata while the argument to body acts only as a body encoder. The public API and examples do not currently document that contract.

Relevant code:

• HttpResponse::body calls only Responder::output
• built-in responders set their content type in Responder::options
• dispatch applies both methods to the final responder
• body has been output-only since the Responder API was introduced

Representative reproduction

This follows the patterns used by the official responder example:

async fn main {
  let app = @mocket.new()
  app.get("/bad-request", _ => {
    @mocket.HttpResponse::new(BadRequest).body("Invalid JSON")
  })
  app.get("/not-found", _ => {
    @mocket.HttpResponse::new(NotFound).body(
      @mocket.html("<h1>404</h1>"),
    )
  })
  app.listen("127.0.0.1:49319")
}

Observed on main@c545db2, native backend:

Request	Status	Body	Content-Type
GET /bad-request	400	Invalid JSON	absent
GET /not-found	404	<h1>404</h1>	absent

Requested clarification

Please define and test the intended contract for HttpResponse::body and HttpResponse::json.

Either design can be coherent:

1. Body encoder only: document that body deliberately ignores Responder::options, require callers to set Content-Type explicitly, and show that in the custom-status examples. Also clarify whether json follows the same rule.
2. Infer the body content type: carry only the body type's default Content-Type into the response, while preserving the status already set on HttpResponse and giving its explicitly supplied headers precedence.

This issue does not require copying every effect of Responder::options. Status codes, arbitrary headers, cookies, and custom responder options should not be merged without a separately documented precedence rule.

Please add black-box tests for direct String/Json/Html responders, custom-status HttpResponse::body values, HttpResponse::json, and explicit Content-Type overrides.

[oboard]

fix: error-raising handlers and HttpResponse::body Content-Type inference- #26
#26