Issues in nusoap_server::parseRequest (v0.9.18)

[VMFnet]

In nusoap v0.9.17, warnings were raised due to undefined variables in nusoap_server::parseRequest. However, in v0.9.18, this behavior changed, and now an error occurs:

"Too few arguments to function MyFunc(), 0 passed in ..."

After investigating, we identified several issues in nusoap_server::parseRequest and invoke_method:

1. Incorrect Operation Name in wsdl::getOperationData()

• In parseRequest, the variable $this->methodnameis passed to getOperationData, which might be incorrect. It is currently set to "MyOperationRequest" but getOperationData() should expect a value like "MyOperation", as this is the correct key under $this->binding[$portData['binding']]['operations'].
• The same issue occurs in nusoap_server::invoke_method.
• As a result, $opData in parseRequest() is empty, leading to warnings when attempting to access $opData['output']['message'] in v0.9.17.

2. Function Stops Execution in v0.9.18

• In v0.9.17, the code continued execution even if $opData['output']['message'] was missing, likely because $this->responseTagName would later be set to a default value or was not required.
• In v0.9.18, execution stops if this offset does not exist, causing SOAP parameters to not be parsed and preventing the function from executing correctly.

3. Incorrect output Key Usage

• In v0.9.18, the code incorrectly expects an 'output' key with 'name'.
• However, in v0.9.17, this key was correctly named 'message', which matches the WSDL definition.
  The code should continue using 'message' instead of 'name' under 'output'.

Temporary Fix

As a quick workaround, removing the return false; line in parseRequest prevents the function from stopping execution.

However, the root cause lies in how operation names are handled and how 'output' keys are referenced.

This needs to be addressed properly in the parseRequest and invoke_method functions.

[tenzap]

Is this fixed by #131?