Server did not recognize the value of HTTP Header SOAPAction

Seeing as nowhere on the internet can I find an explanation of this error I thought I’d share the fruits of my long search for this bug.

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.

I got in a pickle because we moved a web service from one server to another and thus I changed the “namespace” (don’t get confused between web service namespaces and .net namespaces) in the calling C# file to match the new server. But the server doesn’t care about the actual web reality of http://yournamespace.com/blah it only cares that you send it what you have said you are expecting on the server. It doesn’t care if there’s actually anything there or not.

So basically the web service was moved from http://foo.com/servicename to http://bar.com/servicename but the “namespace” of the web service stayed as http://foo.com/servicename because no one changed it.

And that only took about 4 hours to work out!

If you’re having a similar problem but can’t work what I’m saying here, feel free to mail me on bakert+web@gmail.com – I wouldn’t wish my four hours on anyone!

74 Replies to “Server did not recognize the value of HTTP Header SOAPAction”

  1. Thanks!!This solve my problem!! But now I’m facing another problem is that error messages says, “Microsoft.Web.Services.Security.SecurityFault: The security token could not be authenticated or authorized”.
    Server Web Service managed to enter the GetPassword function, but after this function, client application receive the error message as above when trying to call the WebService method. Any idea?

  2. What about if a service works fine when I set WSDLLocation property of THTTPRIO, but when I set the URL property it gives me the error you were getting (Server did not recognize the value of HTTP Header SOAPAction) ?

  3. Thanks, that gives me a clue to where the problem is, but when I check the SOAPAction properties its value is Null, any ideas where you set this property ?

  4. hi

    seeing this helped me !

    i had exactly the same pb and heres some additional inputs… what files to change 🙂

    you have to manually edit the .disco and .wsdl file to have the new namespace – “bar.com/servicename

  5. I had same issue. My problem is that the targetNameSpace running in webServer was different to the targetNameSpace used by client. The wsdl was compiled from a local copy.

  6. well, i have this problem after adding two new methods :/ – no problem with calling the old method, but the two new method would return this exception. does anybody know what to do with it? :/

  7. The meaning of this error is that the String in the client for the URI does not match the String in the server for the URI. That’s all there is to it. Actual URIs are not relevant.

    So possibly you moved the service but left the old Strings in there, however on your new code you used the new URI and this is incorrect – you must match what is in the server code NOT the real URI (although these can be the same).

  8. Thanks man!

    NOTE: namespaces are CaSE SenSitive!

    I “fixed” an accidental upper-case char in the namespace and broke the app!

  9. One more try at explaining this in different words …

    The problem I had was that I thought the strings in the code had to
    match reality. So when I moved it from

    http://example.com/foo/

    to

    http://example.org/bar/

    I changed the string (in square brackets above the method
    declaration?) in my client code.

    This was a mistake. All the webserver cares about is that the string
    in the client code matches the string in the server code. It doesn’t
    matter what the string is.

    So either change both, or neither. As long as they are the same, it works.

  10. Still getting mail abou this one so here’s some more notes:

    The problem I was having was that the strings (above the method
    declarations in square brackets) on the server did not match the
    strings on the client. So I changed them to be the same. They do not
    need to reflect the “real” URL, they just need to be the same on
    server and client.

    Just check your NAME for the service (in source code) is the SAME on
    both the client and the server, CASE SENSITIVE. The whole URL must be
    the same.

  11. Hi,

    I am trying to use sharepoint webservices in my asp.net app. I added the services as web refernce and then called a supported method but I get the error “Server did not recognize the value of HTTP Header SOAPAction”.

    Reading thru these posts, I am still lost where to to fix it.

    Please Help. Thanks.

  12. I just solved a similar problem that came about because the web.config file had been changed to point to the production server for this web service upon deployment, and I’m adding a stored procedure to the development environment (localhost) as part of a modification…try to run the app, and it blows up when I hit the service because it certainly doesn’t think that that stored procedure exists. All I had to do was modify the web.config to point to local host, and it’s all good. Of course, don’t then deploy the web.config while it still points at localhost as the web service

  13. I face this problem

    Server did not recognize the value of HTTP Header SOAPAction

    when I was trying to connect to a web service deplyed in IIS ASP.NET 2.0

    The problem was the attributes of the methods of client proxy and web service was different

    for example:
    //original web service method
    [WebMethod]
    public string example(short m)

    //client proxy method
    [System.Web.Services.Protocols.SoapRpcMethodAttribute(“http://yourwebsite/”, RequestNamespace=”http://yourwebsite/”, ResponseNamespace=”http://yourwebsite/”)]
    [return: System.Xml.Serialization.SoapElementAttribute(“Result”)]
    public string example(short m)

    Me.thank(you);

  14. I face the error~!

    #!/usr/bin/perl -w
    # a sample web service client.
    use strict;
    use SOAP::Lite;

    #my $soap = SOAP::Lite->uri(‘http://www.soaplite.com/Demo’)
    # -> proxy(‘http://services.soaplite.com/hibye.cgi’);
    my $soap = SOAP::Lite->uri(‘http://tempuri.org/’)
    -> proxy(‘http://localhost/WSSecurityRef/WSFeSecurityInfo.ASMX’);
    my $result = $soap->Hello();
    unless ($result->fault) {
    print $result->result();
    }
    else {
    print ‘Error:’;
    print join ‘, ‘,
    $result->faultcode,
    $result->faultstring,
    $result->faultdetail;
    }

    Error:soap:Client, System.Web.Services.Protocols.SoapException: Server did not recognize the value of HTTP Header SOAPAction: http://tempuri.org/#Hello.
    at System.Web.Services.Protocols.Soap11ServerProtocolHelper.RouteRequest()
    at System.Web.Services.Protocols.SoapServerProtocol.Initialize()
    at System.Web.Services.Protocols.ServerProtocolFactory.Create(Type type, HttpContext context, HttpRequest request, HttpResponse response, Boolean& abortProcessing),

  15. Thanks for the direction. Once I realized this was the problem, I did a search in our version control system’s history and discovered that another developer inadvertently changed the capitalization of the namespaces recently. This problem had been elusive and time-consuming, and I appreciate the help in discovering its cause.

  16. I also get the message: Server did not recognize the value of HTTP Header SOAPAction: http://website/Authenticate.

    The problem I am having is that my web service was originally written in visual studio dot net 2003 and everything worked fine. However, ever since I have converted my project from 2003 to visual studio dot net 2005 I have not been able to get my webService to work anymore, I just get the error mentioned above.

    I have used ethereal to capture the soap message passed in both my 2003 web service and then in my 2005 and both soap messages are Identical, so why does the 2005 version work? The only difference between them is that one uses ASP 1.1.4322 and the other uses ASP 2.0.50727 but I don’t see how that is causing the problem.

    Is it something to do with using a different version of SOAP? And if so what is the best was to resolve this? I would appreciate any suggestions anyone has.

  17. @Paul: If you note the soapAction Header has Extra ‘#’ character. This is an issue when using SOAP::Lite

    soapAction http://tempuri.org/#Hello.

    You should try getting rid of the pound character. The problem IS the pount character.

    By default if you haven’t specified any namespace, it goes to http://tempuri.org/

    It should be something like /
    Example: http://tempuri.org/Hello

    [WebMethod]
    public string Hellow( string strName )

    Slightly the same case with brett too.. see to what your WSDL says. Copy paste your webservice in your browser http://website/Authenticate.asmx Somewhere it should tell you the service namespace being used. Now use the same service namespace followed by the method name you are calling. Probably, something changed with 2.0 from 1.1 with the service namespaces.

    Nice one, by the way!

    Cheers,
    NeoDarwinian a.k.a Sheriff

    A little bit of gibberish tehre here and.

  18. Thanks so much. I was at the end of my rope with a production issue. Just the part about “don’t get confused between web service namespaces and .net namespaces” was enough to get me the aaha! I needed to fix the problem.

    JJA

  19. Excellent. I would have never thought that the namespace could kill the client connections. Thanks!

  20. Thanks!!! This one small thing proves to be big. Wasted me a few days time because the guys working on the server side did not tell me about this change. 🙁

    Thanks again!

  21. Thanks man, exaclty this was error and Its solves. Are things that we change and don´t care what we really are doing.

    Thanks again!.

  22. I also spent 4 hours solving this, but the reason was even less technical. The URL of the webservice as defined in the client config file was typed wrong, and that caused the client to use the website’s default “page” instead of the correct one. There was “/” and space after the URL. Makes sense to get this error when wrong web service was attempted to be used… reading IIS log files helped to see this.

  23. I faced the same problem with a vendor supplied WSDL and the problem was solved by bouncing the IIS Server ad supplying the correct SOAPAction as specifed in the WSDL. ALso make sure that Content-Type is set to ‘text/xml’. Cheers

  24. Thanks, this has solved my problem..took me 2 hrs to reach ur post..but not bad..thanks again

  25. Great to know. I was messing with URI’s in the Service header thinking they had to match the actual DNS reference. Thanks!

  26. When creating a new web service with VS 2003 there are no places to declare the namespace by default. In order to change the namespace of your web service use the following attribute declaration above your WebService class (for C#) in your yourwebservicename.asmx.cs file:

    [WebService(Namespace=”http://yourdomain.com/yourwebservicename”)]

    Then make sure that this namespace matches the namespace declared in your client references. I found namespace declarations in the following attributes in my Refereences.cs file:

    WebServiceBindingAttribute
    SoapDocumentMethodAttribute

    Remember to replace the “yourdomain” text and “yourwebservicename” text with your own information.

    Hope this is helpful.

  27. If you are trying to connect to a .NET web service using Apache Soap 2.x for the Client, you will find this error unless you’ve written a Proxy and reprocess the message and response as explained at:
    http://www.microsoft.com/spain/interop/developers/wsresources.mspx
    http://support.microsoft.com/kb/308466/en

    Other solution is not using Apache soap, but Axis or Axis2 any of which should connect to the .NET service smoothly…

    ¡Good Luck!

  28. Thanks so much for taking the time to post this.

    Extremely confusing error message… I lost half a day on this.

    For me it was the difference of running in Development environment versus Production environment.

    Thanks again!

  29. Reading this, and then deleting the web reference in the client app and recompiling solved my problem. I had changed the namespace, but it was still on the same server.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.