.net Standard Library using httpClient.PostAsync has different header values when consumed by .net Core 2.1 and .net Framework 4.7.2

[gperrego]

@gperrego Probably best to open a new issue. It is strange that the behavior is different depending on whether you're running on .NET 4.7.2 vs .NET Core 2.1.

Originally posted by @danroth27 in https://github.com/aspnet/AspNetWebStack/issues/252#issuecomment-617938031

[gperrego]

I have a library that is written in .net standard. This library is not currently a mutitarget library, only .net standard.

I created a sample .net core console application and a .net framework 472 console application to consume this. Added a project reference to both for this purpose (will use NuGet later on).

The implementation is pretty simple:

            HttpResponseMessage result;
            var callTask = Task.Run(() => Task.Run(() => HttpClient.PostAsync(PostUri, request, new JsonMediaTypeFormatter())));
            callTask.Wait();
            result = callTask.Result;

This call works in the 472 but fails doesn't work in .net core 2.1. I installed FiddlerCore to inspect the httpRequests. When doing this I see that the HTTPHeader is changing when calling it from .net Core vs .net Framework. .net Core is using Transfer Encoding: Chunked but .net Framework is using ContentLength. I think that is the cause of this issue but i'm not sure.

The other weird thing is that I'm not seeing a signature that matches (URI, object, mediaTypeFormatter) I do see one that is using generics though.

[mkArtakMSFT]

Thank you for contacting us. We are currently only fixing critical functional issues in the code base, and have decided to not make this change.

[gperrego]

I would have to politely disagree, if you can't use the same code in both .NET framework and .NET Core than that breaks the concept of .NET Standard. That consistency is important if not critical. This slowed down our dev team for a long time because we had to debug the code that was supplied by MS that is supposed to be implemented the same on both platforms.

Were you able to reproduce this? We found that that there is a work around, you need to cast the request object and trick it it work consistently across .NET Core and .NET Framwork.

HttpResponseMessage result; var callTask = Task.Run(() => HttpClient.PostAsync(PostUri, new StringContent(JsonConvert.SerializeObject(request), Encoding.UTF8, "application/json"))); callTask.Wait(); result = callTask.Result;

This seems like an easy fix, are you saying this bug is still present and will continue to be present in future .NET Standard Releases?

@danroth27 - Does this sound right?

Thanks, Greg

[danroth27]

@ericstj is the default transfer encoding used by HttpClient different on .NET Core vs .NET Framework?

[ericstj]

@davidsh might know. I wouldn’t expect chunked encoding since the size is known, but I might be missing something.

[davidsh]

@scalablecory @stephentoub

@davidsh might know. I wouldn’t expect chunked encoding since the size is known, but I might be missing something.

If neither 'Content-Length' or 'Transfer-Encoding: chunked' is set for a request body, then one of them is picked. And yes, I believe that choice changed from .NET Framework to .NET Core.

But for this example, it looks like StringContent() is being picked. And that I believe comes with 'Content-Length' header already set. So, this would have to be debugged to understand what's going on.

[danroth27]

I believe that choice changed from .NET Framework to .NET Core.

@gperrego It sounds like this was a deliberate choice made for .NET Core. While the behavior difference is unfortunate, I think we're now stuck with it.

[gperrego]

@danroth27 - Fair enough, if it is a breaking change its a breaking change. Not sure if you call it that or different implementation. HttpClient.PostAsync is a very high traffic method and even little things like this can make a difference. At least its now documented here for someone else to google. It may be worth a footnote on the doco somewhere?

@davidsh - "this would have to be debugged to understand what's going on"

If someone wants to take a look that would be great. As you said the content length is known so when that happens we should choose the correct Transfer Encoding. Of course the concern would be that any fix needs to be backwards compatible and not break other implementations that may be reliant on the .NET Core default behavior.

If there is a fix that is performant for known and unknown content lengths and still defaults to Chunked if the content length is unknown then that would be great. Then we would have our consistency.

Thanks to everyone for following through, I would not ask that this be reopened unless you guys want to continue.

Cheers!

[rodrigoramos]

Would be this bug fixed in any time in the future? It makes PostAsJsonAsync impossible to use.