Make HttpKnownHeaderNames public

[ohadschn]

Any reason why it's internal? Perhaps it's all the unsafe stuff going on at HttpKnownHeaderNames.TryGetHeaderName.cs but at least the constants could be factored out and exposed - they can be very useful. See for example: http://stackoverflow.com/questions/11037004/asp-mvc-are-there-any-constants-for-the-default-http-headers.

[karelz]

The file is here: HttpKnownHeaderNames.TryGetHeaderNames.cs

Next step: We need formal API proposal - i.e. API shape (trivial) with motivation and use cases for it to be public API.

[yringler]

@ohadschn @karelz, I think this could be closed?

The header name strings are now availaible at Microsoft.Net.Http.Headers

[karelz]

Looks like ASP.NET extension, not something part of .NET Core platform / BCL itself.

[davidsh]

@Tratcher - What is the plan for Microsoft.Net.Http.Headers? It would be good to converge on a single API for this instead of .NET Core also exposing a similar/duplicative API surface as Microsoft.Net.Http.Headers.

[Tratcher]

The theory was that it could eventually be contributed back to corefx but there's no official plan or schedule to do so.

[IanKemp]

The theory was that it could eventually be contributed back to corefx but there's no official plan or schedule to do so.

Why not?

[Tratcher]

Microsoft.Net.Http.Headers duplicated many of the types in System.Net.Http.Headers but then made many breaking changes to improve how they work. CoreFx is strongly against taking breaking changes so re-unifying is going to be very hard.

The HeaderNames class would be one of the easiest since CoreFx doesn't have that type, but moving it would breaking existing AspNetCore customers.

[IanKemp]

Microsoft.Net.Http.Headers duplicated many of the types in System.Net.Http.Headers but then made many breaking changes to improve how they work. CoreFx is strongly against taking breaking changes so re-unifying is going to be very hard.

The HeaderNames class would be one of the easiest since CoreFx doesn't have that type, but moving it would breaking existing AspNetCore customers.

Couldn't you forward that type?

[Tratcher]

Type forwards have limits, like you can't change the namespace.

[stephentoub]

but then made many breaking changes to improve how they work. CoreFx is strongly against taking breaking changes so re-unifying is going to be very hard.

Can you enumerate what the breaking changes are? Are they all API signature changes? Internal details that change behavior? A mix? We should evaluate the changes individually; it's possible some of the breaks could be tolerable, depending on what they are

[Tratcher]

@stephentoub MediaTypeHeaderValue makes a good example:
https://github.com/dotnet/corefx/blob/master/src/System.Net.Http/src/System/Net/Http/Headers/MediaTypeHeaderValue.cs
https://github.com/aspnet/AspNetCore/blob/master/src/Http/Headers/src/MediaTypeHeaderValue.cs

Breaking Changes: Constructors, properties, and parsers changed from string to StringSegment to reduce allocations. The constructors and parsers can be reconciled via overloads, but the properties can't be without duplicating each property.

Non-breaking additions:

• Strict vs lax parsing.
• New properties for more granular access (Type, SubType, etc.).
• New ReadOnly mode for safe re-usability.
• Matching functionality (IsSubsetOf).

[scalablecory]

triage: we are okay with this but need an API proposal.