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

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

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

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

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

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

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

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

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

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

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

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

Если у вас возникла аналогичная проблема, но вы не можете понять, о чем я говорю, напишите мне на [email protected] - я бы ни на кого не потратил свои четыре часа!

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

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

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

}

Должен быть

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

}

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

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

При вызове веб-службы .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, но все же при вызове веб-службы из клиента пространство имен должно быть таким же, которое имеет класс обслуживания, то есть http://MyDomain.com/TestService

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

Я запускаю модуль 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/.

It means (at least in my case) that you are accessing a web service with SOAP and passing a SOAPAction parameter in the HTTP request that does not match what the service is expecting.

У меня была такая же проблема после изменения пространства имен с «tempuri» в моем веб-сервисе.

Вам необходимо обновить ссылку на службу в проекте, который использует указанную выше службу, чтобы он мог получать последние определения SOAP.

По крайней мере, у меня это сработало. :)

Мы переименовали некоторые пространства имен наших проектов веб-сервисов и забыли обновить раздел конфигурации httphandlers веб-сайта пространством имен переименованных проектов.

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

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

my local service contain methods but target server(connecting server) does not contain specified called method.

Еще раз проверьте сценарий своей программы ...

У меня была аналогичная проблема с тем же сообщением об ошибке:

Сервер System.Web.Services.Protocols.SoapException: не распознал значение HTTP-заголовка SOAPAction:

Мы используем динамические URL-адреса в вызовах наших веб-сервисов. У нас есть центральный сервер конфигурации, который управляет местоположением всех вызовов веб-сервисов, чтобы наш код мог работать в DEV, тестировать или работать без перекомпиляции. URL-адрес для конкретного вызова веб-службы для тестовой среды был неправильным на нашем сервере конфигурации. Вызов веб-службы отправлялся не на тот сервер и не на ту веб-службу.

Таким образом, эта ошибка может быть просто результатом того, что запрос веб-службы не соответствует вызываемой веб-службе.

Потребовалось запустить скрипач на сервере веб-приложений, чтобы увидеть, что на самом деле был обращен вызов неправильной веб-службе.

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

Моя ошибка исправлена ​​ответом г-на Джона Сондерса: 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).

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

проблема в System.Web.Services.Protocols.SoapDocumentMethodAttribute в сервисе. Пожалуйста, проверь это. это может измениться.

У меня была такая же ошибка, я смог решить ее, удалив «Веб-ссылку» и добавив вместо нее «Ссылку на службу».

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

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

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

Спасибо!

Я обнаружил, что моя веб-ссылка устарела, и код вызывает удаленную веб-службу.