Le serveur n'a pas reconnu la valeur de l'en-tête HTTP SOAPAction
[SoapRpcMethod(Action = "http://cyberindigo/TempWebService/InsertXML",
RequestNamespace = "http://cyberindigo/TempWebService/Request",
RequestElementName = "InsertXMLRequest",
ResponseNamespace = "http://cyberindigo/TempWebService/Response",
ResponseElementName = "InsertXMLResponse",
Use = System.Web.Services.Description.SoapBindingUse.Literal)]
[WebMethod]
public string InsertXML(string Jobs)
{
return "Hi";
}
Le problème lorsque j'y accède à l'aide de XMLHttpRequest donne l'erreur suivante Le serveur n'a pas reconnu la valeur de HTTP Header SOAPAction: http: // Cyberindigo/TempWebService/InsertXML
La source de la prochaine partie de ce post est:
http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/
(puisque le PO ne voulait pas attribuer, et merci à Peter)
Veuillez noter que Bakert est l'auteur original du texte, pas le PO.
Étant donné que nulle part sur Internet je ne peux trouver une explication à cette erreur, je pensais partager les fruits de ma longue recherche de ce bogue.
Cela signifie (du moins dans mon cas) que vous accédez à un service Web avec SOAP et transmettez un paramètre SOAPAction dans la demande HTTP qui ne correspond pas à ce que le service attend.
Je me suis retrouvé dans le pétrin parce que nous avons déplacé un service Web d’un serveur à un autre et j’ai donc modifié l’espace de noms (ne confondez pas les espaces de noms de services Web et les espaces de noms .net) dans le fichier C # appelant pour le faire correspondre au nouveau serveur. Mais le serveur ne se soucie pas de la réalité Web réelle de http //yournamespace.com/blah, il se soucie seulement de lui envoyer ce que vous avez dit que vous attendiez sur le serveur. Peu importe qu’il y ait quoi que ce soit ou non.
Donc, fondamentalement, le service Web a été déplacé de http: //foo.com/servicename vers http: //bar.com/servicename, mais le «namespace» du service Web est resté en tant que http: //foo.com/servicename car personne changé cela.
Et cela a pris environ 4 heures pour travailler!
Si vous rencontrez un problème similaire mais que vous ne pouvez pas travailler ce que je dis ici, n'hésitez pas à m'envoyer un mail à [email protected] - Je ne voudrais pas que mes quatre heures soient réservées à quiconque!
Je suis d'accord avec Sam en ce que la définition SOAP ne correspond pas à ce qui est attendu. Voici une solution possible, j'ai dû calculer manuellement cette erreur:
Mon problème était que j'ai changé le nom de la méthode Web mais pas le "Nom du message" dans la balise de métadonnées.
[WebMethod(MessageName = "foo")]
public string bar()
{
}
CA devrait etre
[WebMethod(MessageName = "foo")]
public string foo()
{
}
espérons que cela aide quelqu'un
Lorsque vous appelez le service Web .asmx/wcf, veuillez prendre en compte les points suivants:
- L'espace de nom est sensible à la casse, la demande SOAP DOIT être envoyée avec le même espace de nom que celui avec lequel le service Web est déclaré.
par exemple. Pour le WebService déclaré 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 casse pour l'espace de noms tout en appelant.
<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>
- L'espace de noms ne doit pas nécessairement être identique à l'URL hébergée du service. L'espace de noms peut être une chaîne.
par exemple. Le service ci-dessus peut être hébergé sur http://84.23.9.65/MyTestService , mais tout en appelant le service Web à partir du client, l'espace de noms doit être identique à celui de la classe de 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 avait été développé avec Framework 4.5 et que l'appel d'Android devait être effectué avec SoapEnvelope.VER12 et non avec SoapEnvelope.VER11.
J'ai eu le même problème, il a résolu après quelques vérifications:
<< Target WebService Existe mais la méthode appelée n'est pas eXXXists. >>
mon service local contient des méthodes mais un serveur cible (serveur de connexion) ne contient pas la méthode appelée spécifiée.
Vérifiez à nouveau votre scénario de programme ...
J'ai eu le même problème. Pour résoudre le problème, j'ai exécuté Wireshark et capturé la demande générée par mon code. Ensuite, j'ai utilisé XML Spy trial pour créer une demande SOAP (en supposant que vous ayez WSDL) et comparé ces deux.
Cela devrait vous donner une idée de ce qui ne va pas.
J'ai décidé de poster 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 qu'elle me conduise dans la bonne direction (oui, elle a fait l'objet d'un vote), c'était pas assez détaillé pour expliquer ce qui n'allait pas avec ma candidature, du moins dans mon cas.
J'exécute un module BPEL dans OpenESB 2.2 et le scénario de test de mon application composite échouait avec l'erreur suivante:
Caused by: System.Web.Services.Protocols.SoapException: Server did not recognize the value of HTTP Header SOAPAction: .
Après quelques recherches, j'ai constaté que le WSDL externe avait tous les indices nécessaires pour résoudre ce problème. Par exemple, j'utilise le service Web suivant pour valider un numéro de carte de crédit via une orchestration de services Web: http://www.webservicex.net/CreditCard.asmx?WSDL
Si vous cochez les éléments <wsdl:operation, vous verrez qu'il indique clairement la 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>
...
Cependant, une fois que vous avez créé l'application composite et construit le projet avec le BPEL qui appelle ce service WSDL externe, pour une raison quelconque (bug?), Le code XML de la liaison CASA (Composite Application Service Assembly) 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 scénario de test de l'application va correctement et renverra la réponse Soap attendue.
<soap:operation soapAction="http://www.webservicex.net/ValidateCardNumber" style="document"/>
C'est donc une solution plus spécifique que j'ai décidé de documenter en fonction des informations contenues dans ce billet de blog: http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction / .
Cela signifie (du moins dans mon cas) que vous accédez à un service Web avec SOAP et en transmettant un paramètre SOAPAction dans la requête HTTP cela ne correspond pas à ce que le service attend.
Nous avions renommé certains espaces de noms de projets de service Web et oublié de mettre à jour la section de configuration des gestionnaires http du site Web avec l'espace de noms des projets renommés.
J'ai eu la même erreur, j'ai pu résoudre le problème en supprimant la "référence Web" et en ajoutant une "référence de service".
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 utilise le service ci-dessus afin qu'il puisse obtenir les dernières définitions SOAP.
Ou du moins cela a fonctionné pour moi. :)
Mon erreur a été corrigée par la réponse de M. John Saunders: http://forums.asp.net/post/2906487.aspx
en bref: différence entre les espaces de noms de ws .asmx.cs avec les fichiers ws .wsdl.
1) [WebService(Namespace = "http://tempuri.org/")]
l'espace de noms de service Web ultérieur a été remplacé par:
2) [WebService(Namespace = "http://newvalue.com/")]
nous avons donc référencé (1) dans l'application et le service Web est (2) maintenant.
les rendre égaux pour résoudre votre problème.
J'ai eu cette erreur quand j'ai essayé d'appeler une méthode qui n'existait pas. Il n'existait que dans une version plus récente de notre service Web.
J'ai eu un problème similaire avec le même message d'erreur:
System.Web.Services.Protocols.SoapException: Le 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 mode DEV, tester ou vivre sans recompilation. L'URL d'un appel de service Web spécifique pour l'environnement de test était incorrect dans notre serveur de configuration. L'appel du service Web était envoyé au mauvais serveur et au mauvais service Web.
Cette erreur peut donc simplement résulter de la demande de service Web ne correspondant pas au service Web appelé.
Il a fallu que Fiddler s’exécute sur le serveur Web App pour voir que l’appel réel était dirigé vers le service Web incorrect.
le problème se trouve dans System.Web.Services.Protocols.SoapDocumentMethodAttributedans le service. S'il te plaît vérifie le. ça peut changer.
Je devais trier la capitalisation de ma référence de service, supprimer les références et les rajouter pour résoudre ce problème. Je ne sais pas si ces étapes sont superstitieuses, mais le problème a disparu.