Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP 2.0 #454

Closed
westonplatter opened this issue Feb 6, 2014 · 22 comments
Closed

HTTP 2.0 #454

westonplatter opened this issue Feb 6, 2014 · 22 comments

Comments

@westonplatter
Copy link

@westonplatter westonplatter commented Feb 6, 2014

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
Copy link
Member

@evanphx evanphx commented Feb 6, 2014

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
Copy link
Author

@westonplatter westonplatter commented Feb 6, 2014

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

@schneems
Copy link
Contributor

@schneems schneems commented Feb 19, 2014

Are there other HTTP 2.0 implementations to copy from?

Good question.

@nateberkopec
Copy link
Member

@nateberkopec nateberkopec commented Jul 23, 2015

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
Copy link
Member

@evanphx evanphx commented Jul 23, 2015

@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).

@spk spk mentioned this issue Jul 24, 2015
@dblooman
Copy link

@dblooman dblooman commented Nov 26, 2015

Any updates on this?

@deepj
Copy link
Contributor

@deepj deepj commented Mar 25, 2016

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

@dmccown1500
Copy link

@dmccown1500 dmccown1500 commented Aug 3, 2016

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
Copy link
Member

@nateberkopec nateberkopec commented Aug 3, 2016

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
Copy link

@dmccown1500 dmccown1500 commented Aug 3, 2016

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

@evanphx
Copy link
Member

@evanphx evanphx commented Aug 3, 2016

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
Copy link

@dmccown1500 dmccown1500 commented Aug 3, 2016

@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
Copy link

@mcary mcary commented Aug 4, 2016

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
Copy link

@philsturgeon philsturgeon commented Sep 21, 2017

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
Copy link

@CrowdHailer CrowdHailer commented Oct 16, 2017

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
Copy link
Member

@nateberkopec nateberkopec commented Oct 16, 2017

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
Copy link

@pedrofurtado pedrofurtado commented Feb 26, 2019

Is there any plans to add Http2?

@philsturgeon
Copy link

@philsturgeon philsturgeon commented Feb 26, 2019

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

@pedrofurtado
Copy link

@pedrofurtado pedrofurtado commented Feb 26, 2019

Thanks for share, @philsturgeon 👍

@darkBuddha
Copy link

@darkBuddha darkBuddha commented Jan 4, 2021

any news about HTTP2?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet