[Bug]: http-server-js emitter generates incorrect response code for `bytes` body with custom content-type

[snipd-mikel]

Describe the bug

When an operation returns a bytes body with a custom @header contentType (e.g. application/zip),
the emitter generates broken response code that:

1. Correctly sets the content-type from the @header property, then immediately overwrites it with application/json
2. Calls Uint8Array.toJsonObject() which doesn't exist, causing a runtime crash

This is the response-side equivalent of the request-side fix in #6898.

Reproduction

@post
op exportFile(): {
  @statusCode statusCode: 200;
  @header contentType: "application/zip";
  @body content: bytes;
};

Generated code in server-raw.ts:

// Bug 1: correct content-type is immediately overwritten
ctx.response.setHeader("content-type", result.contentType); // "application/zip" ✓
ctx.response.setHeader("content-type", "application/json"); // overwrites it ✗

// Bug 2: Uint8Array has no static toJsonObject method — throws at runtime
ctx.response.end(globalThis.JSON.stringify(Uint8Array.toJsonObject(result.content)));

Expected behavior:

ctx.response.setHeader("content-type", result.contentType);
ctx.response.end(result.content); // send bytes directly, no JSON serialization

Root cause:

In packages/http-server-js/src/http/server/index.ts, the response body handling block unconditionally applies JSON serialization without checking whether the body type is bytes (via ctx.program.checker.isStdType(body.type, "bytes")). The same check already exists on the request deserialization path (added in #6898) but was not applied symmetrically to responses.

Additional context:

Emitter version: 0.58.0-alpha.26

Checklist

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• The provided reproduction is a minimal reproducible example of the bug.

[github-actions]

🎯 Issue Triage

The http-server-js emitter incorrectly handles response bodies of type bytes with a custom @header contentType: it overwrites the correct content-type with application/json and calls the non-existent Uint8Array.toJsonObject(), causing a runtime crash.

Category: Bug
Area: emitter:service:js

📋 Reproduction code

`@post`
op exportFile(): {
  `@statusCode` statusCode: 200;
  `@header` contentType: "application/zip";
  `@body` content: bytes;
};

🔍 Analysis

• Affected package: @typespec/http-server-js (v0.58.0-alpha.26)
• Affected file: packages/http-server-js/src/http/server/index.ts
• Root cause: The response body serialization path unconditionally applies JSON serialization (JSON.stringify) without checking if the body type is bytes. The fix already exists on the request deserialization path (added in [hsjs] Support scalar content-types and extended shared route differentiation. #6898 via ctx.program.checker.isStdType(body.type, "bytes")), but was never applied symmetrically to responses.
• Two bugs in generated output:
  1. Content-type header correctly set from @header, then immediately overwritten with application/json
  2. Uint8Array.toJsonObject(result.content) called — this method doesn't exist, causing a runtime throw

📝 Suggested next steps

• In packages/http-server-js/src/http/server/index.ts, add a bytes type check on the response body handling path (mirroring the fix from [hsjs] Support scalar content-types and extended shared route differentiation. #6898)
• When body type is bytes, skip JSON serialization and send the buffer directly via ctx.response.end(result.content)
• Add a test case for bytes response body with a custom content-type header

Generated by Agentic Triage