Подтвердить что ты не робот

Сервер не распознал значение 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

4b9b3361

Ответ 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>
  1. Пространство имен не должно быть таким же, как и размещенный 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

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