Erreur d'appeler un service REST WCF en utilisant JSON. quota de longueur (8192) a dépassé

Question

Je vais avoir un service hébergé REST WCF dans IIS en utilisant .NET 4 RC. Le POST appelle au service sont sérialisés à l'aide JSON. Tout fonctionne bien jusqu'à ce que la taille de l'un des DataMember (string) est plus longue que 8K. Dans ce cas, je reçois a été dépassé l'erreur décrite ci-dessous indique la MaxStringContentLength. L'attribut maxStringContentLength pour la endPoint a été augmentée et il est lu correctement à partir du fichier de configuration.

config Web est:

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

interface IMyService est définie comme suit:

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

Message d'erreur complet est:

« Le serveur a rencontré une erreur lors du traitement de la demande. Le message d'exception est « Il y avait une erreur désérialisation l'objet de type. Le quota de longueur de contenu maximale de chaîne (8192) a été dépassée lors de la lecture des données XML. Ce quota peut être augmentée en modifiant la propriété MaxStringContentLength sur les XmlDictionaryReaderQuotas objets utilisés lors de la création du lecteur XML.. Voir les journaux de serveur pour plus de détails. La trace de pile d'exception est la suivante: à System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions (lecteur de XmlReaderDelegator, Boolean verifyObjectName, DataContractResolver dataContractResolver) à System.Runtime.Serialization.Json.DataContractJsonSerializer.ReadObject (lecteur de XmlDictionaryReader, Boolean verifyObjectName) à System.ServiceModel. Dispatcher.SingleBodyParameterMessageFormatter.DeserializeRequest (message du message, objet [] paramètres) à System.ServiceModel.Dispatcher.DemultiplexingDispatchMessageFormatter.DeserializeRequest (Message message, Object [] paramètres) à System.ServiceModel.Dispatcher.UriTemplateDispatchFormatter.DeserializeRequest (Message message, Object [] paramètres) à System.ServiceModel.Dispatcher.DispatchOperationRuntime.DeserializeInputs (MessageRpc & RPC) à System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin (MessageRpc & RPC) à System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5 (MessageRpc & RPC) à System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31 (MessageRpc & RPC) à System.ServiceModel.Dispatcher.MessageRpc.Process (Boolean isOperationContextSet) »

Answer 1

Cela fonctionne, assurez-vous d'avoir une URL complète absolue que votre adresse point final. Si vous obtenez rusée et essayez d'utiliser un chemin relatif, ou si vous omettez .svc il bomberez avec l'erreur de quota de lecteur étrange une fois que la demande est trop grande -

Je déposeraient cela sous un bug pour WCF, car soit:

1. URL relatives doivent être interdites (et une exception appropriée moulinée)

ou

2. le quota de lecteur devrait fonctionner avec des chemins relatifs et

Answer 2

Insérez dans votre web.config:

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

et insérer attribut bindingConfiguration = "webHttpBindingConfig" dans votre point final

Answer 3

J'ai eu des problèmes similaires mais avec .NET 3.5

J'ai eu aucun problème sur le journal du serveur, de sorte que le problème était sur le client. Il semble que la configuration avec les valeurs max a augmenté n'a pas été lu et utilisé ...

Je résolus en passant le nom du point de terminaison dans le constructeur EXPLICITE du WebChannelFactory, en utilisant une autre surcharge.

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

est:

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

et dans le app.config il y a:

Le Uri est indiqué dans le nœud de point final, mais il se trouve aussi la bindingConfiguration et ainsi de suite, donc toutes les nouvelles limites accrues fonctionne maintenant.