fix(ext/node): work correctly with wrapper Response objects, use correct rawHeaders structure

[nathanwhit]

Fixes #28022

Will circle back to add a test + clean up a bit.

Basically drizzle-kit studio uses hono with the node-server adapter. That creates wrapper objects for responses that forward property getters to the underlying response (the one we provided). However, in deno.serve we were assuming that the response was actually the same response we initially gave and crashed when it wasn't. instead, just call the property getters if we can't find the inner response.

The raw headers bug is that we were exposing the rawHeaders field on Incoming as a Headers object, instead it's supposed to be a flat array of the header keys + values. I.e. ["Content-Type:", "application/json", "Host:", "http://localhost"]

[Copilot]

Pull Request Overview

This PR fixes an issue with Node’s HTTP polyfills to work correctly with wrapper Response objects by replacing direct access to the rawHeaders array with a new private symbol and updating the corresponding header extraction logic.

• Replaces usage of the public rawHeaders property with a private symbol (kRawHeaders) to encapsulate header data.
• Updates getter and assignment logic for raw headers in IncomingMessageForServer.
• Adjusts response body extraction in 00_serve.ts to handle both stream and static responses appropriately.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
ext/node/polyfills/http.ts	Uses a private symbol for raw headers and updates getter logic.
ext/http/00_serve.ts	Improves response body extraction and header handling.

[littledivy]

LGTM with a test

[lucacasonato]

I understand what you are trying to solve, but I don't think this is the right approach. If I am understanding right, the problem is twofold:

• Deno.serve only accepts "real" Response objects created by the original global new Response() constructor. This is enforced through an internal slot check, but this internal slot check happens too late (it should happen in place of the prototype check).
• The node:http code is constructing a globalThis.Response, which could be manipulated by a user.

I think the correct fix would have been to keep the behaviour of Deno.serve, but move the internal slot check further up (replacing the prototype check), and then updating the node:http code to capture the Response object at the global scope instead of relying on whatever the user may have put there.

See #29105 and follow up #29106