HTTP 2.0

[westonplatter]

I hope I'm not jumping the gun.

I started to use Puma 2 weeks ago in production and love it.

And so I wondered if HTTP 2.0 for Puma was on the feature list or maybe already in the works. After scanning the Github issues, I didn't find mention of HTTP 2.0. Therefore, I'm opening this issue to stir conversation regarding HTTP 2.0 features realizing they are far off, but still tantilizingly important.

Possibly important questions:

• when should (if at all) puma make the advancement to HTTP 2.0?
• what features are easy to get working?
• what featurs are the most painful?
• are there outstanding Puma issues to solve first?
• are there other HTTP 2.0 implementations to copy from?

Happy to move the conversation else where if another communication channel is more appropriate. :)

[evanphx]

I'd love to get started on HTTP 2.0 support! It's not in the works yet but I've been thinking it would be nice/fun to have early support. For me, it's been a matter of finding time. If you want to get started, dig in!

I'm mostly focused on bug fixes and stability right now, so that people have confidence in puma.

[westonplatter]

Cool. I'll come back for a HTTP 2.0 party after I finish contirbutions to a couple other repos.

[schneems]

Are there other HTTP 2.0 implementations to copy from?

Good question.

[westonplatter]

@schneems, here's a couple off the top of my head,

• https://github.com/igrigorik/http-2
• https://github.com/molnarg/node-http2 (pulls in https://github.com/molnarg/node-http2-protocol)

[westonplatter]

@schneems a more complete list, https://github.com/http2/http2-spec/wiki/Implementations.

[nateberkopec]

Is it time to start the HTTP/2 party yet?

Here's @tenderlove's HTTP2 webrick server: https://gist.github.com/tenderlove/79e7e0de4b2097e43356

And here's his HTTP2 server with Puma!: https://gist.github.com/tenderlove/d68d9a3c4f7941192c9b

[evanphx]

@tenderlove and I have been discussing it! @tenderlove, do you want me to
start looking at add support directly to Puma's core?

On Thu, Jul 23, 2015 at 6:03 AM, Nate Berkopec notifications@github.com
wrote:

Is it time to start the HTTP/2 party yet?

Here's @tenderlove https://github.com/tenderlove's HTTP2 webrick
server: https://gist.github.com/tenderlove/79e7e0de4b2097e43356

And here's his HTTP2 server with Puma!:
https://gist.github.com/tenderlove/d68d9a3c4f7941192c9b

—
Reply to this email directly or view it on GitHub
#454 (comment).

[dblooman]

Any updates on this?

[deepj]

@evanphx Any plans to add HTTP/2 support into Puma in near future? It'd be worth having the support in those days.

[dmccown1500]

Hey all wanted to revisit this since it has not been talked about in a bit. Particularly I am wondering if it is readily possible to @tenderlove's implementation as a plugin or config option that would allow for the core puma to stay HTTP 1.1 and open up 2.0 support for those that want it. I will admit I do not have the knowledge or expertise for this as a PR, sorry!

[nateberkopec]

Not to self promote my own article here, but for those wondering why HTTP/2.0 isn't available on your application-server-of-choice yet, you may want to read this.

TL;DR: This problem really needs to be solved at the Rack level before Puma can support HTTP/2 meaningfully. Use an HTTP/2.0 enabled CDN and/or reverse proxy to get 80% of the benefits of HTTP/2 today.

[dmccown1500]

@nateberkopec Thamnks for the fast response. I will take a look at the article and see what I can learn. :-)

[evanphx]

Nate's points are (as is to be expected from Nate) right on. Right now, no rack apps are setup to really get much out of HTTP 2.0 so even if puma supported it, you wouldn't likely see much benefit.

Now, you could make the argument that if Puma did have it, that would push Rails et. al to add support for it. So basically I do think something along these lines will eventually happen it's just pretty low priority right now.

[dmccown1500]

@nateberkopec Great read. I think I am probably actually getting a lot of the benefits of HTTP/2.0 now since Cloudflare sits in front of my site. @evanphx makes sense and I appreciate the feedback.

[mcary]

When using a CDN or loadbalancer/web server like Apache, a Rack or Rails app can send "Link" headers with "rel=preload" to trigger server pushes. That's one way that you can get much of the HTTP2 benefit without actually terminating HTTP2 in your app server. But your app server has to know to send the "Link" headers. So either you have to write code to set response.headers or maybe someday Rails will automatically emit them when your code calls asset helpers or something.

HTTP2 Push with:
Cloudflare: https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/
Apache: https://httpd.apache.org/docs/2.4/mod/mod_http2.html#h2push

It might be cool if the application server (such as Rails) could keep its context from the base HTML request when rendering the assets, at least if they are customized per user or something. But that seems like a relatively minor optimization for an uncommon scenario. Terminating HTTP2 at the CDN or loadbalancer would not enable that sort of thing.

And, as @nateberkopec suggests, HTTP2 could replace WebSockets functionality. That also cannot be accomplished with termination at the CDN or loadbalancer.

[philsturgeon]

Curious if anything has changed in the last 13 months regarding this situation? It seems like Rack 2.0 did not add HTTP 2, or at least I don't see it in the CHANGELOG and cannot find anything about it on Google.

We're just waiting on Rack?

[CrowdHailer]

I would also be curious about the progress on this. I have been building a solution for Elixir based on Rack and would like to see what solution Rack decided on

[nateberkopec]

I'll link #1403 here, as this is probably the most concrete progress we've made on HTTP 2 features in the last year.

[pedrofurtado]

Is there any plans to add Http2?

[philsturgeon]

@pedrofurtado I've heard a lot of good things about Falcon.

[pedrofurtado]

Thanks for share, @philsturgeon 👍

[darkBuddha]

any news about HTTP2?

[alfuken]

Hello from 2022 👋

[tham-tms]

Hello from 2023

[nateberkopec]

See #2697