You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
voidAddCustomAlpn(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?
The text was updated successfully, but these errors were encountered:
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.quiche/quiche/quic/core/quic_version_manager.h
Lines 50 to 54 in eac20c9
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 aClearSupportedAlpns
be preferred?The text was updated successfully, but these errors were encountered: