Skip to content

node:http: expose IncomingMessage.setEncoding for decoded data chunks #3416

Closed

Description

@andrewtdiz

Summary

Client-side http.IncomingMessage responses should expose setEncoding(encoding) and then emit decoded string chunks from data listeners. Perry currently does not expose the method as a function, so user code cannot request Node-compatible decoded response chunks.

Node Behavior

Minimal repro:

import http from "node:http";
import { Buffer } from "node:buffer";

const server = http.createServer((_req, res) => {
  res.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
  res.end(Buffer.from("héllo", "utf8"));
});

server.listen(0, () => {
  const addr = server.address();
  const port = typeof addr === "object" && addr !== null ? addr.port : 0;
  http.get({ host: "127.0.0.1", port, path: "/" }, (res: any) => {
    console.log("setEncoding typeof:", typeof res.setEncoding);
    res.setEncoding("utf8");
    res.on("data", (chunk: any) => {
      console.log("chunk:", typeof chunk, Buffer.isBuffer(chunk), String(chunk));
    });
    res.on("end", () => server.close());
  });
});

Node v25.9.0 observes:

setEncoding typeof: function
chunk: string false héllo

Perry Behavior

A focused parity probe in test-files/tmp_http_incoming_set_encoding.ts fails before the chunk-shape assertion because Perry reports the method as a non-function:

Node.js: setEncoding typeof: function
Perry:   setEncoding typeof: number

Report: test-parity/reports/parity_report_20260530_103216.json.

Source evidence on origin/main: crates/perry-ext-http/src/lib.rs always delivers client response data listeners as a single Buffer chunk and has a TODO noting that res.setEncoding("utf8") should produce string chunks, but Perry does not yet track a per-response encoding flag.

Suggested PR Cut

Batch this with related issues in:
node:http: IncomingMessage body stream semantics

Good batch candidates:

Do not batch with:

  • top-level node:http helper exports
  • ClientRequest header/socket-control work
  • byte-level response framing/header output diffs

Acceptance

  • parity/regression test proves client response IncomingMessage.setEncoding("utf8") is a function and returns/behaves like Node
  • data listeners receive decoded string chunks after an encoding is set
  • default no-encoding data listeners continue to receive Buffer chunks
  • implementation matches Node observable behavior
  • related known-failure/docs/manifest entries updated if touched

Activity

  1. andrewtdiz commented on May 31, 2026

    @andrewtdiz
    ContributorAuthor

    I'm taking this in a focused node:http IncomingMessage body/header semantics PR with #3272, #3273, and #3416. Scope: server request headers, request data chunk shape, and client response setEncoding decoded chunks.

  2. andrewtdiz commented on May 31, 2026

    @andrewtdiz
    ContributorAuthor

    Opened PR #3525 for this IncomingMessage cluster.\n\nVerification: focused http/incoming-message parity passes 2/2 (report test-parity/reports/parity_report_20260531_050116.json); broad http parity passes 9/10 with only the existing http/server/upgrade-websocket mismatch remaining (report test-parity/reports/parity_report_20260531_050245.json); affected cargo check and hygiene checks pass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions