meta: add unified http api initiative by jasnell · Pull Request #65139 · nodejs/node

jasnell · 2026-08-08T15:11:54Z

HTTP APIs in Node.js have become a bit of a mess.

We have separate node:http, node:https, and node:http2 modules. We have separate fetch implementation. We have http3 support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc.

This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities.

@nodejs/quic @mcollina @nodejs/tsc

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com>

nodejs-github-bot · 2026-08-08T15:11:59Z

Review requested:

@nodejs/tsc

panva

Sign me up.

jonchurch · 2026-08-09T20:59:21Z

Stoked to see this as a strategic initiative!

(I know this is early early days, but curious if anyone wants to share what's in their head or in discussions I've missed)

One clarifying question on "built around the web standard fetch model":

Should I read that as Node standardizing the future of request handlers on Request/Response primitives? Or am I looking at the wrong layer here and the end goal is an abstraction layer sitting below Fetch/IncomingMessage, speaking historic protocols as well as future ones? Or is it both: that abstraction layer underneath, with Request/Response handlers standardized on top of it?

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

For context on why I'm asking: I was expecting a unified HTTP API to address the shortcomings the Fetch spec has for modeling jobs that servers need to do. I see the Fetch spec serving browsers as its main constituents, and the tension that can create for servers wanting to model all the jobs they must do via Fetch primitives. So that phrase surprised me, and I'm mostly trying to align my mental model with what layer this new API would occupy relative to the existing stuff. Not opposed to any direction here, just want to clear the fog in my understanding of what problems are on the table.

In the spirit of intellectual honesty, my initial (mistaken) read

I often fall into the trap of categorizing Fetch as a protocol. I know it's not, but my brain often forgets that. I work on Express after all, where we have extended and intertwined with node:http to the point that Fetch looks like a different protocol to me, despite being a different API over the same protocols.

So my initial reaction was that a unified HTTP API would sit above Fetch/IncomingMessage and translate between them at the protocol level. But an implementation competing for the layer Fetch occupies sounds like the xkcd "14 competing standards becomes 15" trap, so I'm assuming that's not on the table hehe

You can see some more of my raw thoughts in this express thread from before I posted this question

bjohansebas · 2026-08-09T21:52:44Z

By the way, as far as I know, there are things that probably will never make it into the Fetch standard, but those things that don't belong in the Fetch spec could still be added as a standard variation within the WinterTC group. That way, both frameworks and runtimes can have a minimal API that runtimes are expected to support.

jasnell · 2026-08-09T22:04:00Z

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

The answer is likely some mixture of both.

jasnell · 2026-08-12T20:11:08Z

Giving this 3 more days more merging.

mcollina

lgtm

ping @KhafraDev

KhafraDev

Unifying node:http, node:https, node:http2, and node:quic is amazing. The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

bjohansebas · 2026-08-13T01:46:23Z

The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

Do you have any resources? I’d like to read more about it.

KhafraDev · 2026-08-13T02:01:53Z

I don't think my personal opinion is relevant to this PR and I don't want to derail it.

nodejs-github-bot · 2026-08-14T15:09:50Z

Landed in db138c4

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #65139 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Tim Perry <pimterry@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Richard Lau <richard.lau@ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>

jasnell · 2026-08-08T15:11:54Z

HTTP APIs in Node.js have become a bit of a mess.

We have separate node:http, node:https, and node:http2 modules. We have separate fetch implementation. We have http3 support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc.

This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities.

@nodejs/quic @mcollina @nodejs/tsc

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com>

nodejs-github-bot · 2026-08-08T15:11:59Z

Review requested:

@nodejs/tsc

panva

Sign me up.

jonchurch · 2026-08-09T20:59:21Z

Stoked to see this as a strategic initiative!

(I know this is early early days, but curious if anyone wants to share what's in their head or in discussions I've missed)

One clarifying question on "built around the web standard fetch model":

Should I read that as Node standardizing the future of request handlers on Request/Response primitives? Or am I looking at the wrong layer here and the end goal is an abstraction layer sitting below Fetch/IncomingMessage, speaking historic protocols as well as future ones? Or is it both: that abstraction layer underneath, with Request/Response handlers standardized on top of it?

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

For context on why I'm asking: I was expecting a unified HTTP API to address the shortcomings the Fetch spec has for modeling jobs that servers need to do. I see the Fetch spec serving browsers as its main constituents, and the tension that can create for servers wanting to model all the jobs they must do via Fetch primitives. So that phrase surprised me, and I'm mostly trying to align my mental model with what layer this new API would occupy relative to the existing stuff. Not opposed to any direction here, just want to clear the fog in my understanding of what problems are on the table.

In the spirit of intellectual honesty, my initial (mistaken) read

I often fall into the trap of categorizing Fetch as a protocol. I know it's not, but my brain often forgets that. I work on Express after all, where we have extended and intertwined with node:http to the point that Fetch looks like a different protocol to me, despite being a different API over the same protocols.

So my initial reaction was that a unified HTTP API would sit above Fetch/IncomingMessage and translate between them at the protocol level. But an implementation competing for the layer Fetch occupies sounds like the xkcd "14 competing standards becomes 15" trap, so I'm assuming that's not on the table hehe

You can see some more of my raw thoughts in this express thread from before I posted this question

bjohansebas · 2026-08-09T21:52:44Z

By the way, as far as I know, there are things that probably will never make it into the Fetch standard, but those things that don't belong in the Fetch spec could still be added as a standard variation within the WinterTC group. That way, both frameworks and runtimes can have a minimal API that runtimes are expected to support.

jasnell · 2026-08-09T22:04:00Z

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

The answer is likely some mixture of both.

jasnell · 2026-08-12T20:11:08Z

Giving this 3 more days more merging.

mcollina

lgtm

ping @KhafraDev

KhafraDev

Unifying node:http, node:https, node:http2, and node:quic is amazing. The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

bjohansebas · 2026-08-13T01:46:23Z

The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

Do you have any resources? I’d like to read more about it.

KhafraDev · 2026-08-13T02:01:53Z

I don't think my personal opinion is relevant to this PR and I don't want to derail it.

nodejs-github-bot · 2026-08-14T15:09:50Z

Landed in db138c4

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #65139 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Tim Perry <pimterry@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Richard Lau <richard.lau@ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>

jasnell · 2026-08-08T15:11:54Z

HTTP APIs in Node.js have become a bit of a mess.

We have separate node:http, node:https, and node:http2 modules. We have separate fetch implementation. We have http3 support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc.

This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities.

@nodejs/quic @mcollina @nodejs/tsc

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com>

nodejs-github-bot · 2026-08-08T15:11:59Z

Review requested:

@nodejs/tsc

panva

Sign me up.

jonchurch · 2026-08-09T20:59:21Z

Stoked to see this as a strategic initiative!

(I know this is early early days, but curious if anyone wants to share what's in their head or in discussions I've missed)

One clarifying question on "built around the web standard fetch model":

Should I read that as Node standardizing the future of request handlers on Request/Response primitives? Or am I looking at the wrong layer here and the end goal is an abstraction layer sitting below Fetch/IncomingMessage, speaking historic protocols as well as future ones? Or is it both: that abstraction layer underneath, with Request/Response handlers standardized on top of it?

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

For context on why I'm asking: I was expecting a unified HTTP API to address the shortcomings the Fetch spec has for modeling jobs that servers need to do. I see the Fetch spec serving browsers as its main constituents, and the tension that can create for servers wanting to model all the jobs they must do via Fetch primitives. So that phrase surprised me, and I'm mostly trying to align my mental model with what layer this new API would occupy relative to the existing stuff. Not opposed to any direction here, just want to clear the fog in my understanding of what problems are on the table.

In the spirit of intellectual honesty, my initial (mistaken) read

