(413) Entité de demande trop grande | uploadReadAheadSize

Ce n’est pas un problème d’IIS mais le problème de WCF. WCF limite par défaut les messages à 65 Ko pour éviter les attaques par déni de service avec des messages volumineux. Aussi, si vous n’utilisez pas MTOM, il envoie des octets [] à la chaîne codée en base64 (augmentation de taille de 33%) => 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é l’erreur 400 Bad Request, mais dans une 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 liaison. Vous pouvez également avoir besoin de définir readerQuotas .

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 il retournerait l’erreur 413 “Entité de requête trop grande”.

La première chose à 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 avez un service REST, vous devez le configurer en tant que “webHttpBinding”. Voici le correctif:

J’ai eu le même problème et uploadReadAheadSize réglé le uploadReadAheadSize :

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 de cmd-thing.

Son 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 dans la configuration, la méthode recommandée pour déverrouiller les sections consiste à utiliser une balise de localisation:

     " 

Donc, vous pouvez écrire dans le bas (car il n’existe pas avant). J’écris ici maxvalue – écris ta propre valeur si tu veux.

Si vous le mettez avant 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 gelaient l’application, générant une erreur (413) Request Entity Too Large .

Je recevais ce message d’erreur, même si j’avais les parameters max définis dans la liaison de mon fichier de configuration de service WCF:

Il semblait que ces parameters de liaison n’étaient pas appliqués, donc le message d’erreur suivant:

IIS7 – (413) Demande d’entité trop grande lors de la connexion au service.

.

Le problème

J’ai réalisé que l’atsortingbut name="" dans la du web.config n’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, comme indiqué dans cette page de documentation .

Si cela ne correspond pas, les parameters de liaison ne seront pas appliqués!

J’espère que cela sauve quelqu’un de la douleur …

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

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

Si vous rencontrez ce problème malgré toutes les solutions de ce thread 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

En résumé (si le lien meurt à l’avenir), si vos demandes sont suffisamment importantes, la négociation du certificate entre le client et le service échouera de manière aléatoire. Pour éviter cela, vous devez 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 sauvegarder ceci pour que vous puissiez le consulter à nouveau plus tard.
2. Vous devriez noter que “Negotiate Client Certificate” est désactivé. Ceci est la configuration du problème; les étapes suivantes montreront comment l’activer.
3. Malheureusement, il est impossible de modifier les liaisons existantes. vous devrez le supprimer et le rappend. Exécutez netsh http delete sslcert : où : adresse IP : correspond au port IP: indiqué dans la configuration que vous avez enregistrée précédemment.
4. Maintenant, vous pouvez append à nouveau la liaison. Vous pouvez afficher les parameters valides pour netsh http add sslcert ici (MSDN), mais dans la plupart des cas, votre commande ressemblera à ceci:

netsh http add sslcert ipport=: appid= certhash= certstorename= clientcertnegotiation=enable

Si vous avez plusieurs liaisons SSL, vous répétez le processus pour chacune d’entre elles. J’espère que cela aidera à sauver quelqu’un d’autre 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 exécuter directement la commande netsh http add sslcert partir de la ligne de commande. Vous devrez d’abord entrer l’invite netsh en tapant netsh , puis émettre votre commande comme http add sslcert ipport=... pour qu’elle fonctionne.

Pour toute autre personne recherchant une erreur IIS WCF 413: Demande d’entité à grande taille et utilisation d’un service WCF dans Sharepoint, voici les informations pour vous. Les parameters 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 object SPWcvSettings et mettre à jour les parameters ci-dessus pour votre service (ils n’existeront pas). N’oubliez pas de simplement utiliser le nom du service (par exemple, [yourservice.svc]) lors de la création et de l’ajout des parameters. 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 du message reçu” 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 renvoyant la valeur true) juste avant la requête avec un contenu volumineux sur le même canal / client wcf. Apparemment, la négociation ssl est faite lors du premier appel. Donc, pas besoin d’augmenter la taille des téléchargements.

Pour moi, la définition de 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 du protocole SSL, le corps entier de l’entité de requête soit préchargé, pour lequel cette propriété de métabase est utilisée.

Pour plus d’informations, voir:

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

pour problème, le serveur distant a renvoyé une réponse inattendue: (413) Demande d’entité trop grande sur WCF avec Resful

s’il vous plaît voir ma configuration d’expliquer

Dans mon cas, je recevais ce message d’erreur parce que j’ai été remplacé par le nom de service et la balise de services pointée vers l’ancien espace de noms. J’ai rafraîchi l’espace de nommage et l’erreur disparaît:

     />