(413) L'entité de la demande est trop grande | uploadReadAheadSize

J'ai écrit un service WCF avec .NET 4.0, qui est hébergé sur mon système Windows 7 x64Ultimate avec IIS 7.5. Une des méthodes de service a un "objet" comme argument et j'essaye d'envoyer un octet [] qui contient une image. Tant que la taille du fichier de cette image est inférieure à env. 48KB, tout va bien. Mais si j'essaie de télécharger une image plus grande, le service WCF renvoie une erreur: (413) Request Entity Too Large. donc, bien sûr, j'ai passé 3 heures à rechercher le message d'erreur sur Google et chaque sujet que j'ai vu à ce sujet suggère d'augmenter la propriété 'uploadReadAheadSize'. Donc, ce que j'ai fait, c'est d'utiliser les commandes suivantes (10485760 = 10 Mo):

"appcmd.exe set config -section:system.webserver/serverruntime/uploadreadaheadsize: 10485760 /commit:apphost"

"cscript adsutil.vbs set w3svc/<APP_ID>/uploadreadaheadsize 10485760"

J'ai également utilisé IIS Manager pour définir la valeur en ouvrant le site et en allant dans "Éditeur de configuration" sous Gestion. Malheureusement, je reçois toujours l'erreur Request Entity Too Large et cela devient vraiment frustrant!

Alors, est-ce que quelqu'un sait ce que je peux essayer d'autre pour corriger cette erreur?

Ce n'est pas le problème d'IIS mais le problème de WCF. Par défaut, WCF limite les messages à 65 Ko pour éviter les attaques par déni de service avec des messages volumineux. De plus, si vous n'utilisez pas MTOM, il envoie l'octet [] à la chaîne encodée en base64 (augmentation de 33% de la taille) => 48 Ko * 1,33 = 64 Ko

Pour résoudre ce problème, vous devez reconfigurer votre service pour accepter des messages plus volumineux. Ce problème a précédemment déclenché une erreur de demande incorrecte 400, mais dans la version plus récente, WCF a commencé à utiliser 413, qui est le code d'état correct pour ce type d'erreur.

Vous devez définir maxReceivedMessageSizedans votre liaison. Vous pouvez également avoir besoin de définir readerQuotas.

<system.serviceModel>
  <bindings>
    <basicHttpBinding>
      <binding maxReceivedMessageSize="10485760">
        <readerQuotas ... />
      </binding>
    </basicHttpBinding>
  </bindings>  
</system.serviceModel>

J'avais le même problème avec IIS 7.5 avec un service WCF REST. Essayer de télécharger via POST n'importe quel fichier au-dessus de 65k et cela renverrait l'erreur 413 «Request Entity too large».

La première chose que vous devez comprendre est le type de liaison que vous avez configuré dans le fichier web.config. Voici un excellent article ...

BasicHttpBinding vs WsHttpBinding vs WebHttpBinding

Si vous disposez d'un service REST, vous devez le configurer en tant que "webHttpBinding". Voici la solution:

<system.serviceModel>

<bindings>
   <webHttpBinding>
    <binding 
      maxBufferPoolSize="2147483647" 
      maxReceivedMessageSize="2147483647" 
      maxBufferSize="2147483647" transferMode="Streamed">
    </binding>  
   </webHttpBinding>
</bindings>

J'ai eu le même problème et le réglage l'a uploadReadAheadSizerésolu:

http://www.iis.net/configreference/system.webserver/serverruntime

"La valeur doit être comprise entre 0 et 2147483647."

Il est facile de le définir dans le fichier applicationHost.config-fle si vous ne voulez pas faire un objet cmd.

Il est situé dans WindowsFOLDER\System32\inetsrv\config (serveur 2008).

Vous devez l'ouvrir avec le bloc-notes. Effectuez d'abord une sauvegarde du fichier.

Selon les commentaires de la configuration, la méthode recommandée pour déverrouiller les sections consiste à utiliser une balise d'emplacement:

<location path="Default Web Site" overrideMode="Allow">
    <system.webServer>
        <asp />
    </system.webServer>
</location>"

