Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quic HTTP/3 support #5999

Open
1 task done
davfsa opened this issue Sep 13, 2021 · 8 comments
Open
1 task done

Quic HTTP/3 support #5999

davfsa opened this issue Sep 13, 2021 · 8 comments

Comments

@davfsa
Copy link

davfsa commented Sep 13, 2021

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
Copy link
Author

davfsa commented Sep 13, 2021

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:

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
Copy link
Member

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
Copy link
Author

davfsa commented Sep 13, 2021

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
Copy link
Member

Dreamsorcerer commented Sep 13, 2021

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
Copy link
Author

davfsa commented Sep 13, 2021

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants