While investigating failures in System.Net.Requests tests ( #20873), I discovered that FtpWebResponse.Headers and FileWebResponse.Headers is returning a WebHeaderCollection object that does not have the private field WebHeaderCollectionType properly initialized within the collection.

This causes code like this:

FileWebResponse response = ...
Assert.Equal(data.Length.ToString(), response.Headers[HttpResponseHeader.ContentLength]);

to pass on .NET Core (which is wrong). Instead, it should throw an exception

System.InvalidOperationException : This collection holds request headers and cannot contain the specified response header.

similar to what happens on .NET Framework. The exception is because FtpWebResponse/FileWebResponse don't have Http type headers.

So, the net result is that we don't have proper validation for WebHeaderCollection type.

The problem is that on .NET Core, the WebHeaderCollection is being created with the default contructor which doesn't pass it any specific WebHeaderCollectionType enum value. On .NET Framework, it uses an internal constructor overload. Also, the WebHeaderCollectionType enum is also marked as internal in .NET Framework and is not a public API.

This was ok for .NET Framework since everything was in System.dll. But on .NET Core, WebHeaderCollection lives in a different library from System.Net.Requests where *WebRequest, *WebResponse classes live.

    internal enum WebHeaderCollectionType : ushort {
        Unknown,
        WebRequest,
        WebResponse,
        HttpWebRequest,
        HttpWebResponse,
        HttpListenerRequest,
        HttpListenerResponse,
        FtpWebRequest,
        FtpWebResponse,
        FileWebRequest,
        FileWebResponse,
    }
    internal WebHeaderCollection(WebHeaderCollectionType type) : base(DBNull.Value);

This is resulting in all WebHeaderCollection objects being set with the WebHeaderCollectionType.Unknown enum value.