Make HttpResponseMessage.Content non-nullable

[stephentoub]

Fixes #35859

cc: @scalablecory, @davidsh, @buyaa-n

[ghost]

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[davidsh]

Do we need to change WinHttpHandler as well?

[stephentoub]

Do we need to change WinHttpHandler as well?

This didn't actually change SocketsHttpHandler, just HttpResponseMessage.Content's getter.

[buyaa-n]

LGTM, you might be already aware of, anyway just in case there is some test failures in Microsoft.Extensions.Http.Logging.RedactedLogValueIntegrationTest. seems related

[wfurt]

probably use of EmptyContent.

     Expected: ···ve: innocuous value\n
     Actual:   ···ve: innocuous value\nContent-Length: 0\n

[stephentoub]

probably use of EmptyContent

Yup. Thanks.

[safern]

LGTM

[gewarren]

@stephentoub As noted in dotnet/docs#25953, it appears that this is a breaking change. Can you confirm?

[stephentoub]

Any bug fix can break something, but this doesn't qualify as a breaking change as far as our definition of the term applies. To my knowledge the behavior of this member was never documented as to when it returned null or didn't, and we don't consider returning non-null when we previously returned null to be a "breaking change", even though, yes, it could break code checking for null (just as we don't consider changing something that was returning instances of type A to instance return an instance of type B that derives from A to be breaking, even though it can of course break someone). On top of that, this would really only affect testing scenarios, as HttpResponseMessage.Content never returned null for responses coming back from HttpMessageHandler/SocketsHttpHandler/WinHttpHandler/etc.