Сервер не распознал значение HTTP-заголовка SOAPAction

Question

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

Проблема, когда я обращаюсь к нему с помощью XMLHttpRequest, он выдает следующую ошибку Сервер не распознал значение HTTP-заголовка SOAPAction: http://Cyberindigo/TempWebService/InsertXML

Answer 1

Источник следующей части этого поста:

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

(поскольку ОП не хотел давать атрибуцию, и спасибо Питеру)

Обратите внимание, что автором текста является Бакерт, а не ОП.

---

Поскольку нигде в Интернете я не могу найти объяснение этой ошибки, я подумал, что поделюсь плодами моего долгого поиска этой ошибки.

Это означает (по крайней мере, в моем случае), что вы обращаетесь к веб-службе с помощью SOAP и передаете в запросе HTTP параметр SOAPAction, который не соответствует ожидаемому сервису.

Я попал в точку, потому что мы переместили веб-сервис с одного сервера на другой, и поэтому я изменил «пространство имен» (не путайте между пространствами имен веб-служб и пространствами имен .net) в вызывающем файле C #, чтобы соответствовать новый сервер. Но сервер не заботится о реальной веб-реальности http //yournamespace.com/blah, он лишь заботится о том, чтобы вы отправили ему то, что, как вы сказали, ожидали на сервере. Неважно, есть там что-нибудь или нет.

Таким образом, в основном веб-служба была перемещена с http: //foo.com/servicename на http: //bar.com/servicename, но «пространство имен» веб-службы осталось как http: //foo.com/servicename. потому что никто не изменил его.

И это заняло всего около 4 часов!

Если у вас возникла похожая проблема, но вы не можете сработать, как я здесь говорю, не стесняйтесь, напишите мне на bakert+web@gmail.com - я бы не хотел, чтобы мои четыре часа кому-то понадобились!

Answer 2

Я согласен с Сэмом в том, что определение SOAP не соответствует ожидаемому. Вот только ОДИН вариант решения, которое мне нужно было, мне пришлось вручную вычислить эту ошибку:

Моя проблема заключалась в том, что я изменил имя веб-метода, но не изменил «MessageName» в теге метаданных.

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

}

Это должно быть

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

}

надеюсь, что это помогает кому-то

Answer 3

При звонке на веб-службу .asmx / wcf соблюдайте следующие пункты:

1. Пространство имен чувствительно к регистру, запрос SOAP ДОЛЖЕН быть отправлен с тем же пространством имен, с которым объявлен WebService.

например. Для WebService, объявленного как ниже

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

      ...... 
     }

 }

Запрос SOAP должен поддерживать тот же регистр для пространства имен при вызове. Иногда мы пропускаем чувствительность к регистру.

<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. Пространство имен не обязательно должно совпадать с размещенным URL-адресом службы. Пространство имен может быть любой строкой.

например. Вышеуказанная служба может быть размещена на http://84.23.9.65/MyTestService, но при вызове веб-службы из клиента пространство имен должно быть таким же, как у класса serice, т.е.

Answer 4

Просто чтобы помочь кому-то в этой проблеме, после полудня отладки проблема заключалась в том, что веб-сервис был разработан с платформой 4.5, и вызов с Android должен быть сделан с SoapEnvelope.VER12, а не с SoapEnvelope.VER11

Answer 5

У меня была такая же проблема, она исправлена ​​после некоторой проверки:

<< Target WebService Существует, но вызванный метод не является eXXXists. >>

мой локальный сервис содержит методы, но целевой сервер (подключающийся сервер) не содержит указанный вызываемый метод.

Проверьте ваш программный сценарий снова ...

Answer 6

Я решил опубликовать свой собственный ответ здесь, потому что я потерял несколько часов на это, и я думаю, что, хотя принятый ответ очень хорош и направил меня в правильном направлении (да, он получил голосование) , это не было достаточно подробно, чтобы объяснить, что случилось с моим заявлением, по крайней мере, в моем случае.

Я использую модуль BPEL в OpenESB 2.2, и тестовый пример моего составного приложения не удался со следующей ошибкой:

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

Проведя некоторое исследование, я заметил, что внешний WSDL имеет все подсказки, необходимые для решения этой проблемы, например, я использую следующий веб-сервис для проверки номера кредитной карты с помощью оркестровки веб-сервисов: http://www.webservicex.net/CreditCard.asmx?WSDL

Если вы проверите элементы <wsdl:operation, вы увидите, что в них четко указано soapAction для этой операции:

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

Но, как только вы создадите составное приложение и создадите проект с BPEL, который вызывает эту внешнюю службу WSDL, по какой-то причине (ошибка?) XML-код привязки сборки службы приложений (CASA) создается с пустым soapAction параметр:

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

После того, как вы скопируете правильный soapAction (http://www.webservicex.net/ValidateCardNumber) в этот параметр), тестовый пример приложения будет корректно возвращать ожидаемый ответ Soap.

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

Итак, это более конкретное решение, которое я решил задокументировать на основе информации, найденной в этом сообщении: http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/.

Это означает (по крайней мере, в моем случае), что вы обращаетесь к веб-сервису с SOAP и , передавая параметр SOAPAction в HTTP-запросе это не соответствует ожидаемому сервису .

Answer 7

У меня была похожая проблема. Чтобы устранить проблему, я запустил Wireshark и перехватил запрос, сгенерированный моим кодом. Затем я использовал XML Spy trial для создания SOAP-запроса (при условии, что у вас WSDL) и сравнил эти два.

Это должно дать вам подсказку, что идет не так.

Answer 8

У меня была такая же проблема, но решение для меня заключалось в том, что я указывал на неправильный веб-сервис. Я правильно обновил веб-ссылку. Но мы храним URl для сервиса в зашифрованном файле, и я не обновил файл с правильным зашифрованным сервисом.

Но все эти предложения действительно помогли мне понять, куда идти для отладки.

Спасибо!

Answer 9

У меня была такая же ошибка, я смог ее устранить, удалив «Web Reference» и добавив вместо «Service Reference»

Answer 10

Моя ошибка исправлена ​​ответом г-н Джон Сондерс: http://forums.asp.net/post/2906487.aspx

короче: разница между пространством имен ws .asmx.cs с ws .wsdl файлов.

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

позднее пространство имен веб-службы изменено на:

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

поэтому мы указали (1) в приложении, а веб-сервис теперь (2).

сделайте их равными, чтобы решить вашу проблему.