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

Allow specifying multiple ALPNs in Endoint::connect #2949

Open
matheus23 opened this issue Nov 19, 2024 · 2 comments
Open

Allow specifying multiple ALPNs in Endoint::connect #2949

matheus23 opened this issue Nov 19, 2024 · 2 comments
Labels
c-iroh feat New feature or request

Comments

@matheus23
Copy link
Contributor

When implementing a backwards-compatible protocol, one wants to assign different ALPNs to different protocol versions.
Examples:

  • http/0.9, http/1.0, http/1.1, h2 and h3
  • iroh-blobs/4, eventually iroh-blobs/5

It's important to indicate which versions you support, and often is the case that you indicate multiple versions simultaneously. E.g. sending an HTTP request using ["http/1.1", "h2", "h3"] as the ALPNs.

We currently don't have a way of specifying multiple ALPNs when doing an Endpoint::connect.

On the server side, you usually configure an ordered list of ALPNs and it chooses the first matching one. This is described in RFC 7301:

It is expected that a server will have a list of protocols that it supports, in preference order, and will only select a protocol if the client supports it. In that case, the server SHOULD select the most highly preferred protocol that it supports and that is also advertised by the client.

This manifests itself in APIs like that of rustls, its docs write:

The server can specify supported ALPN protocols by setting ServerConfig::alpn_protocols. During the handshake, the server will select the first protocol configured that the client supports.

The docs for ServerConfig::alpn_protocols say:

Protocol names we support, most preferred first.

@flub flub added feat New feature or request c-iroh labels Nov 19, 2024
@dignifiedquire
Copy link
Contributor

dignifiedquire commented Nov 19, 2024

why do we need this, instead of doing

builder
  .accept("version0", my_protocol.clone())
  .accept("version1", my_protocol.clone())

which we should test, but ideally already works today

@dignifiedquire
Copy link
Contributor

Sorry, I understood now, you are talking about the connect part..

@ramfox ramfox moved this to 📋 Backlog in iroh Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c-iroh feat New feature or request
Projects
Status: No status
Development

No branches or pull requests

3 participants