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

Support HTTP/3 client connections #546

Closed
PKizzle opened this issue Jun 12, 2023 · 6 comments
Closed

Support HTTP/3 client connections #546

PKizzle opened this issue Jun 12, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@PKizzle
Copy link
Contributor

PKizzle commented Jun 12, 2023

Since Kubernetes 1.24 the feature gate MixedProtocolLBService is enabled by default and finally makes it possible to open the same ports for differenct protocols. This allows clients to connect to HTTP/2 via TCP on port 443 or using HTTP/3 via UDP on the same port. Since there are already Docker images available with the QUIC feature flag being set (haproxytech/haproxy-alpine-quic) I guess that the amount of work to enable this feature should not be overwhelmingly large.

Search Keywords: H3, HTTP3, QUIC

@PKizzle PKizzle changed the title Support QUIC / HTTP/3 Support HTTP/3 client connections Jun 12, 2023
@ivanmatmati ivanmatmati added the enhancement New feature or request label Jun 15, 2023
@dkorunic
Copy link
Member

dkorunic commented Jul 6, 2023

Problem here is that we are then enforcing a QUIC-enabled SSL library in base image of our IC product to everyone, which also includes possible security issues that otherwise distro security maintainers take care of. I don't think we are going to replace regular OpenSSL base image with quictls-enabled one soon.

@PKizzle
Copy link
Contributor Author

PKizzle commented Jul 7, 2023

One option could be to offer two different images similar to how the base haproxy image handles this.

@dkorunic
Copy link
Member

dkorunic commented Jul 7, 2023

I'll pass on your request further up the chain and up for internal discussion 👍

@PKizzle
Copy link
Contributor Author

PKizzle commented Feb 21, 2024

I have noticed that initial QUIC support has been added with 67f3666 🎉

Thank you very much @ivanmatmati!

I have just one question regarding the implementation: Why is it necessary to have a working default certificate for QUIC to be enabled? Consider the following situation: I have configured specific certificates for various subdomains and the default (fallback) certificate is out of date then QUIC will be globally disabled even though all other certificates are valid. This does not seem the case with HTTPS implementation.

@ivanmatmati
Copy link
Collaborator

Hi @PKizzle , we took note of your suggestion and will discuss it in a follow-up of this feature as we plan to expand it in a close future.

@PKizzle
Copy link
Contributor Author

PKizzle commented Jun 9, 2024

Since I am using this feature without any issues in production I will close this issue. Note: I am building the image manually using haproxytech/haproxy-debian-quic as the base image in order to gain full QUIC support.

@PKizzle PKizzle closed this as completed Jun 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants