Home/ Questions/Q 606289
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T17:14:19+00:00

I’m having a WCF REST service hosted in IIS using .NET 4 RC. The

  • 0

I’m having a WCF REST service hosted in IIS using .NET 4 RC. The POST calls to the service are serialized using JSON. Everything works fine until the size of one of the DataMember (string) is longer than 8K. In this case I receive the error described below indicating the MaxStringContentLength has been exceeded. The maxStringContentLength attribute for the endPoint has been increased and it is correctly read from the config file.

Web config is:

<services>
  <service name="MyServiceServer" >
    <endpoint address="http://localhost/MyService" kind="webHttpEndpoint" endpointConfiguration="serviceEndPoint" contract="IMyService">
    </endpoint>
  </service>
</services>

<standardEndpoints>
  <webHttpEndpoint>
    <standardEndpoint name="serviceEndPoint" maxReceivedMessageSize="2048000"  maxBufferSize="2048000" maxBufferPoolSize="0">
      <readerQuotas maxStringContentLength="2048000" maxArrayLength="2048000"  maxDepth ="65000"/>
      <security mode="None">
        <transport clientCredentialType="None"/>
      </security>
    </standardEndpoint>
  </webHttpEndpoint>
</standardEndpoints>

IMyService interface is defined as:

public interface IMyService
{
    [OperationContract]
    [WebInvoke(Method = "POST", UriTemplate = "/request", RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare)]
    void MyMehod(<Class Type> obj);
}

Complete Error Message is:

“The server encountered an error processing the request. The exception message is ‘There was an error deserializing the object of type . The maximum string content length quota (8192) 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.’. See server logs for more details. The exception stack trace is: at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName, DataContractResolver dataContractResolver) at System.Runtime.Serialization.Json.DataContractJsonSerializer.ReadObject(XmlDictionaryReader reader, Boolean verifyObjectName) at System.ServiceModel.Dispatcher.SingleBodyParameterMessageFormatter.DeserializeRequest(Message message, Object[] parameters) at System.ServiceModel.Dispatcher.DemultiplexingDispatchMessageFormatter.DeserializeRequest(Message message, Object[] parameters) at System.ServiceModel.Dispatcher.UriTemplateDispatchFormatter.DeserializeRequest(Message message, Object[] parameters) at System.ServiceModel.Dispatcher.DispatchOperationRuntime.DeserializeInputs(MessageRpc& rpc) at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc) at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)”

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This works, just make sure to have a full absolute URL as your endpoint address. If you get crafty and try to use a relative path, or if you omit .svc it will bomb with the strange reader quota error once the request gets too large —

    I would file this under a Bug for WCF because either:

    1. relative URLs should be disallowed (and an appropriate exception thrown)

    or

    1. the reader quota should work with relative paths as well
    • 0