Le serveur n'a pas reconnu la valeur de HTTP SOAPAction d'en-tête

La source de la prochaine partie de cette publication est:

http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/

(Puisque l'OP ne voulait pas donner d'attribution, et grâce à Peter)

Notez que bakert est l'auteur original du texte, et non l'OP.

En voyant que nulle part sur Internet, je peux trouver une explication de cette erreur, je pensais partager les fruits de ma longue recherche pour ce bug.

Cela signifie (au moins dans mon cas) que vous accédez à un service Web avec SOAP et que vous passez un paramètre SOAPAction dans la requête HTTP qui ne correspond pas à ce que le service attend.

Je suis entré dans un pickle parce que nous avons déplacé un service Web d'un serveur à l'autre et j'ai donc changé l'espace de noms (ne pas être confondu entre les espaces de noms de service Web et les espaces de noms .net) dans le fichier C # appel pour correspondre au nouveau serveur. Mais le serveur ne se préoccupe pas de la réalité Web actuelle de http // ourournamespace.com/blah, il se soucie seulement que vous l'envoyez ce que vous avez dit que vous attendez sur le serveur. Il ne se soucie pas s'il y a quelque chose de réel ou pas.

Donc, fondamentalement, le service Web a été déplacé de http: //foo.com/servicename à http: //bar.com/servicename mais l'espace de noms du service Web est resté http: //foo.com/servicename parce que personne L'a changé.

Et cela n'a pris que 4 heures pour fonctionner!

Si vous rencontrez un problème similaire, mais ne peut pas travailler ce que je dis ici, n'hésitez pas à m'envoyer un mail sur bakert + [email protected]. Je ne voudrais pas mes quatre heures pour personne.

Je suis d'accord avec Sam en ce sens que la définition SOAP ne correspond pas à ce qui est attendu. Voici juste une solution possible, je devais trouver manuellement cette erreur pour moi-même:

Mon problème était que j'ai changé le nom de la méthode Web mais je n'ai pas modifié le "MessageName" dans la balise de métadonnées.

 [WebMethod(MessageName = "foo")] public string bar() { } 

CA devrait etre

 [WebMethod(MessageName = "foo")] public string foo() { } 

J'espère que cela aide quelqu'un

En appelant le service web .asmx / wcf, prenez soin des points ci-dessous:

1. L'espace de noms est sensible à la casse, la requête SOAP DOIT être envoyée avec le même espace de noms avec lequel le WebService est déclaré.

Par exemple, pour le service Web déclaré comme ci-dessous

 [WebService(Namespace = "http://MyDomain.com/TestService")] public class FooClass : System.Web.Services.WebService { [WebMethod] public bool Foo( string name) { ...... } } 

La demande SOAP doit conserver le même cas pour l'espace de noms lors de l'appel. Quelquefois, nous ignorons la sensibilité du cas.

 <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <Foo xmlns="http://MyDomain.com/TestService"> <name>string</name> </Foo> </soap:Body> </soap:Envelope> 

2. L'espace de noms n'a pas besoin d'être identique à l'URL hébergée du service. L'espace de noms peut être n'importe quelle chaîne.

Par exemple, le service ci-dessus peut être hébergé à l' adresse http://84.23.9.65/MyTestService , mais tout en invoquant le service Web du client, l'espace de noms devrait être identique à celui de la classe Serice, à savoir http://MyDomain.com/TestService

Juste pour aider quelqu'un sur ce problème, après un après-midi de débogage, le problème était que le service Web a été développé avec le cadre 4.5 et l'appel d'Android doit être fait avec SoapEnvelope.VER12 et non avec SoapEnvelope.VER11

J'avais un problème similaire. Pour déboguer le problème, j'ai exécuté Wireshark et la demande de capture générée par mon code. Ensuite, j'ai utilisé XML Spy trial pour créer une demande SOAP (en supposant que vous avez WSDL) et comparé ces deux.

Cela devrait vous donner une idée de ce qui ne va pas.

J'ai décidé de publier ma propre réponse ici parce que j'ai perdu quelques heures à ce sujet et je pense que, bien que la réponse acceptée soit très bonne et m'a pointé dans la bonne direction (oui, il a eu un vote), c'était Pas suffisamment détaillé pour expliquer ce qui ne va pas avec ma demande, du moins dans mon cas.

Je lance un module BPEL dans OpenESB 2.2 et le cas de test de mon application composite a échoué avec l'erreur suivante:

 Caused by: System.Web.Services.Protocols.SoapException: Server did not recognize the value of HTTP Header SOAPAction: . 

