Echec de la demande de service Web WCF de grande taille avec (400) demande HTTP incorrecte

J’ai rencontré ce problème apparemment commun et j’ai été incapable de le résoudre.

Si j’appelle mon service Web WCF avec un nombre relativement petit d’éléments dans un paramètre de tableau (j’ai testé jusqu’à 50), tout va bien.

Cependant, si j’appelle le service Web avec 500 éléments, j’obtiens l’erreur de demande incorrecte.

Fait intéressant, j’ai exécuté Wireshark sur le serveur et il semble que la requête ne touche même pas le serveur – l’erreur 400 est générée du côté client.

L’exception est:

System.ServiceModel.ProtocolException: The remote server returned an unexpected response: (400) Bad Request. ---> System.Net.WebException: The remote server returned an error: (400) Bad Request. 

La section system.serviceModel de mon fichier de configuration client est la suivante:

                  

Du côté du serveur, mon fichier web.config a la section system.serviceModel suivante:

                           

J’ai examiné un nombre assez important de réponses à cette question sans succès .

Est-ce que quelqu’un peut m’aider avec ça?

Essayez également de définir maxReceivedMessageSize sur le serveur, par exemple à 4 Mo:

   

La principale raison pour laquelle la valeur par défaut (65535, je crois) est si faible est la réduction du risque d’attaques par déni de service (DoS). Vous devez le définir plus grand que la taille de requête maximale sur le serveur et la taille de réponse maximale sur le client. Si vous vous trouvez dans un environnement Intranet, le risque d’attaques par déni de service est probablement faible. Il est donc sans doute préférable d’utiliser une valeur beaucoup plus élevée que ce à quoi vous vous attendez.

En passant, quelques conseils pour résoudre les problèmes de connexion aux services WCF:

  • Activez le suivi sur le serveur comme décrit dans cet article MSDN .

  • Utilisez un outil de débogage HTTP tel que Fiddler sur le client pour inspecter le trafic HTTP.

J’avais aussi ce problème aussi, mais rien de ce qui précède n’a fonctionné pour moi car j’utilisais une liaison personnalisée (pour BinaryXML) après une longue période de recherche, j’ai trouvé la réponse ici: –

Envoi de fichiers XML volumineux de Silverlight à WCF

Comme j’utilise un customBinding, le paramètre maxReceivedMessageSize doit être défini sur l’élément httpTransport sous l’élément de liaison dans le fichier web.config:

  

Pour ce que cela vaut, une considération supplémentaire lors de l’utilisation de .NET 4.0 est que si un noeud final valide n’est pas trouvé dans votre configuration, un noeud final par défaut sera automatiquement créé et utilisé.

Le noeud final par défaut utilisera toutes les valeurs par défaut. Si vous pensez avoir une configuration de service valide avec une valeur élevée pour maxReceivedMessageSize, mais qu’il y a un problème avec la configuration, vous obtiendrez toujours la requête 400 car un noeud final par défaut serait créé et utilisé.

Ceci est fait en silence, donc difficile à détecter. Vous verrez des messages à cet effet (par exemple, “Aucun point d’extrémité trouvé pour le service, création d’un sharepoint terminaison par défaut” ou similaire) si vous activez le traçage sur le serveur mais aucune autre indication (à ma connaissance).

Dans le serveur de .NET 4.0 dans web.config, vous devez également modifier la liaison par défaut. Définissez les 3 parameters suivants:

  < basicHttpBinding> < !--http://www.intertech.com/Blog/post/NET-40-WCF-Default-Bindings.aspx - Enable transfer of large strings with maxBufferSize, maxReceivedMessageSize and maxStringContentLength --> < binding **maxBufferSize="2147483647" maxReceivedMessageSize="2147483647"**> < readerQuotas **maxStringContentLength="2147483647"**/> < /binding> 

Il peut être utile de déboguer le client, désactivez Outils \ Options \ Débogage \ Général \ Activer uniquement mon code, cliquez sur Débogage \ Exceptions \ ‘intercepter toutes les exceptions de la première chance’ pour les exceptions CLR gérées et voir s’il existe un exception sous-jacente sur le client avant l’exception de protocole et avant que le message n’atteigne le fil. (Je suppose que ce serait une sorte d’échec de sérialisation.)

Vous pouvez également activer la journalisation WCF pour plus d’informations sur l’erreur d’origine. Cela m’a aidé à résoudre ce problème.

Ajoutez ce qui suit à votre fichier web.config, il enregistre le journal dans C: \ log \ Traces.svclog

          

Je veux juste souligner

Mis à part MaxRecivedMessageSize, il existe également des atsortingbuts sous ReaderQuotas, vous pouvez atteindre la limite du nombre d’éléments au lieu de la taille limite. Le lien MSDN est ici

J’ai trouvé la réponse au problème de Bad Request 400.

C’était le paramètre de liaison par défaut du serveur. Vous devez append au paramètre par défaut du serveur et du client.

binding name = “” openTimeout = “00:10:00” closeTimeout = “00:10:00” receiveTimeout = “00:10:00” sendTimeout = “00:10:00” maxReceivedMessageSize = “2147483647” maxBufferPoolSize = “2147483647 “maxBufferSize =” 2147483647 “>

Dans mon cas, cela ne fonctionnait pas même après avoir essayé toutes les solutions et fixé toutes les limites à max. En dernier, j’ai découvert qu’un module de filtrage Microsoft IIS Url Scan 3.1 était installé sur IIS / site Web, qui a sa propre limite pour rejeter les demandes entrantes en fonction de la taille du contenu et renvoyer “404 Page introuvable”.

Sa limite peut être mise à jour dans le fichier %windir%\System32\inetsrv\urlscan\UrlScan.ini en définissant MaxAllowedContentLength sur la valeur requirejse.

Par exemple suivant permettra jusqu’à 300 mb demandes

MaxAllowedContentLength = 314572800

J’espère que ça va aider quelqu’un!