|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49169 SoapServer calls wrong function, although "SOAP action" header is correct
Submitted: 2009-08-05 11:11 UTC Modified: 2018-10-25 00:02 UTC
Avg. Score:4.7 ± 0.8
Reproduced:70 of 70 (100.0%)
Same Version:24 (34.3%)
Same OS:40 (57.1%)
From: jeroen at asystance dot nl Assigned:
Status: Verified Package: SOAP related
PHP Version: 7.2.11 OS: linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: jeroen at asystance dot nl
New email:
PHP Version: OS:


 [2009-08-05 11:11 UTC] jeroen at asystance dot nl
When two <wsdl:operation>s have the same API (that is, have the same <wsdl:message>s), the SoapServer calls the function corresponding to the _first_ <wsdl:operation> specified in the <wsdl:binding>, even although the SoapClient sends the correct "SOAP action" header, which is correctly received on the server.

Reproduce code:
Download, untar and change the URL in interface.wsdl

call SAOPTest.php, which is both a client and server. The server will produce a log that the client outputs, so you can see what the server is doing.

Expected result:
Independent of the order in which the <wsdl:operation>s are listed in the <wsdl:binding> element, the SoapServer should call the function corresponding to the "SOAP action" header specified in the request.

Actual result:
The SoapServer always calls the function corresponding to the _first_ <wsdl:operation> specified.

In the test case, the server will call "function operation1()" twice, even though the second call is to operation2, and the "SOAP action" header's value is "operation2"

To verify, switch the <wsdl:operation> elements in the <wsdl:binding> element and run SOAPTest.php.

You will see that the server will call "function operation2()" twice, even though the "SOAP action" headers are different.


Add a Patch

Pull Requests

Pull requests:

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-05 11:13 UTC] jeroen at asystance dot nl
The correct link to the test case is (without the comma)
 [2009-08-20 15:18 UTC] robin dot harvey at chaptereight dot com

This bug is affecting me too, and I've noticed that it's only the input parameters which trigger the bug - 2 functions can have the same output and they are treated individually.

Also, it seems that it's the order of the wsdl:binding/wsdl:operation declarations which makes a difference, swapping the wsdl:portType/wsdl:operation or wsdl:message ordering does not trigger the bug.

 [2009-09-09 19:27 UTC]
Could reproduce. Even though the soap action looked as follows:
SOAPAction: "operation2"
Operation 1 was called.
 [2009-09-18 13:45 UTC] bigdan at gmail dot com?
Is anyone aware of a workaround? I am having this issue on Ubuntu Hardy.

 [2009-09-18 13:51 UTC] bigdan at gmail dot com
Nevermind on the workaround - either this is not a bug, this issue was noticed well before this bug, or the comments here are entirely unrelated though they correct the issue for me:

TLDR: Instead of <soap:binding style="document you need to use <soap:binding style="rpc
 [2009-09-18 14:10 UTC] jeroen at asystance dot nl
bigdan, I think you left out one option: this _is_ a bug.

Using RPC style _is_ a workaround, but one that doesn't always work.

The real problem is that SOAP should use the SOAPAction header to determine which operation to call, not guess based on parameters (which is what it looks to be doing now).

While the comment you refer to does point out this very issue and predates this bug, that doesn't mean it's not a bug. Rather the commenter could (and should?) have filed this as a bug more than a year ago.
 [2009-09-23 14:51 UTC] robin dot harvey at chaptereight dot com
@bigdan at gmail dot com

The workaround I'm using is to set up my WSDL so that all methods have a unique input type signature.  Of course this leads to an ugly and unnecessarily bloated WSDL, but there's not much other choice (other than WS02 PHP, that is....)
 [2009-09-30 06:58 UTC] wee at xbe dot ch
this bug is really annoying.. the forced use of rpc (the "workaround") is not a serious fix.

we also evaluated wso2 (wsf_php) as the php soapserver simply isn't that business ready, but that too has it's issues (has problems when it comes to generate complex wsdl and with complex type handling on the php side). and it segfaults with an activated zend optimizer+ ;-)

anyway, i just comment to give more importance to this bug.
 [2009-11-04 17:08 UTC] spyowl at gmail dot com
Confirmed on 5.3.1RC3 using WSDL.

The problem seems to be the matching first argument name between methods (not the whole signature) - as long as 2 or more methods have the same name for the first argument the SoapServer will always execute the first method listed, regardless of soapAction, and even if there are additional arguments for those methods that are different from each other.

This is a pretty serious bug.
 [2010-03-30 11:03 UTC] rkm at nykredit dot dk
It's not even enough to change the message name (I didn't get that from the initial comments) - One needs to change the element of the part.

