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 · 18 comments

Comments

Projects
None yet
10 participants
@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

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

schneems commented Feb 19, 2014

Are there other HTTP 2.0 implementations to copy from?

Good question.

@westonplatter

This comment has been minimized.

@westonplatter

This comment has been minimized.

westonplatter commented Mar 8, 2014

@nateberkopec

This comment has been minimized.

Member

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

This comment has been minimized.

Member

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 referenced this issue Jul 24, 2015

Closed

http/2 support? #746

@dblooman

This comment has been minimized.

dblooman commented Nov 26, 2015

Any updates on this?

@deepj

This comment has been minimized.

Contributor

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

This comment has been minimized.

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

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment