HTTP2: Are we there yet?

[Tiago Cardoso]

Hi, I've been looking for developments in the rack framework concerning its update towards great big http2. I've seen the presentation from Aaron Patterson from October/November, and since then, only seen the events middleware landing in master. And there's an alpha 2.0 version. 

I assume that http2 won't come with 2.0 . Still, I'd like to know where we stand, what's missing for rack to develop further in that direction and where could I help/contribute. Hopefully there's a document someone can redirect me to. 

I'm really looking forward to hearing from someone, possibly Mr. Patterson, who's clearly been working in this. I think ruby needs http2 badly. I think that all other standards for pushing server-to-client/full-duplex/pipe-in-my-json will die after widespread adoption, like image spriting and all those HTTP1 performance "enhancements". I think that the ruby frameworks don't need and should not enforce websockets, specially for thing it was not designed for. I think ActionCable is crap. And just as Rails, I am entitled to an opinion, and would like to try to force it into people's throats. And I'd like to force http2 and consider myself a better human being after that.

Only thing I found was this: https://groups.google.com/forum/#!topic/rack-devel/lipvWVZrcfo and after the author left the project. What's the status?

Really appreciate any feedback,
Tiago

[James Tucker]

On Fri, Jan 15, 2016 at 2:28 PM, Tiago Cardoso <honeyry...@gmail.com> wrote:

Hi, I've been looking for developments in the rack framework concerning its update towards great big http2. I've seen the presentation from Aaron Patterson from October/November, and since then, only seen the events middleware landing in master. And there's an alpha 2.0 version. 

I assume that http2 won't come with 2.0 . Still, I'd like to know where we stand, what's missing for rack to develop further in that direction and where could I help/contribute. Hopefully there's a document someone can redirect me to. 

First of all, the Rack SPEC is not incompatible with http2 today. You can use Rack in an http2 server.

What does not exist is new mappings for a server push API. Note that promises (server push) is only additional responses shipped alongside a response. It is not a general IO mechanism.

Rack is primarily a framework/interface layer between Ruby webservers and Ruby web applications, as implemented today. That means it's really focused on the HTTP parts, and while http2 can carry other protocols, I would expect that Rack should probably remain an interface layer for http1 over http2, not * over http2. It's conceivable that something could move into such a space, and maybe that could be called Rack, but it would be an entirely different specification, with entirely different goals and complexities.

The synchronous single-call design of the Rack SPEC will always be a problem for fuller http2 services (e.g. grpc) as they are not request response protocols and don't fit into that model. In the same way, as that doesn't fit, none of the middleware fits either. I wrote about this years ago.

I'm really looking forward to hearing from someone, possibly Mr. Patterson, who's clearly been working in this. I think ruby needs http2 badly. I think that all other standards for pushing server-to-client/full-duplex/pipe-in-my-json will die after widespread adoption, like image spriting and all those HTTP1 performance "enhancements".

http2 does not offer full-duplex for web applications today. No browser exposes server push to javascript or anything like that, and even websockets over http2 is as yet undefined - there's only a spec that's been dead for over a year and a half. You can use SSE over http2 today, and if you were using an HTTP2 enabled Rack compatible server, SSE like this would work. In fact, not only "would work", but does work. I use nginx to terminate http2 today, and have http1 rack backends running SSE like this in the wild, and it works just fine.

 

I think that the ruby frameworks don't need and should not enforce websockets, specially for thing it was not designed for. I think ActionCable is crap. And just as Rails, I am entitled to an opinion, and would like to try to force it into people's throats. And I'd like to force http2 and consider myself a better human being after that.

I've been down this battle with realtime ruby for years, and so did the author of node before he went and wrote node. That's part of where that came form. The fact that ActionCable relies on EventMachine makes me really quite sad as we've largely stopped maintaining that for important reasons for a long time. The real issue here is that we've never had any good SPEC proposals for specs that handle realtime well, and we have tons of streaming bugs in the core middleware. We fixed a lot of them over the last two years, but I'm sure there are more. Things like the Content-Length and Chunking middleware should *never* have existed, and the fact that they do is an ongoing problem for server authors venturing into this domain.

Realtime sockets are also very hard to load balance and scale, and while that might not be actioncables concern, it's a concern for real users in the wild. What most people do today who do this stuff is use external services, rather than putting such things in their monoliths. Users already have very real load balancing problems with high standard deviation response rates and sadly as in the linked example, they often fail to understand the issues here. While some work has gone into better open source load balancers, we still have a long way to go to match up with commercial offerings, and in fact the linked stuff is at least partially commercial only. If you're not using a third party service for realtime persistent sockets, then you'll probably want to use a separate service, because of the many challenges inherent with otherwise muxing it in through your primary serving routes, and indeed that's what we all do.

Only thing I found was this: https://groups.google.com/forum/#!topic/rack-devel/lipvWVZrcfo and after the author left the project. What's the status?

