Allow passing `new Headers()` to `res.writeHead(...)`

[jimmywarting]

What is the problem this feature will solve?

I would like for standard Headers to be passable to http response.writeHead

An example:

http.createServer((req, res) => {
  const headers = new Headers()
  res.writeHead(200, 'OK', headers)
})

What is the feature you are proposing to solve the problem?

Want things that are more web-ish

What alternatives have you considered?

No response

[ShogunPanda]

@nodejs/http What do you think about this? Headers is from fetch API.

cc @marco-ippolito, which is interested in implementing this if we choose to opt-in

[ronag]

SGTM.

[ronag]

Would maybe also be interesting to explore allowing returning a Response from the createServer callback?

[mcollina]

Would maybe also be interesting to explore allowing returning a Response from the createServer callback?

I would be -1 to that. The createServer callback is an event emitted... and adding this would make it exceptionally complicated.

[jimmywarting]

Would maybe also be interesting to explore allowing returning a Response from the createServer callback?

I like that idea also
note that some ppl are using async
http.createServer(async (req, res) => { ... })

So maybe also waiting for something to resolve into a response would be useful.

But then we should probably have respondWith to have little parity with service worker, as to allow offloading some part of your code off the server onto ServiceWorker to allow the app to work offline.

incomingRequest.respondWith(fetch(url))`

Talked a little bit about this here:
#42529 (comment) but the issue got closed

---

b/c the createServer is a event emitted callback then maybe it would be easier to extend it to have respondWith

[mcollina]

I'm -1 as I don't think this will benefit the ecosystem. The Headers object is significantly slower than what we currently do (to the point I recommend against using it whenever possible). Adding this support to a relatively fast API (writeHead) will make the ecosystem worse.

Moreover, Headers is not designed for server usage (cookies, forbidden headers). Note that WinterCG is working on making it more server-friendly.

I think this kind of compatibility would be better left for higher level frameworks.

[mcollina]

I like that idea also
note that some ppl are using async
http.createServer(async (req, res) => { ... })

This is one of the major source of promise issues when people are using our http server APIs. Don't do this.

[jimmywarting]

This is one of the major source of promise issues when people are using our http server APIs. Don't do this.

care to explain why it's an issue to use async?

[bnoordhuis]

It creates promises when they're not needed. Wastes memory and CPU for no reason.

[mcollina]

This is one of the major source of promise issues when people are using our http server APIs. Don't do this.

care to explain why it's an issue to use async?

This video from @jasnell covers it fairly well: https://m.youtube.com/watch?v=XV-u_Ow47s0.

[ShogunPanda]

I'm also -0.5 as I foresee problems as @mcollina already pointed out.
Do we have a consensus to close this?

[mcollina]

I'd be ok in adding a setHeaders() method for example. I just don't want to modify writeHead() or any other low-level APIs.

[ShogunPanda]

I think that's a good compromise.

@marco-ippolito Are still interested in implementing it?

[marco-ippolito]

I think that's a good compromise.

@marco-ippolito Are still interested in implementing it?

Yes 👍🏻