Vous pouvez donc écrire en bas (car il n'existe pas auparavant). J'écris maxvalueici - écrivez votre propre valeur si vous le souhaitez.

<location path="THENAMEOFTHESITEYOUHAVE" overrideMode="Allow">
    <system.webServer>
        <asp />
        <serverRuntime uploadReadAheadSize="2147483647" />
    </system.webServer>
</location>

Si vous le mettez en dernier </configuration>par exemple, vous savez où vous l'avez.

J'espère que cela résout vos problèmes. C'était un problème de surcharge SSL pour moi, où trop de messages bloquaient l'application, provoquant une erreur (413) Request Entity Too Large .

Je recevais ce message d'erreur, même si les maxparamètres étaient définis dans la liaison de mon fichier de configuration de service WCF:

<basicHttpBinding>
        <binding name="NewBinding1"
                 receiveTimeout="01:00:00"
                 sendTimeout="01:00:00"
                 maxBufferSize="2000000000"
                 maxReceivedMessageSize="2000000000">

                 <readerQuotas maxDepth="2000000000"
                      maxStringContentLength="2000000000"
                      maxArrayLength="2000000000" 
                      maxBytesPerRead="2000000000" 
                      maxNameTableCharCount="2000000000" />
        </binding>
</basicHttpBinding>

Il semblait que ces paramètres de liaison n'étaient pas appliqués, d'où le message d'erreur suivant:

IIS7 - (413) Request Entity Too Large lors de la connexion au service.

.

Le problème

J'ai réalisé que l' name=""attribut dans la <service>balise du web.confign'est pas un champ de texte libre, comme je le pensais. Il s'agit du nom complet d'une implémentation d'un contrat de service tel que mentionné dans cette page de documentation .

Si cela ne correspond pas, les paramètres de liaison ne seront pas appliqués!

<services>
  <!-- The namespace appears in the 'name' attribute -->
  <service name="Your.Namespace.ConcreteClassName">
    <endpoint address="http://localhost/YourService.svc"
      binding="basicHttpBinding" bindingConfiguration="NewBinding1"
      contract="Your.Namespace.IConcreteClassName" />
  </service>
</services>

J'espère que cela épargnera de la douleur à quelqu'un ...

Si vous rencontrez ce problème en essayant toutes les solutions de ce fil et que vous vous connectez au service via SSL (par exemple https), cela peut vous aider:

http://forums.newatlanta.com/messages.cfm?threadid=554611A2-E03F-43DB-92F996F4B6222BC0&#top

Pour résumer (au cas où le lien mourrait dans le futur), si vos demandes sont suffisamment importantes, la négociation de certificat entre le client et le service échouera de manière aléatoire. Pour éviter que cela ne se produise, vous devrez activer un certain paramètre sur vos liaisons SSL. À partir de votre serveur IIS, voici les étapes à suivre:

1. Via cmd ou powershell, exécutez netsh http show sslcert. Cela vous donnera votre configuration actuelle. Vous voudrez l'enregistrer d'une manière ou d'une autre afin de pouvoir le référencer à nouveau plus tard.
2. Vous devriez remarquer que «Négocier le certificat client» est désactivé. C'est le paramètre du problème; les étapes suivantes montreront comment l'activer.
3. Malheureusement, il n'existe aucun moyen de modifier les liaisons existantes; vous devrez le supprimer et le rajouter. Courir netsh http delete sslcert <ipaddress>:<port>où<ipaddress>:<port> est l'IP: port indiqué dans la configuration que vous avez enregistrée précédemment.
4. Vous pouvez maintenant rajouter la liaison. Vous pouvez afficher les paramètres valides pour netsh http add sslcert ici (MSDN) mais dans la plupart des cas, votre commande ressemblera à ceci:

netsh http add sslcert ipport=<ipaddress>:<port> appid=<application ID from saved config including the {}> certhash=<certificate hash from saved config> certstorename=<certificate store name from saved config> clientcertnegotiation=enable

Si vous avez plusieurs liaisons SSL, vous répéterez le processus pour chacune d'elles. Espérons que cela aide à sauver quelqu'un d'autre des heures et des heures de maux de tête que ce problème m'a causé.

EDIT: D'après mon expérience, vous ne pouvez pas réellement exécuter la netsh http add sslcertcommande à partir de la ligne de commande directement. Vous devrez d'abord entrer l'invite netsh en tapant netsh, puis émettez votre commande comme http add sslcert ipport=...pour que cela fonctionne.

Cela m'a aidé à résoudre le problème (une ligne - divisée pour la lisibilité / capacité de copie):

C:\Windows\System32\inetsrv\appcmd  set config "YOUR_WEBSITE_NAME" 
     -section:system.webServer/serverRuntime /uploadReadAheadSize:"2147483647" 
     /commit:apphost

Pour moi, définir le uploadReadAheadSize sur int.MaxValue a également résolu le problème, après avoir également augmenté les limites de la liaison WCF.

Il semble que, lors de l'utilisation de SSL, tout le corps de l'entité de requête est préchargé, pour lequel cette propriété de métabase est utilisée.

Pour plus d'informations, consultez:

La page n'a pas été affichée car l'entité de demande est trop grande. iis7

Pour tous ceux qui recherchent une erreur IIS WCF 413: Request entity to large and using a WCF service in Sharepoint, this is the information for you. Les paramètres de l'hôte d'application et de web.config suggérés dans d'autres sites / publications ne fonctionnent pas dans SharePoint si vous utilisez MultipleBaseAddressBasicHttpBindingServiceHostFactory. Vous pouvez utiliser SP Powershell pour obtenir le service SPWebService.Content, créer un nouvel objet SPWcvSettings et mettre à jour les paramètres comme ci-dessus pour votre service (ils n'existeront pas). N'oubliez pas d'utiliser simplement le nom du service (par exemple [yourservice.svc]) lors de la création et de l'ajout des paramètres. Voir ce site pour plus d'informations https://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service