I often fall into the trap of categorizing Fetch as a protocol. I know it's not, but my brain often forgets that. I work on Express after all, where we have extended and intertwined with node:http to the point that Fetch looks like a different protocol to me, despite being a different API over the same protocols.

So my initial reaction was that a unified HTTP API would sit above Fetch/IncomingMessage and translate between them at the protocol level. But an implementation competing for the layer Fetch occupies sounds like the xkcd "14 competing standards becomes 15" trap, so I'm assuming that's not on the table hehe

You can see some more of my raw thoughts in this express thread from before I posted this question

bjohansebas · 2026-08-09T21:52:44Z

By the way, as far as I know, there are things that probably will never make it into the Fetch standard, but those things that don't belong in the Fetch spec could still be added as a standard variation within the WinterTC group. That way, both frameworks and runtimes can have a minimal API that runtimes are expected to support.

jasnell · 2026-08-09T22:04:00Z

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

The answer is likely some mixture of both.

jasnell · 2026-08-12T20:11:08Z

Giving this 3 more days more merging.

mcollina

lgtm

ping @KhafraDev

KhafraDev

Unifying node:http, node:https, node:http2, and node:quic is amazing. The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

bjohansebas · 2026-08-13T01:46:23Z

The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

Do you have any resources? I’d like to read more about it.

KhafraDev · 2026-08-13T02:01:53Z

I don't think my personal opinion is relevant to this PR and I don't want to derail it.

nodejs-github-bot · 2026-08-14T15:09:50Z

Landed in db138c4

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #65139 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Tim Perry <pimterry@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Richard Lau <richard.lau@ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>

jasnell · 2026-08-08T15:11:54Z

HTTP APIs in Node.js have become a bit of a mess.

We have separate node:http, node:https, and node:http2 modules. We have separate fetch implementation. We have http3 support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc.

This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities.

@nodejs/quic @mcollina @nodejs/tsc

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com>

nodejs-github-bot · 2026-08-08T15:11:59Z

Review requested:

@nodejs/tsc

panva

Sign me up.

jonchurch · 2026-08-09T20:59:21Z

Stoked to see this as a strategic initiative!

(I know this is early early days, but curious if anyone wants to share what's in their head or in discussions I've missed)

One clarifying question on "built around the web standard fetch model":

Should I read that as Node standardizing the future of request handlers on Request/Response primitives? Or am I looking at the wrong layer here and the end goal is an abstraction layer sitting below Fetch/IncomingMessage, speaking historic protocols as well as future ones? Or is it both: that abstraction layer underneath, with Request/Response handlers standardized on top of it?

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

For context on why I'm asking: I was expecting a unified HTTP API to address the shortcomings the Fetch spec has for modeling jobs that servers need to do. I see the Fetch spec serving browsers as its main constituents, and the tension that can create for servers wanting to model all the jobs they must do via Fetch primitives. So that phrase surprised me, and I'm mostly trying to align my mental model with what layer this new API would occupy relative to the existing stuff. Not opposed to any direction here, just want to clear the fog in my understanding of what problems are on the table.

In the spirit of intellectual honesty, my initial (mistaken) read

I often fall into the trap of categorizing Fetch as a protocol. I know it's not, but my brain often forgets that. I work on Express after all, where we have extended and intertwined with node:http to the point that Fetch looks like a different protocol to me, despite being a different API over the same protocols.

So my initial reaction was that a unified HTTP API would sit above Fetch/IncomingMessage and translate between them at the protocol level. But an implementation competing for the layer Fetch occupies sounds like the xkcd "14 competing standards becomes 15" trap, so I'm assuming that's not on the table hehe

You can see some more of my raw thoughts in this express thread from before I posted this question

bjohansebas · 2026-08-09T21:52:44Z

By the way, as far as I know, there are things that probably will never make it into the Fetch standard, but those things that don't belong in the Fetch spec could still be added as a standard variation within the WinterTC group. That way, both frameworks and runtimes can have a minimal API that runtimes are expected to support.

