(413) entité de requête trop grande | uploadReadAheadSize
J'ai écrit un service WCF avec .NET 4.0, qui est hébergé sur mon Windows 7 x64 Système ultime avec IIS 7.5 . Une des méthodes de service a un objet comme argument et j'essaie envoyer un octet [] contenant une image . Tant que la taille de fichier de cette image est inférieure à env. 48Ko, tout va bien. Mais si j'essaye de télécharger une image plus grande, le service WCF renvoie une erreur: (413) Request Entity Too Large. Alors bien sûr, j'ai passé 3 heures à googler le message d'erreur et chaque sujet que j'ai vu à propos de ce sujet suggère d'élever le message 'uploadReadAheadSize 'property . J'ai donc utilisé 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 "Editeur de configuration" sous Gestion . Malheureusement, l'erreur relative à Request Entity Too Large s'affiche toujours et cela devient vraiment frustrant!
Alors, est-ce que quelqu'un sait quoi d'autre je peux essayer de réparer cette erreur?
Ce n'est pas un problème de 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. De plus, si vous n'utilisez pas MTOM, il envoie octet [] à la chaîne encodée en base64 (augmentation de la taille de 33%) => 48 Ko * 1,33 = 64 Ko.
Pour résoudre ce problème, vous devez reconfigurer votre service pour accepter les messages plus volumineux. Ce problème avait déjà déclenché une erreur 400 Bad Request, mais dans la version plus récente, WCF a commencé à utiliser le code 413, code de statut correct pour ce type d'erreur.
Vous devez définir maxReceivedMessageSize dans 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. En essayant de télécharger via POST tout fichier supérieur à 65 000 $, l'erreur 413 "Entité de demande trop grande" serait renvoyée.
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 avez un service REST, vous devez le configurer en tant que "webHttpBinding". Voici le correctif:
<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 régler le uploadReadAheadSize l'a résolu:
http://www.iis.net/configreference/system.webserver/serverruntime
"La valeur doit être comprise entre 0 et 2147483647."
Il est facilement paramétrable dans applicationHost.config-fle si vous ne voulez pas faire un objet cmd.
Son situé dans WindowsFOLDER\System32\inetsrv\config (serveur 2008).
Vous devez l'ouvrir avec le bloc-notes. Faites d'abord une sauvegarde du fichier.
Selon les commentaires dans config, le moyen recommandé pour déverrouiller les sections est d'utiliser une balise d'emplacement:
<location path="Default Web Site" overrideMode="Allow">
<system.webServer>
<asp />
</system.webServer>
</location>"
Donc, vous pouvez écrire dans le bas (puisqu'il n'existait pas auparavant). J'écris maxvalue ici - écrivez votre propre valeur si vous voulez.
<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ésoudra vos problèmes. Pour moi, il s’agissait d’un problème de temps système SSL, où trop de publications avaient été gelées après application, générant une erreur (413) Request Entity Too Large.
Je recevais ce message d'erreur, même si les paramètres max é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 ne soient pas appliqués. C'est pourquoi le message d'erreur suivant:
IIS7 - (413) Demander une entité trop grande lors de la connexion au service.
.
Le problème
J'ai réalisé que l'attribut name="" dans la balise <service> du web.config est not 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 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 à quelqu'un de la douleur ...
Cela m'a aidé à résoudre le problème (une ligne - divisé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 en dépit de toutes les solutions de ce fil et que vous vous connectez au service via SSL (par exemple, https), cela pourrait aider:
http://forums.newatlanta.com/messages.cfm?threadid=554611A2-E03F-43DB-92F996F4B6222BC0&#top
Pour résumer (au cas où le lien disparaîtrait à l'avenir), si vos demandes sont suffisamment volumineuses, la négociation du certificat entre le client et le service échouera de manière aléatoire. Pour que cela ne se produise pas, vous devez activer un certain paramètre sur vos liaisons SSL. Depuis votre serveur IIS, voici les étapes à suivre:
- Via cmd ou powershell, exécutez
netsh http show sslcert. Cela vous donnera votre configuration actuelle. Vous voudrez peut-être enregistrer ceci d'une manière ou d'une autre pour pouvoir le référencer ultérieurement. - Vous devriez remarquer que "Négocier le certificat de client" est désactivé. C'est la configuration du problème; les étapes suivantes montreront comment l'activer.
- Malheureusement, il n’existe aucun moyen de modifier les liaisons existantes; vous devrez le supprimer et le rajouter. Exécutez
netsh http delete sslcert <ipaddress>:<port>où<ipaddress>:<port>est l'adresse IP: le port indiqué dans la configuration que vous avez précédemment enregistrée. - Maintenant, vous pouvez ré-ajouter la liaison. Vous pouvez afficher les paramètres valides pour
netsh http add sslcerthere (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 allez répéter le processus pour chacune d'elles. J'espère que cela aidera à sauver quelqu'un d'autre des heures et des heures de maux de tête que ce problème m'a causés.
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 devez d'abord entrer l'invite netsh en tapant netsh, puis émettre votre commande comme http add sslcert ipport=... pour que cela fonctionne.
Pour les autres personnes à la recherche d'une IIS erreur WCF 413: demander une entité trop grande et utiliser un service WCF dans Sharepoint, ces informations sont pour vous. Les paramètres de l'application hôte et 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 de n'utiliser que le nom du service (par exemple, [yourservice.svc]) lors de la création et de l'ajout des paramètres. Consultez ce site pour plus d'informations https://robertsep.wordpress.com/2010/12/21/set-maximum-upload-filesize-sharepoint-wcf-service
Pour moi, définir uploadReadAheadSize sur int.MaxValue corrigeait également le problème, après avoir également augmenté les limites de la liaison WCF.
Il semble que, lorsque vous utilisez SSL, l'intégralité du corps de l'entité de demande est préchargée, 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 la demande est trop grande. iis7
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 64K 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 demande avec un contenu volumineux sur le même canal/client wcf. Apparemment, la négociation ssl est faite au premier appel. Donc pas besoin d'augmenter Uploadreadaheadsize.
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 la demande est trop grande.
Causes les plus probables:
Le serveur Web refuse de traiter la demande parce que la demande l'entité est trop grande.
Le serveur Web ne peut pas traiter la demande car il tente d'exécuter négocier un certificat client, mais l'entité de la demande est trop grande.
L'URL de la demande ou le mappage physique sur l'URL (c'est-à-dire le chemin du système de fichiers physique Vers le 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 client dans le cadre de la poignée de main initiale SSL. (netsh http add sslcert ... clientcertnegotiation = enable) .vs\config\applicationhost.config
Résolvez ceci en éditant \.vs\config\applicationhost.config. Passez de serverRuntime de Deny à Allow comme ceci:
<section name="serverRuntime" overrideModeDefault="Allow" />
Si cette valeur n'est pas modifiée, vous obtiendrez une erreur comme celle-ci lors de la définition de uploadReadAheadSize:
Erreur HTTP 500.19 - Erreur interne du serveur
La page demandée est inaccessible car le fichier .__ correspondant. les données de configuration pour la page ne sont pas valides.
Cette section de configuration ne peut pas être utilisée sur ce chemin. Ça arrive lorsque la section est verrouillée au niveau parent. Le verrouillage est soit par default (overrideModeDefault = "Deny"), ou défini explicitement par un emplacement balise avec overrideMode = "Deny" ou l'héritage allowOverride = "false".
Puis éditez Web.config avec les valeurs suivantes:
<system.webServer>
<serverRuntime uploadReadAheadSize="10485760" />
...
Dans mon cas, je recevais ce message d'erreur parce que j'avais changé l'espace de noms du service et que la balise services était dirigée vers l'ancien espace de noms. J'ai rafraîchi l'espace de noms et l'erreur a disparu:
<services>
<service name="My.Namespace.ServiceName"> <!-- Updated name -->
<endpoint address=""
binding="wsHttpBinding"
bindingConfiguration="MyBindingConfiguratioName"
contract="My.Namespace.Interface" <!-- Updated contract -->
/>
</service>
</services>
le serveur distant a renvoyé une réponse inattendue: (413) Demander une entité trop grande sur WCF avec Resful
s'il vous plaît voir ma configuration d'expliquer
</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>