Consider adding more headers to `HeaderNames`

[benaadams]

Follow up to https://github.com/dotnet/aspnetcore/pull/31311#discussion_r602945650

List of HTTP header fields

With https://github.com/dotnet/aspnetcore/pull/31311 there are advantages to having items in the header list (single instance string).

This is most useful for request headers as they are always constructed strings; whereas response headers set in code are usually and interned string.

Non-exhaustive list of headers not currently included but are interesting:

Commonly used request headers:

public static readonly string XCorrelationId = "X-Correlation-ID";
public static readonly string XRequestId = "X-Request-ID";
public static readonly string XForwardedFor = "X-Forwarded-For";
public static readonly string XForwardedHost = "X-Forwarded-Host";
public static readonly string XForwardedProto = "X-Forwarded-Proto";

However if the server is also reverse-proxying/forwarding/routing between other servers; then response headers also become constructed strings (as they are parsed from the network). So that would then potentially include:

// Security header
public static readonly string ReferrerPolicy = "Referrer-Policy";
// Allow the browser to read cross origin timing values for the Resource Timing API
public static readonly string TimingAllowOrigin = "Timing-Allow-Origin";
// Ye olde "ASP.NET" header
public static readonly string XPoweredBy = "X-Powered-By";

Location is used for redirect; but sometimes Refresh is also used as a non-JS delay timed redirect (with interstitial)

public static readonly string Refresh = "Refresh";

Never seen; but rfc7240

public static readonly string Prefer = "Prefer";
public static readonly string PreferenceApplied = "Preference-Applied";

[ghost]

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[kimsey0]

Accept-CH (client hints, per RFC 8942) would be nice to add too.