Perhaps it doesn't make sense for product code to instantiate these types but the deprecation of the constuctors has made unit testing clients which use the Http implementations of WebRequest/Response far more trouble than it should be. I see no value in taking the constructors away and obvious value in having them, so what is the technical reason for their deprecation?
Hmm, why exactly do you need the constructor of HttpWebRequest? I can't see any preferences of it comparing with WebRequest.Create, which is being suggested as preffered way to create such requests in all the versions from the beginning.
This method is returning the HttpWebRequest as WebRequest, but you still can cast it to the direct type for your needs. If you'll provide some other protocols, as file:// or ftp://, it will return corresponding types.
I think that this Obsolete list is a part of standardizing the .NET Core for all the platforms it'll be used, and it'll be much more simple to maintain the WebRequest creation in one single point of the code.
Update:
I think you've saw this article about deriving the WebRequest class, so I'll just write here another pack of my opinion:
When you are dering from the WebRequest, you need two points:
IWebRequestCreate interfaceWebRequest.RegisterPrefix methodAs the MSDN says:
The
HttpWebRequestclass is registered to service requests for HTTP and HTTPS schemes by default. Attempts to register a differentWebRequestdescendant for these schemes will fail.
So the Microsoft wants to control the http and https oriented classes and don't want anybody to replace this functionality with their own. I think that this could be done because of some security concerns. Sad but true.