rack-devel archive mirror (unofficial) https://groups.google.com/group/rack-devel
 help / color / mirror / code / Atom feed
* HTTP2: Are we there yet?
@ 2016-01-15 22:28 Tiago Cardoso
  2016-01-15 23:00 ` James Tucker
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Tiago Cardoso @ 2016-01-15 22:28 UTC (permalink / raw)
  To: Rack Development


[-- Attachment #1.1: Type: text/plain, Size: 1698 bytes --]

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

-- 

--- 
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 2056 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: HTTP2: Are we there yet?
  2016-01-15 22:28 HTTP2: Are we there yet? Tiago Cardoso
@ 2016-01-15 23:00 ` James Tucker
  2016-01-16  1:15 ` Eric Wong
  2016-01-16  1:25 ` Aaron Patterson
  2 siblings, 0 replies; 6+ messages in thread
From: James Tucker @ 2016-01-15 23:00 UTC (permalink / raw)
  To: Rack Development

[-- Attachment #1: Type: text/plain, Size: 6429 bytes --]

On Fri, Jan 15, 2016 at 2:28 PM, Tiago Cardoso <honeyryderchuck@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
<https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01>.
You can use SSE over http2 today, and if you were using an HTTP2 enabled
Rack compatible server, SSE like this would work
<https://gist.github.com/raggi/ff7971991297e5c8a1ce>. 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
<http://genius.com/James-somers-herokus-ugly-secret-annotated> 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
<https://www.nginx.com/blog/choosing-nginx-plus-load-balancing-techniques/>,
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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 8385 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: HTTP2: Are we there yet?
  2016-01-15 22:28 HTTP2: Are we there yet? Tiago Cardoso
  2016-01-15 23:00 ` James Tucker
@ 2016-01-16  1:15 ` Eric Wong
  2016-01-16  1:25 ` Aaron Patterson
  2 siblings, 0 replies; 6+ messages in thread
From: Eric Wong @ 2016-01-16  1:15 UTC (permalink / raw)
  To: rack-devel

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/20141220222515.GA28045@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...

-- 

--- 
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: HTTP2: Are we there yet?
  2016-01-15 22:28 HTTP2: Are we there yet? Tiago Cardoso
  2016-01-15 23:00 ` James Tucker
  2016-01-16  1:15 ` Eric Wong
@ 2016-01-16  1:25 ` Aaron Patterson
  2016-01-16  2:13   ` James Tucker
  2 siblings, 1 reply; 6+ messages in thread
From: Aaron Patterson @ 2016-01-16  1:25 UTC (permalink / raw)
  To: rack-devel

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

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/

-- 

--- 
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: application/pgp-signature, Size: 455 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: HTTP2: Are we there yet?
  2016-01-16  1:25 ` Aaron Patterson
@ 2016-01-16  2:13   ` James Tucker
  2016-08-09  3:02     ` Samuel Williams
  0 siblings, 1 reply; 6+ messages in thread
From: James Tucker @ 2016-01-16  2:13 UTC (permalink / raw)
  To: Rack Development

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

On Jan 15, 2016 5:25 PM, "Aaron Patterson" <tenderlove@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/
>
> --
>
> ---
> 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 3207 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: HTTP2: Are we there yet?
  2016-01-16  2:13   ` James Tucker
@ 2016-08-09  3:02     ` Samuel Williams
  0 siblings, 0 replies; 6+ messages in thread
From: Samuel Williams @ 2016-08-09  3:02 UTC (permalink / raw)
  To: Rack Development


[-- Attachment #1.1: Type: text/plain, Size: 1611 bytes --]

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?

-- 

--- 
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 1953 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-08-09  3:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-15 22:28 HTTP2: Are we there yet? Tiago Cardoso
2016-01-15 23:00 ` James Tucker
2016-01-16  1:15 ` Eric Wong
2016-01-16  1:25 ` Aaron Patterson
2016-01-16  2:13   ` James Tucker
2016-08-09  3:02     ` Samuel Williams

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/rack.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).