Wcf: BasicHttpBinding ReaderQotas.MaxStringContentLength Question

Created on 28 Feb 2019  路  9Comments  路  Source: dotnet/wcf

I have compiled a WCF client into a .NET Standard 2.0 assembly (using Add Connected Service in VS2017 15.9.7). When I reference the assembly from a .NET Framework 4.7 Console application and call one of the service methods, it fails to deserialize the message body due to MaxStringContentLength being too low, and throws an exception (which seems correct).

Referencing the same assembly from a netcoreapp2.1 Console application and calling the same service method using the same code and MaxStringContentLength does not throw an exception about failing to deserialize the message body.

Increasing the MaxStringContentLength resolved my issue in the .NET Framework 4.7 Console app (which I expected).

Does MaxStringContentLength somehow work differently between .NET Framework and .NET Core?

Net Core 3.1 LTS Servicing bug

Most helpful comment

I found the problem. There are two checks in XmlDictionaryReader.ReadContentAsString which are missing. They are here and here. So this is an issue in corefx, but it should be trivial to fix.

All 9 comments

@csturm83 We don't expect any behavior difference between .NET Framework and .NET Core. Can you provide the call stack of the exception that you run the program on .NET Framework? If you happen to have a simple repro, it would be helpful to share with us.

Call Stack:

System.AggregateException
  HResult=0x80131500
  Message=One or more errors occurred.
  Source=mscorlib
  StackTrace:
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at System.Threading.Tasks.Task`1.get_Result()
   at NetFrameworkConsole.Program.Main(String[] args) in C:\Users\Curt\Documents\Visual Studio 2017\Projects2\ClientLib\NetFrameworkConsole\Program.cs:line 12

Inner Exception 1:
NetDispatcherFaultException: The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:GetDataResult. The InnerException message was 'There was an error deserializing the object of type ClientLib.CompositeType. The maximum string content length quota (32768) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 33031.'.  Please see InnerException for more details.

Inner Exception 2:
SerializationException: There was an error deserializing the object of type ClientLib.CompositeType. The maximum string content length quota (32768) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 33031.

Inner Exception 3:
XmlException: The maximum string content length quota (32768) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 33031.

I came across this behavior consuming a legacy service that has an excessive amount of white space in its responses. I believe the discrepancy can be attributed to leading white space, as the exception is thrown as expected on .NET Core when the response is padded with white space on the right instead of the left.

Repro here.

2 VS Solutions

  • TestService.sln - simple WCF service - run on localhost

    • TestService.csproj

  • ClientLib.sln

    • ClientLib.csproj - (netstandard2.0 WCF client lib)

    • NetCoreConsole.csproj (netcoreapp2.1) - observe no exception!

    • NetFrameworkConsole.csproj (net47) - observe expected exception

@csturm83 Thank you so much for the detailed repro information. We will look into it.

@imcarolwang Could you have someone take the repro that was provided and go through the described scenarios and reproduce the issue. We suspect the bug is going to be in CoreFx, once you have done that let us know or if you have someone on the team that is willing to try debugging it go ahead.

Thank you @imcarolwang for providing the repro.
This confirms a change in behavior from the full framework to core.
Issue3408.zip

@mconnew can you take a quick look and see if we can move this to CoreFx.

I found the problem. There are two checks in XmlDictionaryReader.ReadContentAsString which are missing. They are here and here. So this is an issue in corefx, but it should be trivial to fix.

Great job @imcarolwang
Fixed by dotnet/corefx#38746

Reopening to track that we need to add a unit test for the fix.

Test merged in dotnet/corefx#38805

Was this page helpful?
0 / 5 - 0 ratings