Bug #52819 [Com]: Compling/Encoding
Edit report at http://bugs.php.net/bug.php?id=52819&edit=1 ID: 52819 Comment by: zippy1981 at gmail dot com Reported by:dmewis at agaresmedia dot com Summary:Compling/Encoding Status: Bogus Type: Bug Package:*General Issues Operating System: Lindux PHP Version:Irrelevant Block user comment: N New Comment: First of all, this is not a new problem, so I don't see how it "will affect affordability of software online." If you argued "fixing" this long standing issue, "will affect software afford ability," that would make some sense. Secondly, I think what you are saying is you want you customers, who are PHP developers to be able install your PHP libraries, as bytecode, on their shared hosting servers. However, phpShield cannot be installed unto the shared webhost your customer is using. The problem is even if changes were made to php and phpShield to allow this to happen, ISPs would have to configure PHP to enable these features. It seems liek it would be easier to find shared hosting that has phpShield installed globally. I would suggest contacting phpShield and asking that. Previous Comments: [2010-09-12 01:46:15] ras...@php.net Cry me a river. [2010-09-12 01:34:48] dmewis at agaresmedia dot com Description: Huge problem is developing that will affect affordability of software online. The support staff for phpShield says they can't deploy their compiling/encryption software so that the phpShield loaders can be installed in the user's webspace rather than the root level. This is a huge problem when we are faced with heavy software theft because we are forced into open source. Because PHP almost forces people who use it to write in open source, there are not enough quality software out there except those that use ZendGuard, phpShield, or other byte-code encrypter/encoders that forces hosts to install the loaders at the root level. It is critical for future of software development that there be a way to install byte code encryption loaders IN THE section between the root level and public_html which I refer to as part of the user webspace. We should not be forced to pay a grand a year to Zend for their software, nor should we have to battle website hosts who refuse to install loaders on behalf of their customers. It needs to be made possible that we can finally run byte-code compiled software without a lot of hassle or having to have root level access. Otherwise, it's difficult to sell software to webmasters using shared accounts. Now, I would of posted this as a suggestion, but the PHP development team provides no way of contacting them. Hopefully this gets read by the right person. -- Edit this bug report at http://bugs.php.net/bug.php?id=52819&edit=1
[PHP-BUG] Bug #52726 [NEW]: getCode() from SoapFault thrown from call to AWS 3.0 returns HTTP not 410 4
From:
Operating system: All
PHP version: 5.3.3
Package: SOAP related
Bug Type: Bug
Bug description:getCode() from SoapFault thrown from call to AWS 3.0 returns
HTTP not 410 4
Description:
Exception::getCode() should return an int as per the documentation.
Therefore
SoapFault::getCode() should return the http code.
If you make a soap call to the deprecated Amazon Web Service 3.0 wsdl, a
html 410
(Gone) error is returned. SoapFault::getCode() and SoapFault::faultcode
should
both be 410, but they are HTTP.
Test script:
---
http://soap.amazon.com/schemas2/AmazonWebServices.wsdl',
array('trace' => true));
$request = array(
'keyword' => 'Stuff',
'page' => '1',
'mode' => 'books',
'tag' => 'you\'re it',
'type' => 'medium',
'devtag' => 'YOUR-TOKEN-HERE'
);
try {
$client->KeywordSearchRequest($request);
}
catch (SoapFault $ex) {
if ($ex->faultstring != 'Gone') throw $ex;
if ($ex->getCode() != '410') {
echo "UnexpectedCode: " . $ex->getCode();
throw $ex;
}
}
Expected result:
Nothing
Actual result:
--
UnexpectedCode: 0PHP Fatal error: Uncaught SoapFault exception: [HTTP]
Gone in
/home/zippy/src/testfest/ext/soap/tests/client_error001.phpt:20
Stack trace:
#0 [internal function]: SoapClient->__doRequest('http://soap.ama...', 'http://soap.ama...', 1, 0)
#1 [internal function]: SoapClient->__call('KeywordSearchRe...', Array)
#2 /home/zippy/src/testfest/ext/soap/tests/client_error001.phpt(20):
SoapClient-
>KeywordSearchRequest(Array)
#3 {main}
thrown in /home/zippy/src/testfest/ext/soap/tests/client_error001.phpt on
line
20
--
Edit bug report at http://bugs.php.net/bug.php?id=52726&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52726&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52726&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52726&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52726&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52726&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52726&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52726&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52726&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52726&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52726&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52726&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52726&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52726&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52726&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52726&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52726&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52726&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52726&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52726&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52726&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52726&r=mysqlcfg
[PHP-BUG] Bug #52724 [NEW]: SoapClient() with location param should work with WSDLs with all bad endpoints
From:
Operating system: All
PHP version: 5.3.3
Package: SOAP related
Bug Type: Bug
Bug description:SoapClient() with location param should work with WSDLs with
all bad endpoints
Description:
Apologies for the somewhat obtuse title, the character limit made it hard
to be
clearer.
This is somewhat related to #50698, opened and fixed by me.
If you have a WSDL that only advertises non-HTTP endpoints, or no endpoints
at
all, but you specify a http endpoint the location parameter of the
SoapClient()
constructor, the SoapClient constructor should return successfully.
Furthermore,
it should not attempt to parse the endpoints.
Test script:
---
#At a testfest now. Test with wsdl will be submitted soon:
--TEST--
Request (SoapClient should handle wsdls with all incompatiable endpoint if
you specify and endpoint in the SoapClient() constructor. Edgecase not
handled in bug #50698).
--CREDITS--
Justin Dearing
# TestFest 2010 BKTK
--SKIPIF--
--INI--
soap.wsdl_cache_enabled=0
--FILE--
'http://127.0.0.1/foo.php'));
echo "ok\n";
?>
--EXPECT--
ok
Expected result:
ok
Actual result:
--
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from
'/home/zippy/src/testfest/ext/soap/tests/bugs/bug50698_3.wsdl' : failed to
load
external entity
"/home/zippy/src/testfest/ext/soap/tests/bugs/bug50698_3.wsdl"
in /home/zippy/src/testfest/ext/soap/tests/bugs/new.php on line 2
PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL:
Couldn't load from
'/home/zippy/src/testfest/ext/soap/tests/bugs/bug50698_3.wsdl'
: failed to load external entity
"/home/zippy/src/testfest/ext/soap/tests/bugs/bug50698_3.wsdl"
in /home/zippy/src/testfest/ext/soap/tests/bugs/new.php:2
Stack trace:
#0 /home/zippy/src/testfest/ext/soap/tests/bugs/new.php(2): SoapClient-
>SoapClient('/home/zippy/src...', Array)
#1 {main}
thrown in /home/zippy/src/testfest/ext/soap/tests/bugs/new.php on line 2
--
Edit bug report at http://bugs.php.net/bug.php?id=52724&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52724&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52724&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52724&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52724&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52724&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52724&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52724&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52724&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52724&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52724&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52724&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52724&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52724&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52724&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52724&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52724&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52724&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52724&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52724&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52724&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52724&r=mysqlcfg
Req #50804 [Com]: Documenting configure.js --enable-crt-debug
Edit report at http://bugs.php.net/bug.php?id=50804&edit=1 ID: 50804 Comment by: zippy1981 at gmail dot com Reported by:zippy1981 at gmail dot com Summary:Documenting configure.js --enable-crt-debug Status: Closed Type: Feature/Change Request Package:*General Issues Operating System: win32 only PHP Version:5.3.2RC1 Assigned To:kalle Block user comment: N New Comment: Thank you. Previous Comments: [2010-08-12 00:38:26] ka...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-08-12 00:38:17] ka...@php.net Automatic comment from SVN on behalf of kalle Revision: http://svn.php.net/viewvc/?view=revision&revision=302123 Log: Fixed bug #50804 (Document configure.js --enable-crt-debug) [2010-01-20 12:31:49] zippy1981 at gmail dot com Description: If you are building on windows and run configure.js with --help one of the options you get is --enable-crt-debugExtra CRT debugging I discovered that meant if an error ocurred in PHP you got a large memory dump (or dump of some kind) printed to stderr. I propose the help message be changed to something more helpful such as: --enable-crt-debugExtra CRT debugging (this produces LARGE memory dumps to stderr) If enable-crt-debug does more than that a note indicating this will produce output most people would find prohibitively verbose should be noted. -- Edit this bug report at http://bugs.php.net/bug.php?id=50804&edit=1
Bug #47435 [Com]: FILTER_FLAG_NO_PRIV_RANGE and FILTER_FLAG_NO_RES_RANGE don't work with ipv6
Edit report at http://bugs.php.net/bug.php?id=47435&edit=1 ID: 47435 Comment by: zippy1981 at gmail dot com Reported by: valli at icsurselva dot ch Summary: FILTER_FLAG_NO_PRIV_RANGE and FILTER_FLAG_NO_RES_RANGE don't work with ipv6 Status: Open Type: Bug Package: Filter related Operating System: linux PHP Version: 5.*, 6CVS (2009-02-18) New Comment: I implemented Valli's suggestion with two caveats: 1) I have to do the IPv4 mapping addresses. I will do that next. 2) FILTER_VALIDATE_IP does not handle subnets, only IPs. Previous Comments: [2010-04-07 19:27:13] mikeg at bsd-box dot net Valli's comment seems to be the right solution: It correctly identifies & differentiates the RFC-listed private & reserved space. I would propose an additional "FILTER_FLAG_NO_SPECIAL_RANGE" that captures the union of the other sets as a convenient shortcut, but that's just laziness on my part. [2009-03-03 06:42:20] valli at icsurselva dot ch Yes, fc00::/7 is the one and only IPv6 private range. But there are also a lot of reserved ranges. FILTER_FLAG_NO_PRIV_RANGE (IP not from private ranges) fc00::/7 // unique-local addresses (rfc4193) FILTER_FLAG_NO_RES_RANGE (IP not from reserved ranges) ::/128 // unspecified address (rfc4291) ::1/128// loopback address (rfc4291) fe80::/10 // link local unicast (rfc4291) 2001:db8::/32 // documentation addresses (rfc3849) 5f00::/8 // 6Bone 3ffe::/16 // 6Bone :::0:0/96 // IPv4-Mapped addresses (rfc4291) 2001:10::/28 // ORCHID addresses (rfc4843) ::/0 // default unicast route address FYI the following ranges are implemented for IPv4 in logical_filters.c FILTER_FLAG_NO_PRIV_RANGE (IP not from private ranges) 10.0.0.0/8 // private use network (rfc1918) 172.16.0.0/12 // private use network (rfc1918) 192.168.0.0/16 // private use network (rfc1918) FILTER_FLAG_NO_RES_RANGE (IP not from reserved ranges) 0.0.0.0/8 // "this" network (rfc1700) 169.254.0.0/16 // link local network (rfc3927) 192.0.2.0/24 // test net (rfc3330) 224.0.0.0/4// Multicast (rfc3171) 240.0.0.0/4// Reserved for Future Use (rfc1700) [2009-03-03 01:20:16] il...@php.net According to the RFC I saw, the indicated ranges are the only ones identified as private. [2009-02-26 11:17:20] valli at icsurselva dot ch Sorry, I've checked the wrong file when I wrote the last comment. Now I've seen your fixes. But there are a lot more ranges to check (not only fc00::/7) At least the following IPv6 ranges should match when FILTER_FLAG_NO_RES_RANGE is set (rfc5156): ::/128 // unspecified address (rfc4291) fe80::/10 // link local unicast (rfc4291) 2001:db8::/32 // documentation addresses (rfc3849) 5f00::/8 // 6Bone 3ffe::/16 // 6Bone [2009-02-24 07:55:51] valli at icsurselva dot ch Can't find any code in the snapshots regarding this issue. Will this be fixed in php-5.3? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=47435 -- Edit this bug report at http://bugs.php.net/bug.php?id=47435&edit=1
Req #50698 [Opn]: SoapClient should handle wsdls with some incompatiable endpoints
Edit report at http://bugs.php.net/bug.php?id=50698&edit=1
ID: 50698
User updated by: zippy1981 at gmail dot com
Reported by: zippy1981 at gmail dot com
Summary: SoapClient should handle wsdls with some incompatiable
endpoints
Status: Open
Type: Feature/Change Request
Package: *General Issues
Operating System: Windows XP/7 and probably all.
PHP Version: 5.2.12, 5.3.1
New Comment:
Submitted a new patch with error handling.
Previous Comments:
[2010-04-02 17:29:49] zippy1981 at gmail dot com
Below is a patch that helps to fix the behavior. The following problems
remain:
1) If the wsdl contains only non http endpoints, and the location
parameter is
not specified, a proper error message is not generated.
2) If the wsdl contains only non http endpoints, and the location
parameter is
specified, the error "Uncaught SoapFault exception: [Client] Function
("echo")
is not a valid method for this service in File.php:21" is displayed.
Index: ext/soap/php_sdl.c
===
--- ext/soap/php_sdl.c (revision 297339)
+++ ext/soap/php_sdl.c (working copy)
@@ -832,7 +832,12 @@
if (strncmp((char*)tmp-
>children->content, WSDL_HTTP_TRANSPORT, sizeof(WSDL_HTTP_TRANSPORT)) ==
0) {
soapBinding-
>transport = SOAP_TRANSPORT_HTTP;
} else {
-
soap_error1(E_ERROR, "Parsing WSDL: PHP-SOAP doesn't support transport
'%s'",
tmp->children->content);
+ // Since this
is
an E_NOTICE severity message, it will disappear into the ether.
+
soap_error1(E_NOTICE, "Parsing WSDL: PHP-SOAP doesn't support transport
'%s'",
tmp->children->content);
+
efree(soapBinding);
+
efree(tmpbinding);
+ trav = trav-
>next;
+ continue;
}
}
}
----------------
[2010-01-13 20:59:45] zippy1981 at gmail dot com
Thanks for your reply.
On my initial report I posted an example client. In a comment in the
example client is a link to a github repo with a .NET web service that
causes this issue (e.g. config file was bound to nettcp):
http://github.com/zippy1981/EchoService
Inside the .net service is also a copy of the PHP client.
The .NET code can be compiled on any windows machine with the free IDE
SharpDevelop (http://www.icsharpcode.net/OpenSource/SD/Download/)
I can provide a manually generated wsdl with false endpoints if needed.
I'll gladly help test a fix or provide a mock if needed.
[2010-01-13 20:29:39] srina...@php.net
thanks for the clarification. if you can provide a test case /script ,
it would help us to work on this. thanks again for taking time for
following up on this. your help will definitely help PHP make better !
----------------
[2010-01-13 15:05:54] zippy1981 at gmail dot com
It seems I was not clear in my original ticket.
My soap service has two end points. One is http (soap 1.1). The other
is nettcp, microsoft private protocol.
PHP throws an error when I parse the WSDL simply because it contains
an endpoint it can't connect to. This is in spite of the following
four facts:
1) There is a http endpoint it knows how to connect to in the WSDL
2) I override the WSDL endpoints in the soap constructor.
3) A soap client only needs to connect to one endpoint in a WSDL to
communicate with it
If I manually edit the WSDL so that the nettcp endpoint is no longer
advertised, but it still exists, PHP will connect to it fine.
[2010-01-13 14:41:18] srina...@php.net
as far as I understand, Microsoft TCP transport spec is a private
interface for communicating between .Net server/clients. I would expect
that you will need SOAP/TCP as end point for communicating between php
client and .Net server.
Af course,my knowledge might be out
Req #50698 [Opn]: SoapClient should handle wsdls with some incompatiable endpoints
Edit report at http://bugs.php.net/bug.php?id=50698&edit=1
ID: 50698
User updated by: zippy1981 at gmail dot com
Reported by: zippy1981 at gmail dot com
Summary: SoapClient should handle wsdls with some incompatiable
endpoints
Status: Open
Type: Feature/Change Request
-Package: Feature/Change Request
+Package: *General Issues
Operating System: Windows XP/7 and probably all.
PHP Version: 5.2.12, 5.3.1
New Comment:
Below is a patch that helps to fix the behavior. The following problems
remain:
1) If the wsdl contains only non http endpoints, and the location
parameter is
not specified, a proper error message is not generated.
2) If the wsdl contains only non http endpoints, and the location
parameter is
specified, the error "Uncaught SoapFault exception: [Client] Function
("echo")
is not a valid method for this service in File.php:21" is displayed.
Index: ext/soap/php_sdl.c
===
--- ext/soap/php_sdl.c (revision 297339)
+++ ext/soap/php_sdl.c (working copy)
@@ -832,7 +832,12 @@
if (strncmp((char*)tmp-
>children->content, WSDL_HTTP_TRANSPORT, sizeof(WSDL_HTTP_TRANSPORT)) ==
0) {
soapBinding-
>transport = SOAP_TRANSPORT_HTTP;
} else {
-
soap_error1(E_ERROR, "Parsing WSDL: PHP-SOAP doesn't support transport
'%s'",
tmp->children->content);
+ // Since this
is
an E_NOTICE severity message, it will disappear into the ether.
+
soap_error1(E_NOTICE, "Parsing WSDL: PHP-SOAP doesn't support transport
'%s'",
tmp->children->content);
+
efree(soapBinding);
+
efree(tmpbinding);
+ trav = trav-
>next;
+ continue;
}
}
}
Previous Comments:
----------------
[2010-01-13 20:59:45] zippy1981 at gmail dot com
Thanks for your reply.
On my initial report I posted an example client. In a comment in the
example client is a link to a github repo with a .NET web service that
causes this issue (e.g. config file was bound to nettcp):
http://github.com/zippy1981/EchoService
Inside the .net service is also a copy of the PHP client.
The .NET code can be compiled on any windows machine with the free IDE
SharpDevelop (http://www.icsharpcode.net/OpenSource/SD/Download/)
I can provide a manually generated wsdl with false endpoints if needed.
I'll gladly help test a fix or provide a mock if needed.
[2010-01-13 20:29:39] srina...@php.net
thanks for the clarification. if you can provide a test case /script ,
it would help us to work on this. thanks again for taking time for
following up on this. your help will definitely help PHP make better !
----------------
[2010-01-13 15:05:54] zippy1981 at gmail dot com
It seems I was not clear in my original ticket.
My soap service has two end points. One is http (soap 1.1). The other
is nettcp, microsoft private protocol.
PHP throws an error when I parse the WSDL simply because it contains
an endpoint it can't connect to. This is in spite of the following
four facts:
1) There is a http endpoint it knows how to connect to in the WSDL
2) I override the WSDL endpoints in the soap constructor.
3) A soap client only needs to connect to one endpoint in a WSDL to
communicate with it
If I manually edit the WSDL so that the nettcp endpoint is no longer
advertised, but it still exists, PHP will connect to it fine.
[2010-01-13 14:41:18] srina...@php.net
as far as I understand, Microsoft TCP transport spec is a private
interface for communicating between .Net server/clients. I would expect
that you will need SOAP/TCP as end point for communicating between php
client and .Net server.
Af course,my knowledge might be outdated on this.
------------
#50804 [NEW]: Documenting configure.js --enable-crt-debug
From: zippy1981 at gmail dot com Operating system: Windows Any PHP version: 5.3.2RC1 PHP Bug Type: *Compile Issues Bug description: Documenting configure.js --enable-crt-debug Description: If you are building on windows and run configure.js with --help one of the options you get is --enable-crt-debugExtra CRT debugging I discovered that meant if an error ocurred in PHP you got a large memory dump (or dump of some kind) printed to stderr. I propose the help message be changed to something more helpful such as: --enable-crt-debugExtra CRT debugging (this produces LARGE memory dumps to stderr) If enable-crt-debug does more than that a note indicating this will produce output most people would find prohibitively verbose should be noted. -- Edit bug report at http://bugs.php.net/?id=50804&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50804&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50804&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50804&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50804&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50804&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50804&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50804&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50804&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50804&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50804&r=support Expected behavior: http://bugs.php.net/fix.php?id=50804&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50804&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50804&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50804&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50804&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50804&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50804&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50804&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50804&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50804&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50804&r=mysqlcfg
#50785 [NEW]: Incorrect handling of SSL in configure.js
From: zippy1981 at gmail dot com Operating system: Windows PHP version: 5.3.1 PHP Bug Type: *Compile Issues Bug description: Incorrect handling of SSL in configure.js Description: If you try to build PHP on windows, and don't have the ssl libraries configure.js will see SSL is missing, but still configure phar to use ssl. As a result nmake will fail. The expected behavior would be to configure phar without ssl. Configure output: Checking for library ssleay32.lib ... Enabling extension ext\phar Native OpenSSL support in Phar enabled -- Edit bug report at http://bugs.php.net/?id=50785&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50785&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50785&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50785&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50785&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50785&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50785&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50785&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50785&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50785&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50785&r=support Expected behavior: http://bugs.php.net/fix.php?id=50785&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50785&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50785&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50785&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50785&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50785&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50785&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50785&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50785&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50785&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50785&r=mysqlcfg
#50698 [Opn]: SoapClient should handle wsdls with some incompatiable endpoints
ID: 50698 User updated by: zippy1981 at gmail dot com Reported By: zippy1981 at gmail dot com Status: Open Bug Type: Feature/Change Request Operating System: Windows XP/7 and probably all. PHP Version: 5.2.12, 5.3.1 New Comment: Thanks for your reply. On my initial report I posted an example client. In a comment in the example client is a link to a github repo with a .NET web service that causes this issue (e.g. config file was bound to nettcp): http://github.com/zippy1981/EchoService Inside the .net service is also a copy of the PHP client. The .NET code can be compiled on any windows machine with the free IDE SharpDevelop (http://www.icsharpcode.net/OpenSource/SD/Download/) I can provide a manually generated wsdl with false endpoints if needed. I'll gladly help test a fix or provide a mock if needed. Previous Comments: [2010-01-13 20:29:39] srina...@php.net thanks for the clarification. if you can provide a test case /script , it would help us to work on this. thanks again for taking time for following up on this. your help will definitely help PHP make better ! [2010-01-13 15:05:54] zippy1981 at gmail dot com It seems I was not clear in my original ticket. My soap service has two end points. One is http (soap 1.1). The other is nettcp, microsoft private protocol. PHP throws an error when I parse the WSDL simply because it contains an endpoint it can't connect to. This is in spite of the following four facts: 1) There is a http endpoint it knows how to connect to in the WSDL 2) I override the WSDL endpoints in the soap constructor. 3) A soap client only needs to connect to one endpoint in a WSDL to communicate with it If I manually edit the WSDL so that the nettcp endpoint is no longer advertised, but it still exists, PHP will connect to it fine. [2010-01-13 14:41:18] srina...@php.net as far as I understand, Microsoft TCP transport spec is a private interface for communicating between .Net server/clients. I would expect that you will need SOAP/TCP as end point for communicating between php client and .Net server. Af course,my knowledge might be outdated on this. [2010-01-12 21:49:27] zippy1981 at gmail dot com Verified on Windows 7 as well. [2010-01-10 22:10:39] zippy1981 at gmail dot com Also verified to break on 5.3.1. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50698 -- Edit this bug report at http://bugs.php.net/?id=50698&edit=1
#50698 [Fbk->Opn]: SoapClient should handle wsdls with some incompatiable endpoints
ID: 50698
User updated by: zippy1981 at gmail dot com
Reported By: zippy1981 at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP/7 and probably all.
PHP Version: 5.2.12, 5.3.1
New Comment:
It seems I was not clear in my original ticket.
My soap service has two end points. One is http (soap 1.1). The other
is nettcp, microsoft private protocol.
PHP throws an error when I parse the WSDL simply because it contains
an endpoint it can't connect to. This is in spite of the following
four facts:
1) There is a http endpoint it knows how to connect to in the WSDL
2) I override the WSDL endpoints in the soap constructor.
3) A soap client only needs to connect to one endpoint in a WSDL to
communicate with it
If I manually edit the WSDL so that the nettcp endpoint is no longer
advertised, but it still exists, PHP will connect to it fine.
Previous Comments:
[2010-01-13 14:41:18] srina...@php.net
as far as I understand, Microsoft TCP transport spec is a private
interface for communicating between .Net server/clients. I would expect
that you will need SOAP/TCP as end point for communicating between php
client and .Net server.
Af course,my knowledge might be outdated on this.
[2010-01-12 21:49:27] zippy1981 at gmail dot com
Verified on Windows 7 as well.
[2010-01-10 22:10:39] zippy1981 at gmail dot com
Also verified to break on 5.3.1.
[2010-01-08 21:52:35] zippy1981 at gmail dot com
I also reported this on stack overflow. If anyone has any suggestions
for workarounds, especially if there workaround on the .NET side feel
free to post them there.
http://stackoverflow.com/questions/1933213/connecting-to-a-wcf-service-
in-php-that-has-a-a-nettcp-binding-and-a-basichttpbin
[2010-01-08 21:19:44] zippy1981 at gmail dot com
Description:
I have a WCF web service written in .NET that has different endpoints.
I
want .NET clients to be able to talk to it using nettcp (a propietary
microsoft protocol) and PHP to be able to talk to it using basicHttp
(soap 1.1). However, if WSDL contains any endpoints other than http or
https endpoints I get the following error:
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
I think the following should occur:
If no endpoint is explicitly specified in the constructor, PHP should
pick the first compatible endpoint available in the wsdl and use it. If
the endpoint is explicitly declared in the constructor, then PHP should
not care about the available endpoints.
Reproduce code:
---
http://github.com/zippy1981/EchoService
$client = new SoapClient
('http://localhost:8731/EchoService/?wsdl',
array(
'location' =>
'http://localhost:8731/EchoService/Basic',
'trace' => true,
'soap_version' => SOAP_1_1,
'connection_timeout' => 5
)
);
echo $client->echo(array('request' => "Hello World"))->EchoResult;
?>
Expected result:
c:\php\php.exe EchoClient.php
Hello World
Actual result:
--
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
--
Edit this bug report at http://bugs.php.net/?id=50698&edit=1
#50698 [Opn]: SoapClient should handle wsdls with some incompatiable endpoints
ID: 50698
User updated by: zippy1981 at gmail dot com
Reported By: zippy1981 at gmail dot com
Status: Open
Bug Type: Feature/Change Request
-Operating System: Windows XP
+Operating System: Windows XP/7 and probably all.
PHP Version: 5.2.12, 5.3.1
New Comment:
Verified on Windows 7 as well.
Previous Comments:
[2010-01-10 22:10:39] zippy1981 at gmail dot com
Also verified to break on 5.3.1.
[2010-01-08 21:52:35] zippy1981 at gmail dot com
I also reported this on stack overflow. If anyone has any suggestions
for workarounds, especially if there workaround on the .NET side feel
free to post them there.
http://stackoverflow.com/questions/1933213/connecting-to-a-wcf-service-
in-php-that-has-a-a-nettcp-binding-and-a-basichttpbin
[2010-01-08 21:19:44] zippy1981 at gmail dot com
Description:
I have a WCF web service written in .NET that has different endpoints.
I
want .NET clients to be able to talk to it using nettcp (a propietary
microsoft protocol) and PHP to be able to talk to it using basicHttp
(soap 1.1). However, if WSDL contains any endpoints other than http or
https endpoints I get the following error:
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
I think the following should occur:
If no endpoint is explicitly specified in the constructor, PHP should
pick the first compatible endpoint available in the wsdl and use it. If
the endpoint is explicitly declared in the constructor, then PHP should
not care about the available endpoints.
Reproduce code:
---
http://github.com/zippy1981/EchoService
$client = new SoapClient
('http://localhost:8731/EchoService/?wsdl',
array(
'location' =>
'http://localhost:8731/EchoService/Basic',
'trace' => true,
'soap_version' => SOAP_1_1,
'connection_timeout' => 5
)
);
echo $client->echo(array('request' => "Hello World"))->EchoResult;
?>
Expected result:
c:\php\php.exe EchoClient.php
Hello World
Actual result:
--
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
--
Edit this bug report at http://bugs.php.net/?id=50698&edit=1
#50698 [Opn]: SoapClient should handle wsdls with some incompatiable endpoints
ID: 50698
User updated by: zippy1981 at gmail dot com
Reported By: zippy1981 at gmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP
-PHP Version: 5.2.12
+PHP Version: 5.2.12, 5.3.1
New Comment:
Also verified to break on 5.3.1.
Previous Comments:
[2010-01-08 21:52:35] zippy1981 at gmail dot com
I also reported this on stack overflow. If anyone has any suggestions
for workarounds, especially if there workaround on the .NET side feel
free to post them there.
http://stackoverflow.com/questions/1933213/connecting-to-a-wcf-service-
in-php-that-has-a-a-nettcp-binding-and-a-basichttpbin
[2010-01-08 21:19:44] zippy1981 at gmail dot com
Description:
I have a WCF web service written in .NET that has different endpoints.
I
want .NET clients to be able to talk to it using nettcp (a propietary
microsoft protocol) and PHP to be able to talk to it using basicHttp
(soap 1.1). However, if WSDL contains any endpoints other than http or
https endpoints I get the following error:
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
I think the following should occur:
If no endpoint is explicitly specified in the constructor, PHP should
pick the first compatible endpoint available in the wsdl and use it. If
the endpoint is explicitly declared in the constructor, then PHP should
not care about the available endpoints.
Reproduce code:
---
http://github.com/zippy1981/EchoService
$client = new SoapClient
('http://localhost:8731/EchoService/?wsdl',
array(
'location' =>
'http://localhost:8731/EchoService/Basic',
'trace' => true,
'soap_version' => SOAP_1_1,
'connection_timeout' => 5
)
);
echo $client->echo(array('request' => "Hello World"))->EchoResult;
?>
Expected result:
c:\php\php.exe EchoClient.php
Hello World
Actual result:
--
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
--
Edit this bug report at http://bugs.php.net/?id=50698&edit=1
#50698 [Opn]: SoapClient should handle wsdls with some incompatiable endpoints
ID: 50698
User updated by: zippy1981 at gmail dot com
Reported By: zippy1981 at gmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
I also reported this on stack overflow. If anyone has any suggestions
for workarounds, especially if there workaround on the .NET side feel
free to post them there.
http://stackoverflow.com/questions/1933213/connecting-to-a-wcf-service-
in-php-that-has-a-a-nettcp-binding-and-a-basichttpbin
Previous Comments:
[2010-01-08 21:19:44] zippy1981 at gmail dot com
Description:
I have a WCF web service written in .NET that has different endpoints.
I
want .NET clients to be able to talk to it using nettcp (a propietary
microsoft protocol) and PHP to be able to talk to it using basicHttp
(soap 1.1). However, if WSDL contains any endpoints other than http or
https endpoints I get the following error:
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
I think the following should occur:
If no endpoint is explicitly specified in the constructor, PHP should
pick the first compatible endpoint available in the wsdl and use it. If
the endpoint is explicitly declared in the constructor, then PHP should
not care about the available endpoints.
Reproduce code:
---
http://github.com/zippy1981/EchoService
$client = new SoapClient
('http://localhost:8731/EchoService/?wsdl',
array(
'location' =>
'http://localhost:8731/EchoService/Basic',
'trace' => true,
'soap_version' => SOAP_1_1,
'connection_timeout' => 5
)
);
echo $client->echo(array('request' => "Hello World"))->EchoResult;
?>
Expected result:
c:\php\php.exe EchoClient.php
Hello World
Actual result:
--
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
--
Edit this bug report at http://bugs.php.net/?id=50698&edit=1
#50698 [NEW]: SoapClient should handle wsdls with some incompatiable endpoints
From: zippy1981 at gmail dot com
Operating system: Windows XP
PHP version: 5.2.12
PHP Bug Type: Feature/Change Request
Bug description: SoapClient should handle wsdls with some incompatiable
endpoints
Description:
I have a WCF web service written in .NET that has different endpoints. I
want .NET clients to be able to talk to it using nettcp (a propietary
microsoft protocol) and PHP to be able to talk to it using basicHttp
(soap 1.1). However, if WSDL contains any endpoints other than http or
https endpoints I get the following error:
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
I think the following should occur:
If no endpoint is explicitly specified in the constructor, PHP should
pick the first compatible endpoint available in the wsdl and use it. If
the endpoint is explicitly declared in the constructor, then PHP should
not care about the available endpoints.
Reproduce code:
---
http://github.com/zippy1981/EchoService
$client = new SoapClient
('http://localhost:8731/EchoService/?wsdl',
array(
'location' => 'http://localhost:8731/EchoService/Basic',
'trace' => true,
'soap_version' => SOAP_1_1,
'connection_timeout' => 5
)
);
echo $client->echo(array('request' => "Hello World"))->EchoResult;
?>
Expected result:
c:\php\php.exe EchoClient.php
Hello World
Actual result:
--
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
--
Edit bug report at http://bugs.php.net/?id=50698&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50698&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50698&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50698&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50698&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50698&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50698&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50698&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50698&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50698&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50698&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50698&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50698&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50698&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50698&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50698&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50698&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50698&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50698&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50698&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50698&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50698&r=mysqlcfg
#43706 [NEW]: MSI installer should set the registry value for IniFilePath on IIS ISAPI instal
From: zippy1981 at gmail dot com Operating system: Windows XP PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: MSI installer should set the registry value for IniFilePath on IIS ISAPI instal Description: When installing on windows with the MSI, and selecting IIS ISAPI as the web server config the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\PHP\IniFilePath" should be set to the install directory. -- Edit bug report at http://bugs.php.net/?id=43706&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43706&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43706&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43706&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43706&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43706&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43706&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43706&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43706&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43706&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43706&r=support Expected behavior:http://bugs.php.net/fix.php?id=43706&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43706&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43706&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43706&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43706&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43706&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43706&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43706&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43706&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43706&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43706&r=mysqlcfg
