It's so cool to have this split. QUIC is so capable, such a neat set of ideas for a transport. That HTTP can express itself in terms of another spec is one of the most compelling, longest-hardest won & best victories for "abstraction" that computing has seen. That we'll be able to iterate on HTTP in new ways, by having a common semantic base, keeps the future open & iterable. Huge wins.
Obligatory link to Mark Nottingham's "A New Definition of HTTP3"[1], which talks about the split of HTTP into a semantic definition in RFC9110[2] & the creation of HTTP2/RFC9113 and HTTP3 (over QUIC, this document).
> It's so cool to have this split. QUIC is so capable, such a neat set of ideas for a transport.
That's what I thought too. A while ago, I wanted to use it in an Android app. I thought this was going to be a no-brainer. After all, Google more or less invented QUIC as SPDY about a decade ago. To my understanding, since they just YOLO'd it they agreed to form a proper working group and create quic. So here we are, ten years later, Google is heavily using quic for all their web stuff, and I naively assumed that Android would've had a native quic implementation for a while now, either directly in the SDK/runtime, or some first party library from Google. Nada. There is cronet, the networking engine of chrome as a library, which does speak quic but only exposes classes and functions to speak http, so you cannot even use its quic implementation directly. I went on and had to use some C library and JNI to do it, which is just ridiculous.
Sorry for this tangentially related vent, I'm still in disbelief.
That's what I thought too. A while ago, I wanted to use it in an Android app. I thought this was going to be a no-brainer. After all, Google more or less invented QUIC as SPDY about a decade ago. To my understanding, since they just YOLO'd it they agreed to form a proper working group and create quic. So here we are, ten years later, Google is heavily using quic for all their web stuff, and I naively assumed that Android would've had a native quic implementation for a while now, either directly in the SDK/runtime, or some first party library from Google. Nada. There is cronet, the networking engine of chrome as a library, which does speak quic but only exposes classes and functions to speak http, so you cannot even use its quic implementation directly. I went on and had to use some C library and JNI to do it, which is just ridiculous.
Sorry for this tangentially related vent, I'm still in disbelief.