Il server non ha riconosciuto il valore di HTTP Header 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"; } 

Il problema quando sto accedendo usando XMLHttpRequest dà il seguente errore Il server non ha riconosciuto il valore di HTTP Header SOAPAction: http: // Cyberindigo / TempWebService / InsertXML

La fonte della prossima parte di questo post è:

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

(dal momento che il PO non voleva dare l’attribuzione, e grazie a Peter)

Si noti che bakert è l’autore originale del testo, non l’OP.


Vedendo come da nessuna parte su internet posso trovare una spiegazione di questo errore ho pensato di condividere i frutti della mia lunga ricerca di questo bug.

Significa (almeno nel mio caso) che stai accedendo a un servizio web con SOAP e passando un parametro SOAPAction nella richiesta HTTP che non corrisponde a ciò che il servizio si aspetta.

Sono entrato in un pickle perché abbiamo spostato un servizio Web da un server a un altro e quindi ho modificato lo “spazio dei nomi” (non confondermi tra gli spazi dei nomi dei servizi web e .net) nel file C # chiamante per abbinare il nuovo server. Ma il server non si preoccupa della reale realtà web di http //yournamespace.com/blah, si preoccupa solo che tu invii ciò che hai detto che stai aspettando sul server. Non importa se c’è davvero qualcosa lì o no.

Quindi, in pratica, il servizio Web è stato spostato da http: //foo.com/servicename a http: //bar.com/servicename ma lo “spazio dei nomi” del servizio Web è rimasto come http: //foo.com/servicename perché nessuno cambiato.

E ci sono volute solo 4 ore per allenarsi!

Se stai riscontrando un problema simile ma non riesci a lavorare su quello che sto dicendo, non esitare a scrivermi su [email protected] – Non vorrei augurare le mie quattro ore a nessuno!

Sono d’accordo con Sam sul fatto che la definizione SOAP non corrisponde a quanto previsto. Qui è solo una soluzione che potrebbe essere, ho dovuto capire manualmente questo errore per me:

Il mio problema era che ho cambiato il nome del metodo web ma non ho modificato il “MessageName” nel tag metadata.

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

Dovrebbe essere

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

spero che aiuti qualcuno

Mentre chiami il servizio web .asmx / wcf, tieni in considerazione i seguenti punti:

  1. Lo spazio dei nomi è sensibile al maiuscolo / minuscolo, la richiesta SOAP DEVE essere inviata con lo stesso spazio dei nomi con cui viene dichiarato il WebService.

Ad es. per il WebService dichiarato come di seguito

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

La richiesta SOAP deve mantenere lo stesso caso per namespace durante la chiamata. Altrimenti trascuriamo la distinzione tra maiuscole e minuscole.

    string    
  1. Lo spazio dei nomi non deve essere uguale all’URL ospitato del servizio. Lo spazio dei nomi può essere qualsiasi stringa.

Ad esempio, il servizio di cui sopra può essere ospitato su http://84.23.9.65/MyTestService , ma mentre si sta richiamando il servizio Web dal client, lo spazio dei nomi dovrebbe essere lo stesso che la class di serice sta avendo, ad esempio http://MyDomain.com/TestService

Ho avuto lo stesso problema, riparato dopo alcuni controlli:

<< Target WebService esiste ma ha chiamato metodo non eXXXist. >>

il mio servizio locale contiene metodi ma il server di destinazione (server di connessione) non contiene il metodo chiamato specificato.

Controlla di nuovo lo scenario del tuo programma …

Solo per aiutare qualcuno su questo problema, dopo un pomeriggio di debug, il problema era che il servizio web è stato sviluppato con il framework 4.5 e la chiamata da Android deve essere eseguita con SoapEnvelope.VER12 e non con SoapEnvelope.VER11

Ho avuto un problema simile. Per eseguire il debug del problema, ho eseguito Wireshark e acquisito la richiesta generata dal mio codice. Quindi ho usato la prova XML Spy per creare una richiesta SOAP (supponendo che tu abbia WSDL) e ho confrontato questi due.

Questo dovrebbe darti un suggerimento su cosa va storto.

