Errore chiamando un servizio WCF REST utilizzando JSON. contingente lunghezza (8192) superato

Question

Ho un servizio WCF REST ospitato in IIS utilizzando .NET 4 RC. Il POST chiamate al servizio vengano serializzati mediante JSON. Tutto funziona bene fino a quando la dimensione di uno dei DataMember (stringa) è più lunga di 8K. In questo caso ricevo l'errore descritto di seguito indica il MaxStringContentLength è stato superato. L'attributo MaxStringContentLength per l'endpoint è stato aumentato e che sia correttamente leggere dal file di configurazione.

Web di configurazione è:

<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>

interfaccia IMyService è definito come:

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

Messaggio di errore completo è:

“Il server ha rilevato un errore durante l'elaborazione della richiesta. Il messaggio di eccezione è 'C'è stato un errore deserializzazione l'oggetto di tipo. La quota lunghezza del contenuto della stringa massimo (8192) è stato superato durante la lettura dei dati XML. Questo contingente può essere aumentato modificando la proprietà MaxStringContentLength sulle XmlDictionaryReaderQuotas utilizzato durante la creazione del lettore XML. '. Vedere i log del server per ulteriori dettagli. L'analisi dello stack eccezione è: a System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions (lettore XmlReaderDelegator, booleano verifyObjectName, DataContractResolver dataContractResolver) a System.ServiceModel a System.Runtime.Serialization.Json.DataContractJsonSerializer.ReadObject (lettore XmlDictionaryReader, booleano verifyObjectName). Dispatcher.SingleBodyParameterMessageFormatter.DeserializeRequest (messaggio messaggio, oggetto parametri []) a System.ServiceModel.Dispatcher.DemultiplexingDispatchMessageFormatter.DeserializeRequest (messaggio messaggio, Object [] parametri) a System.ServiceModel.Dispatcher.UriTemplateDispatchFormatter.DeserializeRequest (messaggio messaggio, Object [] parametri) a System.ServiceModel.Dispatcher.DispatchOperationRuntime.DeserializeInputs (MessageRpc & RPC) a System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin (MessageRpc & RPC) a System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5 (MessageRpc & RPC) a System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31 (MessageRpc & RPC) a System.ServiceModel.Dispatcher.MessageRpc.Process (booleano isOperationContextSet)”

Answer 1

Questo funziona, basta assicurarsi di avere un URL assoluto completa il tuo indirizzo endpoint. Se si ottiene furbo e tenta di utilizzare un percorso relativo, o se si omette .svc sarà bombardare con lo strano errore di quota lettore una volta che la richiesta diventa troppo grande -

Vorrei presentare questo sotto un Bug per WCF perché o:

1. URL relativi dovrebbero essere consentiti (e un'eccezione appropriata gettati)

o

2. la quota lettore dovrebbe funzionare con i percorsi relativi, nonché

Answer 2

inserire nel web.config:

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

e attributi inserto bindingConfiguration = "webHttpBindingConfig" nel vostro punto finale

Answer 3

Ho avuto problemi simili, ma con .NET 3.5

Non ho avuto problemi sul log del server, in modo che il problema era sul client. Sembra che la configurazione con i valori massimi aumento non è stato letto e utilizzato ...

Così ho risolto passando il nome dell'endpoint esplicitamente nel costruttore della WebChannelFactory, utilizzando un altro sovraccarico.

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

è:

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

e nel app.config c'è:

L'Uri è indicato nel nodo finale, ma ci si trova anche il bindingConfiguration e così via, in modo che tutti i nuovi limiti aumentati ora funziona.