Edit report at https://bugs.php.net/bug.php?id=49169&edit=1

 ID:                 49169
 Comment by:         php dot net at exby dot com
 Reported by:        jeroen at asystance dot nl
 Summary:            SoapServer calls wrong function, although "SOAP
                     action" header is correct
 Status:             Verified
 Type:               Bug
 Package:            SOAP related
 Operating System:   linux
 PHP Version:        5.3.3
 Block user comment: N
 Private report:     N

 New Comment:

I still can't believe this is not fixed. Can we get someone from php.net 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.


Previous Comments:
------------------------------------------------------------------------
[2013-02-24 20:05:03] reto at casserini dot com

Another workaround. 

Instead of

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

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>
    <message name="getUsers">
        <part name="parameters" element="tns:getUsersInput"/>
    </message>

works fine for me.

------------------------------------------------------------------------
[2012-10-12 19:30:12] 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?

------------------------------------------------------------------------
[2011-02-11 12:28:25] jeroen at asystance dot nl

Just wanted to verify this bug is still present in 5.3.3

------------------------------------------------------------------------
[2010-09-08 14:04:08] 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.

------------------------------------------------------------------------
[2010-09-08 13:54:12] 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.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=49169


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=49169&edit=1

Reply via email to