The Content-Type for TextMessageEncoder doesn't support a whitespace character between content-type and charset, moreover the IsContentTypeSupported overload doesn't work

[Teugata]

Describe the bug Trying to connect a WCF client to a Java SOAP receiver, however we are having an issue with the content type.

By design or not, the Content-Type for TextMessageEncoder doesn't support a whitespace character between content-type and charset as is easily identifiable in the relevant code: https://github.com/dotnet/wcf/blob/main/src/System.Private.ServiceModel/src/System/ServiceModel/Channels/TextMessageEncoder.cs#L359

So instead we tried to use a CustomTextMessageEncoder and override IsContentTypeSupported which was mentioned as a fix by many, but the overridden method is never hit and the connection still fails on the following error:

Error message:

The content type application/soap+xml;charset=utf-8 of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly.

To Reproduce Steps to reproduce the behavior:

1. Setup a client binding expecting content type "application/soap+xml; charset=utf-8"
2. Setup a server binding expecting content type "application/soap+xml;charset=utf-8"
3. Have them communicate with eachother (In our case it was the response message of the server that resulted in a content type mismatch probably because their soap implementation doesn't have this limitation, in case of a WCF to WCF implementation the error might already pop up earlier)

optional steps for IsContentTypeSupported override issue 4. Create a CustomTextMessageEncoder as per the microsoft example: https://docs.microsoft.com/en-us/dotnet/framework/wcf/samples/custom-message-encoder-custom-text-encoder 5. Override public virtual bool IsContentTypeSupported(string contentType), set a breakpoint in the new version and watch the breakpoint never be hit, the method is never used.

Callstack of the error Message: System.ServiceModel.ProtocolException: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089) at IrrelevantInternalCode

Expected behavior The space should be supported or it should be possible to override the default behavior using the IsContentTypeSupported overload

[HongGit]

@Teugata this seems to be the same as .NET Framework. can you please try https://justsimplycode.com/2019/11/02/disable-header-100-continue-in-net-core-wcf-client/ to modify the content-type header after the response being received?

[HongGit]

Close this issue due to no response.

Feel free to re-open if the issues persist after above suggestion.

[Teugata]

@HongGit We made a workaround by introducing a custom message encoder that is able to manipulate the ContentType. Rather than providing another workaround can't you guys simply support spaces in the afore mentioned code which parses and sets the content types?

Why is this issue considered closed if it's still an issue without having to use a messy workaround?

[HongGit]

Reactivating for further investigation.

[greggwon]

This is a really bothersome issue without direct instructions for how to fix the situation by either hand editing Reference.cs (which is not really viable) or providing a working codebase or at least a more pluggable API where we can call into the Reference.cs generated Client to a public method there to either provide a lambda that does approval, or provide a set of content types that are acceptable and allow null to mean anything.