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

Option to override ALPNs #68

Open
backkem opened this issue Apr 29, 2024 · 0 comments
Open

Option to override ALPNs #68

backkem opened this issue Apr 29, 2024 · 0 comments

Comments

@backkem
Copy link

backkem commented Apr 29, 2024

Currently one can add a additional custom ALPN to the list of supported ALPNs in the QuicVersionManager. However, ALPNs that are based on the supported Quic version are always available.

// Subclasses may add custom ALPNs to the supported list by overriding
// RefilterSupportedVersions() to first call
// QuicVersionManager::RefilterSupportedVersions() then AddCustomAlpn().
// Must not be called elsewhere.
void AddCustomAlpn(const std::string& alpn);

Consider the following use-case: I want to build an application protocol, using Quic v1 as the transport protocol. However, I want to use a custom ALPN instead of h3 since this server would not support HTTP. This doesn't seem possible to have a list consisting of only the custom ALPN now.
In my specific case, I'd like to have a list that only contains "osp" as defined here.

Would this be amenable? If so, would it be feasible to break up QuicVersionManager::RefilterSupportedVersions or would adding a ClearSupportedAlpns be preferred?

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

No branches or pull requests

1 participant