radix•

Kazu Yamomoto has done an amazing job! Not just HTTP/2, but ALPN, ECDHE, and AES GCM... A lot of popular languages out there do not yet have all these features in their ecosystem. I'm glad to see Haskell in a leading position. :)

37
dpwiz•

The only missing piece is TLS SNI (to ditch nginx completely and switch to unproxied keter).

8
mallai•

I liked this part: "So, if you upgrade Warp and WarpTLS in your site serving TLS and anyone visits your site with Firefox or Chrome, your contents are automatically transferred via HTTP/2 over TLS.". There's nothing better than "free lunch" :-).

13
bos•

Kazu knocks it out of the park yet again. Very impressive work.

12
semigroup•

I asked this on the web dev list too, but will there be support added to WAI for server push? (https://www.igvita.com/2013/06/12/innovating-with-http-2.0-server-push/)

Obviously it would break the current model of an Application being (Request -> IO Response), but it seems like one of the crucial improvements that HTTP/2 provides.

3
Vektorweg•

Is it just me or is HTTP/2 a bad idea?

Great work that Warp supports HTTP/2 but somehow I wish it wouldn't.

-3†
Vektorweg•

I really would like to know what the arguments of the downvoters are.

What problems do HTTP/2 solve? Support your creepy overloaded websites working on hundreds of seemingly useless single files where you usually go host them on separate domains to save some bytes of header space? Thats crazy. The problem is your website and not the transfer protocol.

HTTP/2 is useless and complicated. HTTP/1 was designed for simplicity and now decades later we know by today how we could make an easier and sufficiently efficient protocol. But no, let us go down and confuse their protocol so they will only be few to implement it.

3†
focuskids•

what the arguments of the downvoters are.

This is a release of the Warp web server, not a "rehash finalized IETF decisions" forum.

What problems do HTTP/2 solve?

  • Allow servers to handle more concurrent users by reducing TCP connections
  • Reduce latency, round trips, and total network IO.
  • Reduce need for DNS hacks to parallelize connections.
  • Reduce overall DNS requests.

Support your creepy overloaded websites working on hundreds of seemingly useless single files where you usually go host them on separate domains to save some bytes of header space?

Like a fun video game? A mapping application? A CAD modelling tool? Those things use lots of javascript and lots of assets -- graphics, data, etc. Why is that creepy or crazy? Why should that use case not be supported?

5
Vektorweg•

Thank you for your answer.

Reduce latency, round trips, and total network IO.

It just compresses headers, which is not the solution for this header mess, and multiplexes it over one connection. But multiple TCP connections isn't a critical problem. Also pipelining is already done in HTTP/1.1. HTTP/2 can't get it much faster than that.

Allow servers to handle more concurrent users by reducing TCP connections

But this only works well for us, because Haskell can serve multiple streams well. Its difficult for other-PL users to implement good schedulers (especially ones optimized for the web application) and still provide a good API for it. Also note that in HTTP/2 the client decides what should be send first, which totally breaks all benefits your server could bring in from good concurrency.

Reduce need for DNS hacks to parallelize connections.

Reduce overall DNS requests.

Is this an accountable issue? Especially when DNS is cached by default?

Like a fun video game? A mapping application? A CAD modelling tool? Those things use lots of javascript and lots of assets -- graphics, data, etc. Why is that creepy or crazy? Why should that use case not be supported?

Now we need to talk about the purpose of the web. In how far is the web just an information source or a real application? And the question is still open: how will HTTP/2 work better than HTTP/1.1?

4
radix•

You're overtly conflating the idea of "not up to my standards" with "not better than HTTP/1.1". It's better than HTTP/1.1 in many measurable ways, and you're outright ignoring them.

5
[deleted]•

[deleted]

1
WarDaft•

Like HTML, JavaScript, and CSS, I sincerely doubt we'll be able to replace HTTP with something sane, no matter how hard we try. With work you can make it efficient, but if you strike out on your own you'll only be able to talk to yourself, and that's just crazy.

The work done on Warp here allows us to ignore these concerns and work in a magical kingdom where everything is simply better without expending any additional effort on our parts. Could it be even better at some layer? Yes, but if we as a species possessed the capability stop and rationally pick the best overall option, the world wold not look like it does now.

4
Vektorweg•

I have some hidden fear that our descendants will not understand how things work. And I think that this could be a big problem for them.

2
WarDaft•

I don't see how our descendants are any different from someone now who doesn't understand the core but is a new hire on a project. At least it's written in Haskell which provides a huge safety net for someone trying to understand it.

1
Taladar•

The streams here are no more complicated than the similar mechanism that has been used in the SSH protocol for years.

Implementers don't seem to have any trouble understanding that one.

1