Implement HTTP2 server support to enable gRPC

vsly-ru commented 9 months ago

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

alexandernst commented 4 months ago

We have an (official?) ETA for this! :)

https://x.com/jarredsumner/status/1807731197046653438

guest271314 commented 4 months ago

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

Does that HTTP/2 support include duplex:"half" for WHATWG fetch() implementation to support upload streaming?

movva-gpu commented 4 months ago

I guess you have to ask Jarred if you wanna know x)

vsly-ru commented 4 months ago

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 commented 3 months ago

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

LucyEgan commented 3 months ago

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

chimericdream commented 3 months ago

@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://github.com/oven-sh/bun/issues/8823 - Bun's open ticket to support HTTP/2
 */
config.server!.proxy = {};

LucyEgan commented 3 months ago

@chimericdream 💜 your a star, thank you!

pmbanugo commented 2 months ago

maybe HTTP 3 also, in the future

LucyEgan commented 2 months ago

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

movva-gpu commented 2 months ago

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 :woman_shrugging:

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 :pray:)

LucyEgan commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

cirospaciari commented 2 months ago

@cirospaciari What is the branch? https://github.com/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 commented 2 months ago

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

rtritto commented 1 month ago

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

jamie-notifi commented 1 month ago

@cirospaciari What is the branch? https://github.com/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 commented 1 month ago

@cirospaciari What is the branch? https://github.com/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 https://github.com/oven-sh/bun/pull/14286

guest271314 commented 1 month ago

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 commented 1 month ago

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

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

guest271314 commented 1 month ago

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

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

This is fixed https://github.com/oven-sh/bun/issues/10582.

This is not fixed https://github.com/oven-sh/bun/issues/7206.

Jarred-Sumner commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

Too early for an HTTP/3 issue? 😄

Kapsonfire-DE commented 1 week ago

http2 push

@Jarred-Sumner http2 push is a dropped feature. browsers dont implement that anymore

oven-sh / bun