It's not going anywhere because no one is stepping up to do it. Please understand that stepping up to do it means actually getting something working that works for a wide array of use cases, not just putting your hand in the air and saying "I'll do it" - just that we've seen that many times, even I did that once and I knew better than to volunteer so much of my free time.

I don't mean to discourage you though, I would really love to see this happen and if you have the time to start writing test cases and developing a real API for this, I'd be more than happy to provide guidance and feedback. That goes for everyone else too, and it's not the first time I've said it. As with the above, no ones yet taken up the offer.

Really appreciate any feedback,
Tiago

--

---
You received this message because you are subscribed to the Google Groups "Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Wong]

I experimented on it over a year ago with yahns to run Rack apps.
However I could not stay interested enough to deal with all the
corner cases (denial-of-service potential, fairness) with
multiplexed app dispatch for a single TCP connection:

http://yhbt.net/yahns-public/20141220222...@dcvr.yhbt.net/t/
yahns: http://yahns.yhbt.net/README

As one may infer from the above URLs; I absolutely detest the use of
JS, CSS and unnecessary graphics. HTTP/2 isn't at all useful to me.

It's still mildly interesting on a technical level; so maybe I'll
take some time to revisit it after Let's Encrypt matures...

[Aaron Patterson]

On Fri, Jan 15, 2016 at 02:28:46PM -0800, Tiago Cardoso wrote:
> Hi, I've been looking for developments in the rack framework concerning its
> update towards great big http2. I've seen the presentation from Aaron
> Patterson from October/November, and since then, only seen the events
> middleware landing in master. And there's an alpha 2.0 version.
>
> I assume that http2 won't come with 2.0 . Still, I'd like to know where we
> stand, what's missing for rack to develop further in that direction and
> where could I help/contribute. Hopefully there's a document someone can
> redirect me to.
>
> I'm really looking forward to hearing from someone, possibly Mr. Patterson,

Right now, my rough plan is:

Add a new key / value pair to the env hash where the value is an object
that, when called, does server push. The webserver is responsible for
implementing what that means (my current experiments will re-issue a
request to the app server, so the application can't tell the difference
between a request that originated from a browser vs a request that
originated from a push). This will give us server push (which is
the only thing that h2 does differently than h1 from Rack's
perspective) while maintaining backwards compatibility. Probably Rack 3
will diverge from hashes everywhere, but this should work for now.

Other stuff that h2 does, like keeping the connection alive, header
compression, etc isn't Rack's concern.

--
Aaron Patterson
http://tenderlovemaking.com/

[James Tucker]

On Jan 15, 2016 5:25 PM, "Aaron Patterson" <tende...@ruby-lang.org> wrote:
>
> On Fri, Jan 15, 2016 at 02:28:46PM -0800, Tiago Cardoso wrote:
> > Hi, I've been looking for developments in the rack framework concerning its
> > update towards great big http2. I've seen the presentation from Aaron
> > Patterson from October/November, and since then, only seen the events
> > middleware landing in master. And there's an alpha 2.0 version.
> >
> > I assume that http2 won't come with 2.0 . Still, I'd like to know where we
> > stand, what's missing for rack to develop further in that direction and
> > where could I help/contribute. Hopefully there's a document someone can
> > redirect me to.
> >
> > I'm really looking forward to hearing from someone, possibly Mr. Patterson,
>
> Right now, my rough plan is:
>
> Add a new key / value pair to the env hash where the value is an object
> that, when called, does server push.  The webserver is responsible for
> implementing what that means (my current experiments will re-issue a
> request to the app server, so the application can't tell the difference
> between a request that originated from a browser vs a request that
> originated from a push).  This will give us server push (which is
> the only thing that h2 does differently than h1 from Rack's
> perspective) while maintaining backwards compatibility.  Probably Rack 3
> will diverge from hashes everywhere, but this should work for now.

I'd been thinking about this being something that will just ask the server to redispatch a new request to get the content.

>
> Other stuff that h2 does, like keeping the connection alive, header
> compression, etc isn't Rack's concern.
>
> --
> Aaron Patterson
> http://tenderlovemaking.com/
>

[Samuel Williams]

I've thought about these issues too.

I don't think there is anything wrong with Rack. It could be tidied up a bit and it's good, IMHO, that it's entered maintenance mode. Not much needs to change IMHO. It's solid. Big changes here will only cause chaos.

In my mind, HTTP2 is more about communication between client and front-end server. If the application server implements HTTP1 that's fine. Let's face it, in production we don't usually use Rack to serve static files, etc.

Additionally, in my mind, an HTTP application server is no place for real-time communication. They are two separate concerns. For example, we have a real-time web chat system which implements a real-time run-loop using multiple event-driven reactors. It still communicates with a backend database using the same code as our application server, but it works in a way which can scale to 1000s of active connections per instance.

I think that trying to shoehorn these orthogonal concerns into Rack is probably a bad idea in general and will just destroy the original beauty of `response = app.call(env)`.

I'd prefer to see Rack evolve in a way which makes it better as an application server for request/response type workloads. If we need to augment that with something else, let's figure that out in a different framework?