Description: ------------ Hello While migrating old scripts to a recent Linux host I discovered that the old way of calling "$client = new SOAP_Client('http://user:pass@..." does no longer work. When calling $client->send() there is still an internal call to Transport/HTTP.php's function _validateURL which parses the URL and creates a $this->headers['Authorization'] but the SOAP_Client->call() function does not honor this header() variable at all but only takes options from the passwd $options variable. So the new way of calling is (as documented in Bug 11830) to pass "user" and "pass" as options to SOAP_Client->call(). Still I would assume that the old way was dropped by accident and should be reactivated (as it's a common to pass credentials inside the URL). bye, -christian- Test script: --------------- $this->soapclient = new SOAP_Client("http://webservice:topsecret@webmanager.company.de "); $domainids = $this->soapclient->call('getDomainId', array(), ''); Expected result: ---------------- something from the remote server Actual result: -------------- HTTP Response 401 Authentication Failed (Code HTTP)

The bug was introduced between 0.9.1 and 0.9.2. The changelog mentions Bug #5003 but at least the suggested patch seems not to be wrong. bye, -christian-

Ah hah! SOAP_Transport_HTTP::_getRequest($msg, $options); does $this->headers = array(); which overrides the already stored information. The workaround: Pass in a username / password into $options['user'] and $options['pass']; when you call _getRequest...

Workaround... $client = new SOAP_Client('...'); $client->setOpt('user', 'myusername'); $client->setOpt('pass', 'password'); $client->call('...');

There is a testcase for this bug attached

The test is rather useless, of course it would fail if you pass an empty $options array. Generally, I don't see why we should still support passing user names and passwords by URL, if it works by passing them as parameters. Or do you say the the method documented in bug #11830 doesn't work?

@Jan Schneider: One reason why you should still support it was that you did support it before and should not break backwards compatibility. At least throw an exception if you encounter a ^https?://\w+:\w+@ regexp at the beginning of the URL and do not silently drop the credentials. BTW, where is the usage of setOpt('user') documented, can't find it in the examples/client.php nor in the API documentation of SOAP_Client->setOpt() on pear.php.net... :( bye, -christian-

BC is not an issue, because this is not a stable version. And it is *not* documented yet, that's why I pointed you to the patch *adding* the documentation. But you still didn't answer the most important question: does it work with that method for you or not?

Hi Jan I currently have no SOAP environment to test against. BTW, your SOAP package is tagged "beta" for six years now, given the general 0.something culture in the open source world you should consider to avoid BC issues! :-) bye, -christian-

Personally, I'm voting for retaining the ability to understand http://user:pass@domain.com/path/ - it's a valid URL Jan, if you look into the code in SOAP_Transport_HTTP... send() -> __validateUrl() // parses information into internal storage of the object (user : pass) -> _sendHTTP() ---> _getRequest() // does $this->headers = array(); ... it's silently changing internal stuff and appears to be a quite legitimate regression; which the shows as broken. Perhaps one approach to fixing it could be to parse any urls into a Net_URL instance; and store that seperately to all of the other $headers() until the last moment? ie: 1. Instantiate -> stuff in information 2. Store data in specialized locations - for instance, SOAP_Transport_HTTP::$url 3. Provide a simple protected method to assemble the headers just in time, and rely on that to build up your array (rather than tamper with it sporadically throughout the code)

+ "which the test shows as..."

See also Bug #13335 ; which is sounds very much like $headers = array() occuring when you send your http request...