it-swarm.com.de

Der Server hat den Wert von HTTP-Header-SOAPAction nicht erkannt

   [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";
    }

Das Problem, wenn ich mit XMLHttpRequest darauf zugreife, gibt den folgenden Fehler aus: __ Server hat den Wert von HTTP-Header-SOAPAction nicht erkannt: http: // Cyberindigo/TempWebService/InsertXML

39
user42070

Die Quelle des nächsten Teils dieses Beitrags ist: 

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

(da das OP keine Zuschreibung geben wollte, und danke an Peter)

Bitte beachten Sie, dass bakert der ursprüngliche Autor des Textes ist, nicht das OP.


Da ich nirgendwo im Internet sehe, kann ich eine Erklärung für diesen Fehler finden. Ich dachte, ich würde die Früchte meiner langen Suche nach diesem Fehler teilen.

Dies bedeutet (zumindest in meinem Fall), dass Sie mit SOAP auf einen Webdienst zugreifen und in der HTTP-Anforderung einen SOAPAction-Parameter übergeben, der nicht den Erwartungen des Dienstes entspricht.

Ich befand mich in einem Pickle, weil wir einen Webdienst von einem Server auf einen anderen verschoben haben. Daher habe ich den "Namespace" (nicht zwischen Web-Service-Namespaces und .net-Namespaces verwirrt) in der aufrufenden C # -Datei an den neuen Server angepasst. Der Server kümmert sich jedoch nicht um die Webrealität von http // yourourpaces.com/blah. Es ist nur wichtig, dass Sie ihm das senden, was Sie auf dem Server erwartet haben. Es ist egal, ob es tatsächlich etwas gibt oder nicht.

Im Grunde wurde der Web-Service von http: //foo.com/servicename nach http: //bar.com/servicename verschoben, aber der "Namespace" des Web-Service blieb unter http: //foo.com/servicename, weil keiner änderte es.

Und das hat nur etwa 4 Stunden gedauert!

Wenn Sie ein ähnliches Problem haben, aber das, was ich hier sage, nicht funktionieren kann, senden Sie mir bitte eine E-Mail an [email protected] Ich wünsche meinen vier Stunden für niemanden!

62
user255762

Ich stimme mit Sam darin überein, dass die SOAP -Definition nicht den Erwartungen entspricht. Hier ist nur eine Lösung, ich könnte diesen Fehler manuell für mich selbst ermitteln:

Mein Problem war, dass ich den Namen der Webmethode geändert habe, aber "MessageName" im Metadaten-Tag nicht geändert habe.

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

}

Es sollte sein

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

}

hoffe das hilft jemandem

6
Ben

Bitte beachten Sie beim Aufruf des .asmx/wcf-Webservice die folgenden Punkte:

  1. Der Namespace unterscheidet zwischen Groß- und Kleinschreibung, die Anforderung SOAP MUSS mit demselben Namespace gesendet werden, mit dem der WebService deklariert wird. 

z.B. Für den WebService wie unten angegeben

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

      ...... 
     }

 }

Die SOAP - Anforderung muss beim Aufruf den gleichen Fall für den Namespace beibehalten. Manchmal wird die Groß- und Kleinschreibung ignoriert.

<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. Der Namespace muss nicht mit der gehosteten URL des Diensts identisch sein. Der Namespace kann eine beliebige Zeichenfolge sein.

z.B. Der obige Dienst kann auf http://84.23.9.65/MyTestService gehostet werden, der Namespace sollte jedoch beim Aufrufen des Web Service vom Client mit dem der serice-Klasse identisch sein, z. B. http: // MyDomain. de/TestService

5

Um jemandem bei diesem Problem zu helfen, bestand das Problem nach einem Nachmittag des Debugging darin, dass der Webservice mit Framework 4.5 entwickelt wurde und der Aufruf von Android mit SoapEnvelope.VER12 und nicht mit SoapEnvelope.VER11 erfolgen muss

3
Flavio Bianchi

Ich hatte dasselbe Problem, das nach einiger Überprüfung behoben wurde:

<< Ziel WebService Existiert, aber die aufgerufene Methode ist nicht eXXXists. >>

mein lokaler Dienst enthält Methoden, aber Zielserver (Verbindungsserver) enthält keine angegebene aufgerufene Methode.

Überprüfe dein Programmszenario erneut ...

3
Zolfaghari

Ich hatte ein ähnliches Problem. Um das Problem zu debuggen, habe ich Wireshark ausgeführt und eine von meinem Code erzeugte Capture-Anforderung. Dann habe ich XML ​​Spy trial verwendet, um eine SOAP - Anforderung zu erstellen (vorausgesetzt, Sie haben WSDL) und diese beiden verglichen.

Dies sollte Ihnen einen Hinweis geben, was schief geht.

2
ya23

Ich habe mich entschlossen, meine eigene Antwort hier zu posten, da ich ein paar Stunden verloren habe, und ich denke, obwohl die akzeptierte Antwort sehr gut ist und mich in die richtige Richtung weist (ja, es hat eine Abstimmung erhalten), war es nicht detailliert genug, um zu erklären, was bei meiner Bewerbung falsch war, zumindest in meinem Fall.

Ich führe ein BPEL-Modul in OpenESB 2.2 aus und der Testfall meiner Verbundanwendung schlug mit dem folgenden Fehler fehl:

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

