Quic HTTP/3 support

[davfsa]

Is your feature request related to a problem?

No response

Describe the solution you'd like

Quic HTTP/3 support in both the client and server to aid with speed. This might also require HTTP/2 support first

Describe alternatives you've considered

N/A

Related component

Server, Client

Additional context

HTTP/3 Draft: https://quicwg.org/base-drafts/draft-ietf-quic-http.html

Code of Conduct

• I agree to follow the aio-libs Code of Conduct

[davfsa]

After looking at past issues and the amount of effort it would take to implement both HTTP/2 and HTTP/3, I am not sure if this will ever be implemented.

Things that I have found that should be done to be able to support them:

• Move away from http-parser as it doesnt support HTTP/2 and is not actively maintained (Maintainer notice nodejs/http-parser#522).
  • An alternative that is suggested is https://github.com/nodejs/llhttp, which has Python binds written in C that could be used (https://github.com/pallas/pyllhttp)
• A bit of a rewrite of some parts of the library to support different HTTP versions
  • Not sure how big this might be, but it is probably quite big
• Understand and implement HTTP/2 and HTTP/3

I would be willing to try and kickstart this with my limited knowledge, hopefully learning new things as I do so, but would like to get the green light before :)

[Dreamsorcerer]

Indeed, it will need someone to volunteer time to implement. I'm not familiar with any of the HTTP stuff, but someone else here will probably be able to provide guidance.

llhttp is in #5364. So, you could probably fork off that PR. If that's needed to add support for HTTP/2/3, then it's probably a good reason to get that merged.

Also worth pointing out that we only really care about this on the client side. Server side is expected to be deployed behind nginx or similar, so there's not much point spending time implementing it there.

[davfsa]

Thanks for pointing out the llhttp pr, I didnt think about searching the pull requests for it 😅

As per your server side comment, it might be best to have the implementation there so that people can enable it if needed in the future (or at least an open pr that can be merged when nginx adds support). But for now, I will focus on the client only, as I got to figure out how HTTP works (im not familiar either, but thought it might be a cool thing to try and work out how to use)

[Dreamsorcerer]

As per your server side comment, it might be best to have the implementation there so that people can enable it if needed in the future (or at least an open pr that can be merged when nginx adds support).

I think you misunderstood. nginx handles the TLS connection, and then proxies to the python application locally (i.e. using just TCP or Unix sockets). So, when deployed in a reasonable production environment, there is no HTTPS connection handled by the application.

The only reason to add support server-side is for someone deploying an application exposed directly to the internet (without nginx). This is something we heavily discourage. Therefore, it's not worth spending any time on it.

[davfsa]

As per your server side comment, it might be best to have the implementation there so that people can enable it if needed in the future (or at least an open pr that can be merged when nginx adds support).

I think you misunderstood. nginx handles the TLS connection, and then proxies to the python application locally (i.e. using just HTTP or Unix sockets). So, when deployed in a reasonable production environment, there is no HTTPS connection handled by the application.

The only reason to add support server-side is for someone deploying an application exposed directly to the internet (without nginx). This is something we heavily discourage. Therefore, it's not work spending any time on it.

Ah, ok, thanks for the explanation

[septatrix]

This is only indirectly related but supporting ASGI would allow use to use HTTP/2 capabilities of current ASGI servers like daphne and also HTTP/3 once some of them implement it. While this would not allow for features like server push it would enable the user to benefit from better connection multiplexing or faster handshake in the case of QUIC. I do not know the ASGI specification in depth but implementing it is presumably easier than adding support for both new HTTP versions (and these will presumably get HTTP/3 support sooner or later).

[Dreamsorcerer]

supporting ASGI would allow to use HTTP/2 capabilities

This would be server-side, which as I mentioned above is probably not worth implementing, as you should be deploying behind nginx or similar. ASGI is unrelated to the client-side code.

[Dreamsorcerer]

For anyone looking to try implementing this, I think other libraries have used the h2 library for HTTP/2 support, so that's probably a good starting point.