Cowboy 2.0 rc1 out

Chat / Discussions
1

Cowboy, the Erlang web server that powers Phoenix Framework (among many others projects!), is nearing its long-awaited 2.0 release. The announcement is here:

https://ninenines.eu/articles/cowboy-2.0.0-rc.1/

with more details on the changes from 1.x here:

https://ninenines.eu/docs/en/cowboy/2.0/guide/migrating_from_1.0/

HTTP2, improved compression (including on websockets), and quite a bit more. I can only imagine this will be a very nice improvement to a future version of Phoenix!

9 Likes
2

Interesting!
Well, not a lot of features to be excited about though. HTTP/2 is not that good-all-around, QUIC is not there yet, and HTTP 1.1 performance seems like lowered a bit

1 Like
3

HTTP/2 is not good as a protocol or not well implemented in this cowboy release candidate?

4

No idea about cowboy implementation, it should be all right. Protocol itself provides not too many benefits at this moment, performance boost is at most on single-digits percent level e.g. and its advanced features (like ability to send some resources even before browser requests them) are far from being used anyhow. Also it comes with some security concerns - no idea is it fixed or even can be fixed, but there was an issue with compression - HTTP/2 allows to compress everything including headers, and, you know, zip-bombs are the thing.

1 Like
5

I really really want this ability, like really badly. It would quite simplify some work of mine.

Not any worse then it already is.

Plus having TLS setup in the initial handshake is really nice. ^.^

1 Like
6

What kind of work would it simplify?

I’m in the process of collecting compelling real world usecases for HTTP/2

7

At work the system is built up as a set of html files that contain a web component and javascript and all, self-contained. They may reference others that may or may not have already been included as well. So right now the site grabs the first set of imports and brings them in, then it sees those need more, and then those need more, and then those need more, all in a certain order they need to be resolved.

I know ‘most’ of what is needed at the start and there are two things I can do in HTTP1 to help fix the loading time:

  1. I can add the imports to the first template dynamically in the right order (more than a bit painful, but doable), but that does not help ones that are loaded dynamically later.
  2. I can use a tool to munge ‘sets’ altogether, which is what I’m doing now, problem is that different pages need different ‘sets’, so I have to make lots of baked sets of them (if I included the entire site it would not be as small and different departments should not even get html/javascript code of other departments because they told me to, plus certain parts change often so it would be regenerated often).

In HTTP2 it is just telling the client ‘you need all of this’ and just have the single import load the first and all the rest load in the proper order based on what is needed and since I’ve already sent it all to the browser it loads up about instantly while taking a lot less traffic since the headers and such count add up over lots of tiny files, and all done in a single request.