Après avoir effectué des recherches, j'ai remarqué que la WSDL externe possède tous les indices dont nous avons besoin pour résoudre ce problème, par exemple, j'utilise le service Web suivant pour valider un numéro de carte de crédit grâce à une orchestration de Web Services: http: // http://Www.webservicex.net/CreditCard.asmx?WSDL

Si vous vérifiez les éléments de l' <wsdl:operation vous verrez qu'il indique clairement l'effet soapAction pour cette opération:

 <wsdl:binding name="CCCheckerSoap" type="tns:CCCheckerSoap"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="ValidateCardNumber"> <soap:operation soapAction="http://www.webservicex.net/ValidateCardNumber" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> ... 

Mais, une fois que vous avez créé l'application composite et que vous construisez le projet avec BPEL qui invoque ce service WSDL externe, pour une raison quelconque (bug?), Le XML de la liaison Composite Application Service Assembly (CASA) est généré avec un paramètre soapAction vide:

 <binding name="casaBinding1" type="ns:CCCheckerSoap"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="ValidateCardNumber"> <soap:operation soapAction="" style="document"/> <input> <soap:body use="literal"/> </input> 

Une fois que vous copiez le soapAction approprié (http://www.webservicex.net/ValidateCardNumber) dans ce paramètre, le cas de test de l'application sera correctement et renverrez la réponse de savon attendue.

 <soap:operation soapAction="http://www.webservicex.net/ValidateCardNumber" style="document"/> 

Donc, c'est une solution plus spécifique que j'ai décidé de documenter en fonction de l'information trouvée dans cette publication: http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/ .

Cela signifie (au moins dans mon cas) que vous accédez à un service Web avec SOAP et que vous passez un paramètre SOAPAction dans la requête HTTP qui ne correspond pas à ce que le service attend .

J'ai eu le même problème, il a été corrigé après quelques vérifications:

<< Target WebService existe, mais appelé méthode, non eXXXists. >>

Mon service local contient des méthodes, mais le serveur cible (serveur de connexion) ne contient pas de méthode appelée spécifiée.

Vérifiez à nouveau le scénario de votre programme …

J'ai eu le même problème après avoir changé l'espace de noms de "tempuri" dans mon service Web.

Vous devez mettre à jour votre référence de service dans le projet qui consomme le service ci-dessus, afin qu'il puisse obtenir les dernières définitions SOAP.

Ou du moins cela a fonctionné pour moi. 🙂

Nous avons renommé certains de nos espaces de noms de projet web et nous avons oublié de mettre à jour la section de configuration httphandlers du site Web avec l'espace de noms des projets renommés.

Ma faute est résolue par la réponse M. John Saunders: http://forums.asp.net/post/2906487.aspx

En bref: différence entre l'espace de noms de ws .asmx.cs avec ws .wsdl files.

 1) [WebService(Namespace = "http://tempuri.org/")] 

L'espace de nommage du service Web ultérieur a changé pour:

 2) [WebService(Namespace = "http://newvalue.com/")] 

Nous avons donc mentionné (1) dans la demande et le service Web est (2) maintenant.

Rendez-les égaux pour réparer votre problème.

J'ai dû trier la majuscule de ma référence de service, supprimer les références et les ajouter pour corriger cela. Je ne suis pas sûr si l'une de ces étapes est superstitieuse, mais le problème a disparu.

J'ai eu un problème similaire avec le même message d'erreur:

System.Web.Services.Protocols.SoapException: serveur n'a pas reconnu la valeur de l'en-tête HTTP SOAPAction :

Nous utilisons des URL dynamiques dans nos appels de service Web. Nous avons un serveur de configuration central qui gère l'emplacement de tous les appels de service Web afin que notre code puisse s'exécuter en DEV, tester ou vivre sans recompiler. L'URL d'un appel de service Web spécifique pour l'environnement de test était incorrecte dans notre serveur de configuration. L'appel du service Web a été envoyé au mauvais serveur et au mauvais service Web.

Cette erreur peut donc résulter simplement du fait que la demande de service Web ne correspond pas au service Web appelé.

Il a fallu de l'exécution de violoneux sur le serveur de l'application Web pour voir que l'appel réel concernait le service Web incorrect.

Le problème se trouve dans System.Web.Services.Protocols.SoapDocumentMethodAttribute dans le service. S'il te plaît vérifie le. Il peut changer.

J'ai eu la même erreur, j'ai pu le résoudre en supprimant la «Référence Web» et en ajoutant plutôt une «référence de service»

J'ai eu cette erreur lorsque j'ai essayé d'appeler une méthode qui n'existait pas. Cela n'existait que dans une version plus récente de notre service web.