WebClient ResponseHeaders.HasKeys() returns incorrect result

[ighristov]

WebClient's ResponseHeaders.HasKeys() returns false when there actually are keys and they are reported correctly through AllKeys property. The code below asserts correctly in .NET Framework 4.7.2 and fails in .NET Core 2.1:

using (var client = new WebClient())
{
    var data = client.DownloadData("https://img-prod-cms-rt-microsoft-com.akamaized.net/cms/api/am/imageFileData/RE1Mu3b?ver=5c31");
    System.Diagnostics.Debug.Assert(client.ResponseHeaders.HasKeys());
}

[Sebazzz]

This appears to be due to WebHeaderCollection actually using an internal NameValueCollection, but at the same time inheriting from NameValueCollection. The inner NameValueCollection contains the data and some members, like AllKeys are properly overwritten. HasKeys is not virtual and cannot be overwritten and returns the contents of the WebHeaderCollection itself, which is empty.

[GSPP]

This collection design is really messed up 😁

[caesar-chen]

Per platform-compat repo:

WebClient is on life-support only (that is, only critical fixes, no new improvements, enhancements). Use HttpClient instead.

Does this issue only happen with WebClient.ResponseHeaders? Have you tried HttpClient?

[remcoros]

NameValueCollection has "InternalHasKeys" which is virtual.

looking at referencesource (https://github.com/Microsoft/referencesource/blob/3b1eaf5203992df69de44c783a3eda37d3d4cd10/System/net/System/Net/WebHeaderCollection.cs#L1930), this seems to be missing from corefx

[karelz]

Triage: It needs closer look to decide what is the right decision. We may move the type maybe, but is that problematic? Is that the best solution?
Or maybe promote one internal constructor to public ...

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.