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: ApplicationProtocol in ConnectionOptionsCallback not used #72361

Closed
JamesNK opened this issue Jul 18, 2022 · 4 comments
Closed

QUIC: ApplicationProtocol in ConnectionOptionsCallback not used #72361

JamesNK opened this issue Jul 18, 2022 · 4 comments

Comments

@JamesNK
Copy link
Member

JamesNK commented Jul 18, 2022

Description

QuicListenerOptions.ApplicationProtocols appears to override the values set on QuicServerConnectionOptions.ServerAuthenticationOptions.ApplicationsProtocols which is returned from ConnectionOptionsCallback.

I recall from discussion with msquic team that QuicListenerOptions.ApplicationProtocols must contain all possible protocols, and then the application protocols returned from ConnectionOptionsCallback must be one of those values.

Reproduction Steps

  1. Set QuicListenerOptions.ApplicationProtocols to h3.
  2. Set QuicListenerOptions.ConnectionOptionsCallback to return options with a different ApplicationProtocols value, e.g. new SslApplicationProtocol("custom")
  3. Connect with a client that has application protocols of h3.

Expected behavior

I expected an error for multiple reasons:

  1. The server has done something invalid by specifying h3 protocol to the listener but custom protocol in the callback.
  2. The client is specifying h3 but the connection callback has specified custom.

Actual behavior

The client connects to the server and the negotiated protocol is h3.

It seems like the protocol in the callback is being ignored.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Jul 18, 2022
@ghost
Copy link

ghost commented Jul 18, 2022

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

QuicListenerOptions.ApplicationProtocols appears to override the values set on QuicServerConnectionOptions.ServerAuthenticationOptions.ApplicationsProtocols which is returned from ConnectionOptionsCallback.

I recall from discussion with msquic team that QuicListenerOptions.ApplicationProtocols must contain all possible protocols, and then the application protocols returned from ConnectionOptionsCallback must be one of those values.

Reproduction Steps

  1. Set QuicListenerOptions.ApplicationProtocols to h3.
  2. Set QuicListenerOptions.ConnectionOptionsCallback to return options with a different ApplicationProtocols value, e.g. new SslApplicationProtocol("custom")
  3. Connect with a client that has application protocols of h3.

Expected behavior

I expected an error for multiple reasons:

  1. The server has done something invalid by specifying h3 protocol to the listener but custom protocol in the callback.
  2. The client is specifying h3 but the connection callback has specified custom.

Actual behavior

The client connects to the server and the negotiated protocol is h3.

It seems like the protocol in the callback is being ignored.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author: JamesNK
Assignees: -
Labels:

area-System.Net.Quic

Milestone: -

@JamesNK
Copy link
Member Author

JamesNK commented Jul 18, 2022

@ManickaP
Copy link
Member

This feature unfortunately didn't make into MsQuic for .NET 7.0. As you can see microsoft/msquic#2418 is still open, as well as #49423.
MsQuic team didn't have time to address it and since we now only have "h3" and no need to narrow it down, we confirmed we can live without it for one more release.

We should either close this issue as duplicate of #49423 or keep this and close the other (after all this one better describes the remaining problem).

@JamesNK
Copy link
Member Author

JamesNK commented Jul 18, 2022

Ok. I'll close this.

@JamesNK JamesNK closed this as completed Jul 18, 2022
@ghost ghost removed the untriaged New issue has not been triaged by the area owner label Jul 18, 2022
@karelz karelz added this to the 7.0.0 milestone Jul 19, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Aug 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants