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

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

2 голосов
/ 13 февраля 2010

У меня есть служба 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.Jerial.DaseRecjectBerjectJoDjectjectObDjectReader.OgnjectObDjectEgnObjectSigner.OjectjectObDjectReader.OntDispatcher.SingleBodyParameterMessageFormatter.DeserializeRequest (сообщение-сообщение, параметры Object []) в System.ServiceModel.Dispatcher.DemultiplexingDispatchMessageFormatter.DeserializeRequest (сообщение-сообщение, параметры Object []) в System.ServiceModel.Dispatcher.UriizeReis (MessageTestReader)параметров) в System.ServiceModel.Dispatcher.DispatchOperationRuntime.DeserializeInputs (MessageRpc & rpc) в System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin (MessageRpc & rpc) в System.ServiceModel.Dispatcher.vp_setup.RecTecRecRec5Rec5Rec5ceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31 (MessageRpc & rpc) в System.ServiceModel.Dispatcher.MessageRpc.Process (логический isOperationContextSet) ”

Ответы [ 3 ]

2 голосов
/ 15 февраля 2010

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

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

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

или

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

Вставьте в свой web.config: 

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

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

0 голосов
/ 17 апреля 2013

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

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

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

WAS: 

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();

IS 

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

и в app.config есть:

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

...