PostAsJsonAsync extension method sets Content-Length to 0 in .NET Core 2.1 with any versions of System.Net.Http and System.Net.Http.Formatting

[doboczyakos]

var response = await _client.PostAsJsonAsync(requestUri, value, cancellationToken);

Request object is null on the server side because content length is set to 0.
I've tried the newest versions of System.Net.Http and System.Net.Http.Formatting and the issue is the same.
It works if I replace this with the following:

var objectContent = new ObjectContent(value, new System.Net.Http.Formatting.JsonMediaTypeFormatter(), (System.Net.Http.Headers.MediaTypeHeaderValue)null);
await objectContent.ReadAsStringAsync();
var response = await _client.PostAsync(requestUri, objectContent, cancellationToken);

[dougbu]

Adding @mkArtakMSFT and @danroth27

@doboczyakos have you debugged the server application to confirm the Content-Length header is present in the request and that Transfer-Encoding is not? And, is there a proxy between your client and server (proxies sometimes mess with Content-Length)?

(I edited your description to make the code a bit easier to read.)

[doboczyakos]

The server application is an ASP.NET web api application on local IIS. I saw that content length was 0 but I'm double checking it tomorrow.
The above mentioned code is in a .NET Standard 2.0 class library and the executed client application is .NET Core 2.1

[doboczyakos]

Transfer-Encoding: chunked and no Content-Length header

[doboczyakos]

It also works if I run this from a .NET Framework 4.8 application

[dougbu]

This sounds like a duplicate of #197 and that was fixed in the 5.2.7 release. Are you using the latest packages in the web app?

[doboczyakos]

You mean on the server side?

[doboczyakos]

Ok. I've read the linked thread. What happens if I can make no effect on the server side?

[dougbu]

I meant the server side. The client sending Transfer-Encoding without Content-Length is correct according to the HTTP 1.1 spec. But, the server interpreting a missing Content-Length as 0 when the request is chunked is not correct. That's what #197 fixed.

I'm having trouble following your changes to the client and server applications. You seem to be changing package versions in the client application as well as the target framework for at least the client app. What happens when using the latest client and server Web.API package (no ASP.NET Core packages in the server app) and targeting .NET Core 3.0 in the client and .NET Framework 4.7.2 (say) in the server? Does the problem reproduce when you move the client to .NET Core 2.2 or 2.1?

[doboczyakos]

The client is targeting .NET Core 2.1 (and tested with 2.2 too)
The server side is .NET Framework 4.8
I've made no changes on the server side.

[mkArtakMSFT]

Thank you for filing this issue. In order for us to investigate this issue, please provide a minimalistic repro project that illustrates the problem.

[pranavkm]

Ok. I've read the linked thread. What happens if I can make no effect on the server side?

@doboczyakos unfortunately a fix on the server would be required. You could consider changing the client to buffer and send a Content-Length if the server cannot be modified. However, beyond that, I'm not sure there's much we could do here.

[doboczyakos]

@doboczyakos unfortunately a fix on the server would be required. You could consider changing the client to buffer and send a Content-Length if the server cannot be modified. However, beyond that, I'm not sure there's much we could do here.

I have the workaround which is quite funny but works. I'm wondering why the client can't have this as a feature especially when .NET Framework has this bug on server side. Please let me understand your way of thinking about it.

[pranavkm]

@doboczyakos the bug was fixed on the server. We generally wouldn't accept a workaround for a bug fix that has a known patch.