Ho deciso di pubblicare la mia risposta qui perché ho perso alcune ore su questo e penso che, anche se la risposta accettata è molto buona e mi ha indirizzato nella giusta direzione (sì, ha ottenuto un voto), è stato non abbastanza dettagliato per spiegare cosa c’era di sbagliato nella mia applicazione, almeno nel mio caso.

Sto eseguendo un modulo BPEL in OpenESB 2.2 e il Test Case della mia applicazione composita non funzionava con il seguente errore:

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

Dopo aver fatto alcune ricerche, ho notato che il WSDL esterno ha tutti gli indizi necessari per risolvere questo problema, ad esempio sto utilizzando il seguente servizio Web per convalidare un numero di carta di credito tramite un’orchestrazione di servizi Web: http: // http://www.webservicex.net/CreditCard.asmx?WSDL

Se controlli gli elementi vedrai che indica chiaramente soapAction per soapAction :

        ... 

Tuttavia, una volta creata l'applicazione composita e creato il progetto con BPEL che richiama questo servizio WSDL esterno, per qualche motivo (bug?), L'XML dell'associazione CASA (Composite Application Service Assembly) viene generato con un parametro soapAction vuoto:

        

Una volta copiata la corretta soapAction (http://www.webservicex.net/ValidateCardNumber) in questo parametro, il Test Case dell'applicazione restituirà correttamente la risposta Soap prevista.

  

Quindi, è una soluzione più specifica che ho deciso di documentare in base alle informazioni trovate in questo post: http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/ .

Significa (almeno nel mio caso) che stai accedendo a un servizio web con SOAP e passando un parametro SOAPAction nella richiesta HTTP che non corrisponde a ciò che il servizio si aspetta .

Ho avuto lo stesso problema dopo aver cambiato lo spazio dei nomi da “tempuri” nel mio servizio web.

È necessario aggiornare il riferimento del servizio nel progetto che sta consumando il servizio di cui sopra, in modo che possa ottenere le ultime definizioni SOAP.

O almeno ha funzionato per me. 🙂

Abbiamo rinominato alcuni spazi dei nomi del nostro servizio web e abbiamo dimenticato di aggiornare la sezione di configurazione httphandlers del sito web con lo spazio dei nomi dei progetti rinominati.

Il mio errore è stato risolto da Mr. John Saunders: http://forums.asp.net/post/2906487.aspx

in breve: differenza tra Namespace di ws .asmx.cs con i file ws .wsdl .

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

lo spazio dei nomi del servizio Web successivo è stato modificato in:

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

quindi abbiamo fatto riferimento (1) all’applicazione e il servizio web è (2) ora.

rendili uguali per risolvere il tuo problema.

Ho avuto lo stesso errore, sono stato in grado di risolverlo rimuovendo il “Web Reference” e aggiungendo un “Service Reference”

Ho dovuto risolvere le lettere maiuscole del mio riferimento al servizio, eliminare i riferimenti e aggiungerli per risolvere il problema. Non sono sicuro che qualcuno di questi passaggi sia superstizioso, ma il problema è andato via.

Ho avuto un problema simile con lo stesso messaggio di errore:

System.Web.Services.Protocols.SoapException: server non ha riconosciuto il valore di HTTP Header SOAPAction :

Utilizziamo URL dinamici nelle nostre chiamate al servizio web. Abbiamo un server di configurazione centrale che gestisce la posizione di tutte le chiamate al servizio web in modo che il nostro codice possa essere eseguito in DEV, test o live senza ricompilazione. L’URL per una chiamata al servizio web specifico per l’ambiente di test era errato nel nostro server di configurazione. La chiamata al servizio web è stata inviata al server sbagliato e al servizio web sbagliato.

Quindi questo errore può essere semplicemente il risultato della richiesta del servizio web che non corrisponde al servizio web che viene chiamato.

È stato necessario eseguire il violinista sul server Web App per verificare che la chiamata effettiva fosse al servizio Web errato.

il problema è nel System.Web.Services.Protocols.SoapDocumentMethodAttribute nel servizio. Per favore controllalo. potrebbe essere cambiato.

Ho ricevuto questo errore quando ho provato a chiamare un metodo che non esisteva. Esisteva solo in una versione più recente del nostro servizio web.