Nach einigen Nachforschungen ist mir aufgefallen, dass die externe WSDL alle Hinweise enthält, die zur Behebung dieses Problems erforderlich sind. Beispielsweise verwende ich den folgenden Webdienst, um eine Kreditkartennummer durch eine Orchestrierung der Webdienste zu überprüfen: http://www.webservicex.net/CreditCard.asmx?WSDL

Wenn Sie die <wsdl:operation-Elemente überprüfen, werden Sie feststellen, dass die soapAction für diese Operation eindeutig angegeben ist:

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

Wenn Sie jedoch die Verbundanwendung erstellt und das Projekt mit der BPEL erstellt haben, die diesen externen WSDL-Dienst aufruft, wird aus irgendeinem Grund (Fehler?) Der XML-Code der CASA-Bindung (Composite Application Service Assembly) mit einem leeren soapAction-Parameter generiert:

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

Nachdem Sie die richtige soapAction (http://www.webservicex.net/ValidateCardNumber) in diesen Parameter kopiert haben, wird der Testfall der Anwendung korrekt angezeigt und die erwartete Soap-Antwort zurückgegeben.

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

Es handelt sich also um eine spezifischere Lösung, die ich basierend auf den Informationen in diesem Blogbeitrag dokumentieren möchte: http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/ .

Dies bedeutet (zumindest in meinem Fall), dass Sie auf einen Webdienst zugreifen mit SOAP und übergeben einen SOAPAction-Parameter in der HTTP-Anforderung das stimmt nicht mit dem überein, was der Dienst erwartet.

2
theMarceloR

Wir hatten einige unserer Web-Service-Projekt-Namespaces umbenannt und vergessen, den Konfigurationsabschnitt der Website-HTTP-Handler mit dem Namespace der umbenannten Projekte zu aktualisieren.

Ich hatte das gleiche Problem, aber die Lösung für mich war, dass ich auf den falschen Webdienst zeigte. Ich hatte die Webreferenz korrekt aktualisiert. Wir speichern die URL für den Dienst jedoch in einer verschlüsselten Datei, und ich habe die Datei nicht mit dem richtigen verschlüsselten Dienst aktualisiert.

Aber all diese Vorschläge haben mir wirklich geholfen, zu erkennen, wohin ich beim Debuggen gehen soll.

Vielen Dank!

1
Sue

Ich hatte den gleichen Fehler. Ich konnte ihn beheben, indem ich stattdessen die "Webreferenz" entfernte und stattdessen eine "Servicereferenz" hinzufügte

1
Manikandan

Ich hatte das gleiche Problem, nachdem ich den Namespace von "tempuri" in meinem Web Service geändert hatte.

Sie müssen Ihre Servicereferenz in dem Projekt aktualisieren, das den obigen Service verwendet, damit die neuesten SOAP - Definitionen abgerufen werden können.

Oder zumindest hat das für mich funktioniert. :)

1
Ken

Mein Fehler wurde durch die Antwort von Herrn John Saunders behoben: http://forums.asp.net/post/2906487.aspx

kurz gesagt: Unterschied zwischen dem Namespace von ws .asmx.cs mit den Dateien ws .wsdl.

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

später wurde der Web-Service-Namespace geändert in:

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

so haben wir (1) in Anwendung und Web-Service (2) jetzt verwiesen.

machen Sie sie gleich, um Ihr Problem zu beheben.

1
Zolfaghari

Ich habe diesen Fehler erhalten, als ich versuchte, eine Methode aufzurufen, die nicht existierte. Sie gab es nur in einer neueren Version unseres Webservice.

0
Cosmin

Ich hatte ein ähnliches Problem mit der gleichen Fehlermeldung:

System.Web.Services.Protocols.SoapException: Der Server hat den Wert des HTTP-Headers nicht erkannt. SOAPAction:

Wir verwenden dynamische URLs in unseren Webservice-Aufrufen. Wir verfügen über einen zentralen Konfigurationsserver, der den Ort aller Webdienstaufrufe verwaltet, sodass unser Code in DEV ausgeführt, getestet oder live ausgeführt werden kann, ohne dass er neu kompiliert werden muss. Die URL für einen bestimmten Webdienstaufruf für die Testumgebung war in unserem Konfigurationsserver falsch. Der Webdienstaufruf wurde an den falschen Server und den falschen Webdienst gesendet. 

Dieser Fehler kann also einfach darauf zurückzuführen sein, dass die Webdienstanforderung nicht mit dem aufgerufenen Webdienst übereinstimmt. 

Es musste ein Fiddler auf dem Web App-Server ausgeführt werden, um zu sehen, dass der tatsächliche Aufruf des falschen Webdiensts erfolgte.

0
Graeme Black

das Problem befindet sich im System.Web.Services.Protocols.SoapDocumentMethodAttribute im Dienst. Überprüfen Sie bitte das. es kann sich ändern.

0
Balamurugan

Ich musste die Großschreibung meiner Servicereferenz ermitteln, die Referenzen löschen und sie erneut hinzufügen, um das Problem zu beheben. Ich bin nicht sicher, ob einer dieser Schritte abergläubisch ist, aber das Problem ist verschwunden.

0
gaijintendo