jasnell · 2026-08-09T22:04:00Z

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

The answer is likely some mixture of both.

jasnell · 2026-08-12T20:11:08Z

Giving this 3 more days more merging.

mcollina

lgtm

ping @KhafraDev

KhafraDev

Unifying node:http, node:https, node:http2, and node:quic is amazing. The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

bjohansebas · 2026-08-13T01:46:23Z

The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

Do you have any resources? I’d like to read more about it.

KhafraDev · 2026-08-13T02:01:53Z

I don't think my personal opinion is relevant to this PR and I don't want to derail it.

nodejs-github-bot · 2026-08-14T15:09:50Z

Landed in db138c4

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #65139 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Tim Perry <pimterry@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Richard Lau <richard.lau@ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>

jasnell · 2026-08-08T15:11:54Z

HTTP APIs in Node.js have become a bit of a mess.

We have separate node:http, node:https, and node:http2 modules. We have separate fetch implementation. We have http3 support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc.

This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities.

@nodejs/quic @mcollina @nodejs/tsc

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com>

nodejs-github-bot · 2026-08-08T15:11:59Z

Review requested:

@nodejs/tsc

panva

Sign me up.

jonchurch · 2026-08-09T20:59:21Z

Stoked to see this as a strategic initiative!

(I know this is early early days, but curious if anyone wants to share what's in their head or in discussions I've missed)

One clarifying question on "built around the web standard fetch model":

Should I read that as Node standardizing the future of request handlers on Request/Response primitives? Or am I looking at the wrong layer here and the end goal is an abstraction layer sitting below Fetch/IncomingMessage, speaking historic protocols as well as future ones? Or is it both: that abstraction layer underneath, with Request/Response handlers standardized on top of it?

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

For context on why I'm asking: I was expecting a unified HTTP API to address the shortcomings the Fetch spec has for modeling jobs that servers need to do. I see the Fetch spec serving browsers as its main constituents, and the tension that can create for servers wanting to model all the jobs they must do via Fetch primitives. So that phrase surprised me, and I'm mostly trying to align my mental model with what layer this new API would occupy relative to the existing stuff. Not opposed to any direction here, just want to clear the fog in my understanding of what problems are on the table.

In the spirit of intellectual honesty, my initial (mistaken) read

I often fall into the trap of categorizing Fetch as a protocol. I know it's not, but my brain often forgets that. I work on Express after all, where we have extended and intertwined with node:http to the point that Fetch looks like a different protocol to me, despite being a different API over the same protocols.

So my initial reaction was that a unified HTTP API would sit above Fetch/IncomingMessage and translate between them at the protocol level. But an implementation competing for the layer Fetch occupies sounds like the xkcd "14 competing standards becomes 15" trap, so I'm assuming that's not on the table hehe

You can see some more of my raw thoughts in this express thread from before I posted this question

bjohansebas · 2026-08-09T21:52:44Z

By the way, as far as I know, there are things that probably will never make it into the Fetch standard, but those things that don't belong in the Fetch spec could still be added as a standard variation within the WinterTC group. That way, both frameworks and runtimes can have a minimal API that runtimes are expected to support.

jasnell · 2026-08-09T22:04:00Z

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

The answer is likely some mixture of both.

jasnell · 2026-08-12T20:11:08Z

Giving this 3 more days more merging.

mcollina

lgtm

ping @KhafraDev

KhafraDev

Unifying node:http, node:https, node:http2, and node:quic is amazing. The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

bjohansebas · 2026-08-13T01:46:23Z

The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

Do you have any resources? I’d like to read more about it.

KhafraDev · 2026-08-13T02:01:53Z

I don't think my personal opinion is relevant to this PR and I don't want to derail it.

nodejs-github-bot · 2026-08-14T15:09:50Z

Landed in db138c4

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #65139 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Tim Perry <pimterry@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Richard Lau <richard.lau@ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>

jasnell · 2026-08-08T15:11:54Z

