On Fri, Feb 16, 2024 at 12:29 AM Kazuho Oku <[email protected]> wrote: > > Hello QUIC and HTTP enthusiasts, > > We, Lucas and I, have submitted two drafts aimed at broadening the reach of > HTTP/3 - yes, making it available over TCP as well. We are eager to hear your > thoughts on these:
> > Some might argue that implementing a polyfill of QUIC comes with its own set > of costs. However, it is my understanding that many QUIC stacks already have > the capability to read QUIC frames other than from QUIC packets, primarily > for testing purposes. This suggests that the effort would be more about > leveraging existing code paths rather than writing new code from scratch. > Furthermore, a QUIC polyfill would extend its benefits beyond just HTTP, by > aiding other application protocols that aim to be built on top of QUIC, > providing them accessibility over TCP. I have some mild skepticism about this design. Each QUIC extension now has to consider TCP transport, vs. each HTTP extension considering H2 or H3. However I think the necessary change isn't that much for QUIC over TCP vs. H2/H3, unless the extension does a lot of the prohibited things. You don't however get much improvement: H2's TCP related limitations remain. Is this need for a choice supposed to also apply to non-HTTP QUIC applications? Sincerely, Watson
