This was discussed over in denoland/deno_std#153 but was locked during the move.
While we still have concerns around the HTTP server, we should also consider supporting HTTP/2, HTTP/3 and QUIC.
kitsonk
All 7 comments
hazae41
on 25 Feb 2020
It's quite likely that we will expose native HTTP server.
Getting these protocols correct is very difficult - it's better to collaborate with other Rust users. We will probably using warp. (We will be using warp for Chrome DevTools web socket server, so it makes sense to also expose a native WebSocket object using that. Might as well also use it for HTTP bindings.)
The reason why we have std/http and not a native HTTP server is because we're still working out the kinks in the "op model". In our benchmarks deno_tcp is still slower than node_tcp
I want to fix that first before adding the native HTTP since it will be built on top of the same primitives.
ry
on 25 Feb 2020
@ry Is there a ticket for those performance benchmarks or any schedule for when it might make it in?
hcldan
on 18 May 2020
What's the status on http/2 support in Deno?
Justsnoopy30
on 13 Jun 2020
The issue is open. That indicates that it isn't resolved yet.
kitsonk
on 13 Jun 2020
The issue is open. That indicates that it isn't resolved yet.
Well yes, I can see that. What I meant was, how much progress has been made on this?
Justsnoopy30
on 13 Jun 2020
Any progress would be mentioned in this issue.
kitsonk
on 13 Jun 2020
Related issues
zekth
·
38Comments
kyranet
·
47Comments
fujiazhang
·
514Comments
Bidek56
·
46Comments
alinnert
·
71Comments
Most helpful comment
It's quite likely that we will expose native HTTP server.
Getting these protocols correct is very difficult - it's better to collaborate with other Rust users. We will probably using warp. (We will be using warp for Chrome DevTools web socket server, so it makes sense to also expose a native WebSocket object using that. Might as well also use it for HTTP bindings.)
The reason why we have
std/httpand not a native HTTP server is because we're still working out the kinks in the "op model". In our benchmarks deno_tcp is still slower than node_tcpI want to fix that first before adding the native HTTP since it will be built on top of the same primitives.