HTTP APIs in Node.js have become a bit of a mess.

We have separate node:http, node:https, and node:http2 modules. We have separate fetch implementation. We have http3 support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc.

This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities.

@nodejs/quic @mcollina @nodejs/tsc

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com>

nodejs-github-bot · 2026-08-08T15:11:59Z

Review requested:

@nodejs/tsc

panva

Sign me up.

jonchurch · 2026-08-09T20:59:21Z

Stoked to see this as a strategic initiative!

(I know this is early early days, but curious if anyone wants to share what's in their head or in discussions I've missed)

One clarifying question on "built around the web standard fetch model":

Should I read that as Node standardizing the future of request handlers on Request/Response primitives? Or am I looking at the wrong layer here and the end goal is an abstraction layer sitting below Fetch/IncomingMessage, speaking historic protocols as well as future ones? Or is it both: that abstraction layer underneath, with Request/Response handlers standardized on top of it?

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

For context on why I'm asking: I was expecting a unified HTTP API to address the shortcomings the Fetch spec has for modeling jobs that servers need to do. I see the Fetch spec serving browsers as its main constituents, and the tension that can create for servers wanting to model all the jobs they must do via Fetch primitives. So that phrase surprised me, and I'm mostly trying to align my mental model with what layer this new API would occupy relative to the existing stuff. Not opposed to any direction here, just want to clear the fog in my understanding of what problems are on the table.

In the spirit of intellectual honesty, my initial (mistaken) read

I often fall into the trap of categorizing Fetch as a protocol. I know it's not, but my brain often forgets that. I work on Express after all, where we have extended and intertwined with node:http to the point that Fetch looks like a different protocol to me, despite being a different API over the same protocols.

So my initial reaction was that a unified HTTP API would sit above Fetch/IncomingMessage and translate between them at the protocol level. But an implementation competing for the layer Fetch occupies sounds like the xkcd "14 competing standards becomes 15" trap, so I'm assuming that's not on the table hehe

You can see some more of my raw thoughts in this express thread from before I posted this question

bjohansebas · 2026-08-09T21:52:44Z

By the way, as far as I know, there are things that probably will never make it into the Fetch standard, but those things that don't belong in the Fetch spec could still be added as a standard variation within the WinterTC group. That way, both frameworks and runtimes can have a minimal API that runtimes are expected to support.

jasnell · 2026-08-09T22:04:00Z

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

The answer is likely some mixture of both.

jasnell · 2026-08-12T20:11:08Z

Giving this 3 more days more merging.

mcollina

lgtm

ping @KhafraDev

KhafraDev

Unifying node:http, node:https, node:http2, and node:quic is amazing. The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

bjohansebas · 2026-08-13T01:46:23Z

The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

Do you have any resources? I’d like to read more about it.

KhafraDev · 2026-08-13T02:01:53Z

I don't think my personal opinion is relevant to this PR and I don't want to derail it.

nodejs-github-bot · 2026-08-14T15:09:50Z

Landed in db138c4

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #65139 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Tim Perry <pimterry@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Richard Lau <richard.lau@ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>

jasnell · 2026-08-08T15:11:54Z

HTTP APIs in Node.js have become a bit of a mess.

We have separate node:http, node:https, and node:http2 modules. We have separate fetch implementation. We have http3 support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc.

This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities.

@nodejs/quic @mcollina @nodejs/tsc

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com>

nodejs-github-bot · 2026-08-08T15:11:59Z

Review requested:

@nodejs/tsc

panva

Sign me up.

jonchurch · 2026-08-09T20:59:21Z

Stoked to see this as a strategic initiative!

(I know this is early early days, but curious if anyone wants to share what's in their head or in discussions I've missed)

One clarifying question on "built around the web standard fetch model":

Should I read that as Node standardizing the future of request handlers on Request/Response primitives? Or am I looking at the wrong layer here and the end goal is an abstraction layer sitting below Fetch/IncomingMessage, speaking historic protocols as well as future ones? Or is it both: that abstraction layer underneath, with Request/Response handlers standardized on top of it?

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

