Open bartschotten opened 2 years ago
I think I've found the problem. In HttpResponseMessageHelper.ParseIncomingResponse WCF only treats it as a NullMessage when there is no Content-Type. As we can see in the response above there is a Content-Type header in this case. Since this seems to be an Oracle system I even found this ancient issue that describes exactly this behavior: https://community.oracle.com/tech/developers/discussion/1670521/oneway-web-service-operation-has-text-html-response-content-type
I'll leave this here as a feature request to throw a more descriptive error than a NullReferenceException when there is a content-type, but no content. May be there should be a counterpart of the SR.HttpContentTypeHeaderRequired ProtocolException, which is thrown when there is content, but no content-type.
I'm trying to migrate an existing SOAP/WCF client from .NET Framework to .NET 6. I haven't changed the actual client code (which used to work) at all. It's calling an endpoint that's not under my control so it's difficult to pinpoint exactly where it goes wrong, but here's what I'm observing. First the stack trace:
This is a One-Way operation so I'm already a bit surprised that it tries to read the response content at all, but this is what I'm getting from the response while debugging:
So I see that HttpResponseMessageHelper.GetStreamAsync finds no Content-Length header (because of chunked encoding), then tries to read the first byte of the contentStream but finds it empty. It then returns a null contentStream.
This null stream is then passed onto MessageEncoder.ReadMessageAsync, which throws a NullReferenceException trying to read it.
I don't know if it's a bug or if the way that I have it set up is simply not supported, but does anyone know what is supposed to happen here? The way this path is handled doesn't seem very robust to me. I would have expected it to either ignore the response (because it's one-way), or to return some kind of empty response.
.NET 6 System.ServiceModel 4.9.0