Adding a new Enhanced Connect :protocol pseudo-header

[Daniel-Genkin-MS-2]

Background and Motivation

I would like to propose adding a new protocol pseudo-header to HeaderNames. This will be helpful for adding support for new protocols to the stack that use the new Enhanced CONNECT method (e.g WebTransport (#41877) or WebSockets over HTTP/2 (#41558)). Currently there isn't such a pseudo-header. Therefore, we would need to hardcode it in the code currently. This proposed change would abstract the actual value into the HeaderNames file and thus help with maintainability as well as keep it more consistent with how the repo handles all the other headers and pseudo-headers.

Proposed API

/// <summary>Gets the <c>Protocol</c> HTTP header name.</summary>
public static readonly string Protocol = ":protocol";

Usage Examples

HeaderNames.Protocol

Alternative Designs

As this is a very tiny change, the only other reasonable possible designs are just to rename the variable or to place it in some other file. The proposed name, Protocol, seems to be the most consistent with the other values that are already defined and seems like all the pseudo-headers are already defined in this HeaderNames.cs file.

Risks

I don't think there are any risks here besides maybe choosing a bad variable name and confusing the customers who try to use it.

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[halter73]

API Review Notes:

1. Can this be used by code outside of Kestrel?

• No.

2. Can we make it internal?

• Yes if we move the class and assembly for the ":protocol" psuedo-header name.

3. Should we obsolete other pseudo header names?

• Yes. Will need new API proposal.
• At least make them non-browsable in the editor.