For context on why I'm asking: I was expecting a unified HTTP API to address the shortcomings the Fetch spec has for modeling jobs that servers need to do. I see the Fetch spec serving browsers as its main constituents, and the tension that can create for servers wanting to model all the jobs they must do via Fetch primitives. So that phrase surprised me, and I'm mostly trying to align my mental model with what layer this new API would occupy relative to the existing stuff. Not opposed to any direction here, just want to clear the fog in my understanding of what problems are on the table.

In the spirit of intellectual honesty, my initial (mistaken) read

I often fall into the trap of categorizing Fetch as a protocol. I know it's not, but my brain often forgets that. I work on Express after all, where we have extended and intertwined with node:http to the point that Fetch looks like a different protocol to me, despite being a different API over the same protocols.

So my initial reaction was that a unified HTTP API would sit above Fetch/IncomingMessage and translate between them at the protocol level. But an implementation competing for the layer Fetch occupies sounds like the xkcd "14 competing standards becomes 15" trap, so I'm assuming that's not on the table hehe

You can see some more of my raw thoughts in this express thread from before I posted this question

bjohansebas · 2026-08-09T21:52:44Z

By the way, as far as I know, there are things that probably will never make it into the Fetch standard, but those things that don't belong in the Fetch spec could still be added as a standard variation within the WinterTC group. That way, both frameworks and runtimes can have a minimal API that runtimes are expected to support.

jasnell · 2026-08-09T22:04:00Z

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

The answer is likely some mixture of both.

jasnell · 2026-08-12T20:11:08Z

Giving this 3 more days more merging.

mcollina

lgtm

ping @KhafraDev

KhafraDev

Unifying node:http, node:https, node:http2, and node:quic is amazing. The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

bjohansebas · 2026-08-13T01:46:23Z

The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

Do you have any resources? I’d like to read more about it.

KhafraDev · 2026-08-13T02:01:53Z

I don't think my personal opinion is relevant to this PR and I don't want to derail it.

nodejs-github-bot · 2026-08-14T15:09:50Z

Landed in db138c4

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #65139 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Tim Perry <pimterry@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Richard Lau <richard.lau@ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>

jasnell · 2026-08-08T15:11:54Z

HTTP APIs in Node.js have become a bit of a mess.

We have separate node:http, node:https, and node:http2 modules. We have separate fetch implementation. We have http3 support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc.

This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities.

@nodejs/quic @mcollina @nodejs/tsc

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com>

nodejs-github-bot · 2026-08-08T15:11:59Z

Review requested:

@nodejs/tsc

panva

Sign me up.

jonchurch · 2026-08-09T20:59:21Z

Stoked to see this as a strategic initiative!

(I know this is early early days, but curious if anyone wants to share what's in their head or in discussions I've missed)

One clarifying question on "built around the web standard fetch model":

Should I read that as Node standardizing the future of request handlers on Request/Response primitives? Or am I looking at the wrong layer here and the end goal is an abstraction layer sitting below Fetch/IncomingMessage, speaking historic protocols as well as future ones? Or is it both: that abstraction layer underneath, with Request/Response handlers standardized on top of it?

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

For context on why I'm asking: I was expecting a unified HTTP API to address the shortcomings the Fetch spec has for modeling jobs that servers need to do. I see the Fetch spec serving browsers as its main constituents, and the tension that can create for servers wanting to model all the jobs they must do via Fetch primitives. So that phrase surprised me, and I'm mostly trying to align my mental model with what layer this new API would occupy relative to the existing stuff. Not opposed to any direction here, just want to clear the fog in my understanding of what problems are on the table.

In the spirit of intellectual honesty, my initial (mistaken) read

I often fall into the trap of categorizing Fetch as a protocol. I know it's not, but my brain often forgets that. I work on Express after all, where we have extended and intertwined with node:http to the point that Fetch looks like a different protocol to me, despite being a different API over the same protocols.