<wsdl:message name="getByIdRequest">
  <wsdl:part name="parameters" element="tmp:ClientId"/>

Will not work with (reusing tmp:ClientId):
<wsdl:message name="getByIdRequest2">
  <wsdl:part name="parameters" element="tmp:ClientId"/>

You'll have to create a new element, wich makes it hard to use i a corporate environment, where you have to use standard elemnts - Thus this is not a valid option, even though it works:
<wsdl:message name="getByIdRequest2">
  <wsdl:part name="parameters" element="tmp:ClientId_Clone"/>

This bug has been here for a while, any movement against a solution?

So far I have to create a WSDL for each operation, which is not very PHP-smooth!
 [2010-03-30 12:19 UTC] rkm at nykredit dot dk
Adding to the above comment - If first SoapServer fails to read your WSDL properly, it will end up calling all known methods of the object added to SoapServer.
- By "known" I mean, that if the .wsdl describes *another* binding to *another* method, than the one called - The other method gets called as well, and the result added to the <SOAP-ENV:Header> tag in the return.
 [2010-09-08 13:54 UTC] hoffmeister dot c at gmx dot de
This is no bug. I guess you used style="document" in the wsdl file operation description. In this case there is no operation name passed from the client to the server. Try style="rpc" (remote procedure call) instead. That works pretty well.
 [2010-09-08 14:04 UTC] rkm at nykredit dot dk
Well, maybe the RPC-protocol will work, but where I work, it is mandatory to create services using style="document", and it really isn't to the advantage of PHP to tell the servicepeople in the Java dept. that we can't handle "document" styles.

Actually I circumvented the problem, by putting all the message definitions in separate files, which I then include in the schema-part of the wsdl.
Then PHP can handle the soap:binding style="document" just fine, so the problem only occurs if the names are duplicated within the same file.
 [2011-02-11 12:28 UTC] jeroen at asystance dot nl
-PHP Version: 5.2SVN-2009-08-05 (snap) +PHP Version: 5.3.3
 [2011-02-11 12:28 UTC] jeroen at asystance dot nl
Just wanted to verify this bug is still present in 5.3.3
 [2012-10-12 19:30 UTC] mrice at canarylabs dot com
This bug appears to still be present in 5.3.6.

I need help on how to use the workaround of: “Actually I circumvented the 
problem, by putting all the message definitions in separate files, which I then 
include in the schema-part of the wsdl.
Then PHP can handle the soap:binding style="document" just fine, so the problem 
only occurs if the names are duplicated within the same file.”

We are recreating a web service from an already existing one and existing 
clients need to work.

How do you include the message definitions in separate files as stated above?
 [2013-02-24 20:05 UTC] reto at casserini dot com
Another workaround. 

Instead of

    <message name="getCourses">
        <part name="parameters" type="xsd:int"/>
    <message name="getUsers">
        <part name="parameters" type="xsd:int"/>

which always leads to a call of the first operation "getCourses", I define two new types:

    <xsd:element name="getCoursesInput" type="xsd:int"/>
    <xsd:element name="getUsersInput" type="xsd:int"/>

and use them for the messages:

    <message name="getCourses">
        <part name="parameters" element="tns:getCoursesInput"/>
    <message name="getUsers">
        <part name="parameters" element="tns:getUsersInput"/>

works fine for me.
 [2013-04-08 18:06 UTC] php dot net at exby dot com
I still can't believe this is not fixed. Can we get someone from to respond to this - whether or not there is any intention to fix this?? I really don't want to use JAVA for setting up services 
but so far PHP's inability to correctly understand the soapaction header is forcing me in this direction.

And no, I can't switch to rpc/encoded and it's not a 'fix'. Document Literal is by far the more used paradigm outside of the PHP world - and web services are often implemented in the Enterprise space.

Please, somebody fix this.
 [2016-01-13 18:04 UTC] ben at redsnapper dot net
Still not fixed. Extremely annoying.
 [2016-07-28 22:33 UTC] mail at mailforspam dot com
7 years... I really hate you core team.
 [2018-10-24 21:44 UTC] mwintoch at wp dot pl
This issue still exists on PHP 7.2, even with Zend\Soap 2.7
 [2018-10-25 00:02 UTC]
-PHP Version: 5.3.3 +PHP Version: 7.2.11
 [2018-10-25 00:02 UTC]
OP's link is no good anymore and I know very little of SOAP. Does someone have a client+server+WSDL example I can test with?
 [2021-10-15 13:07 UTC] publicidad at megamarket dot com dot co
The following pull request has been associated:

Patch Name: Prevent the creation of new branches from random users
On GitHub:
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu May 30 07:01:30 2024 UTC