Implement HTTP2 server support to enable gRPC

[vsly-ru]

What is the problem this feature would solve?

As described in #887, HTTP2 support is mandatory for gRPC to work. We appreciate the bun team for successfully implementing HTTP2 client-side support, enabling connectivity to gRPC servers.

However, on the server side, the issue persists, preventing the operation of gRPC servers. Unfortunately, there seems to be a lack of prioritization for server support, evident from the absence of an ETA and limited developer replies on the issue.

So I assumed that the team determines feature implementation priority based on the upvotes received for an issue. Given that #887 may be deemed partially resolved, it's possible that its upvotes no longer influence the priority of the ongoing server-side concern.

This new issue is raised to emphasize the continued importance of server-side HTTP2 support. We hope to bring back the attention by collecting upvotes here. Thank you.

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

Implement HTTP2 server support in Bun.

What alternatives have you considered?

No response

[birkskyum]

Tags to make the ticket searchable:
http2.createServer, http2.createSecureServer, createServer, createSecureServer

[guest271314]

Possibly related #7206

[birkskyum]

This has become the 22th most upvoted ticket in just 1 day, which I find to be highly unusual.

[debkanchan]

I'm dying for this to land so I can finally move on from node once and for all

[birkskyum]

Same - can't use backend integrations for Auth0, Stripe etc. without it, because they strictly require http2 w/ https even in localhost using their dev mode APIs.

[birkskyum]

10th most requested features in less than a week.

@Electroid , there is a picture forming that the http2 client release only satisfied a minority of the people reacting to the other ticket. I imagine Windows support draw all resources now (and rightly so!), but any updates or plans for this will be appreciated.

[Electroid]

Yes, it's clear that folks need this. I think most realistic would be between 1.1 and 1.2, but we don't have specific dates right now.

[ewrogers]

This has become the 22th most upvoted ticket in just 1 day, which I find to be highly unusual.

Another dev here who has to use JS/TS and refuses to build "yet another JSON REST API microservice" when everyone knows gRPC is the better option.

[rhadamez]

Probably Bun is being avoid to be used due http2 not in. After this implementation will be some issues related to it, so until there me and my pals gonna stay with node.

[guest271314]

An alternative could be Bun's TCP server?

[Yashrocky96]

Because of this I'm unable to use Firebase SDK and Even GCP SDKs. Majority of our code is based on the SDKs.

If this is solved, then we can adopt this completely for our internal usage

[debkanchan]

Me and the gang waiting for this to dropped so we can finally ditch node

[pukingrainbows]

Also for running vite with https locally it is required, trying to use the "vite-plugin-mkcert";

[birkskyum]

Also for running vite with https locally it is required, trying to use the "vite-plugin-mkcert";

Exactly, missing this breaks all frameworks but Next.js through mkcert, and maybe Next too through a similar issue.

[razvanphp]

Also for running vite with https locally it is required, trying to use the "vite-plugin-mkcert";

I'm pretty sure this is related, but just FYI, when running Vite 4.5 and have basicSsl() plugin included in config (from @vitejs/plugin-basic-ssl) the error message is very misleading:

% bun --bun vite
error when starting dev server:
TypeError: Invalid path string: path is too long (max: 1024)
    at readFile (native)
    at <anonymous> (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:54807:11)
    at readFileIfExists (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:22374:33)
    at <anonymous> (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:22368:21)
    at resolveHttpsConfig (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:22361:35)
    at <anonymous> (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:24928:142)
    at processTicksAndRejections (:12:39)

[patriksimms]

For anyone stumbling into this issue while getting @httptoolkit/httpolyglot to run in bun (required e.g. for mockttp):

We created a fork which removes http2.createServer calls. With this, you can run mockttp just fine. Once bun supports this, the fork of course will be deprecated.

https:/esome/httpolyglot-bun

[zachsents]

Others have mentioned it but this issue absolutely cripples anyone using GCP libraries, including firebase-admin. We need this so bad

[Yashrocky96]

@zachsents I agree, I had to use different firebase-functions to execute Firestore queries and maintain a 2nd API, which is not desirable @Jarred-Sumner

Hope this gets fixed, so that I can move it to the main Bun + Elysia.js API

[Lillious]

The one feature my team needs to ditch node. I hope this gets implemented sooner than later!

[dunadain]

Plz I need this feature for my game server

[TomasHubelbauer]

@rhuanbarreto that seems to be about an HTTP2 client (making HTTP2 calls from Bun) not a server.

[MarcStdt]

Yes, it's clear that folks need this. I think most realistic would be between 1.1 and 1.2, but we don't have specific dates right now.

I think we approached that timeframe now. Is there any chance to get an ETA on this?
Me and my team are basically on the fence to adopt bun, but this is just a hard blocker for us.
I think this is also one of the most awaited features by now.

[vsly-ru]

Why is that "(grpc)" in parentheses? Does that include a standalone HTTP/2 server that has nothing to do with grpc?

HTTP/2(server) is the underlying transport of gRPC. So the task is to implement the HTTP/2, not gRPC, because gRPC is not a part of nodejs and Bun. It's just a lib, one of whose dependencies is not implemented yet.

[guest271314]

bun is faster than deno (and deno is faster than node) for processing standard input and writing to standard output.

[LucyEgan]

+1 this is required for vite dev https, so hopefully soon 🤞 Q3 ends in 1.5 months 👀

[chimericdream]

@LucyEgan (and anyone else who finds their way here needing https with vite dev), this is the workaround my team is currently using to get https working with vite:

