Sylius
Add support for HTTP/2
This is a very highly voted feature request, so I just want to explain why it hasn't been worked on yet.
- There are perfectly good HTTP/2 proxies which provide most of the protocol upside without any changes to the application server
- Certain features which don't lend themselves to proxies, such as "server push" of related content, aren't part of the core Ring spec, and I don't have a strong opinion as to how the spec should be extended
Given both of these, this is a ways down my list of useful features to add to Aleph. If anyone has counterarguments against these, or additional points to raise, please feel free to comment on this thread.
I have a use case where HTTP/2 support would be very useful.
There are several HTTP server instances shadow-cljs (build tool for CLJS). All for development purposes. One for each browser build that just serves the static files and one "shared" server which handles the websocket connections used by the REPL clients. It is also used to live-reload files in a browser env.
I just added support for SSL in development since a few people asked for it.
It would be very neat if I could just turn on HTTP/2 as well. Don't need things like server-push.
Not a high priority since it works just fine without. Given that :none development builds easily download a couple hundred .js files HTTP/2 would be very beneficial.
@arnaudgeiser I've been working on this the past couple weekends, and I have a rough idea for how we should proceed.
tl;dr It'll be invisible for people who don't care about fancy HTTP/2 features, like prioritization and flow control. We'll go with some default policies that make sense, and the only thing they should notice is a speed boost. Maybe the only new HTTP/2 feature that the average user will care about are push promises, the ability to send "responses" without a request (like pushing a Js/CSS/image file you know they'll need, but there's a lot of caveats to getting this right re ordering/timing/caches).
For those who need to fiddle with all the knobs/buttons, I think we'll expose a new connection-level handler interface, where your handler has a view of all streams and requests, can make holistic decisions about response ordering, can handle prioritization requests, pause dependent streams (maybe), handle flow control for backpressure, etc.
@KingMob FWIW, HTTP/2 Server Push support was removed from Chromium last year because it didn't quite live up to its promise and wasn't used much in practice either (see post for details and links to further analyses). So if it makes implementation easier on your end, you can probably justify leaving it out.
This is what I get for being a Firefox guy. 😄 Thanks for sharing that, Moritz.
I knew it was tricky after reading https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0/edit, and planned to warn users in the docs before they tried it, but I figured it would be easy enough to implement if anyone wanted it. I assumed it would be low priority, but now it's even lower, I guess.
At the code level, I don't think it would be that hard to write/use, the hard part is doing it in a way that actually helps and not hurts, performance. I know servers like H2O have built cache-aware server push systems to mitigate the issue, but with limited resources, it might be better to focus on HTTP/3 and skipping this entirely.
Hmmm, now I better see what the status of prioritization is...though that's only advisory, not mandatory.