Have kestrel filter out pseudo headers

[Tratcher]

dotnet/runtime#48009 (comment)

HTTP/2 uses pseudo headers for special values like method, path, authority, scheme, etc., but they have lots of constraints about where they can be placed, only using reserved ones, etc..

https://tools.ietf.org/html/rfc7540#section-8.1.2.1

Pseudo-header fields are not HTTP header fields.

As a result, other http header APIs won't accept them as input. E.g. HttpRequestMessage, WebHeaderCollection, etc.. This means components that copy request headers from Kestrel have to filter these out.

https://github.com/microsoft/reverse-proxy/blob/a3247ba1168325f46ab0ee4a24d3de1d9acdd853/src/ReverseProxy/Service/Proxy/HttpTransformer.cs#L49-L53

// Filter out HTTP/2 pseudo headers like ":method" and ":path", those go into other fields.
if (headerName.Length > 0 && headerName[0] == ':')
{
    continue;
}

https://github.com/CoreWCF/CoreWCF/blob/9957bb14bede95c22a8c6c7b3be4e42e84ba8471/src/CoreWCF.Http/src/CoreWCF/Channels/HttpContextExtensions.cs#L18-L19

if (header.Key.StartsWith(":")) // HTTP/2 pseudo header, skip as they appear on other properties of HttpRequest
    continue;

Http.Sys and IIS also filter out pseudo headers.

Historically we thought we were being more transparent about the protocol by including these values, but I'm not aware of any situations where they have proven useful since they are duplicated elsewhere in the request.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[jkotalik]

+1 on this.