If anyone is interested (doubtful) .. The problem is solved. Apparently the problem lay in my wsdl, which had the "synchronousQuery" method defined with the input of "synchronousQueryRequest", which had the parameters in a different order, ie. queryStatement first, then targetSessionID. Interesting that SOAP should be so weak as to actually completely ignore the well named parameters in favor of using parameter order! Even though this is working now, I still find it odd. -Steinn E. Sigurðarson On 9/9/06, Steinn E. Sigurðarson <steinnes@gmail.com> wrote:
Hello everyone, I'm writing to describe an interesting problem I ran into yesterday while building a pure javascript interface to a SOAP service I have implemented in PHP. The problem seems to be that once the request is handled, parameters are switched around, causing them to pass to my methods in the wrong order. The exact scenario is that I'm sending a request with two parameters; "targetSessionID", and "queryStatement". Below is a copy of the SOAP request the javascript soapclient generates and sends to the server. ---- <?xml version="1.0" encoding="utf-8"?><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><synchronousQuery xmlns="http://schema.example.com";><targetSessionID>1</targetSessionID><queryStatement>test123</queryStatement></synchronousQuery></soap:Body></soap:Envelope> ---- I've also printed out to the error log of my webserver what the PHP script is receiving on stdin, and the request does indeed look like this. So barring some shortcomings of this request (for example not using CDATA encapsulating for the potentially dangerous content of the queryStatement) it should work. However the interesting part comes when I start printing out debugging information in the server side synchronousQuery method. The code of which is here below; ---- function synchronousQuery($targetSessionID, $queryStatement) { error_log("targetSessionID=" . $targetSessionID); error_log("queryStatement=" . $queryStatement); if (!$this->validateSession($targetSessionID)) throw new NoSuchSessionException("Invalid session ID supplied: " . $targetSessionID); $this->results = $this->process_query($queryStatement); $this->totalResultsCount = count($this->results); // we need to save this value if (!$this->results) return ""; return $this->results_list(); } ---- As you can see, I log to the error log the input I'm getting for the two parameters, and the error prints look like this: ---- [Fri Sep 08 17:45:30 2006] [error] [client 137.208.121.176] targetSessionID=<simpleQuery><summary>essays</summary></simpleQuery> [Fri Sep 08 17:45:30 2006] [error] [client 137.208.121.176] queryStatement=1 ---- So you can see that the targetSessionID variable contains the data which in the SOAP request itself was contained in the queryStatement parameter, and vice versa. My server version is Apache/2.0.55 (Debian) PHP/5.1.4-0.1 -- perhaps I should try and upgrade? Has anyone else had a similar problem? Another quite perplexing thing -- this webservice has worked quite correctly for me before using another PHP based SOAP client, so this morning I got the idea that perhaps some slight error in the javascript generated soap request (something slight enough so that I did not detect it myself) was throwing everything off. I went and took a look at the SOAP requests my other SOAP client, based on PHP, was sending, as they are working correctly and thus should be more correct. I was slightly horrified to find out that this "parameter switching" does not seem confined to this particular server of mine, or the server side SOAP stuff, but my client was in fact sending the parameters in the wrong order (the queryStatement data contained within the targetSessionID parameter, etc). When the data reached the server (in the wrong order) it was switched around again, presumably by the same problem as switched it around in the PHP SOAP clients request, and thus two wrongs made a right. Here is the way the request looks from the PHP SOAP client; ---- <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ns1="http://schema.example.com"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";><SOAP-ENV:Body><ns1:synchronousQuery><queryStatement xsi:type="xsd:string">1</queryStatement><targetSessionID xsi:type="xsd:string"><simpleQuery> <fullname>Composition</fullname> </simpleQuery></targetSessionID></ns1:synchronousQuery></SOAP-ENV:Body></SOAP-ENV:Envelope> ---- Although this is perhaps not "nice" to read, you can easily see the entity encoded simpleQuery stuff that's been contained within the targetSessionID parameter? Just to be extra-extra clear, here is the code for the actual SOAP request from the PHP; ---- $resultset=$sc_target->__call("synchronousQuery", array( new SoapParam($session_id,"targetSessionID"), new SoapParam($requests[$idx],"queryStatement") )); ---- I admit that I am not an expert on SOAP, and I may be doing things wrong somewhere, and quite frankly I find this too ridiculous a bug for me to be the one discovering it, now, so I'm quite expecting this to be a known condition even? But looking through a couple of pages of the mailing list post subjects', I didn't see anything at a glance which sounded similar, so post I will. Any ideas what my problem could be? Best regards, Steinn E. Sigurðarson
-- PHP Soap Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
