(413) Entité de demande trop grande | uploadReadAheadSize

Question

J'ai écrit un service WCF avec .NET 4.0, qui est hébergé sur mon ordinateur Windows 7. x64 Système ultime avec IIS 7.5. L'une des méthodes du service a pour argument un "objet" et j'essaie d'envoyer un byte[] qui contient une image. Tant que la taille du fichier de cette image est inférieure à environ 48 Ko, tout se passe bien. Mais si j'essaie de télécharger une image plus grande, le service WCF renvoie une erreur : (413) Request Entity Too Large. Bien sûr, j'ai passé 3 heures à chercher le message d'erreur sur Google et tous les sujets que j'ai vus à ce sujet suggèrent d'augmenter la propriété 'uploadReadAheadSize'. Ce que j'ai fait, c'est utiliser les commandes suivantes (10485760 = 10MB) :

"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 "Configuration Editor" sous Management. Malheureusement, j'obtiens toujours l'erreur "Request Entity Too Large" et cela devient vraiment frustrant !

Quelqu'un sait-il ce que je peux essayer d'autre pour corriger cette erreur ?

Answer 1

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

Pour résoudre ce problème, vous devez reconfigurer votre service pour accepter des messages plus volumineux. Cette question a précédemment tiré 400 Bad Request erreur 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 maxReceivedMessageSize dans votre reliure. Vous pouvez également avoir besoin de définir readerQuotas .

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

Answer 2

J'avais le même problème avec IIS 7.5 avec un service WCF REST. J'essayais de télécharger via POST un fichier de plus de 65k et il retournait 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 web.config. Voici un excellent article...

BasicHttpBinding vs WsHttpBinding vs WebHttpBinding

Si vous avez un service REST, vous devez le configurer comme "webHttpBinding". Voici la solution :

<system.serviceModel>

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

Answer 3

J'ai eu le même problème et le réglage de la uploadReadAheadSize l'a ré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 truc par cmd.

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

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

D'après les commentaires de la configuration, la manière recommandée de déverrouiller les sections est d'utiliser une balise de localisation :

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

Vous pouvez donc écrire dans le fond (puisqu'il n'existe pas auparavant). J'écris maxvalue ici - é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 avant </configuration> par exemple, vous savez où vous l'avez.

J'espère que cela résout vos problèmes. Il s'agissait pour moi d'un problème de surcharge SSL, où trop de messages bloquaient l'application, ce qui entraînait l'apparition d'un (413) Entité de demande trop grande erreur.

Answer 4

J'ai reçu ce message d'erreur, même si j'avais la max définis dans la liaison de mon fichier de configuration du 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 semble que ces paramètres de liaison ne soient 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

Je me suis rendu compte que le name="" au sein de l'élément <service> de l'étiquette web.config es pas un champ de texte libre, comme je le pensais. Il s'agit du nom entièrement qualifié d'une mise en œuvre d'un contrat de service comme 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 ça évitera à quelqu'un de souffrir...

Answer 5

Si vous rencontrez ce problème malgré toutes les solutions proposées dans ce fil de discussion et que vous vous connectez au service via SSL (par exemple, https), cette solution peut vous aider :

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

Pour résumer (au cas où la liaison serait interrompue à l'avenir), si vos demandes sont suffisamment importantes, la négociation du certificat entre le client et le service échouera de manière aléatoire. Pour éviter que cela ne se produise, vous devez activer un certain paramètre sur vos liaisons SSL. Depuis votre serveur IIS, voici les étapes que vous devez suivre :

1. Via cmd ou powershell, exécutez netsh http show sslcert . Vous obtiendrez ainsi votre configuration actuelle. Vous voudrez l'enregistrer d'une manière ou d'une autre afin de pouvoir y faire référence ultérieurement.
2. Vous devriez remarquer que "Negotiate Client Certificate" est désactivé. C'est le paramètre qui pose problème ; les étapes suivantes montrent comment l'activer.
3. Malheureusement, il n'y a aucun moyen de modifier les liaisons existantes ; vous devrez les supprimer et les réinsérer. Exécutez netsh http delete sslcert <ipaddress>:<port> donde <ipaddress>:<port> est l'IP:port indiqué dans la configuration que vous avez sauvegardée précédemment.
4. Maintenant, vous pouvez ajouter à nouveau la reliure. Vous pouvez voir 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 devez répéter le processus pour chacune d'entre elles. J'espère que cela permettra à quelqu'un d'autre d'éviter les heures et les 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 fonction netsh http add sslcert à partir de la ligne de commande directement. Vous devrez d'abord entrer dans l'invite netsh en tapant netsh puis lancez votre commande comme http add sslcert ipport=... pour qu'il fonctionne.