HttpWebRequest.GetRequestStream returns new stream instance on every invocation

[dallmair]

Description

Some third-party code we're depending on does this:

var request = WebRequest.CreateHttp(url);
request.Method = "POST";

// Problem: Calling request.GetRequestStream() twice returns same stream object in .NET Framework,
// but different objects in .NET Core 3.1.
using (var writer = new StreamWriter(request.GetRequestStream()))
    writer.Write("Hello, world!");
request.GetRequestStream().Close();

request.GetResponse();

Of course, there are things to improve here; Unfortunately, this code is not under our control, so we have no way to change it.

Anyway, the code works fine on .NET Framework 4.7.2 as the GetRequestStream method returns the same System.Net.ConnectStream object on both calls. In contrast, it fails on .NET Core 3.1.400, because the method returns a new instance on every call, which means that the above code just sends empty POST requests.

Expectation: GetRequestStream should return the same object on every invocation.

Configuration

• .NET Core 3.1.400
• Windows 10.0.19041.388
• x64

Regression?

Yes. As outlined above, this works fine on .NET Framework 4.7.2, but does not work on .NET Core 3.1.

Other information

Here's the relevant code section, which shows that a new RequestStream is created on every invocation:

runtime/src/libraries/System.Net.Requests/src/System/Net/HttpWebRequest.cs

Lines 1029 to 1056 in 6072e4d

	public override Stream GetRequestStream()
	{
	return InternalGetRequestStream().Result;
	}
	private Task<Stream> InternalGetRequestStream()
	{
	CheckAbort();
	// Match Desktop behavior: prevent someone from getting a request stream
	// if the protocol verb/method doesn't support it. Note that this is not
	// entirely compliant RFC2616 for the aforementioned compatibility reasons.
	if (string.Equals(HttpMethod.Get.Method, _originVerb, StringComparison.OrdinalIgnoreCase) ||
	string.Equals(HttpMethod.Head.Method, _originVerb, StringComparison.OrdinalIgnoreCase) ||
	string.Equals("CONNECT", _originVerb, StringComparison.OrdinalIgnoreCase))
	{
	throw new ProtocolViolationException(SR.net_nouploadonget);
	}
	if (RequestSubmitted)
	{
	throw new InvalidOperationException(SR.net_reqsubmitted);
	}
	_requestStream = new RequestStream();
	return Task.FromResult((Stream)_requestStream);
	}

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[karelz]

Thanks for your report. Can you please help me understand your situation a bit more?

1. How do you use the 3rd party code on .NET Core? Is it a .NET Framework DLL you are running on .NET Core?
2. Is there option to ask the 3rd party to either change their code or target .NET Standard or .NET Core?
3. How wide-spread is usage of the 3rd party code? Is it exclusive to your project, your company, or is it commonly used library across internet?
   4, How much does it block you? Do you have option to work around the problem? (e.g. use different code or library)

For context: HttpWebRequest is considered obsolete/legacy API on .NET Core (not performant and not fully featured as on .NET Framework). We recommend users to use HttpClient instead.
That said, we fix some incompatabilities if they affect larger number of users and block migration to Core.

[dallmair]

Sorry for the delay, busy times over here.

First of all, I definitely agree on usage of HttpClient. We've updated all of our own code base to use it which was a massive effort, but is way better. We do not regret this switch at all.

We encountered this compatibility issue with the SharePoint Online CSOM library. The SharePoint team added a .NET Standard 2.0 flavor of their library in June, and we tried it out as we're currently planning our product's future and are toying a few ideas, including the switch to .NET Core. Unfortunately, HttpWebRequest is part of CSOM's public API and authentication story, so they're kind of stuck with it.

As this might affect others as well (both other users of CSOM as well as other libraries having the same bug), we wanted to at least report it here as a compatibility issue. There's no need for a fix in 3.1 for us right now. Looking a bit further into the future, we think a fix in .NET 5 would be awesome but it might be a little late in the cycle already, not sure about that. Should be possible to fix it in .NET 6, though.

Hope that answers your questions. If there's anything else we can provide, please don't hesitate to ask.

This issue has been automatically marked as no recent activity because it has been marked as needing more info but has not had any activity for 14 days. It will be closed if no further activity occurs within 7 more days.

[stephentoub]

@danmosemsft, on multiple issues now I see that we tagged the issue as needs more info, then more info was provided, but the needs more info label wasn't removed, and now the bot is going to automatically close the issue. That's not great.

[dallmair]

@stephentoub Thanks for the follow-up regarding the bot, good to know you're also monitoring things.