h2/h3

[jbr]

As a long term goal, I'd like to look into h2 and h3. I really don't want to write my own implementation of these, but I'm not sure how hard it will be to fit existing implementations into the conn model.

[marknefedov]

Are you planning add support to http crate (as dependencies) or separate them?

[jbr]

Not sure if I'm answering the right question, but a few early thoughts:

I haven't put a lot of consideration into the details of the implementation, as I haven't closely read the spec(s) yet. h2 would almost certainly involve changes to the trillium-http crate, but I'm not sure if it would be best to split it into a distinct crate or to incorporate the implementation into that crate. h3 would necessitate changes to the runtime adapter crates as well, I think, since quic isn't tcp.

If trillium can use the existing h2/h3 implementations, that would be ideal. I'm not sure if the "owned transport inside of a conn instead of a request→response" approach can be used cleanly with the existing protocol implementations, but the first step will be trying that.

Generally, though, my thoughts about sequencing this are that first I want to flesh out trillium as a core-feature-complete http/1.x framework/ecosystem/toolkit and see how people are using it before shifting attention to internals like h2/3 (and http/1.x performance, which is still just a first pass and probably can be significantly improved)

[mleonhard]

HTTP/2 and HTTP/3 are unnecessarily complicated binary protocols. Their primary benefit is a tiny performance improvement. Their cost is large:

• More code to maintain
• More bugs
• More security problems
• Much more effort to debug production issues. Debugging binary HTTP will be difficult like debugging TLS.
• Much much harder to get an end-to-end understanding of systems that use HTTP-RPC

These costs are very heavy for startups, hobbyists, and non-tech organizations. They are an ongoing tax due to added complexity. This slows down startups and hobbyists and therefore harms innovation. Slowing down innovation makes our species less rich. It harms human society.

Large companies created HTTP/2 & 3 and they benefit from it. The tiny performance improvement translates into hardware and bandwidth savings. Those organizations are large and can easily pay engineers to deal with the new protocols. Most of their engineers work with internal RPC protocols and are completely unaffected by an external switch from HTTP/1.1 to HTTP/2 & 3.

Cloud providers benefit from HTTP/2 & 3 by selling products that solve the new pain. Pushing complicated new protocols and then selling services to make them usable is rent-seeking behavior.

Large companies also benefit immensely from harming innovation. Fewer startups means fewer competitors.

Therefore, HTTP/2 & 3 are wins for large organizations and cloud providers, and losses for the rest of us.

Please do not support HTTP/2 or HTTP3 in Trillium.

We need a new text-based HTTP version that removes unused and problematic features, simplifies the protocol where possible, and changes it to improve privacy and security.

[jbr]

h2 and h3 would be opt-in, either as a distinct crate or a cargo feature flag, so you'd be able to use trillium with just http/1 support just as you can today. That said, adding h2/h3 is a lot of work, so it's fairly low down on my personal priority list.

[joshtriplett]

@jbr FWIW, I think there'd be a lot of value in skipping over HTTP/2 and just supporting 1.1 and 3. HTTP/1.1 for backwards compatibility for clients that don't support it or broken networks that don't support UDP, and HTTP/3 for anything modern. HTTP/2 is in that marginal space in between, and doesn't seem worth as much effort to support.

[justforcomment]

Hello, @mleonhard ! =)

I think that there is some rational grain in your arguments. Although, given the dislikes, some took your words too radically.

I don't have enough personal experience to form such conclusions on my own. Could you share links to similar discussions?