#51129 [Opn-Csd]: XX is not a valid Stream-Context resource while using Soap with local_cert
ID: 51129 User updated by: bigdan at gmail dot com Reported By: bigdan at gmail dot com -Status: Open +Status: Closed Bug Type: SOAP related Operating System: linux PHP Version: 5.3.1 New Comment: Today's (php5.3-201002241330) snapshot worked. Closing. Previous Comments: [2010-02-24 03:31:31] bigdan at gmail dot com Description: This bug is strangley similar to #46427, but not exactly the same. This bug _only_ manifests when using php 5.3/5.3.1 and php snapshots. In order to reproduce this bug, local_cert (and passphrase - unfortunately, I cannot test without the passphrase) need to specified in the SoapClient parameters. Any calls to this constructed client fail with: E_WARNING: SoapClient::__doRequest(): XX is not a valid Stream-Context resource in ... where XX is the resource number, which is missing a #. Using php 5.2.4-2ubuntu5.6, this exact same script works perfectly. This problem manifests regardless of whether the soap client is encapsulated in a function or procedural. Expected result: The SoapClient method executing successfully. Actual result: -- E_WARNING: SoapClient::__doRequest(): 179 is not a valid Stream-Context resource in ... -- Edit this bug report at http://bugs.php.net/?id=51129edit=1
#51129 [NEW]: XX is not a valid Stream-Context resource while using Soap with local_cert
From: bigdan at gmail dot com Operating system: linux PHP version: 5.3.1 PHP Bug Type: Streams related Bug description: XX is not a valid Stream-Context resource while using Soap with local_cert Description: This bug is strangley similar to #46427, but not exactly the same. This bug _only_ manifests when using php 5.3/5.3.1 and php snapshots. In order to reproduce this bug, local_cert (and passphrase - unfortunately, I cannot test without the passphrase) need to specified in the SoapClient parameters. Any calls to this constructed client fail with: E_WARNING: SoapClient::__doRequest(): XX is not a valid Stream-Context resource in ... where XX is the resource number, which is missing a #. Using php 5.2.4-2ubuntu5.6, this exact same script works perfectly. This problem manifests regardless of whether the soap client is encapsulated in a function or procedural. Expected result: The SoapClient method executing successfully. Actual result: -- E_WARNING: SoapClient::__doRequest(): 179 is not a valid Stream-Context resource in ... -- Edit bug report at http://bugs.php.net/?id=51129edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51129r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51129r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51129r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51129r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51129r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51129r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51129r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51129r=needscript Try newer version: http://bugs.php.net/fix.php?id=51129r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51129r=support Expected behavior: http://bugs.php.net/fix.php?id=51129r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51129r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51129r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51129r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51129r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51129r=dst IIS Stability: http://bugs.php.net/fix.php?id=51129r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51129r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51129r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51129r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51129r=mysqlcfg
#49169 [Com]: SoapServer calls wrong function, although SOAP action header is correct
ID: 49169 Comment by: bigdan at gmail dot com? Reported By: jeroen at asystance dot nl Status: Verified Bug Type: SOAP related Operating System: linux PHP Version: 5.2SVN-2009-08-05 (snap) New Comment: Is anyone aware of a workaround? I am having this issue on Ubuntu Hardy. Thanks Previous Comments: [2009-09-09 19:27:50] sjo...@php.net Could reproduce. Even though the soap action looked as follows: SOAPAction: operation2 Operation 1 was called. [2009-08-20 15:18:33] robin dot harvey at chaptereight dot com Hi, This bug is affecting me too, and I've noticed that it's only the input parameters which trigger the bug - 2 functions can have the same output and they are treated individually. Also, it seems that it's the order of the wsdl:binding/wsdl:operation declarations which makes a difference, swapping the wsdl:portType/wsdl:operation or wsdl:message ordering does not trigger the bug. HTH --Robin [2009-08-05 11:13:06] jeroen at asystance dot nl The correct link to the test case is http://jayvee.nl/soaptest2.tar (without the comma) [2009-08-05 11:11:00] jeroen at asystance dot nl Description: When two wsdl:operations have the same API (that is, have the same wsdl:messages), the SoapServer calls the function corresponding to the _first_ wsdl:operation specified in the wsdl:binding, even although the SoapClient sends the correct SOAP action header, which is correctly received on the server. Reproduce code: --- Download http://jayvee.nl/soaptest2.tar, untar and change the URL in interface.wsdl call SAOPTest.php, which is both a client and server. The server will produce a log that the client outputs, so you can see what the server is doing. Expected result: Independent of the order in which the wsdl:operations are listed in the wsdl:binding element, the SoapServer should call the function corresponding to the SOAP action header specified in the request. Actual result: -- The SoapServer always calls the function corresponding to the _first_ wsdl:operation specified. In the test case, the server will call function operation1() twice, even though the second call is to operation2, and the SOAP action header's value is operation2 To verify, switch the wsdl:operation elements in the wsdl:binding element and run SOAPTest.php. You will see that the server will call function operation2() twice, even though the SOAP action headers are different. -- Edit this bug report at http://bugs.php.net/?id=49169edit=1
#49169 [Com]: SoapServer calls wrong function, although SOAP action header is correct
ID: 49169 Comment by: bigdan at gmail dot com Reported By: jeroen at asystance dot nl Status: Verified Bug Type: SOAP related Operating System: linux PHP Version: 5.2SVN-2009-08-05 (snap) New Comment: Nevermind on the workaround - either this is not a bug, this issue was noticed well before this bug, or the comments here are entirely unrelated though they correct the issue for me: http://us3.php.net/manual/en/soapserver.handle.php#81750 TLDR: Instead of soap:binding style=document you need to use soap:binding style=rpc Previous Comments: [2009-09-18 13:45:30] bigdan at gmail dot com? Is anyone aware of a workaround? I am having this issue on Ubuntu Hardy. Thanks [2009-09-09 19:27:50] sjo...@php.net Could reproduce. Even though the soap action looked as follows: SOAPAction: operation2 Operation 1 was called. [2009-08-20 15:18:33] robin dot harvey at chaptereight dot com Hi, This bug is affecting me too, and I've noticed that it's only the input parameters which trigger the bug - 2 functions can have the same output and they are treated individually. Also, it seems that it's the order of the wsdl:binding/wsdl:operation declarations which makes a difference, swapping the wsdl:portType/wsdl:operation or wsdl:message ordering does not trigger the bug. HTH --Robin [2009-08-05 11:13:06] jeroen at asystance dot nl The correct link to the test case is http://jayvee.nl/soaptest2.tar (without the comma) [2009-08-05 11:11:00] jeroen at asystance dot nl Description: When two wsdl:operations have the same API (that is, have the same wsdl:messages), the SoapServer calls the function corresponding to the _first_ wsdl:operation specified in the wsdl:binding, even although the SoapClient sends the correct SOAP action header, which is correctly received on the server. Reproduce code: --- Download http://jayvee.nl/soaptest2.tar, untar and change the URL in interface.wsdl call SAOPTest.php, which is both a client and server. The server will produce a log that the client outputs, so you can see what the server is doing. Expected result: Independent of the order in which the wsdl:operations are listed in the wsdl:binding element, the SoapServer should call the function corresponding to the SOAP action header specified in the request. Actual result: -- The SoapServer always calls the function corresponding to the _first_ wsdl:operation specified. In the test case, the server will call function operation1() twice, even though the second call is to operation2, and the SOAP action header's value is operation2 To verify, switch the wsdl:operation elements in the wsdl:binding element and run SOAPTest.php. You will see that the server will call function operation2() twice, even though the SOAP action headers are different. -- Edit this bug report at http://bugs.php.net/?id=49169edit=1