/*
 * This is only needed because Bun does not yet support HTTP/2, which Vite
 * uses for its https configuration. Once Bun adds HTTP/2 support, we can
 * remove this and simply use a regular https config.
 *
 * See:
 * https://vitejs.dev/config/server-options.html#server-https - note the bit about downgrading to TLS when `proxy` is set
 * https:/oven-sh/bun/issues/8823 - Bun's open ticket to support HTTP/2
 */
config.server!.proxy = {};

[LucyEgan]

@chimericdream 💜 your a star, thank you!

[pmbanugo]

maybe HTTP 3 also, in the future

[LucyEgan]

@pmbanugo when HTTP 4 has been standard for a few years 😄

[movva-gpu]

No it hasn't @LucyEgan ? Well at least I can't find any info about it :²

I found RCF9114 - HTTP3 and RFC9204 - QPACK: HTTP3, but nothing about http4 being a standard :/

I also found some information about HttpClient 4.x but that's an Apache Camel thing, not a standard of any kind 🤷‍♀️

And @pmbanugo, I'm not in the oven.sh team and I don't know if you get the hold of the time and the energy needed to make what they do (I'm not trying to be mean I genuinely don't know if you do), but if they haven't implemented HTTP2 yet, they're not gonna implement HTTP3 right after it comes out (sadly ik ik). Bun is (as far as I understand) not yet made or even able to be shipped to production, or at least not in the case of an HTTP2 web server, because it can't yet (can't wait for it to happen tho 🙏)

[LucyEgan]

@movva-gpu 🤣🤣🤣 naa HTTP 4 is totally a thing, just around the corner 🫠

(Incase it wasn't clear, both of these comments are a joke)

[pmbanugo]

No it hasn't @LucyEgan ? Well at least I can't find any info about it :²

I found RCF9114 - HTTP3 and RFC9204 - QPACK: HTTP3, but nothing about http4 being a standard :/

I also found some information about HttpClient 4.x but that's an Apache Camel thing, not a standard of any kind 🤷‍♀️

And @pmbanugo, I'm not in the oven.sh team and I don't know if you get the hold of the time and the energy needed to make what they do (I'm not trying to be mean I genuinely don't know if you do), but if they haven't implemented HTTP2 yet, they're not gonna implement HTTP3 right after it comes out (sadly ik ik). Bun is (as far as I understand) not yet made or even able to be shipped to production, or at least not in the case of an HTTP2 web server, because it can't yet (can't wait for it to happen tho 🙏)

HTTP/3 might take a long time (or maybe never). Node.js doesn't even have HTTP/3 support, and I think the HTTP/2 implementation isn't fully RFC-compliant yet (I think I read that somewhere). Many of these tools mostly use http 1.1 and recommends it. If you want http/3, then use things like Caddy server or any web server that supports it.

[cirospaciari]

For people asking for updates, I'm actively working on server side support for this and improving client side support, will post updates soon. And we have plans for HTTP/3 too.

[guest271314]

@cirospaciari What is the branch? https:/oven-sh/bun/tree/ciro/http2-server?

[cirospaciari]

@cirospaciari What is the branch? https:/oven-sh/bun/tree/ciro/http2-server?

Yeah but is outdated, I broke down in more branchs locally, will push soon and open a PR (but in this branch you mentioned the really basic stuff already works)

[guest271314]

I look forward to testing your gear until it breaks. Thanks.

[rtritto]

Anywone can confirm if #13880 (Vite + Elysia) is related to this issue?

Edit:
Related comment #13880 (comment)

[jamie-notifi]

@cirospaciari What is the branch? https:/oven-sh/bun/tree/ciro/http2-server?

Yeah but is outdated, I broke down in more branchs locally, will push soon and open a PR (but in this branch you mentioned the really basic stuff already works)

Hey, any targeted release version // date for this feature?

[cirospaciari]

@cirospaciari What is the branch? https:/oven-sh/bun/tree/ciro/http2-server?

Yeah but is outdated, I broke down in more branchs locally, will push soon and open a PR (but in this branch you mentioned the really basic stuff already works)

Hey, any targeted release version // date for this feature?

Updating my branch and bug fixing you can follow on #14286

[guest271314]

If anything I would be implementing Deno's HTTP/2 server, not Node.js.

Just implementing an HTTP/2 server alone is not enough. This has to be done for WHATWG Fetch implementation, too.

[ignoramous]

This has to be done for WHATWG Fetch implementation, too.

Believe the client has already been implemented: #887 (docs).

[guest271314]

This has to be done for WHATWG Fetch implementation, too.

Believe the client has already been implemented: #887 (docs).

This is fixed #10582.

This is not fixed #7206.

[Jarred-Sumner]

Creating a server in node:http2 will ship in Bun v1.1.31, which we aim to release tomorrow (thanks to @cirospaciari).

This includes many bugfixes for the client as well. About 90% of grpc-js’ test suite passes, the remaining todos are mostly named pipes on windows, injecting sockets from http1, and http2 push.

You can try it out now via

bun upgrade --canary

[deathemperor]

Also for running vite with https locally it is required, trying to use the "vite-plugin-mkcert";

I'm pretty sure this is related, but just FYI, when running Vite 4.5 and have basicSsl() plugin included in config (from @vitejs/plugin-basic-ssl) the error message is very misleading:

% bun --bun vite
error when starting dev server:
TypeError: Invalid path string: path is too long (max: 1024)
    at readFile (native)
    at <anonymous> (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:54807:11)
    at readFileIfExists (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:22374:33)
    at <anonymous> (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:22368:21)
    at resolveHttpsConfig (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:22361:35)
    at <anonymous> (/Volumes/Code/portal/node_modules/vite/dist/node/chunks/dep-52909643.js:24928:142)
    at processTicksAndRejections (:12:39)

This error still occurs running bun latest canary

[Atulin]

Too early for an HTTP/3 issue? 😄