Migrating from aioquic to HTTP/3

[guest271314]

quic-transport references were removed from WebTransport specification. I have been using aioquic for 'quic-transport' URL protocol https://github.com/guest271314/webtransport/blob/main/quic_transport_server_tts.py. What needs to be modified to achieve the same result using aiohttp?

[webknjaz]

aiohttp does only supports HTTP/1.1. To support HTTP/2 and HTTP/3 somebody needs to step in and actually implement it. I have no idea how much effort it would take but since the current implementation is a C-extension, for the newer standards one would need to first find some C-implementation, write a wrapper using Cython, make an equivalent pure-Python implementation as a fallback, wire it all together and send as a PR.

[guest271314]

For now QuicTransport() still appears to be to available https://bugs.chromium.org/p/chromium/issues/detail?id=1011392, and Chrome has not implemented WebTransport of HTTP/3 https://bugs.chromium.org/p/chromium/issues/detail?id=1193409&q=component%3ABlink%3ENetwork%3EWebTransport. However, after reading the discussions the vote was made to use HTTP/3 for WebTransport, so I want to be prepared for the case of more moving targets. Perhaps I mistakenly considered this as already HTTP/3 supported because I installed this when tentatively testing aiortc.

[guest271314]

QuicTransport interface is slated for removal https://bugs.chromium.org/p/chromium/issues/detail?id=1011392#c67. It would be helpful if individuals that are already using QuicTransport and quic-transport URL in WebTransport https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport have code ready to migrate. I am willing to help in any way I can in this effort (I learned all the Python I know experimenting with QuicTransport and WebTransport).

[ViktorSky]

Implementing HTTP/2 and HTTP/3 in aiohttp will be a good idea, because it will allow the development of current technologies, especially for aiohttp.web, since it is considered the fastest in python

[Dreamsorcerer]

especially for aiohttp.web

This is the least likely place we'll care about supporting it. Applications should be deployed behind a reverse proxy (e.g. nginx), and that will handle the HTTP/2+ connection with the client. Supporting it in aiohttp server-side provides very little benefit.

[guest271314]

I was experimenting with QuicTransport in Chromium, then that became WebTransport and at some point I couldn't get aioquic to work anymore https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport. Since then I've been using Deno in Deno Deploy for an HTTP/2 server https://gist.github.com/guest271314/d20b2a2924d0e2e0c333c01d8b8acace. Both Deno and Node.js support full-duplex streaming over WHATWG Fetch https://github.com/guest271314/native-messaging-deno/tree/fetch-duplex. No browser does. The closest we get is between a ServiceWorker and a WindowClient on Chromium-based browsers, which does achieve full-duplex streaming. Good luck!