You can find a possible way to fix this issue in the attached patch file.

Cheers,
Thomas

Would it make sense to allow for more flexibility with setting the Uri? For cases of mod_rewrite, in context of MVC, etc. Patch attached.

Thanks!

Full ack, absolutely great!

I ran in the same problem. Same solution

Zend_Soap_AutoDiscover.targetNamespace.patch allows for setting the soap endpoint url separately from the target namespace.

Like for Ing. Jitka Darbujanova in ZF-4172 this issue is a showstopper for me, Zend_Soap_AutoDiscover disallows HTTPS and setting uri / location / whatever on a personal choice is impossible. The patches attached to this bug report are easy to understand and shouldn't break anything - it would be great if someone could take care of this ticket. Issue is still there in 1.6.1.

Best regards,
Thomas Gelf

Oops! I somehow managed it to toggle assignment, sorry.
I'll let it be reassigned automatically...

Sorry, all three patches are bogus..

The first one is just a hack to solve the HTTPS problem, the second and third ones ignore the setFunction alltogether. None provides unittests and documentation changes.

Also the one with setUri (Zend_Soap_Autodiscover.uri.php) has the problem that when setClass is called BEFORE setUri, the uri setting is ignored. This is not desired behaviour since its common expectation that the setter functions of webservice objects (like SOAPServer) only begin to act on calling $server->handle();

I have attached a patch that allows changing the default wsdl location uri only by constructor, to handle the problem described in the above paragraph. I have added a unittest to check for the changed webservice url and a proposed change to the documentation.

To allow for a setUri function to be accessible for the public scope, underlying changes to the WSDL component have to be done. Therefore my setUri function is just private for the time being, hoping that the WSDL component will be refactored someday to be more flexible.

• add private setUri function (due to problems in communication with WSDL component)
• add new variable in constructor taking Zend_Uri|string and saving to $this->_uri
• change setClass to test for $this->_uri
• change setFunction to test for $this->_uri

• Add Test-Case for AutoDiscover setting Uri via constructor

The corresponding file to this comments are AutoDiscoverTestSetUri.php.patch and AutoDiscoverSetUri.php.patch

Fixed in Trunk via second constructor parameter $uri or function setUri($uri).

Thank you for fixing this, setUri() is a great addition. However my initial bug report regarded hardcoded http schema and autodetection. My proposed patch is not a hack, schema detection is done the same way in other parts of the Zend Framework (Controller, OpenID...). And it requires no new documentation as it fixes existing behaviour conforming to what a developer would expect from an "autodiscover" component.

Not using HTTPS is not an option for most webservices today, and if there is an autodetection component it should also detect wheter I'm running HTTPS or not. I do NOT want to have to either do schema detection in my controllers and I do NOT want to hardcode / configure URIs in my application. Schema detection should work out of the box - and adding port detection for non-standard ports would also be a nice-to-have feature.

Adding schema detection from my very first patch to your setUri() function would solve this, adding port detection (like Zend_OpenId::selfUrl()) would be a nice addition.

Best regards,
Thomas Gelf

NB: Sorry for impudently reopening this issue

i am sorry, misunderstood the issue (overstepped it). I'll fix the HTTPS issue right away.

Fixed detection of HTTPS schema in trunk

Changing issues in preparation for the 1.7.0 release.