Сервер не распознал значение HTTP-заголовка 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";
}
Проблема, когда я обращаюсь к нему с помощью XMLHttpRequest, дает следующую ошибку
Сервер не распознал значение HTTP-заголовка SOAPAction: http://Cyberindigo/TempWebService/InsertXML
Ответы
Ответ 1
Источник следующей части этого поста:
http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/
(так как ОП не хотел давать атрибуцию и спасибо Питеру)
Обратите внимание, что Бакерт является первоначальным автором текста, а не ОП.
Поскольку нигде в Интернете я не могу найти объяснение этой ошибки, я думал, что поделюсь плодами моего долгого поиска этой ошибки.
Это означает (по крайней мере, в моем случае), что вы обращаетесь к веб-службе с помощью SOAP и передаете в запросе HTTP параметр SOAPAction
, который не соответствует ожидаемому сервису.
Я попал в тупик, потому что мы переместили веб-сервис с одного сервера на другой, и поэтому я изменил "пространство имен" (не путайте между пространствами имен веб-служб и пространствами имен .net) в вызывающем файле С#, чтобы соответствовать новому серверу. Но сервер не заботится о реальной веб-реальности http://yournamespace.com/blah
он заботится только о том, чтобы вы отправили ему то, что, как вы сказали, ожидали на сервере. Это не волнует, если там на самом деле что-нибудь там или нет.
Таким образом, в основном веб-служба была перемещена с http://foo.com/servicename
на http://bar.com/servicename
но "пространство имен" веб-службы осталось как http://foo.com/servicename
потому что никто изменил это.
И это заняло около 4 часов!
Если у вас возникла подобная проблема, но вы не можете сработать, о чем я здесь говорю, не стесняйтесь, напишите мне на [email protected] - я бы не пожелал, чтобы мои четыре часа кому-либо!
Ответ 2
Я согласен с Сэмом в том, что определение SOAP не соответствует ожидаемому. Вот только одно решение, которое может быть, мне пришлось вручную определить эту ошибку для себя:
Моя проблема заключалась в том, что я изменил имя веб-метода, но не изменил "MessageName" в теге метаданных.
[WebMethod(MessageName = "foo")]
public string bar()
{
}
Это должно быть
[WebMethod(MessageName = "foo")]
public string foo()
{
}
надеюсь, что кто-то поможет
Ответ 3
При вызове веб-службы .asmx/wcf, пожалуйста, позаботьтесь о нижеследующих пунктах:
- Пространство имен чувствительно к регистру, запрос 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>
- Пространство имен не должно быть таким же, как и размещенный URL-адрес службы. Пространство имен может быть любой строкой.
например. Вышеуказанная служба может размещаться на http://84.23.9.65/MyTestService, но при вызове веб-службы от клиента пространство имен должно быть таким же, что и класс serice т.е. http://MyDomain.com/TestService
Ответ 4
У меня была такая же проблема, она исправлена после некоторой проверки:
< < Target WebService Существует, но называется метод не eXXXists. →
моя локальная служба содержит методы, но целевой сервер (подключаемый сервер) не содержит указанный вызываемый метод.
Снова проверьте сценарий вашей программы...
Ответ 5
Просто, чтобы помочь кому-то по этой проблеме, после обеда отладки проблема заключалась в том, что веб-сервис был разработан с фреймворком 4.5, а вызов от android должен выполняться с помощью SoapEnvelope.VER12, а не с SoapEnvelope.VER11
Ответ 6
У меня была аналогичная проблема. Чтобы отладить проблему, я запустил Wireshark и запрос на захват, сгенерированный моим кодом. Затем я использовал пробник XML Spy для создания запроса SOAP (при условии, что у вас есть WSDL) и сравнил эти два.
Это должно дать вам подсказку, что не так.
Ответ 7
Я решил опубликовать свой собственный ответ здесь, потому что я потерял несколько часов на этом, и я думаю, что, хотя принятый ответ очень хорош и указал мне в правильном направлении (да, он получил голосование), он не был достаточно подробным, чтобы объяснить, что было не так с моим приложением, по крайней мере, в моем случае.
Я запускаю модуль 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:operation soapAction="http://www.webservicex.net/ValidateCardNumber" style="document"/>
Итак, это более конкретное решение, которое я решил записать на основе информации, найденной в этом сообщении в блоге: http://bluebones.net/2003/07/server-did-not-recognize-http-header-soapaction/.
Это означает (по крайней мере, в моем случае), что вы обращаетесь к веб-службе с SOAP и передают параметр SOAPAction в HTTP-запросе что не соответствует ожидаемой услуге.
Ответ 8
У меня была такая же проблема после изменения пространства имен из "tempuri" в моей веб-службе.
Вы должны обновить свою ссылку на службу в проекте, который использует вышеупомянутую услугу, чтобы он мог получить последние определения SOAP.
Или, по крайней мере, это сработало для меня.:)
Ответ 9
Мы переименовали некоторые из наших пространств имен проектов webservice и забыли обновить раздел конфигурации httphandlers сайта с пространством имен переименованных проектов.
Ответ 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).
сделать их равными, чтобы исправить вашу проблему.
Ответ 11
У меня была такая же ошибка, я смог ее устранить, удалив "Web Reference" и добавив вместо нее "Service Reference"
Ответ 12
У меня была такая же проблема, но решение для меня заключалось в том, что я указывал на неправильный веб-сервис. Я правильно обновил веб-ссылку. Но мы храним URl для сервиса в зашифрованном файле, и я не обновил файл с правильным зашифрованным сервисом.
Но все эти предложения действительно помогли мне понять, куда идти для отладки.
Спасибо!
Ответ 13
Мне пришлось сортировать капитализацию ссылки на службу, удалять ссылки и добавлять их, чтобы исправить это. Я не уверен, что любой из этих шагов суеверен, но проблема исчезла.
Ответ 14
У меня была аналогичная проблема с тем же сообщением об ошибке:
System.Web.Services.Protocols.SoapException:
Сервер не распознал значение заголовка HTTP SOAPAction
:
Мы используем динамический URL-адрес в наших вызовах веб-службы. У нас есть центральный сервер конфигурации, который управляет местоположением всех вызовов веб-сервисов, чтобы наш код мог работать в DEV, тестировать или жить без перекомпиляции. URL-адрес для определенного вызова веб-службы для тестовой среды был неверным на нашем сервере конфигурации. Вызов веб-службы отправлялся на неправильный сервер и неправильный веб-сервис.
Таким образом, эта ошибка может быть просто результатом запроса веб-службы, не соответствующего вызываемому веб-сервису.
Для веб-сервера приложений потребовалось запустить скрипт, чтобы убедиться, что фактический вызов был вызван неправильной веб-службой.
Ответ 15
проблема заключается в System.Web.Services.Protocols.SoapDocumentMethodAttribute
в службе. Пожалуйста, проверь это. он может измениться.
Ответ 16
Я получил эту ошибку, когда попытался вызвать метод, которого не было. Он существовал только в более новой версии нашего веб-сервиса.