Dans mon cas, j'ai dû augmenter la «taille maximale des messages reçus» de l'emplacement de réception dans BizTalk. Cela a également une valeur par défaut de 64 Ko et donc chaque message a été renvoyé par BizTAlk indépendamment de ce que j'ai configuré dans mon web.config

J'ai pu résoudre ce problème en exécutant un appel factice (par exemple, IsAlive retournant true) juste avant la requête avec un contenu volumineux sur le même canal / client wcf. Apparemment, la négociation SSL est effectuée au premier appel. Donc pas besoin d'augmenter Uploadreadaheadsize.

Pour le problème, le serveur distant a renvoyé une réponse inattendue: (413) Request Entity Too Large on WCF with Resful

s'il vous plaît voir ma configuration explicative

</client>
<serviceHostingEnvironment multipleSiteBindingsEnabled="false" aspNetCompatibilityEnabled="true"/>

<bindings>

   <!-- this for restfull service -->
  <webHttpBinding>
    <binding name="RestfullwebHttpBinding"
      maxBufferPoolSize="2147483647"
      maxReceivedMessageSize="2147483647"
      maxBufferSize="2147483647" transferMode="Streamed">

      <readerQuotas 
        maxDepth="2147483647" 
        maxStringContentLength="2147483647"
        maxArrayLength="2147483647" 
        maxBytesPerRead="2147483647" /> 

    </binding>
  </webHttpBinding>
  <!-- end -->

   <!-- this for Soap v.2 -->
  <wsHttpBinding>
    <binding name="wsBinding1" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
      <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false"/>
      <!--UsernameToken over Transport Security-->
      <security mode="TransportWithMessageCredential">
        <message clientCredentialType="UserName" establishSecurityContext="true"/>
      </security>
    </binding>
  </wsHttpBinding>
   <!-- this for restfull service -->

   <!-- this for Soap v.1 -->
  <basicHttpBinding>
    <binding name="basicBinding1" maxReceivedMessageSize="2147483647" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false" transferMode="Streamed">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
      <security mode="None"/>
    </binding>
  </basicHttpBinding>
</bindings> 
<!-- end -->

