HttpRequest.ContentLength is null when using TestHost

[benmccallum]

Describe the bug

⚠️Update: I'm no longer taking this approach and inspecting the Content-Length header's value, we found a much better way with help from David Fowler, but the issue is still valid. For reproducability, I've branched the commit at the time here.

Apologies if I'm completely wrong here. Over here I'm upgrading a middleware to 3.x and System.Text.Json.

I'm trying to optimize a deserialization from the HttpRequest.Body by pre-allocating a buffer using the shared array pool given HttpRequest.ContentLength. See here. Problem is, when our integration tests run, which use HttpClient.PostAsync(..., new StringContent(...)) to post to a TestHost, the Content-Length header is always null.

Is this is a limitation of the test host, or a bug? I guess I could write a unit test the specific internals of that function.

To Reproduce

1. Clone PRbranch linked above.
2. Put a breakpoint in GraphQLHttpMiddleware in the JsonContentType case of the switch statement.
3. Test Explorer > Samples.Server.Tests (netcoreapp3.1) > right-click "Single_Query..." and Debug.
4. Breakpoint will be hit and httpRequest.ContentLength will be null.

Further technical details

• ASP.NET Core version: 3.1.0
• Include the output of dotnet --info
  
• The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version: VS Community 2019 v16.4.3

[analogrelay]

I think this would depend on what StringContent does. Looking at it, it doesn't set Content-Length, which means this is somewhat expected. Our general rule-of-thumb for using TestHost here is that if you are coupled directly to specific headers like Content-Length you need to set them in the test client code. On the server, in general, the only way to know for sure the length of the body is to read it (since the request could be a chunked request or a Connection: close request with no Content-Length header).

[benmccallum]

Sorry I've been absent, been dealing with SameSite cookie fun and haven't had a chance to think about this and then am on hols until Thursday.

How could I explicitly set the content length? I notice that if I do var content = new StringContent(...); that content.Headers.ContentLength (from the top of my head) had a value, so it's a little strange this doesn't get passed on through.

Will have more of a think about this next week.

[analogrelay]

How could I explicitly set the content length? I notice that if I do var content = new StringContent(...); that content.Headers.ContentLength (from the top of my head) had a value, so it's a little strange this doesn't get passed on through.

Hrm, that is interesting. There may be a bug for us to look at here. We'll see what we find. I'd definitely agree that if the content has a ContentLength we should try to propagate that.

Sorry I've been absent, been dealing with SameSite cookie fun

Oh we're certainly familiar with that ;). No worries!

[analogrelay]

@Tratcher was saying that the ContentLength property itself is a bit of a trap here. If you dereference it, the HttpContent computes the length on-demand, but the actual Header isn't present in the header collection (until you set it).

Still, I think we can do something to fix this. It seems like there's some weird edge case stuff going on here that we can try to tidy up.

[ADustyOldMuffin]

Could I maybe take a whack at this if it's still available? Is the idea to set the header content-length from the ContentLength property if it's valid/set?