Runtime: Allow null HttpResponseMessage in HttpClient.SendAsync?

[tmenier]

I understand that making this change could quite possibly have far-reaching implications, so I guess at the very least I'd like to start a discussion and understand why it is the way it is.

Currently HttpClient.SendAsync checks that the returned HttpResponseMessage is not null and throws an InvalidOperationException if it is. (Specifically here and here.) I question why that check is necessary. It seems valid to want to implement a custom HttpMessageHandler that returns a null response in specific scenarios and not consider it an error condition. But with this behavior in HttpClient, you're basically forced to implement that flow through exception handling upstream.

I'm curious to get the team's thoughts on this. Thanks!

[mikedn]

It seems valid to want to implement a custom HttpMessageHandler that returns a null response in specific scenarios and not consider it an error condition.

Any real world examples?

[tmenier]

I maintain a library that basically wraps a fluent interface around HttpClient and provides a few other goodies. One is the ability to configure error handling globally, as described here. A bug was recently discovered that really came down to a bad assumption on my part that returning a null HttpResponseMessage from a handler was valid. I can certainly work around it, but it led me to question the design decision. Thanks.

[davidsh]

It is a fundamental design principle that the handler's SendAsync() method for HttpClient always return a non-null HttpResponseMessage. That design is part of the original design for HttpClient when we built the API for .NET 4.5. It would be a breaking change to alter that principle.

[davidsh]

As discussed, it is by-design behavior of this design. The .NET Framework and .NET Core share this common design that handlers can not return NULL HttpResponseMessage objects.