So my initial reaction was that a unified HTTP API would sit above Fetch/IncomingMessage and translate between them at the protocol level. But an implementation competing for the layer Fetch occupies sounds like the xkcd "14 competing standards becomes 15" trap, so I'm assuming that's not on the table hehe

You can see some more of my raw thoughts in this express thread from before I posted this question

bjohansebas · 2026-08-09T21:52:44Z

By the way, as far as I know, there are things that probably will never make it into the Fetch standard, but those things that don't belong in the Fetch spec could still be added as a standard variation within the WinterTC group. That way, both frameworks and runtimes can have a minimal API that runtimes are expected to support.

jasnell · 2026-08-09T22:04:00Z

Either way, would the top level Request/Response layer be extended to compensate for the things the Fetch spec makes hard for servers to model today? Or would it stay pure Fetch spec, with those server concerns discussed at the WHATWG level?

The answer is likely some mixture of both.

jasnell · 2026-08-12T20:11:08Z

Giving this 3 more days more merging.

mcollina

lgtm

ping @KhafraDev

KhafraDev

Unifying node:http, node:https, node:http2, and node:quic is amazing. The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

bjohansebas · 2026-08-13T01:46:23Z

The fetch half... I've already spoken as to why, personally, I think it's a bad idea.

Do you have any resources? I’d like to read more about it.

KhafraDev · 2026-08-13T02:01:53Z

I don't think my personal opinion is relevant to this PR and I don't want to derail it.

nodejs-github-bot · 2026-08-14T15:09:50Z

Landed in db138c4

HTTP APIs in Node.js have become a bit of a mess. We have separate `node:http`, `node:https`, and `node:http2` modules. We have separate `fetch` implementation. We have `http3` support in development. There are new http features like datagrams and priorities that are entirely unsupported, etc. This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model. Client and Server.. independent of underlying transport and updated to modern HTTP protocol capabilities. Signed-off-by: James M Snell <jasnell@gmail.com> PR-URL: #65139 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com> Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Tim Perry <pimterry@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Richard Lau <richard.lau@ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>

nodejs-github-bot added the doc Issues and PRs related to Node.js documentation. label Aug 8, 2026

jasnell requested a review from a teamAugust 8, 2026 15:13

panva approved these changes Aug 8, 2026
View reviewed changes

legendecas approved these changes Aug 8, 2026
View reviewed changes

bjohansebas approved these changes Aug 8, 2026
View reviewed changes

bjohansebas mentioned this pull request Aug 8, 2026
Server Fetch mode expressjs/discussions#515
Open

daeyeon approved these changes Aug 8, 2026
View reviewed changes

efekrskl approved these changes Aug 8, 2026
View reviewed changes

mertcanaltin approved these changes Aug 8, 2026
View reviewed changes

trivikr approved these changes Aug 8, 2026
View reviewed changes

marco-ippolito approved these changes Aug 9, 2026
View reviewed changes

atlowChemi approved these changes Aug 9, 2026
View reviewed changes

pimterry approved these changes Aug 9, 2026
View reviewed changes

benjamingr approved these changes Aug 9, 2026
View reviewed changes

richardlau approved these changes Aug 12, 2026
View reviewed changes

mcollina approved these changes Aug 13, 2026
View reviewed changes

KhafraDev approved these changes Aug 13, 2026
View reviewed changes

metcoder95 approved these changes Aug 14, 2026
View reviewed changes

jasnell added the commit-queue PRs queued for automated landing through the Commit Queue. label Aug 14, 2026

nodejs-github-bot merged commit db138c4 into nodejs:mainAug 14, 2026
59 checks passed

nodejs-github-bot removed the commit-queue PRs queued for automated landing through the Commit Queue. label Aug 14, 2026

github-actionsBot mentioned this pull request Aug 25, 2026
2026-08-26, Version 26.8.0 (Current) #65551
Merged