PEAR SOAP (or, it's about time I stopped lurking)

Hey all, It's about time I stopped lurking (apologies to Shane, Greg, et. al. for not being very participatory). I think it's about time I offer to help out since the code I write for my company is now in maintenence (tweak) mode. I'm open to suggestions on how to stop being such a wallflower, commit rules and the like (tychay@php.net but send e-mail to tychay@mac.com as my computer is in the shop for the rest of the week).... Perhaps this goes on the [SOAP] mailing list. The rest of this post concerns PEAR SOAP. I apologize in advance if any of my questions are stupid or my suggestions break everything since I haven't time to install the SOAP_Interop package (should I?). They specifically apply to the last release and PHP4 (since I use the stuff in deployment). Re: SOAP/Transport/HTTP.php in _SendHTTPS() cURL since 7.10.0+ will verify the SSL host/peer before connecting. This makes it nasty when testing certain things. It would be nice if we could add an option to turn verification off. When such an option is on... curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0); Oops I noticed you added a $options['curl'] thing going... Hmm, maybe scratch this. Re: SOAP/Transport/HTTP.php in_SendHTTPS() I seem to remember that the way it runs currently it forgets to log anything and doesn't send the proper headers (or somesuch). I can't remember the exact syntax I used but it was something like.... curl_setopt($ch, CURLOPT_CUSTOMREQUEST, $this->outgoing_payload); curl_setopt($ch, CURLOPT_URL, $this->url); curl_setopt($ch, CURLOPT_FAILONERROR, 0); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_VERBOSE, 1); curl_setopt($ch, CURLOPT_HEADER, 1); //insert options parsing here. $this->incoming_payload = curl_exec($ch); curl_close($ch); if ($!this->_parseResponse()) { return $this->fault; } return $this->response; I took the liberty of leveraging the methods/properties that were lying around that already have everything constructed instead of doing some silly "let's let curl make the headers and managing the head section" thing so it behaves just like the non https version but with https support. I also refactored the location of curl_close(). Not too sure if this works and it needs another pair of eyes. Re: SOAP/Server.php in verifyMethod() Are you sure this is the correct way of iterating over the input parameters? For instance, let's say I already went through the effort to create a dispatch_map and I accept two parameters "homeID" (long) and "sessionTicket" (string). Now if I send it in the following order... sessionTicket then homeID but properly labelled (for instance, this is how the SOAP layer in Cocoa Web Services will do this and I think CapeStudio also (not sure)). PEAR SOAP will barf with a "soap request contained mismatching parameters of name sessionTicket had type [string], which did not match signature's type: [long], matched? -7". Note that since SOAP labels all parameters it is perfectly valid to reverse the order, but because this method seems to interate over each param type instead of verifying by name it doesn't... here is what I mean: You have: $sig_t = array_values($sig); for($i=0; $i < count($p); $i++) { if (strcasecmp($sig_t[$i],$p[$i])!=0 && (isset($this->_typemap[SOAP_XML_SCHEMA_VERSION][$sig_t[$i]]) && strcasecmp($this->_typemap[SOAP_XML_SCHEMA_VERSION][$sig_t[$i]],$this->_typemap[SOAP_XML_SCHEMA_VERSION][$p[$i]])!=0)) which means in english: 1) grab all the names of the parameters of the dispatch map 2) iterate over all the input parameters IN ORDER and then make sure that the names are in the dispatch map and their position (of the input parameters, not the input parameter position adjusted by the rules of the dispatch map) has the correct type (again, accorded by position it was provided, not by the named postion) then don't give a fault ... 3) profit?? (I assume here you upload the params to the method in the order they are provided, not in the corrected order). Now I have a minor interest in fixing this. I'll do it if someone can walk me through the administration (the code is realatively simple to fix but I want to make sure I'm not breaking some unit tests or whatnot). Re: Disco.php Nice discovery code. However, how come the only <documentation> tag I can bind the the WSDL is in the <service> line. This actually means more than a bit to me because I have to manually keep my WSDL in sync with my class library since I provide the WSDL with human readable documentation (and make an HTML version available by parsing the WSDL). I supposse I can hack it by modifying the $_this->_wsdl ex post facto but it would be nicer if there were hooks here for adding documentation lines. BTW, why is there a tag called ['attr'] for all attributes? I ask this because this causes two troubles... first it means you can never have a tag called <attr> and second because it isn't logical to create an array for attributes when they are just members of the base tag that can't have nesting. Why not base attributes on xpath rules so instead of... $this->_wsdl['definitions']['service']['attr']['name'] it would be $this->_wsdl['definitions']['service']['@name'] which would never run into a conflict. Sure iteration would be a slight pain but it's much more intuitive IMO. At the very minimum, name the tag "@" so that it can't ever be confused with a real XML tag which requires a letter or an _ in the first position. I suppose this is a simpleXML stupidity? Opinions? Take care, terry chay tychay@php.net tychay@mac.com