Le serveur ne reconnaît pas la valeur de l'en-Tête HTTP SOAPAction

La source de la prochaine partie de ce post est:

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

(depuis l'OP ne voulais pas donner l'attribution, et merci à Peter)

Veuillez noter que bakert est l'auteur original du texte, pas de l'OP.

---

De voir que nulle part sur internet puis-je trouver une explication à cette erreur, je pensais que je voudrais partager le fruit de ma longue recherche de ce bug.

Cela signifie (au moins dans mon cas) que vous accédez à un service web avec du SAVON et de passer un SOAPAction paramètre de la requête HTTP qui ne correspond pas à ce que le service attendu.

Je suis dans le pétrin parce que nous nous sommes déplacés d'un service web à partir d'un serveur à un autre et donc j'ai changé le “namespace” (ne pas confondre entre services web les espaces de noms et .net les espaces de noms) dans l'appel de fichier C# afin de correspondre au nouveau serveur. Mais le serveur n'a pas de soins à propos de la réalité web de http://yournamespace.com/blah il ne se soucie que vous envoyer ce que vous avez dit vous attendons sur le serveur. Il ne se soucie pas si il y a réellement de quoi que ce soit là ou pas.

Donc, fondamentalement, le service web a été déplacé de http://foo.com/servicename à http://bar.com/servicename mais le “namespace” du service web est resté comme http://foo.com/servicename parce que personne ne l'a changé.

Et qui a seulement pris environ 4 heures de travail!

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 [email protected] – je ne voudrais pas que mon quatre heures sur n'importe qui!

Tout en appelant la .asmx /service web wcf veuillez prendre soin de points ci-dessous:

1. L'espace de noms est sensible à la casse,le SAVON de demande DOIT être envoyé avec le même espace de noms avec lesquels le WebService est déclarée.

par exemple Pour le WebService 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 requête SOAP doit maintenir le même cas pour l'espace de noms lors d'un appel.Parfois, nous perdons de vue le cas de la sensibilité.

<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>

1. L'espace de noms n'a pas besoin d'être la même qu'en hébergé url du service.L'espace de noms peut être n'importe quelle chaîne.

par exemple, de service ci-Dessus peuvent être hébergés à http://84.23.9.65/MyTestService , mais toujours tout en appelant le Service Web à partir d'un client de l'espace de noms doit être la même que l'prolongée classe est d'avoir c'est à direhttp://MyDomain.com/TestService

Juste pour aider quelqu'un sur ce problème, après un après-midi de débogage, le problème est que le service web a été développé avec le framework 4.5 et l'appel à partir d'android doit être fait avec SoapEnvelope.VER12 et pas avec SoapEnvelope.VER11

J'ai décidé de poster ma question ici parce que j'ai perdu quelques heures, et je pense que, bien que l'on a accepté la réponse est très bon et m'a orienté dans la bonne direction (oui, elle a un voteup), il n'était pas assez détaillée pour expliquer ce qui n'allait pas avec ma demande, au moins dans mon cas.

Je suis à court d'un BPEL module dans OpenESB 2.2 et les 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 fait quelques recherches j'ai remarqué que les externes WSDL a tous les indices que nous avons besoin pour résoudre ce problème, par exemple, je suis en utilisant le service web suivant pour valider un numéro de carte de crédit à travers une orchestration de Services Web:
http://www.webservicex.net/CreditCard.asmx?WSDL

Si vous cochez la <wsdl:operation éléments, vous verrez qu'il énonce 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>
...

Mais, une fois que vous créez l'Application Composite et de construire le projet avec le BPEL qui appelle cette externe WSDL du service, pour quelque raison (bug?), le XML de l'Application Composite Assemblée de Service (CASA) de liaison est généré avec un vide soapAction paramètre:

<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 avez copier le soapAction (http://www.webservicex.net/ValidateCardNumber) dans ce paramètre, l'application du scénario de Test correctement et le retour attendu de la réponse Soap.

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

Donc, c'est une solution que j'ai décidé de document basé sur l'information contenue dans ce blog: 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 du SAVON et de l' le passage d'un SOAPAction paramètre de la requête HTTP
qui ne correspond pas à ce que le service s'attend à.

Nous avait renommé certains de nos webservice projet les espaces de noms et j'ai oublié de mettre à jour le site web httphandlers section de configuration avec l'espace de noms de la renommée des projets.

J'ai eu la même erreur, j'ai été en mesure de résoudre le problème en supprimant le "Web de Référence" et l'ajout d'un "Service de Référence" au lieu

J'ai dû trier sur la capitalisation de mon service de référence, de supprimer les références et re les ajouter à résoudre ce problème. Je ne suis pas sûr si l'un de ces étapes sont superstitieux, mais le problème a disparu.

le problème est dans le Système.Web.Services.Les protocoles.SoapDocumentMethodAttribute
dans le service. S'il vous plaît vérifier. il peut changé.