<services>
  <clear/>

  <service name="ING.IWCFService.CitisecHashTransfer"  >
    <endpoint address="http://localhost:8099/CitisecHashTransfer.svc"
                  behaviorConfiguration="RestfullEndpointBehavior"
                  binding="webHttpBinding"
                  bindingConfiguration="RestfullwebHttpBinding"
                  name="ICitisecHashTransferBasicHttpBinding"
                  contract="ING.IWCFService.ICitisecHashTransfer" />
  </service>

</services>
<behaviors>
  <serviceBehaviors>
    <behavior name="ServiceBehavior">
      <serviceMetadata httpsGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
      <dataContractSerializer maxItemsInObjectGraph="2147483647"/>

      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="ING.IWCFService.IWCFServiceValidator, ING.IWCFService"/>
      </serviceCredentials>
      <serviceSecurityAudit auditLogLocation="Application" serviceAuthorizationAuditLevel="SuccessOrFailure" messageAuthenticationAuditLevel="SuccessOrFailure"/>
      <serviceThrottling maxConcurrentCalls="1000" maxConcurrentSessions="100" maxConcurrentInstances="1000"/>

    </behavior>
    <behavior>
      <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="true"/>
      <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
    </behavior>
  </serviceBehaviors>
  <endpointBehaviors>
    <behavior name="EndpointBehavior">
      <dataContractSerializer maxItemsInObjectGraph="2147483647" />
    </behavior> 
    <behavior name="RestfullEndpointBehavior">
      <dataContractSerializer maxItemsInObjectGraph="2147483647"  />
      <webHttp/>
    </behavior> 
  </endpointBehaviors>
</behaviors>

Dans mon cas, je recevais ce message d'erreur parce que j'ai été modifié l'espace de noms du service et la balise services a été pointée vers l'ancien espace de noms. J'ai rafraîchi l'espace de noms et l'erreur disparaît:

<services>
  <service name="My.Namespace.ServiceName"> <!-- Updated name -->
    <endpoint address="" 
              binding="wsHttpBinding" 
              bindingConfiguration="MyBindingConfiguratioName" 
              contract="My.Namespace.Interface" <!-- Updated contract -->
    />
  </service>
</services>

Vous avez une erreur similaire sur IIS Express avec Visual Studio 2017.

Erreur HTTP 413.0 - Entité de demande trop grande

La page n'a pas été affichée car l'entité de demande est trop grande.

Causes les plus probables:

• Le serveur Web refuse de traiter la demande car l'entité de demande est trop volumineuse.

• Le serveur Web ne peut pas traiter la demande car il tente de négocier un certificat client mais l'entité de demande est trop volumineuse.

• L'URL de la demande ou le mappage physique vers l'URL (c'est-à-dire, le chemin d'accès du système de fichiers physique au contenu de l'URL) est trop long.

Choses que vous pouvez essayer:

• Vérifiez que la demande est valide.

• Si vous utilisez des certificats clients, essayez:

  • Augmentation de system.webServer/serverRuntime@uploadReadAheadSize

  • Configurez votre point de terminaison SSL pour négocier les certificats clients dans le cadre de la négociation SSL initiale. (netsh http ajouter sslcert ... clientcertnegotiation = activer) .vs \ config \ applicationhost.config

Résolvez cela en éditant \.vs\config\applicationhost.config. Passer serverRuntimede Denyà Allowcomme ceci:

<section name="serverRuntime" overrideModeDefault="Allow" />

Si cette valeur n'est pas modifiée, vous obtiendrez une erreur comme celle-ci lors du réglage uploadReadAheadSize:

Erreur HTTP 500.19 - Erreur de serveur interne

Impossible d'accéder à la page demandée car les données de configuration associées pour la page ne sont pas valides.

Cette section de configuration ne peut pas être utilisée sur ce chemin. Cela se produit lorsque la section est verrouillée au niveau parent. Le verrouillage est soit par défaut (overrideModeDefault = "Deny"), soit défini explicitement par une balise d'emplacement avec overrideMode = "Deny" ou l'héritage allowOverride = "false".

Puis modifiez Web.configavec les valeurs suivantes:

<system.webServer>
  <serverRuntime uploadReadAheadSize="10485760" />
...