Ошибка вызова службы REST WCF с использованием JSON. длина квоты (8192) превышена

У меня есть служба WCF REST, размещенная в IIS с использованием.NET 4 RC. Вызовы POST для службы сериализуются с использованием JSON. Все работает нормально, пока размер одного из DataMember (строка) не превышает 8 КБ. В этом случае я получаю ошибку, описанную ниже, указывающую на превышение MaxStringContentLength. Атрибут maxStringContentLength для конечной точки был увеличен, и он правильно считывается из файла конфигурации.

Веб-конфигурация это:

<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 определяется как:

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

Полное сообщение об ошибке:

"Сервер обнаружил ошибку при обработке запроса. Сообщение об исключении: "Произошла ошибка при десериализации объекта типа. Максимальная квота длины строки содержимого (8192) была превышена при чтении данных XML. Эту квоту можно увеличить, изменив свойство MaxStringContentLength в объекте XmlDictionaryReaderQuotas, используемом при создании средства чтения XML.'. Смотрите журналы сервера для более подробной информации. Трассировка стека исключений: в System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(считыватель XmlReaderDelegator, логическое verifyObjectName, DataContractResolver dataContractResolver) в System.Runtime.Serialization.Jerialization.JerialDexjectBerjectJojectBext_Reader.ReaderID Dispatcher.SingleBodyParameterMessageFormatter.DeserializeRequest(сообщение-сообщение, параметры Object[]) в System.ServiceModel.Dispatcher.DemultiplexingDispatchMessageFormatter.DeserializeRequest(сообщение-сообщение, Object[] параметры) в System.ServiceModel.Dispatcher.UriizematisD (MessageTestMateRate) (MessageTestReader) параметров) в System.ServiceModel.Dispatcher.DispatchOperationRuntime.DeserializeInputs (MessageRpc& rpc) в System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin (MessageRpc& rpc) в System.ServiceModel.Dispatcher.pupSerp.SecTecRecRecTecRec5Rec5 ceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc) в System.ServiceModel.Dispatcher.MessageRpc.Process(логическое значение isOperationContextSet) "

Источник

3 ответа

Решение

Это работает, просто убедитесь, что в качестве адреса конечной точки указан полный абсолютный URL. Если вы стали хитрыми и попытаетесь использовать относительный путь, или если вы опустите.svc, это приведет к странной ошибке квоты читателя, как только запрос станет слишком большим -

Я бы подал это под Ошибка для WCF, потому что либо:

  1. относительные URL должны быть запрещены (и выброшено соответствующее исключение)

или же

  1. квота читателя также должна работать с относительными путями
Источник

Вставьте в ваш web.config:

<configuration>
  <system.serviceModel>
    <bindings>
      <webHttpBinding>
        <binding name="webHttpBindingConfig">
          <readerQuotas maxStringContentLength="2048000" />
        </binding>
      </webHttpBinding>
    </bindings>
  </system.serviceModel>
</configuration>

и вставьте атрибут bindingConfiguration="webHttpBindingConfig" в конечную точку

Источник

У меня были похожие проблемы, но с.NET 3.5

У меня не было проблем с журналом сервера, поэтому проблема была на клиенте.Кажется, что конфигурация с увеличенными максимальными значениями не была прочитана и использовалась...

Поэтому я решил передать имя конечной точки EXPLICITLY в конструкторе WebChannelFactory, используя другую перегрузку.

БЫЛО:

WebChannelFactory<IWKRestTest> factory = new WebChannelFactory<IWKRestTest>(new Uri(XXX));
factory.Credentials.UserName.UserName = K_USERNAME;
factory.Credentials.UserName.Password = K_PASSWORD;
IWKRestTest proxy = factory.CreateChannel();

ЯВЛЯЕТСЯ:

WebChannelFactory<IWKRestTest> factory = new WebChannelFactory<IWKRestTest>("IWKRestTestService");

и в app.config есть:

Uri указывается в узле конечной точки, но там вы также найдете bindingConfiguration и так далее, поэтому все новые увеличенные ограничения теперь работают.

Источник
Другие вопросы по тегам