#49255 [Opn->Bgs]: PDO fails to insert boolean FALSE to MySQL in prepared statement
ID: 49255 Updated by: sjo...@php.net Reported By: carysmith at creighton dot edu -Status: Open +Status: Bogus Bug Type: PDO related Operating System: Windows 2003 Ent. PHP Version: 5.2.10 New Comment: Marking as bogus, because prepared statements are supposed to work like this. Feel free to contact me if you disagree. Previous Comments: [2009-08-21 11:52:25] sjoerd-php at linuxonly dot nl Thank you for your report. When PDO replaces question marks in execute(), it does not take the type of the columns into account. It thus does not know that the parameter to execute() should be interpreted as a boolean, it simply replaces question marks by strings. Because the string representation of false is the empty string, it replaces the question mark by ''. It makes no sense to change the string representation of false to 0, because that would give problems on other places in PHP. It makes no sense to parse the query to determine the type, as this is very hard to do. To work around this problem, you should convert the boolean value yourself. You can do so like this: $numeric_boolean = (int)$php_boolean; [2009-08-14 15:53:18] carysmith at creighton dot edu Description: Before I report the bug, would just like to say that PDO is excellent and I am enjoying working with it. The Issue: When attempting to insert a Boolean FALSE into a MySQL Boolean column, the insert fails. Inserting a 0 does not. The following example code is borrowed from another post which was similar http://bugs.php.net/bug.php?id=38386 and modified to accommodate how I am using it. Reproduce code: --- prepare( $query); $createStatement->execute(); // Attempt to insert Boolean records into table - (FALSE insert fails without error) $query = 'insert into Testing.test_boolean set TheBoolean = ?;'; $statement = $dbh->prepare( $query); $statement->execute(array(true)); $statement->execute(array(false)); // However by replacing Boolean with integers does work $statement->execute(array(1)); $statement->execute(array(0)); ?> Expected result: 4 rows added to the table: 1 0 1 0 Actual result: -- 3 rows added to the table: 1 1 0 Investigation of the MySQL logs shows the Boolean FALSE is inserted as an empty string '' which fails. Please verify if I am missing something or this cannot be reproduced. In the meantime I am changing the code to use numbers instead of Boolean. -- Edit this bug report at http://bugs.php.net/?id=49255&edit=1
#49333 [Opn]: Bug in recursive regex processing
ID: 49333
Updated by: sjo...@php.net
Reported By: inf3rno dot hu at gmail dot com
Status: Open
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5.2.10
New Comment:
Could not reproduce. When I run the code example you supplied, I get
the expected result. Are you sure you have submitted the right code
example?
Previous Comments:
[2009-08-23 08:10:45] inf3rno dot hu at gmail dot com
Description:
I developed a recursive regex pattern for compile template patterns.
During the tests I found this bug. I managed to restrict it to the
following piece of code.
The count of the numbers, and every character (\n too) counts. So if I
have 11+ characters long string in the 'y'-s block, then it's buggy, but
by 10- character long strings it works fine.
I hope it's a real bug, and not a damage in my computer. :-)
Reproduce code:
---
$pattern='%.*?(?:([a-z])(?:.*?(?:(?R).*?)*?\1)?|$)%sD';
$test='
x
0123456789
x
y
01234567890
y';
preg_match_all($pattern,$test,$matches,PREG_SET_ORDER);
var_dump($matches);
Expected result:
array(3) { [0]=> array(2) { [0]=> string(18) " x 0123456789 x" [1]=>
string(1) "x" } [1]=> array(2) { [0]=> string(19) " y 01234567890 y"
[1]=> string(1) "y" } [2]=> array(1) { [0]=> string(0) "" } }
Actual result:
--
array(0) { }
--
Edit this bug report at http://bugs.php.net/?id=49333&edit=1
#49340 [Opn]: Signals not catcable when certain functions are in execution
ID: 49340 Updated by: sjo...@php.net Reported By: alexmontoanelli at gmail dot com Status: Open Bug Type: PCNTL related Operating System: Linux PHP Version: 5.2.10 New Comment: Thank you for your bug report. I don't fully understand the problem. Is the problem that you have to hit enter for the signal handler to run? Or that the line with 'echo $foo' is ran after the fgets? Previous Comments: [2009-08-23 22:12:28] alexmontoanelli at gmail dot com Description: After executions of certain functions, the handler configured by posix_singal, are not called where the funcion are in execution - like freads. Reproduce code: --- #!/usr/bin/php http://bugs.php.net/?id=49340&edit=1
#49342 [Opn->Bgs]: gnu_cmp doesn't work with decimal strings
ID: 49342
Updated by: sjo...@php.net
Reported By: scott at connerly dot net
-Status: Open
+Status: Bogus
Bug Type: GNU MP related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
Thank you for your bug report.
The documentation on GMP says:
These functions allow you to work with arbitrary-length integers using
the GNU MP library.
Since 2.5 is not an integer, I don't think your example is supposed to
work. Also, I can't find the example on the function.gmp-cmp page, so it
also does not seem an error in the documentation.
Previous Comments:
[2009-08-24 04:36:24] scott at connerly dot net
Description:
gnu_cmp doesn't work with decimal strings
Reproduce code:
---
---
>From manual page: function.gmp-cmp
---
$integers = gmp_cmp('2','5');
$floats = gmp_cmp('2.5','5');
var_dump($integers,$floats);
Expected result:
both should return -1
Actual result:
--
int(-1)
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=49342&edit=1
#49330 [Opn->Bgs]: counter doesn't count properly
ID: 49330
Updated by: sjo...@php.net
Reported By: john at sinteur dot com
-Status: Open
+Status: Bogus
Bug Type: Math related
Operating System: FreeBSD, Mac OS
PHP Version: 5.2.10
New Comment:
Thank you for your report.
The behavior you report is not a bug. If PHP encounters a number beyond
the bounds of the integer type, it will be interpreted as a float
instead. That is why it is possible to have $xxx bigger than
PHP_INT_MAX. Operands of modulus are converted to integers (by stripping
the decimal part) before processing. That is why the $xxx is wrapped
around for the modulo operator.
PHP_INT_MAX % $a == 2147483647 % $a
(PHP_INT_MAX + 1) % $a == -2147483648 % $a
Previous Comments:
[2009-08-22 16:22:33] john at sinteur dot com
Description:
Counting doesn't appear to wrap properly at 32 bits
Reproduce code:
---
$xxx=0;
while (true) {
$xxx++;
if ($xxx%1000 == 0)
print $xxx . "\n";
}
Expected result:
1000
2000
3000
4000
5000
...(etc)
212000
213000
214000
215000
216000
217000
218000
Actual result:
--
1000
2000
3000
4000
5000
...(etc)
212000
213000
214000
2154967296
2164967296
2174967296
2184967296
--
Edit this bug report at http://bugs.php.net/?id=49330&edit=1
#49226 [Opn->Bgs]: SoapServer failing on construction (cannot load wsdl)
ID: 49226
Updated by: sjo...@php.net
Reported By: richard at rjharrison dot org
-Status: Open
+Status: Bogus
Bug Type: SOAP related
Operating System: linux
PHP Version: 5.3.0
New Comment:
Thank you both for your feedback.
SOAP retrieves the WSDL using HTTP/1.0, which does not have chunked
transfers. Therefore, the server should provide a Content-length header.
If it does not do that, SoapServer can not load the WSDL correctly. This
is not a bug in PHP, since the content-length header is mandatory for
HTTP/1.0 messages which have a body.
You could implement/request the feature that PHP can load WSDLs even if
they don't have a content-length header, but it is not a bug in PHP
itself.
Previous Comments:
[2009-08-12 17:24:55] richard at rjharrison dot org
"Its not in the PHP 5.3 release, rather its a bug in the Zend
AutoDiscover class"
If it works fine in 5.2(.6) but not in 5.3 then something changed in
5.3 that made things break, which suggests a bug in 5.3.
If adding a content-length header fixes things then that's great as a
quick-fix, but SoapServer should be able to deal with chunk-encoded
responses which don't, by their nature, have a content-length.
[2009-08-12 14:01:26] stig dot woxholt at fotoknudsen dot no
The service works when using a local file.
I did some more tests, and have identified the actual problem.
Its not in the PHP 5.3 release, rather its a "bug" in the Zend
AutoDiscover class provided by Zend.
I assume the reporter also might be using this to generate the WSDL's
?
I guess that in php 5.3 the soap server expects the content length to
be set in the header inorder to parse the complete wsdl, but the
AutoDiscover class does not send this.
By adding header('Content-Length: '.strlen($this->_wsdl->toXML())); to
the handle function in the AutoDiscover class things are working
I'll report the findings on the Zend bugtracker.
----
[2009-08-12 13:05:41] richard at rjharrison dot org
@sjoerd,
When I load the WSDL over HTTP there is no content-length header, as
the response is sent chunk-encoded. As stated in the original report, if
I save the WSDL to disk then it works, for example:-
http://myserver/path?wsdl');
file_put_contents("wsdl.xml", $data);
$serv = new SoapServer("wsdl.xml"); // works
?>
@stig,
The behaviour you describe with different size WSDL might backup the
theory that it's chunk-encoding related. With a small body size, I think
PHP *does* send a content-length header; but if the body is larger than
the output buffer (?) it will switch to chunk-encoding to allow for the
unknown, variable length.
----
[2009-08-12 11:39:05] sjoerd-php at linuxonly dot nl
Thank you for your bug report.
When you retrieve the WSDL over HTTP, does the Content-Length header
match the length of the WSDL? You can try saving the WSDL to disk and
load that one instead.
[2009-08-12 10:52:46] stig dot woxholt at fotoknudsen dot no
We have started porting our soap services from 5.2.x to 5.3 and see the
same problem here.
I have spend quite some time trying to identify the problem, and it
seemes to me that when the wsdl reaches a certain size it stops
working.
Ie. i have a service with 10 exposed methods. When all these methods
are exposed i get an error, same as Richards. If i cut down on the
number of exposed methods, to ie. 3 on the service it works.
This is services that is used in production on the 5.2.x builds, and
works perfectly there.
Looks to me that there might be a bug in the XML parsing of the WSDL
somewhere.
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/49226
--
Edit this bug report at http://bugs.php.net/?id=49226&edit=1
#49226 [Bgs]: SoapServer failing on construction (cannot load wsdl)
ID: 49226
Updated by: sjo...@php.net
Reported By: richard at rjharrison dot org
Status: Bogus
Bug Type: SOAP related
Operating System: linux
PHP Version: 5.3.0
New Comment:
The specifications you supply do not describe how to retrieve the
WSDL.
In this case, the WSDL is retrieved using HTTP. I don't think it is
specified which HTTP version to use. The SoapServer class uses HTTP 1.0.
If the server serving the WSDL implements HTTP 1.0, it should send a
content-length header. If it does not implement HTTP 1.0, it should send
a 505 HTTP Version Not Supported.
Previous Comments:
[2009-08-24 13:20:41] richard at rjharrison dot org
Sjoerd,
Respectfully, I think you're wrong. I am *far* from being a SOAP
expert, but the specifications for SOAP 1.1[1] and for WSDL[2] both show
use of HTTP 1.1.
1. http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383526
2. http://www.w3.org/TR/wsdl#_http
[2009-08-24 12:51:11] sjo...@php.net
Thank you both for your feedback.
SOAP retrieves the WSDL using HTTP/1.0, which does not have chunked
transfers. Therefore, the server should provide a Content-length header.
If it does not do that, SoapServer can not load the WSDL correctly. This
is not a bug in PHP, since the content-length header is mandatory for
HTTP/1.0 messages which have a body.
You could implement/request the feature that PHP can load WSDLs even if
they don't have a content-length header, but it is not a bug in PHP
itself.
[2009-08-12 17:24:55] richard at rjharrison dot org
"Its not in the PHP 5.3 release, rather its a bug in the Zend
AutoDiscover class"
If it works fine in 5.2(.6) but not in 5.3 then something changed in
5.3 that made things break, which suggests a bug in 5.3.
If adding a content-length header fixes things then that's great as a
quick-fix, but SoapServer should be able to deal with chunk-encoded
responses which don't, by their nature, have a content-length.
[2009-08-12 14:01:26] stig dot woxholt at fotoknudsen dot no
The service works when using a local file.
I did some more tests, and have identified the actual problem.
Its not in the PHP 5.3 release, rather its a "bug" in the Zend
AutoDiscover class provided by Zend.
I assume the reporter also might be using this to generate the WSDL's
?
I guess that in php 5.3 the soap server expects the content length to
be set in the header inorder to parse the complete wsdl, but the
AutoDiscover class does not send this.
By adding header('Content-Length: '.strlen($this->_wsdl->toXML())); to
the handle function in the AutoDiscover class things are working
I'll report the findings on the Zend bugtracker.
----
[2009-08-12 13:05:41] richard at rjharrison dot org
@sjoerd,
When I load the WSDL over HTTP there is no content-length header, as
the response is sent chunk-encoded. As stated in the original report, if
I save the WSDL to disk then it works, for example:-
http://myserver/path?wsdl');
file_put_contents("wsdl.xml", $data);
$serv = new SoapServer("wsdl.xml"); // works
?>
@stig,
The behaviour you describe with different size WSDL might backup the
theory that it's chunk-encoding related. With a small body size, I think
PHP *does* send a content-length header; but if the body is larger than
the output buffer (?) it will switch to chunk-encoding to allow for the
unknown, variable length.
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/49226
--
Edit this bug report at http://bugs.php.net/?id=49226&edit=1
#49346 [Opn->Bgs]: using return() with an empty argument list is causing in a parser error
ID: 49346 Updated by: sjo...@php.net Reported By: mirko dot steiner at slashdevslashnull dot de -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: linux, freebsd PHP Version: 5.2.10 New Comment: Thank you for your report. The behavior you report is not a bug. You call return as if it is a function. It is not, it is a language construct. The correct syntax is: return 'bar'; or return; The parenthesis are not needed. Previous Comments: [2009-08-24 15:20:57] mirko dot steiner at slashdevslashnull dot de Description: using return() with an empty argument list is causing in a parser error. Reproduce code: --- Expected result: no parser error :-) Actual result: -- Parse error: syntax error, unexpected ')' in /usr/local/www/develop/htdocs/test.php on line 6 -- Edit this bug report at http://bugs.php.net/?id=49346&edit=1
#49347 [Opn]: iterating through an array plus creating a refererence to the current element
ID: 49347
Updated by: sjo...@php.net
Reported By: zoli at lippai dot net
Status: Open
Bug Type: Arrays related
Operating System: OS X 10.5.8
PHP Version: 5.3.0
New Comment:
The variable $list has the expected value after the for loop. You can
show this by doing print_r($list). However, the $item in the first for
loop seems to interfere with the $item in the second foreach loop.
Previous Comments:
[2009-08-24 15:44:05] zoli at lippai dot net
Description:
When I iterate through an array with "for" and create a reference to
the current element inside the for, then the last element of the array
will be a reference to the previous element.
If I unset the reference variable at the end of every cycle, then it
works fine.
Reproduce code:
---
1),
array('id' => 2)
);
for($i = 0; $i < count($list); $i++) {
$item = &$list[$i];
$item['someValue'] = 'x';
}
foreach($list as $item)
{
var_dump($item);
}
Expected result:
array(2) {
["id"]=>
int(1)
["someValue"]=>
string(1) "x"
}
array(2) {
["id"]=>
int(2)
["someValue"]=>
string(1) "x"
}
Actual result:
--
array(2) {
["id"]=>
int(1)
["someValue"]=>
string(1) "x"
}
array(2) {
["id"]=>
int(1)
["someValue"]=>
string(1) "x"
}
(Please note the second elements id, which is 1 instead of 2)
--
Edit this bug report at http://bugs.php.net/?id=49347&edit=1
#49226 [Bgs->Fbk]: SoapServer failing on construction (cannot load wsdl)
ID: 49226 Updated by: sjo...@php.net Reported By: richard at rjharrison dot org -Status: Bogus +Status: Feedback Bug Type: SOAP related Operating System: linux PHP Version: 5.3.0 New Comment: PHP 5.3 indeed seems to request the WSDL using HTTP/1.1, I was wrong about that, I'm sorry. However, it works fine with other WSDLs which are sent chunked. There seems to be something special about your setup which triggers this bug. Could you make a dump of the HTTP transaction with a sniffer? Note that you may have to disable the WSDL caching to force SoapServer to get the WSDL over HTTP. Previous Comments: [2009-08-24 17:53:22] richard at rjharrison dot org Ok I understand your point (that the WSDL server is supposedly at fault for not providing an HTTP 1.0 response). I just tested again and watched my Apache access_log. With 5.2.10, the request is sent from SoapServer using HTTP 1.0, and the response from the WSDL server correctly includes a content-length header (and everything works fine). When I test with 5.3, SoapServer sends the request using HTTP 1.1 (according to the Apache log) and the response is chunk-encoded causing SoapServer to error. Therefore I believe that SoapServer in 5.3 is sending an HTTP 1.1 request but is unable to process an HTTP 1.1 response. [2009-08-24 16:49:16] sjo...@php.net The specifications you supply do not describe how to retrieve the WSDL. In this case, the WSDL is retrieved using HTTP. I don't think it is specified which HTTP version to use. The SoapServer class uses HTTP 1.0. If the server serving the WSDL implements HTTP 1.0, it should send a content-length header. If it does not implement HTTP 1.0, it should send a 505 HTTP Version Not Supported. [2009-08-24 13:20:41] richard at rjharrison dot org Sjoerd, Respectfully, I think you're wrong. I am *far* from being a SOAP expert, but the specifications for SOAP 1.1[1] and for WSDL[2] both show use of HTTP 1.1. 1. http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383526 2. http://www.w3.org/TR/wsdl#_http [2009-08-24 12:51:11] sjo...@php.net Thank you both for your feedback. SOAP retrieves the WSDL using HTTP/1.0, which does not have chunked transfers. Therefore, the server should provide a Content-length header. If it does not do that, SoapServer can not load the WSDL correctly. This is not a bug in PHP, since the content-length header is mandatory for HTTP/1.0 messages which have a body. You could implement/request the feature that PHP can load WSDLs even if they don't have a content-length header, but it is not a bug in PHP itself. [2009-08-12 17:24:55] richard at rjharrison dot org "Its not in the PHP 5.3 release, rather its a bug in the Zend AutoDiscover class" If it works fine in 5.2(.6) but not in 5.3 then something changed in 5.3 that made things break, which suggests a bug in 5.3. If adding a content-length header fixes things then that's great as a quick-fix, but SoapServer should be able to deal with chunk-encoded responses which don't, by their nature, have a content-length. 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/49226 -- Edit this bug report at http://bugs.php.net/?id=49226&edit=1
#49262 [Opn->Fbk]: PDO MySQL doesn't take STRING params
ID: 49262
Updated by: sjo...@php.net
Reported By: grzegorz at heex dot pl
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Win XP Sp3
PHP Version: 5.3.0
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Previous Comments:
[2009-08-14 20:23:43] grzegorz at heex dot pl
Description:
Now, PDO in PHP 5.3 is usless.
Reproduce code:
---
$name = 'same_name';
$pdo= new
PDO("mysql:host=localhost;dbname=[base];",'[user]','[pass]');
$sth = $pdo->prepare("SELECT * FROM lng WHERE lng_name=:Name");
$sth->bindValue(':Name',$name,PDO::PARAM_STR);
$sth->execute();
die('OK');
Expected result:
OK
Actual result:
--
PHP CGI / FastCGI crash
--
Edit this bug report at http://bugs.php.net/?id=49262&edit=1
#48847 [Opn->Fbk]: debug_backtrace() doesn't reference arguments in stack in some cases
ID: 48847 Updated by: sjo...@php.net Reported By: an0nym at narod dot ru -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.2.10, 5.3.0 New Comment: Thank you for your bug report. Why do you think it should be possible what you are trying to do? The documentation for debug_backtrace does not describe that it returns a reference. I am surprised that it is possible to change function parameters in the error handler, and I don't think it is supported behavior. Previous Comments: [2009-07-08 08:00:43] an0nym at narod dot ru Description: When argument of function or method is defined with type declaration and default value and is called with some value of this argument, debug_backtrace() doesn't reference this argument of function in stack. When function definition is the same except argument doesn't have default value, everything goes normal. Reproduce code: --- Expected result: bool(false) bool(true) bool(false) bool(true) Actual result: -- bool(false) bool(true) bool(true) bool(false) -- Edit this bug report at http://bugs.php.net/?id=48847&edit=1
#48667 [Opn->Ver]: "could not implement" - NOT redefining functions
ID: 48667
Updated by: sjo...@php.net
Reported By: uramihsayibok at gmail dot com
-Status: Open
+Status: Verified
Bug Type: SPL related
Operating System: Windows XP
PHP Version: 5.2.10
New Comment:
Reproducable and strange. Error is also not very descriptive.
Previous Comments:
[2009-06-23 22:14:17] uramihsayibok at gmail dot com
Description:
When trying to make a class that implements IteratorAggregate and SPL's
SeekableIterator the order of the interfaces in the list matters. One
order (IA first SI second) works while the other (SI first IA second)
produces a fatal error in Unknown.
THESE TWO INTERFACES ARE SEPARATE AND DISTINCT - NO FUNCTIONS IN
COMMON!
Traversable -> Iterator -> SeekableIterator
(seek,current,next,key,valid,rewind)
Traversable -> IteratorAggregate (getIterator)
I haven't been able to reproduce this with user-defined interfaces and
I haven't gone looking to see if this happens with any other built-in
interfaces.
Something to do with that fact that they redefine how iteration on a
class works?
Reproduce code:
---
#1 (works)
abstract class Foo1 implements IteratorAggregate, SeekableIterator {}
#2 (does not work)
abstract class Foo2 implements SeekableIterator, IteratorAggregate {}
Expected result:
#1 and #2 should both work or both not work.
In this case, work, since neither have any functions in common to
redefine.
Actual result:
--
#1 - okay
#2 - "Fatal error: Class Foo2 could not implement interface
IteratorAggregate in Unknown on line 0"
--
Edit this bug report at http://bugs.php.net/?id=48667&edit=1
#48607 [Opn]: fwrite() doesn't check reply from ftp server before exiting
ID: 48607 Updated by: sjo...@php.net Reported By: karachi at mail dot ru Status: Open Bug Type: Streams related Operating System: FreeBSD PHP Version: 5.2.10 New Comment: You can use a pastebin or e-mail it to sjoerd-php at linuxonly dot nl. Previous Comments: [2009-08-18 16:24:58] karachi at mail dot ru I mean I captured data but I can't attach them to the bug [2009-08-18 16:23:58] karachi at mail dot ru Where can I save captured ftp data? [2009-08-13 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-08-05 21:57:24] j...@php.net Yes, we really need more info about this. [2009-06-26 20:24:14] sjoerd-php at linuxonly dot nl Thank you for your bug report. To further investigate this bug, it would be useful if you can supply some more information. Specifically, the data sent from and to the FTP server would be useful. You can obtain this with a sniffer such as tcpdump or Wireshark or maybe by configuring your FTP server. You would be looking for something like this: 230 Anonymous access granted, restrictions apply. SIZE test_file 550 test_file: No such file or directory EPSV 229 Entering Extended Passive Mode (|||3110|) STOR /test_file 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/48607 -- Edit this bug report at http://bugs.php.net/?id=48607&edit=1
#49358 [Opn->Bgs]: MySQLi extension fails to recognize POINT (spatial) colums
ID: 49358
Updated by: sjo...@php.net
Reported By: phpbug at r-o-b-e-r-t dot de
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: Debian/Ubuntu/Gentoo
PHP Version: 5.2.10
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Previous Comments:
[2009-08-25 14:55:29] phpbug at r-o-b-e-r-t dot de
Description:
As reported in Bug "#37671 MySQLi extension fails to recognize BIT
colums" I have the same problem with a Spatial Column.
The Column coord is a POINT Field.
Reproduce code:
---
Here is the Table-Definition:
CREATE TABLE `user` (
`coord` point default NULL,
) ENGINE=InnoDB
The Test Code:
// $mysqli is an existing db connection
$stmt = $mysqli->prepare("SELECT coord FROM user");
$stmt->execute();
$stmt->bind_result($res);
while ($stmt->fetch() === true ) {
debug_zval_dump($res);
var_dump($res);
}
$stmt->close();
Expected result:
The binary representation of the point
Actual result:
--
The Output is the same as the BIT-Field Problem (#37671)
Warning: mysqli_stmt::bind_result(): Server returned unknown type 255.
Probably your client library is incompatible with the server version you
use! in /home/robert/tmp/test.php on line 11
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
--
Edit this bug report at http://bugs.php.net/?id=49358&edit=1
#49359 [Opn->Bgs]: MySQLi extension fails to recognize POINT (spatial) colums
ID: 49359
Updated by: sjo...@php.net
Reported By: bugs at r-o-b-e-r-t dot de
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: Debian/Ubuntu/Gentoo
PHP Version: 5.2.10
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Previous Comments:
[2009-08-25 14:55:52] bugs at r-o-b-e-r-t dot de
Description:
As reported in Bug "#37671 MySQLi extension fails to recognize BIT
colums" I have the same problem with a Spatial Column.
The Column coord is a POINT Field.
Reproduce code:
---
Here is the Table-Definition:
CREATE TABLE `user` (
`coord` point default NULL,
) ENGINE=InnoDB
The Test Code:
// $mysqli is an existing db connection
$stmt = $mysqli->prepare("SELECT coord FROM user");
$stmt->execute();
$stmt->bind_result($res);
while ($stmt->fetch() === true ) {
debug_zval_dump($res);
var_dump($res);
}
$stmt->close();
Expected result:
The binary representation of the point
Actual result:
--
The Output is the same as the BIT-Field Problem (#37671)
Warning: mysqli_stmt::bind_result(): Server returned unknown type 255.
Probably your client library is incompatible with the server version you
use! in /home/robert/tmp/test.php on line 11
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
--
Edit this bug report at http://bugs.php.net/?id=49359&edit=1
#49360 [Opn->Bgs]: MySQLi extension fails to recognize POINT (spatial) colums
ID: 49360
Updated by: sjo...@php.net
Reported By: bugs at r-o-b-e-r-t dot de
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: Debian/Ubuntu/Gentoo
PHP Version: 5.2.10
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Previous Comments:
[2009-08-25 14:59:03] bugs at r-o-b-e-r-t dot de
Description:
As reported in Bug "#37671 MySQLi extension fails to recognize BIT
colums" I have the same problem with a Spatial Column.
The Column coord is a POINT Field.
Reproduce code:
---
Here is the Table-Definition:
CREATE TABLE `user` (
`coord` point default NULL,
) ENGINE=InnoDB
The Test Code:
// $mysqli is an existing db connection
$stmt = $mysqli->prepare("SELECT coord FROM user");
$stmt->execute();
$stmt->bind_result($res);
while ($stmt->fetch() === true ) {
debug_zval_dump($res);
var_dump($res);
}
$stmt->close();
Expected result:
The binary representation of the point
Actual result:
--
The Output is the same as the BIT-Field Problem (#37671)
Warning: mysqli_stmt::bind_result(): Server returned unknown type 255.
Probably your client library is incompatible with the server version you
use! in /home/robert/tmp/test.php on line 11
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
--
Edit this bug report at http://bugs.php.net/?id=49360&edit=1
#42528 [Opn->Bgs]: Out of "char"(8-bit) range value doesn't roll back, with uni-code ON.
ID: 42528 Updated by: sjo...@php.net Reported By: mahesh dot vemula at in dot ibm dot com -Status: Open +Status: Bogus -Bug Type: Performance problem +Bug Type: *Unicode Issues Operating System: RHEL4 PHP Version: 6CVS-2007-09-03 (CVS) New Comment: Thank you for your bug report. In unicode, characters and bytes do not map one-on-one. That means that the codepoint for a character may be bigger than 256. The ord() function returns the numerical value for the codepoint, which may be bigger than 256. It should not wrap around as you describe. Previous Comments: [2007-09-07 12:30:28] mahesh dot vemula at in dot ibm dot com Samething is happening for strncasecmp() function also. [2007-09-03 11:53:31] mahesh dot vemula at in dot ibm dot com Description: The character(8-bit) range of value does not roll back to the corresponding minimum value, once the value reaches beyond the range of a char(8-bit) that it can hold, when Unicode is ON. Reproduce code: --- --TEST-- --FILE-- --EXPECTF-- Expected result: unicode(8) "" unicode(1) "0" unicode(1) "1" Actual result: -- unicode(8) "" unicode(9) "1" unicode(9) "10001" -- Edit this bug report at http://bugs.php.net/?id=42528&edit=1
#48607 [Opn->Ver]: fwrite() doesn't check reply from ftp server before exiting
ID: 48607 Updated by: sjo...@php.net Reported By: karachi at mail dot ru -Status: Open +Status: Verified Bug Type: Streams related Operating System: FreeBSD PHP Version: 5.2.10 New Comment: I could reproduce the QUIT before the transfer being complete. FTP Request: STOR /a.php FTP Response: 150 Opening BINARY mode data connection for /a.php FTP Request: QUIT FTP Response: 226 Transfer complete Previous Comments: [2009-08-25 08:28:23] sjo...@php.net You can use a pastebin or e-mail it to sjoerd-php at linuxonly dot nl. [2009-08-18 16:24:58] karachi at mail dot ru I mean I captured data but I can't attach them to the bug [2009-08-18 16:23:58] karachi at mail dot ru Where can I save captured ftp data? [2009-08-13 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-08-05 21:57:24] j...@php.net Yes, we really need more info about this. 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/48607 -- Edit this bug report at http://bugs.php.net/?id=48607&edit=1
#48607 [Ver]: fwrite() doesn't check reply from ftp server before exiting
ID: 48607
Updated by: sjo...@php.net
Reported By: karachi at mail dot ru
Status: Verified
Bug Type: Streams related
Operating System: FreeBSD
PHP Version: 5.2.10
New Comment:
The solution may be something like this, although this may break things
when the current transaction is not about to send a 226 Transfer
complete.
Index: ext/standard/ftp_fopen_wrapper.c
===
--- ext/standard/ftp_fopen_wrapper.c(revision 287652)
+++ ext/standard/ftp_fopen_wrapper.c(working copy)
@@ -97,7 +97,16 @@
*/
static int php_stream_ftp_stream_close(php_stream_wrapper *wrapper,
php_stream *stream TSRMLS_DC)
{
+ int result;
+ char tmp_line[512];
+
php_stream *controlstream = (php_stream *)stream->wrapperdata;
+
+ result = GET_FTP_RESULT(controlstream);
+ if (result != 226 && result != 250) {
+ // Maybe throw a warning?
+ return 1;
+ }
if (controlstream) {
php_stream_write_string(controlstream, "QUIT\r\n");
Previous Comments:
[2009-08-25 16:33:02] sjo...@php.net
I could reproduce the QUIT before the transfer being complete.
FTP Request: STOR /a.php
FTP Response: 150 Opening BINARY mode data connection for /a.php
FTP Request: QUIT
FTP Response: 226 Transfer complete
[2009-08-25 08:28:23] sjo...@php.net
You can use a pastebin or e-mail it to sjoerd-php at linuxonly dot nl.
[2009-08-18 16:24:58] karachi at mail dot ru
I mean I captured data but I can't attach them to the bug
[2009-08-18 16:23:58] karachi at mail dot ru
Where can I save captured ftp data?
[2009-08-13 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
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/48607
--
Edit this bug report at http://bugs.php.net/?id=48607&edit=1
#47977 [Opn->Fbk]: bindParam, current(), next()
ID: 47977
Updated by: sjo...@php.net
Reported By: fhgvbrdyftgjhgtfr at gazeta dot pl
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Unix
PHP Version: 5.2.9
New Comment:
Thank you for your bug report.
Although you supplied code to reproduce the problem, it is more
complicated and longer than necessary. Please supply a short, complete
and understandable piece of code to reproduce the problem. This is to
make sure the problem is with PHP and not with the example.
Previous Comments:
[2009-05-16 01:20:50] fhgvbrdyftgjhgtfr at gazeta dot pl
true, 'de'=>true);
$array = array_diff($array2, array_keys($array3));
reset($array);
$size = count($array);
$in = '?';
for($i = 1; $i < $size; ++$i) $in .= ', ?';
$stmt = $db->prepare('SELECT `name` FROM `table` WHERE `language` = ?
AND `code` IN('.$in.')');
$stmt->bindValue(1, 'en', PDO::PARAM_STR);
$i = 1;
$element = current($array);
do {
$stmt->bindParam(++$i, $element, PDO::PARAM_STR);
} while(($element = next($array)) !== false);
$stmt->execute();
var_dump($stmt->fetchAll());
?>
-
expected result:
array(3) {
[0]=>
array(2) {
["name"]=>
string(4) "test"
[0]=>
string(4) "test"
}
[1]=>
array(2) {
["name"]=>
string(4) "test"
[0]=>
string(4) "test"
}
[2]=>
array(2) {
["name"]=>
string(4) "test"
[0]=>
string(4) "test"
}
}
actual result:
array(0) {
}
db:
CREATE TABLE IF NOT EXISTS `table` (
`name` varchar(45) NOT NULL,
`language` enum('en','fr') NOT NULL,
`code` char(2) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO `table` (`name`, `language`, `code`) VALUES
('test', 'en', 'gb'),
('test', 'en', 'nz'),
('test', 'en', 'us'),
('test', 'en', 'cz');
[2009-05-08 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-04-30 10:47:04] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-04-16 00:22:47] fhgvbrdyftgjhgtfr at gazeta dot pl
Description:
bindParam doesn't work with vars returned by current(), next()
Reproduce code:
---
prepare('SELECT `name` FROM `table` WHERE `language` = ?
AND `code` IN('.$in.')');
$stmt->bindValue(1, 'en', PDO::PARAM_STR, 2);
$i = 1;
$element = current($array);
do {
$stmt->bindParam(++$i, $element, PDO::PARAM_STR, 2);
} while(($element = next($array)) !== false);
Expected result:
SELECT `name` FROM `table` WHERE `language` = 'en' AND `code` IN('us',
'gb', 'nz')
Actual result:
--
SELECT `name` FROM `table` WHERE `language` = 'en' AND `code` IN('0',
'0', '0')
When i change
$stmt->bindParam(++$i, $element, PDO::PARAM_STR, 2);
to
$stmt->bindValue(++$i, $element, PDO::PARAM_STR, 2);
i get:
SELECT `name` FROM `table` WHERE `language` = 'en' AND `code` IN('us',
'gb', 'nz')
--
Edit this bug report at http://bugs.php.net/?id=47977&edit=1
#49388 [Opn->Ver]: magic_quotes_gpc=on produces deprecated msg on CLI even if error_reporting=0
ID: 49388 Updated by: sjo...@php.net Reported By: romanf at trash dot net -Status: Open +Status: Verified Bug Type: Output Control Operating System: OpenSuse 11 PHP Version: 5.3.0 New Comment: Thank you for your bug report. I could reproduce your problem with the following command: php -d 'error_reporting=0' -d 'magic_quotes_gpc=on' -r '' It seems that PHP is not yet initialized when the warning is triggered. When it is not initialized it prints all warnings without taking error_reporting into account (module_initialized is 0 on main/main.c:920). Previous Comments: [2009-08-27 14:14:49] romanf at trash dot net Description: I have a php.ini with error_reporting=0 magic_quotes_gpc=on If I run a test-script on the CLI, the deprecated warning is still shown on stderr. When run under a webserver (e.g. apache) no output is produced. Expected result: Deprecated warning should be suppressed on CLI as well if error_reporting=0. Actual result: -- Deprecated warning is NOT suppressed on CLI (and only on CLI) if magic_quotes_gpc=on regardless of error_reporting. -- Edit this bug report at http://bugs.php.net/?id=49388&edit=1
#49387 [Opn->Fbk]: E_DEPRECATED looks like a fatal error, even off
ID: 49387 Updated by: sjo...@php.net Reported By: fernando dot wendt at gmail dot com -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Windows XP PHP Version: 5.3.0 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2009-08-27 12:53:36] fernando dot wendt at gmail dot com Description: PHP is ignoring the php.ini error_reporting configuration, and is always hangin up scripts with the E_DEPRACATED message. The default error_reporting = E_ALL & ~E_DEPRACATED is not working. All depracated warnings are working as fatal errors, and i believe that was not the intention it supposed to do. The only way to avoid this (at least on my workaround) is setting up the display_errors = Off (even on my workstation). Reproduce code: --- Try some script that have depracated function or issue to work. It will freeze as a fatal error, pointing a depracated message. Expected result: First, it should respect the php.ini ~E_DEPRECATED flag and then show deprecated issues as warnings, not as fatal errors. Actual result: -- php.ini ~E_DEPRECATED is not working: his behavior looks like a fatal error, and is not being respected if is on or off. -- Edit this bug report at http://bugs.php.net/?id=49387&edit=1
#49361 [Opn->Ver]: wordwrap works incorrectly
ID: 49361
Updated by: sjo...@php.net
Reported By: code-it at mail dot ru
-Status: Open
+Status: Verified
Bug Type: Strings related
Operating System: *
PHP Version: 5.3.0
New Comment:
Thank you for your bug report.
Your report is too long and too hard to understand. However, I did the
best I could to make a simple script which reproduces the problem you
describe and is more like real-life usage of wordwrap.
Expected:
The quick brown fox just
jumped over the lazy dog
which laid on the ground
Actual:
The quick brown fox just
jumped over the lazy
dog
which laid on the
ground
Previous Comments:
[2009-08-25 15:58:31] code-it at mail dot ru
Description:
wordwrapping suppose that
wordwrap(wordwrap($s,$n,$d),$n,$d) is equal to wordwrap($s,$n,$d) and
yes, sometimes php works that way:
$s0 = 'a a a a a a a a';
$s1 = wordwrap($s0,7,'XX');
$s2 = wordwrap($s1,7,'XX');
gives $s1==$s2=='a a a aXXa a a a'
but if we add an extra space to the end of $s0, the result will be
'a a a aXXa a a aXX' != 'a a a aXXa a aXXaXX'
if we construct $s0 as (a )+a? we get $s1!=$s2 if and only if
strlen($s0)%8==0. more, the diff between $s1 and $s2 every time is the
same: trailing 'XXaXX' in $s2 instead of ' aXX' in $s1.
now lets take a look at the case of 1-char-length thing as the 3rd
argument to wordwrap
$s0 = 'a a a a a a a a a a a'; // as above, $s0 is constructed as (a
)+a?
$s1 = wordwrap($s0,5,'X');
$s2 = wordwrap($s1,5,'X');
here we only get $s1==$s2 having strlen($s0)<11!
this bug is related to line 828 in
/php-src/branches/PHP_5_3/ext/standard/string.c?revision=287264:
current line: laststart = lastspace = current;
should be: laststart = lastspace = current+1;
+1 is obviuos: if we found a breakchar in the string, we can forget
about everything to the left of it INCLUDING itself and restart the
whole algorythm at the NEXT character as the first character in our new
string. so the very first `laststart = lastspace = 0;` to start becomes
`laststart = lastspace = current+1;` to restart. this patch completely
removes the strange behaviour.
when strlen(3rd argument to wordwrap)>1 another section of code works
and the above patch doesnt affect it
Reproduce code:
---
FAIL\n";
}
if ($k==$n) {
echo "passed all, no fails\n";
}
}
f(5,'X',20);
f(7,'XX',50);
?>
Expected result:
$len=5, $breakstr='X', $n=20 ---
passed all, no fails
$len=7, $breakstr='XX', $n=50 ---
passed all, no fails
Actual result:
--
$len=5, $breakstr='X', $n=20 ---
strlen($s0)=11 -> FAIL
strlen($s0)=12 -> FAIL
strlen($s0)=13 -> FAIL
strlen($s0)=14 -> FAIL
strlen($s0)=15 -> FAIL
strlen($s0)=16 -> FAIL
strlen($s0)=17 -> FAIL
strlen($s0)=18 -> FAIL
strlen($s0)=19 -> FAIL
strlen($s0)=20 -> FAIL
$len=7, $breakstr='XX', $n=50 ---
strlen($s0)=8 -> FAIL
strlen($s0)=16 -> FAIL
strlen($s0)=24 -> FAIL
strlen($s0)=32 -> FAIL
strlen($s0)=40 -> FAIL
strlen($s0)=48 -> FAIL
--
Edit this bug report at http://bugs.php.net/?id=49361&edit=1
#49393 [Opn->Fbk]: Comment Block exiting prematurally
ID: 49393
Updated by: sjo...@php.net
Reported By: mudoch at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Win XPsp3
PHP Version: 5.3.0
New Comment:
Thank you for your bug report.
I was unable to reproduce the bug you described. Are you sure there is
no ?> somewhere in the comment? Did you supplied the right example code?
Is there some non-ASCII character in your file? It may help us if you
put the file up for download somewhere.
Previous Comments:
[2009-08-27 19:00:02] mudoch at gmail dot com
Description:
The comment block /* ... */ will exit at the first > in the block
verses the action in 5.2.5 where the code was written and tested.
Reproduce code:
---
= 2.1
* @package barcode-mribti
* @copyright 2001 Karim Mribti
* @see image.php
* @version $Id$
*
* barcode site home page
* Adapted from 0.0.7a on 2007-05-24 by Frédéric G. MARAND for Agorus
S.A.
*
* May2009 Lawrence Sall - modified for a cleaner fit, adjust util.php
for
* desired defaults.
*
*
*/
include("home.php");
?>
Expected result:
Page in home.php to be displayed
Actual result:
--
= 2.1 * @package barcode-mribti * @copyright 2001 Karim Mribti * @see
image.php * @version $Id$ * * barcode site home page * Adapted from
0.0.7a on 2007-05-24 by Frédéric G. MARAND for Agorus S.A. * * May2009
Lawrence Sall - modified for a cleaner fit, adjust util.php for *
desired defaults. * * */ include("home.php"); ?>
--
Edit this bug report at http://bugs.php.net/?id=49393&edit=1
#49340 [Opn]: Signals not catchable when certain functions are in execution
ID: 49340 Updated by: sjo...@php.net Reported By: alexmontoanelli at gmail dot com Status: Open Bug Type: PCNTL related Operating System: Linux PHP Version: 5.2.10 New Comment: PHP signals are implemented with ticks (http://us3.php.net/manual/en/control-structures.declare.php). Ticks are events that occur every so much statements in a script. Since fgets() blocks, no more statements are executed and no more ticks are fired. This means that no signal arrives. I do not know whether the current behavior is by design or by mistake, so I cannot determine whether it is a bug or not. It would certainly be desirable to be able to interrupt a blocking read by doing Ctrl-C. Previous Comments: [2009-08-27 11:28:41] alexmontoanelli at gmail dot com some position ? [2009-08-24 13:04:08] alexmontoanelli at gmail dot com Where I say: 'There is true?', is 'That's true?' Regards [2009-08-24 11:41:59] alexmontoanelli at gmail dot com The problem is that I need hit enter - exit from fgets - to run the signal handler - but this is not the correct way - in python for example, the signal handler are calling when the function are waiting for a user input. I found this page - http://br2.php.net/manual/en/function.pcntl-signal.php - the commentary above: '28-Mar-2006 07:26 Process handling is not available when using a blocking socket! Bear this in mind.' There is true? Regards [2009-08-24 08:54:42] sjo...@php.net Thank you for your bug report. I don't fully understand the problem. Is the problem that you have to hit enter for the signal handler to run? Or that the line with 'echo $foo' is ran after the fgets? [2009-08-23 22:12:28] alexmontoanelli at gmail dot com Description: After executions of certain functions, the handler configured by posix_singal, are not called where the funcion are in execution - like freads. Reproduce code: --- #!/usr/bin/php http://bugs.php.net/?id=49340&edit=1
#49348 [Opn->Ver]: Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!)
ID: 49348 Updated by: sjo...@php.net Reported By: BelStudent at yandex dot ru -Status: Open +Status: Verified Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.*, 6 New Comment: In _get_zval_cv_lookup(), type is BP_VAR_W, while it should be BP_VAR_RW for the example code. Previous Comments: [2009-08-25 08:18:09] j...@php.net Reopened, Gwynne's arguments are rock solid. :) [2009-08-25 07:13:46] gwy...@php.net Actually, this is a valid problem; the problem described by bug #21008 is a different issue. There seems to be some confusion as to whether it should be fixed or not, but it's neither a duplicate nor bogus. Specifically, bug #21008 describes an issue with setting a variable to a value, where this report describes an issue with updating a variable. These are two distinct operations, and are handled differently. More to the point, the following code throws a notice: That the code described by this bug doesn't is an inconsistency. [2009-08-24 16:21:58] BelStudent at yandex dot ru Description: Usually, if you try to do this: ++$num, then thrown notice, that the "Undefined variable: num". This helps avoid errors. But if you have class and you're trying to do so ++$this->num num nowhere and had not previously identified, then the issue no warnings and notices. Accidentally deleted in the symbol and received ++$this->nu, and then climbed into hell knows what mistakes to find this place and correct to ++$this->num took several hours. So I am very concerned about the issue: how to do so were given notice, if you try to do something with uninitialized (unknown) variable in the class? Reproduce code: --- num; } } new A(); ?> Expected result: Undefined property: A::$num Actual result: -- empty -- Edit this bug report at http://bugs.php.net/?id=49348&edit=1
#49244 [Opn->Ver]: Floating point NaN cause garbage characters
ID: 49244
Updated by: sjo...@php.net
Reported By: ronlentjes at yahoo dot com dot au
-Status: Open
+Status: Verified
Bug Type: Scripting Engine problem
Operating System: Linux Fedora 8
PHP Version: 5.3.0
Previous Comments:
[2009-08-20 19:19:13] sjoerd-php at linuxonly dot nl
The problem is with calling php_sprintf_appendstring. Its 9th parameter
is not precision, it is length.
Index: ext/standard/formatted_print.c
===
--- ext/standard/formatted_print.c (revision 287513)
+++ ext/standard/formatted_print.c (working copy)
@@ -232,14 +232,14 @@
if (zend_isnan(number)) {
is_negative = (number<0);
php_sprintf_appendstring(buffer, pos, size, "NaN", 3, 0,
padding,
-alignment,
precision, is_negative, 0, always_sign);
+alignment, 3,
is_negative, 0, always_sign);
return;
}
if (zend_isinf(number)) {
is_negative = (number<0);
php_sprintf_appendstring(buffer, pos, size, "INF", 3, 0,
padding,
-alignment,
precision, is_negative, 0, always_sign);
+alignment, 3,
is_negative, 0, always_sign);
return;
}
----
[2009-08-20 11:15:47] sjoerd-php at linuxonly dot nl
Could reproduce with PHP 5.2.10.
[2009-08-14 04:25:22] ronlentjes at yahoo dot com dot au
Perhaps you test it differently than I do. I'll give you the easiest
way to see it happen:
put this in a file called test.php:
---
---
Output will be (bash, Fedora 8, Linux):
# php test.php
---
NaN*A
---
Output for browser will be NaN??? or NaN???F or other variations of
that.
This is reporducable on versions 4.2.2 (crash), 5.2.4, 5.3.0 (as
indicated previously).
I just retried this now.
Cheers,
Ron Lentjes
LC CLS.
[2009-08-13 14:29:39] ras...@php.net
I am unable to reproduce this in neither 5.2 nor 5.3, and Valgrind is
clean on Debian.
[2009-08-13 14:14:51] ronlentjes at yahoo dot com dot au
Description:
This has been an issue since 4.2.2 and still in 5.3.0.
$d = pow (-1.0, 0.3); // or anything causing NaN
echo "$d\n";
-> NAN
printf ("%f\n", $d);
(4.2.2) -> crash
(5.2.4) -> NaN
(5.3.0) -> NaN
(viewed in browser as NaN???)
Two issues here:
Inconsistent display of NAN for echo and NaN for printf.
Output of bogus characters after the 3 letters NaN for printf.
I think you are missing a '\0' null termination after the NaN
characters which probably cause a runaway to crash 4.2.2 but is just
'hanging' in there for the newer versions.
Cheers,
Ron Lentjes
LC CLS.
Reproduce code:
---
$d = pow (-1.0, 0.3);
echo "$d\n";
printf ("%f\n", $d);
Expected result:
NaN
NaN
Actual result:
--
(4.2.2)
NAN
crash
(5.2.4)
NAN
NaN
(5.3.0)
NAN
NaN
(viewed in browser as NaN???)
--
Edit this bug report at http://bugs.php.net/?id=49244&edit=1
#49397 [Opn->Fbk]: SoapClient Error
ID: 49397
Updated by: sjo...@php.net
Reported By: persiancity at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: Windows
PHP Version: 5.3.0
New Comment:
Thank you for your bug report.
The problem you describe looks similar to bug #49226. Does it work
correctly if you save the WSDL to disk before loading it? Could you make
a dump of the HTTP connection with a sniffer?
Previous Comments:
[2009-08-28 09:49:21] persiancity at gmail dot com
Description:
I get thos error on PHP5.3 on Windows when try to use SoapClient. There
is not error for same code in PHP 5.2 and above.
Reproduce code:
---
$client = new SoapClient('http://efyek.com/ws/pws.php?wsdl');
Actual result:
--
Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't
load from 'http://efyek.com/ws/pws.php?wsdl' : Extra content at the end
of the document in class.p24.php:39 Stack trace: #0 class.p24.php(39):
SoapClient->SoapClient('http://efyek.co...') #1 indexall.php(38):
p24Class->connect() #2 {main} thrown in class.p24.php on line 39
--
Edit this bug report at http://bugs.php.net/?id=49397&edit=1
#49423 [Fbk]: fwrite doesn't send "REGISTER" to udp port 5060
ID: 49423
Updated by: sjo...@php.net
Reported By: david dot schueler at wapkamera dot de
Status: Feedback
Bug Type: Streams related
Operating System: Gentoo Linux
PHP Version: 5.2.10
New Comment:
Thank you for your report.
I could not reproduce your problem. You say it only fails to send
something if port 5060 is used. This leads me to think this issue is
specific to your computer. Maybe another program is running on port
5060, or a firewall has blocked this port. How do you determine whether
the packet is sent?
Previous Comments:
[2009-08-31 15:50:41] j...@php.net
And I guess you wanted to send the \r\n as line feed/break instead of
literal \r\n ? If so, you should put double quotes around the text..
[2009-08-31 15:46:53] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works fine for me. fwrite() returns int(13).
[2009-08-31 13:22:55] david dot schueler at wapkamera dot de
Description:
If i execute the script below, it will not send the text "REGISTER"
over UDP. If the text is prepended with any other character or sent to
another port it will be transmitted successful.
Reproduce code:
---
array("bindto" => "0:5050")); // set source
port = 5050
$context = stream_context_create($opts);
$socket = stream_socket_client("udp://127.0.0.1:5060", $errno, $error,
30, STREAM_CLIENT_CONNECT, $context);
fwrite($socket,'REGISTER \r\n');
?>
Expected result:
The text "REGISTER" followed by a line break to be send over UDP to the
given host and port.
Actual result:
--
Nothing happens. No packet gets generated, no error or warning is
thrown. fwrite() retuns 0.
--
Edit this bug report at http://bugs.php.net/?id=49423&edit=1
#47002 [Opn->Ver]: Fields truncated
ID: 47002
Updated by: sjo...@php.net
Reported By: victorjavierss at live dot com dot mx
-Status: Open
+Status: Verified
Bug Type: dBase related
Operating System: Windows
PHP Version: 5.2CVS-2009-01-04 (snap)
New Comment:
Could reproduce and code shows it gets only 1024 fields.
Previous Comments:
[2009-08-20 16:44:18] sjoerd-php at linuxonly dot nl
get_dbf_head assumes a max of 1024 fields. Below is a patch which
removes the 1024 limit and resizes the memory buffer if there are more
than 1024 fields.
--- 5.2latest/php5.2-200906261830/ext/dbase/dbf_head.c 2009-01-17
18:45:09.0 +0100
+++ php-5.2.10/ext/dbase/dbf_head.c 2009-08-20 18:37:56.0
+0200
@@ -22,7 +22,7 @@
dbhead_t *dbh;
struct dbf_dhead dbhead;
dbfield_t *dbf, *cur_f, *tdbf;
- int ret, nfields, offset, gf_retval;
+ int ret, nfields, offset, gf_retval, cur_f_offset, tdbf_size;
if ((dbh = (dbhead_t *)calloc(1, sizeof(dbhead_t))) == NULL)
return NULL;
@@ -46,14 +46,14 @@
dbhead.dbh_date[DBH_DATE_MONTH],
dbhead.dbh_date[DBH_DATE_DAY]);
- /* malloc enough memory for the maximum number of fields:
- 32 * 1024 = 32K dBase5 (for Win) seems to allow that many */
- tdbf = (dbfield_t *)calloc(1, sizeof(dbfield_t)*1024);
+ /* Although 1024 fields used to be the max, bug 47002 reports more
than 1024 fields. */
+ tdbf_size = 1024;
+ tdbf = (dbfield_t *)calloc(1, sizeof(dbfield_t)*tdbf_size);
offset = 1;
nfields = 0;
gf_retval = 0;
- for (cur_f = tdbf; gf_retval < 2 && nfields < 1024; cur_f++) {
+ for (cur_f = tdbf; gf_retval < 2; cur_f++) {
gf_retval = get_dbf_field(dbh, cur_f);
if (gf_retval < 0) {
@@ -66,6 +66,13 @@
offset += cur_f->db_flen;
nfields++;
}
+ if (nfields >= tdbf_size) {
+ cur_f_offset = cur_f - tdbf;
+ tdbf = realloc(tdbf, sizeof(dbfield_t) * tdbf_size * 2);
+ memset(tdbf + tdbf_size, '\0', tdbf_size);
+ tdbf_size *= 2;
+ cur_f = tdbf + cur_f_offset;
+ }
}
dbh->db_nfields = nfields;
[2009-01-13 06:01:04] victorjavierss at live dot com dot mx
I'm guess is dBase IV
[2009-01-13 05:59:39] victorjavierss at live dot com dot mx
Ooops, i got confused with other dbf, that i'm using, but that file is
over 1024 fields and y need all of them
[2009-01-12 14:09:25] typoon at gmail dot com
Victor,
Are you sure this file has 1625 fields? I opened the file with DBF
Viewer and I only see 1100 fields. Also I changed the logic a little bit
to calculate the number of fields based on the header length and I also
obtain 1100 fields.
Can you please confirm the number of fields in the file? Also, what is
the version of dbase you are using?
Thanks!
[2009-01-11 18:59:51] victorjavierss at live dot com dot mx
Here is one of the DBF's that i'm using:
http://cid-d95738776c6cf0d0.skydrive.live.com/self.aspx/.Public/USAERF07.DBF
as I said it retrieves me 1024 fild instead of 1625
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/47002
--
Edit this bug report at http://bugs.php.net/?id=47002&edit=1
#47221 [Opn->Ver]: no result from array_diff()
ID: 47221 Updated by: sjo...@php.net Reported By: sgnutzmann at yahoo dot de -Status: Open +Status: Verified Bug Type: Arrays related Operating System: win32 only - Windows XP PHP Version: 5.2.8 New Comment: Could reproduce. This code shows the time taken to array_diff two arrays for the builtin array_diff and for a PHP function fast_array_diff I wrote. http://www.gissen.nl/files/fast_array_diff.php'); $start = microtime(true); $res2 = fast_array_diff($a, $b); echo "Fast_array_diff duration: ".(microtime(true) - $start)."\n"; sort($res1); sort($res2); assert($res1 == $res2); ?> Output: Built-in array_diff duration: 11.8710849285 Fast_array_diff duration: 0.254959106445 Previous Comments: [2009-02-08 13:03:18] j...@php.net Please don't send me more spam. (never saw that and any direct mails to me will be deleted anyway) [2009-01-27 13:55:35] sgnutzmann at yahoo dot de I just try the latest version 'php-5.2-win32-VC6-x86-latest.msi' (2009-Jan-27 12:00:00). This version has the same problem as PHP 5.2.8 (no return in 5 minutes from array_diff(), infinite loop?). I sent my test dataset 'TestData.txt' to j...@php.net. [2009-01-27 12:09:33] sgnutzmann at yahoo dot de PHP 5.2.6 has the same problem as PHP 5.2.8 [2009-01-27 10:32:48] sgnutzmann at yahoo dot de Complete test script (size of generated test file 5,865 KB) First lines of test file: 76906 #00/1109 #00/1162 #00/1163 #00/1335 #00/1337 Result, if I use PHP 5.2.4: Size of first array: 76906 Size of second array: 433959 Start of array_diff Number of unknown identifier 17826 No result from array_diff, if I use PHP 5.2.8 (without any extension) [2009-01-26 17:58:51] sgnutzmann at yahoo dot de Description: I use the function array_diff() to compare two sorted string-arrays with numerical keys (array sizes are 76,906 and 433,959, string sizes in all array elements less than 20 characters). With PHP 5.2.4 the function returns very fast (just few seconds), with PHP 5.2.8 I kill PHP.exe after 30 minutes(!) without result. PHP.INI: memory_limit = 1536M extension=php_pdo.dll extension=php_zip.dll extension=php_pdo_odbc.dll Reproduce code: --- // $Sales and $Inv read previously from file system $idSales = array(); foreach ( $Sales as $i => $data ) $idSales[$i] = '#'.$data[2]; array_multisort ($idSales, $Sales); $idInv = array(); foreach ( $Inv as $i => $data ) $idInv[$i] = '#'.$data[1]; array_multisort ($idInv, $Inv); echo "Start array_diff\n"; $unknown = array_diff ( $idSales, $idInv ); echo "End array_diff\n"; Expected result: see description Actual result: -- no result in 30 minutes -- Edit this bug report at http://bugs.php.net/?id=47221&edit=1
#47501 [Opn]: stripslashes() converts \0 into a null character
ID: 47501 Updated by: sjo...@php.net Reported By: gazheyes at gmail dot com Status: Open Bug Type: Strings related Operating System: * PHP Version: 5.2.8 New Comment: Thank you for your bug report. I could reproduce the problem, but I don't think it is a bug. Stripslashes is meant to be the reverse of addslashes or the magic_quotes_gpc behavior. This means it does not only remove the slash in front of quotes, but also handles some other escaped characters, such as newlines and null characters: Previous Comments: [2009-02-25 15:22:37] gazheyes at gmail dot com Result:- string(2) "\0" string(1) " " [2009-02-25 13:37:33] j...@php.net Try this script instead: [2009-02-25 11:15:51] gazheyes at gmail dot com Description: Stripslashes appears to be converting null escapes into a null character. I've tested other unicode characters from 0 to 100,000 and only null escapes are converted. IMO you shouldn't be able to decode null chars from a url like this. Marc Zimmerli originally found this bug. Reproduce code: --- the url contains page.php?x=\0 Expected result: 0 Actual result: -- null -- Edit this bug report at http://bugs.php.net/?id=47501&edit=1
#47501 [Opn->Bgs]: stripslashes() converts \0 into a null character
ID: 47501 Updated by: sjo...@php.net Reported By: gazheyes at gmail dot com -Status: Open +Status: Bogus Bug Type: Strings related Operating System: * PHP Version: 5.2.8 New Comment: So I set it to bogus. Previous Comments: [2009-08-31 16:57:09] sjo...@php.net Thank you for your bug report. I could reproduce the problem, but I don't think it is a bug. Stripslashes is meant to be the reverse of addslashes or the magic_quotes_gpc behavior. This means it does not only remove the slash in front of quotes, but also handles some other escaped characters, such as newlines and null characters: [2009-02-25 15:22:37] gazheyes at gmail dot com Result:- string(2) "\0" string(1) " " [2009-02-25 13:37:33] j...@php.net Try this script instead: [2009-02-25 11:15:51] gazheyes at gmail dot com Description: Stripslashes appears to be converting null escapes into a null character. I've tested other unicode characters from 0 to 100,000 and only null escapes are converted. IMO you shouldn't be able to decode null chars from a url like this. Marc Zimmerli originally found this bug. Reproduce code: --- the url contains page.php?x=\0 Expected result: 0 Actual result: -- null -- Edit this bug report at http://bugs.php.net/?id=47501&edit=1
#49423 [Fbk]: fwrite doesn't send "REGISTER" to udp port 5060
ID: 49423
Updated by: sjo...@php.net
Reported By: david dot schueler at wapkamera dot de
Status: Feedback
Bug Type: Streams related
Operating System: Gentoo Linux
PHP Version: 5.2.10
New Comment:
I can reproduce the behavior you describe, but only if there is no
process listening on port 5060. If I start "nc -l -u -p 5060", the
fwrites succeed. Do you have a program listening on port 5060?
Previous Comments:
[2009-08-31 17:37:27] david dot schueler at wapkamera dot de
Again with latest php5.2:
~ # php test.php
5.2.11RC2-dev
Outputting: REGISTER abc
Bytes written to socket: 0
Outputting: REGISTER
Bytes written to socket: 8
Outputting: REGISTER
Bytes written to socket: 9
Outputting: REGISTER
Bytes written to socket: 9
~ # tcpdump -i lo -s0 -A port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
19:35:25.189697 IP localhost.5050 > localhost.5060: SIP, length: 8
E..$<@.@..$...#REGISTER
19:35:25.189911 IP localhost.5050 > localhost.5060: SIP, length: 9
E..%<@.@.."...$ REGISTER
19:35:25.189953 IP localhost.5050 > localhost.5060: SIP, length: 9
E..%<@.@..!...$REGISTER
^C
3 packets captured
6 packets received by filter
0 packets dropped by kernel
[2009-08-31 16:54:28] david dot schueler at wapkamera dot de
Okay, here's a tcpdump output, which shows that the other REGISTER
strings are beeing sent:
km33 ~ # tcpdump -i lo -s0 -A port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
18:42:22.598199 IP localhost.5050 > localhost.5060: SIP, length: 8
E..$|b...@.@..#REGISTER
18:42:22.598231 IP localhost.5050 > localhost.5060: SIP, length: 9
E..%|c...@.@..$ REGISTER
18:42:22.598242 IP localhost.5050 > localhost.5060: SIP, length: 9
E..%|d...@.@..$REGISTER
^C
3 packets captured
6 packets received by filter
0 packets dropped by kernel
As you can see i'm sending from port 5050 to port 5060 (which is the
default SIP port). No other process is listening on port 5050. Only
asterisk is listening on port 5060, which i want to communicate with.
km33 ~ # netstat -anp | grep 5050
km33 ~ # netstat -anp | grep 5060
udp 0 0 0.0.0.0:5060 0.0.0.0:* 11132/asterisk
And i'm not blocking any ports on my system, because i'm not using any
firewall on my testsystem.
[2009-08-31 16:26:58] david dot schueler at wapkamera dot de
Yes i wanted to send as line feed. But it doesn't matter because even
sending "REGISTER \r\n" nor "REGISTER abc" is working on 5.2.10.
I made a little script for showing what is happening:
array("bindto" => "0:5050"));
$context = stream_context_create($opts);
$socket = stream_socket_client("udp://127.0.0.1:5060", $errno, $error,
30, STREAM_CLIENT_CONNECT, $context);
$s[] = "REGISTER abc";
$s[] = "REGISTER";
$s[] = " REGISTER";
$s[] = "REGISTER ";
foreach ($s as $out) {
echo "Outputting: \"".$out."\"\n";
$bytes = fwrite($socket,$out);
echo "Bytes written to socket: ".$bytes."\n";
}
?>
And the output is:
Kienzle ~ # php fwrite.php
5.2.10-pl0-gentoo
Outputting: "REGISTER abc"
Bytes written to socket: 0
Outputting: "REGISTER"
Bytes written to socket: 8
Outputting: " REGISTER"
Bytes written to socket: 9
Outputting: "REGISTER "
Bytes written to socket: 9
Kienzle ~ # uname -a
Linux Kienzle 2.6.27-gentoo-r8 #7 SMP Wed Apr 29 18:42:19 CEST 2009
x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD
GNU/Linux
On another system, running the same version of php:
km33 ~ # php test.php
5.2.10-pl0-gentoo
Outputting: "REGISTER abc"
Bytes written to socket: 0
Outputting: "REGISTER"
Bytes written to socket: 8
Outputting: " REGISTER"
Bytes written to socket: 9
Outputting: "REGISTER "
Bytes written to socket: 9
km33 ~ # uname -a
Linux km33902 2.6.30-gentoo-r4 #2 SMP Tue Aug 4 17:44:21 CEST 2009
x86_64 AMD Phenom(tm) 9950 Quad-Core Processor AuthenticAMD GNU/Linux
And for example on a Debian System:
ns20 ~ # php test.php
5.2.0-8+etch15
Outputting: "REGISTER abc"
Bytes written to socket: 12
Outputting: "REGISTER"
Bytes written to socket: 0
Outputting: " REGISTER"
Bytes written to socket: 9
Outputting: "REGISTER "
Bytes written to socket: 0
e...@ns2014921:~$ uname -a
Linux ns2014921.ovh.net 2.6.24.2--std-ipv4-32 #4 SMP Wed Feb 13
16:50:04 CET 2008 i686 GNU/Linux
Look, the problem occures at "REGISTER".
I use "tcpdump -i lo -s0 -A port 5060" to look for the packet being
sent. And if fwrite() returns 0 then there arent any bytes on the
interface. So the output seems to be true.
-
#49397 [Fbk]: SoapClient Error
ID: 49397
Updated by: sjo...@php.net
Reported By: persiancity at gmail dot com
Status: Feedback
Bug Type: SOAP related
Operating System: Windows
PHP Version: 5.3.0
New Comment:
I could not reproduce the problem you report.
This bug is unlikely to get solved unless you provide some more
information. Maybe you can try a sniffing program I wrote:
http://www.gissen.nl/files/sniff.php
You can start it with:
php -f sniff.php > dump.txt
Then, run the code you supplied but with a different URL:
http://localhost:8080/http://efyek.com/ws/pws.php?wsdl');
?>
Please supply us with the resulting dump.txt.
Previous Comments:
[2009-08-28 10:31:37] persiancity at gmail dot com
yes. this is working when I save it on disk and call it locally.
sorry I have not installed sniffer program.
[2009-08-28 10:15:45] sjo...@php.net
Thank you for your bug report.
The problem you describe looks similar to bug #49226. Does it work
correctly if you save the WSDL to disk before loading it? Could you make
a dump of the HTTP connection with a sniffer?
[2009-08-28 09:49:21] persiancity at gmail dot com
Description:
I get thos error on PHP5.3 on Windows when try to use SoapClient. There
is not error for same code in PHP 5.2 and above.
Reproduce code:
---
$client = new SoapClient('http://efyek.com/ws/pws.php?wsdl');
Actual result:
--
Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't
load from 'http://efyek.com/ws/pws.php?wsdl' : Extra content at the end
of the document in class.p24.php:39 Stack trace: #0 class.p24.php(39):
SoapClient->SoapClient('http://efyek.co...') #1 indexall.php(38):
p24Class->connect() #2 {main} thrown in class.p24.php on line 39
--
Edit this bug report at http://bugs.php.net/?id=49397&edit=1
#49226 [NoF]: SoapServer failing on construction (cannot load wsdl)
ID: 49226 Updated by: sjo...@php.net Reported By: richard at rjharrison dot org Status: No Feedback Bug Type: SOAP related Operating System: linux PHP Version: 5.3.0 New Comment: Bug #49397 describes the same problem, but with SoapClient. Previous Comments: [2009-09-01 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-08-24 19:22:37] sjo...@php.net PHP 5.3 indeed seems to request the WSDL using HTTP/1.1, I was wrong about that, I'm sorry. However, it works fine with other WSDLs which are sent chunked. There seems to be something special about your setup which triggers this bug. Could you make a dump of the HTTP transaction with a sniffer? Note that you may have to disable the WSDL caching to force SoapServer to get the WSDL over HTTP. [2009-08-24 17:53:22] richard at rjharrison dot org Ok I understand your point (that the WSDL server is supposedly at fault for not providing an HTTP 1.0 response). I just tested again and watched my Apache access_log. With 5.2.10, the request is sent from SoapServer using HTTP 1.0, and the response from the WSDL server correctly includes a content-length header (and everything works fine). When I test with 5.3, SoapServer sends the request using HTTP 1.1 (according to the Apache log) and the response is chunk-encoded causing SoapServer to error. Therefore I believe that SoapServer in 5.3 is sending an HTTP 1.1 request but is unable to process an HTTP 1.1 response. [2009-08-24 16:49:16] sjo...@php.net The specifications you supply do not describe how to retrieve the WSDL. In this case, the WSDL is retrieved using HTTP. I don't think it is specified which HTTP version to use. The SoapServer class uses HTTP 1.0. If the server serving the WSDL implements HTTP 1.0, it should send a content-length header. If it does not implement HTTP 1.0, it should send a 505 HTTP Version Not Supported. [2009-08-24 13:20:41] richard at rjharrison dot org Sjoerd, Respectfully, I think you're wrong. I am *far* from being a SOAP expert, but the specifications for SOAP 1.1[1] and for WSDL[2] both show use of HTTP 1.1. 1. http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383526 2. http://www.w3.org/TR/wsdl#_http 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/49226 -- Edit this bug report at http://bugs.php.net/?id=49226&edit=1
#47221 [Ver->Bgs]: no result from array_diff()
ID: 47221 Updated by: sjo...@php.net Reported By: sgnutzmann at yahoo dot de -Status: Verified +Status: Bogus Bug Type: Arrays related Operating System: win32 only - Windows XP PHP Version: 5.2.8 New Comment: Duplicate of bug #47643. Previous Comments: [2009-09-01 00:04:33] fel...@php.net See bug #47643 [2009-08-31 16:42:06] sjo...@php.net Could reproduce. This code shows the time taken to array_diff two arrays for the builtin array_diff and for a PHP function fast_array_diff I wrote. http://www.gissen.nl/files/fast_array_diff.php'); $start = microtime(true); $res2 = fast_array_diff($a, $b); echo "Fast_array_diff duration: ".(microtime(true) - $start)."\n"; sort($res1); sort($res2); assert($res1 == $res2); ?> Output: Built-in array_diff duration: 11.8710849285 Fast_array_diff duration: 0.254959106445 [2009-02-08 13:03:18] j...@php.net Please don't send me more spam. (never saw that and any direct mails to me will be deleted anyway) [2009-01-27 13:55:35] sgnutzmann at yahoo dot de I just try the latest version 'php-5.2-win32-VC6-x86-latest.msi' (2009-Jan-27 12:00:00). This version has the same problem as PHP 5.2.8 (no return in 5 minutes from array_diff(), infinite loop?). I sent my test dataset 'TestData.txt' to j...@php.net. [2009-01-27 12:09:33] sgnutzmann at yahoo dot de PHP 5.2.6 has the same problem as PHP 5.2.8 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/47221 -- Edit this bug report at http://bugs.php.net/?id=47221&edit=1
#49348 [Asn]: Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!)
ID: 49348 Updated by: sjo...@php.net Reported By: BelStudent at yandex dot ru Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.*, 6 Assigned To: stas New Comment: I was talking about this: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_execute.c?revision=286362&view=markup#l251 With ++$foo, type is BP_VAR_RW, which makes sense and gives a notice. With ++$this->foo, it is BP_VAR_W. Previous Comments: [2009-08-31 22:12:10] j...@php.net # svn log -r100312 zend_object_handlers.c r100312 | stas | 2002-10-20 22:22:04 +0300 (Sun, 20 Oct 2002) | 2 lines looks like this message should go --- Stas, care to explain? Uncommenting that will bring back the notice. And Sjoerd, what did you mean with that comment..? [2009-08-27 21:06:36] sjo...@php.net In _get_zval_cv_lookup(), type is BP_VAR_W, while it should be BP_VAR_RW for the example code. [2009-08-25 08:18:09] j...@php.net Reopened, Gwynne's arguments are rock solid. :) [2009-08-25 07:13:46] gwy...@php.net Actually, this is a valid problem; the problem described by bug #21008 is a different issue. There seems to be some confusion as to whether it should be fixed or not, but it's neither a duplicate nor bogus. Specifically, bug #21008 describes an issue with setting a variable to a value, where this report describes an issue with updating a variable. These are two distinct operations, and are handled differently. More to the point, the following code throws a notice: That the code described by this bug doesn't is an inconsistency. [2009-08-24 16:21:58] BelStudent at yandex dot ru Description: Usually, if you try to do this: ++$num, then thrown notice, that the "Undefined variable: num". This helps avoid errors. But if you have class and you're trying to do so ++$this->num num nowhere and had not previously identified, then the issue no warnings and notices. Accidentally deleted in the symbol and received ++$this->nu, and then climbed into hell knows what mistakes to find this place and correct to ++$this->num took several hours. So I am very concerned about the issue: how to do so were given notice, if you try to do something with uninitialized (unknown) variable in the class? Reproduce code: --- num; } } new A(); ?> Expected result: Undefined property: A::$num Actual result: -- empty -- Edit this bug report at http://bugs.php.net/?id=49348&edit=1
#48507 [Opn->Ver]: fgetcsv() ignoring special characters
ID: 48507 Updated by: sjo...@php.net Reported By: krynble at yahoo dot com dot br -Status: Open +Status: Verified Bug Type: Filesystem function related Operating System: Unix PHP Version: 5.2.9 Previous Comments: [2009-06-26 19:35:22] sjoerd-php at linuxonly dot nl Could reproduce with php 5.2.10, php 5.2.11-dev (200906261830) and php 5.3rc4. Example code: Expected: string(5) "?TICA" Actual: string(4) "TICA" [2009-06-13 18:10:03] krynble at yahoo dot com dot br Unfortunately I'm unable to test it because the server is running in a Datacenter. If someone can give a feedback about it, I would apreciate. Still, thanks for the help! [2009-06-10 12:47:52] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-06-09 14:18:39] krynble at yahoo dot com dot br Description: Problem using fgetcsv ignoring special characters at the begining of a string. The example I had was using the word "ÓTICA" with the "#" character as separator. Reproduce code: --- Consider a file with the following contents: WEIRD#ÓTICA#BEHAVIOR When using fgetcsv to parse this file, I get an output like this: Array( [0] => WEIRD, [1] => TICA, [2] => BEHAVIOR ) Expected result: Array( [0] => WEIRD, [1] => ÓTICA, [2] => BEHAVIOR ) Actual result: -- Array( [0] => WEIRD, [1] => TICA, [2] => BEHAVIOR ) -- Edit this bug report at http://bugs.php.net/?id=48507&edit=1
#48858 [Opn->Ver]: array item definition problem (regression!)
ID: 48858
Updated by: sjo...@php.net
Reported By: justin dot carlson at gmail dot com
-Status: Open
+Status: Verified
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3.0
Previous Comments:
[2009-07-09 14:37:30] justin dot carlson at gmail dot com
I've confirmed this in Linux as well.
The following works fine:
'foo', b => 'bar');
print_R($test);
?>
So, it may be related to class constants?
----
[2009-07-09 07:25:39] sjoerd-php at linuxonly dot nl
Thank you for your bug report.
I was able to reproduce the problem and make the testcase somewhat
simpler:
'First',
self::D => 'Last'
);
}
print_r(Foo::$sample);
?>
[2009-07-08 22:15:10] justin dot carlson at gmail dot com
Description:
Array items are not as defined when using the same key twice.
I have not yet tested this outside of a class.
Reproduce code:
---
'Apple',
self::B => 'Boy',
self::C => 'Cat',
self::D => 'Dog'
);
public static function Bar() {
print_R( self::$sample );
}
}
?>
Expected result:
In PHP 5.2.x:
Array
(
[2] => Boy
[3] => Cat
[1] => Dog
)
This is what I would expect to be valid, as the 2nd entry would
override the first, making "Dog" the correct value for index 1.
Actual result:
--
In PHP 5.3.x:
Array
(
[1] => Apple
[2] => Boy
[3] => Cat
)
This was not expected, as the 1st entry maintained it's value.
--
Edit this bug report at http://bugs.php.net/?id=48858&edit=1
#49423 [Fbk]: fwrite doesn't send "REGISTER" to udp port 5060
ID: 49423 Updated by: sjo...@php.net Reported By: david dot schueler at wapkamera dot de Status: Feedback Bug Type: Streams related Operating System: Gentoo Linux PHP Version: 5.2.10 New Comment: Also, please try on the problematic system with nc instead of asterisk as the listening process. Previous Comments: [2009-09-01 13:06:59] david dot schueler at wapkamera dot de And here on a 2nd non-64bit system: Hauser ~ # php fwrite.php 5.2.6RC4-pl0-gentoo Outputting: REGISTER abc Bytes written to socket: 12 Outputting: REGISTER Bytes written to socket: 8 Outputting: REGISTER Bytes written to socket: 9 Outputting: REGISTER Bytes written to socket: 9 Hauser ~ # nc -l -u -p 5060 REGISTER abcREGISTER REGISTERREGISTER So this really looks to me, that it is depending on 64bit. Is it possible to you to reproduce this on 64bit? [2009-09-01 12:52:45] david dot schueler at wapkamera dot de And on a non 64bit system running Gentoo: athen ~ # uname -a Linux athen 2.6.20-hardened-r5 #1 SMP Sun Jul 29 21:36:07 GMT 2007 i686 AMD Duron(tm) processor AuthenticAMD GNU/Linux athen ~ # php fwrite.php 5.2.3-pl3-gentoo Outputting: REGISTER abc Bytes written to socket: 12 Outputting: REGISTER Bytes written to socket: 8 Outputting: REGISTER Bytes written to socket: 9 Outputting: REGISTER Bytes written to socket: 9 athen ~ # nc -l -u -p 5060 REGISTER abcREGISTER REGISTERREGISTER So this is running fine with a listening process. So may this issue due to the 64bit? [2009-09-01 12:39:51] david dot schueler at wapkamera dot de Okay. I built 5.2.11 on an other systerm running debian. Here are the results with no process listening on port 5060: ns20 ~ # php test.php 5.2.11RC2-dev Outputting: "REGISTER abc" Bytes written to socket: 12 Outputting: "REGISTER" Bytes written to socket: 0 Outputting: " REGISTER" Bytes written to socket: 9 Outputting: "REGISTER " Bytes written to socket: 0 And, with listening nc on 5060: ns20 ~ # nc -l -u -p 5060 REGISTER abcREGISTER REGISTERREGISTER ns20 ~ # php test.php 5.2.11RC2-dev Outputting: "REGISTER abc" Bytes written to socket: 12 Outputting: "REGISTER" Bytes written to socket: 8 Outputting: " REGISTER" Bytes written to socket: 9 Outputting: "REGISTER " Bytes written to socket: 9 So on that debian system it is working. But i don't know why its running on that system and not on the Gentoo platform. There's really no firewall blocking the traffic. Even if it would so, no packet should go through. But some are doing. This is driving me crazy. :-/ [2009-09-01 08:55:49] david dot schueler at wapkamera dot de Yes. Asterisk is listening on port 5060, which i want to communicate with, as i described before. I got this problem when i was trying to send a SIP REGISTER packet to asterisk. For beeing sure asterisk is working on 127.0.0.1 i placed a SIP REGISTER in a file and ran this command: Kienzle ~ # nc -u 127.0.0.1 5060 < register SIP/2.0 404 Not found From: Joe User To: "J. User" ;tag=as23fd48f7 Call-ID: 39485...@joespc.example.com CSeq: 19 REGISTER User-Agent: WAPKamera Notifier Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO Supported: replaces Content-Length: 0 So the asterisk is answering with 404 not foud, which is correct. Even netstat is confirming this. Kienzle ~ # netstat -anp | grep 5060 udp 0 0 0.0.0.0:5060 0.0.0.0:* 4481/asterisk But, even if no process is listening on port 5060 nothing would change, as you can see: Kienzle ~ # /etc/init.d/asterisk stop * Stopping Asterisk ... [ ok ] Kienzle ~ # netstat -anp | grep 5060 Kienzle ~ # php fwrite.php 5.2.10-pl0-gentoo Outputting: REGISTER abc Bytes written to socket: 0 Outputting: REGISTER Bytes written to socket: 8 Outputting: REGISTER Bytes written to socket: 0 Outputting: REGISTER Bytes written to socket: 9 Kienzle ~ # nc -u 127.0.0.1 5060 < register Kienzle ~ # tcpdump -i lo -s0 -A port 5060 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes 10:54:43.706902 IP localhost.5050 > localhost.5060: SIP, length: 8 e.@.@..M...#REGISTER 10:54:43.707031 IP localhost.5050 > localhost.5060: SIP, length: 9 e.@.@..K...$REGISTER ^C 2 packets captured 4 packets received by filter 0 packets dropped by kernel Kienzle ~ # [2009-08-31 19:56:01] sjo...@php.net I can reproduce the behavior you describe, but only if there is no process listening on port 5060. If I start "nc -l -u -p 5060", the fwrites succeed. Do you have a prog
#46888 [Opn->Ver]: copy() : safe_mode / allow_url_fopen does not allow opening urls
ID: 46888 Updated by: sjo...@php.net Reported By: php at degoulet dot net -Status: Open +Status: Verified Bug Type: Safe Mode/open_basedir Operating System: * PHP Version: 5.2.9 New Comment: Could reproduce. With safe mode, files which are handled by stream wrappers are checked against the filesystem. This is wrong. Previous Comments: [2009-05-15 14:04:27] christian at elmerot dot se You apply the patch using the command patch when you build PHP from the sourcecode. If you've never done this before I cannot recommend that you do this for something like PHP. If you still go ahead, download the PHP sourcecode, extract it and read the files (README and INSTALL). Check documentation for using the patch command (man patch). in general you save the patch to a file (lets call it safemode.patch) then you simply run "patch main/safe_mode.c < safemode.patch" in the folder where you unpacked the source [2009-04-28 13:32:43] neo at nord-style dot com Hello, I've the same problem but I don't understand how use this patch. Actually safe_mode off but it's not a solution. How and Where Am i use this : --- diff -Nur php-5.2.8/main/safe_mode.c php-5.2.8_1/main/safe_mode.c --- php-5.2.8/main/safe_mode.c 2008-07-24 18:01:59.0 +0200 +++ php-5.2.8_1/main/safe_mode.c2008-12-17 15:01:07.502862702 +0100 @@ -52,6 +52,7 @@ long uid=0L, gid=0L, duid=0L, dgid=0L; char path[MAXPATHLEN]; char *s, filenamecopy[MAXPATHLEN]; + php_stream_wrapper *wrapper = NULL; TSRMLS_FETCH(); path[0] = '\0'; @@ -72,6 +73,15 @@ mode = CHECKUID_CHECK_FILE_AND_DIR; } } + + /* +* If given filepath is a URL, allow - safe mode stuff +* related to URL's is checked in individual functions +* Possibly/likely allows for safe_mode bypass!!! +*/ + wrapper = php_stream_locate_url_wrapper(filename, NULL, STREAM_LOCATE_WRAPPERS_ONLY TSRMLS_CC); + if ((wrapper != NULL) && (strstr(filename, "..\/") == NULL)) + return 1; /* First we see if the file is owned by the same user... * If that fails, passthrough and check directory... --- Thx [2009-03-12 13:44:07] fuxa_kos at unihost dot cz problem still in 5.2.9 [2008-12-17 15:22:50] php at degoulet dot net thanks : this workaround works fine ! [2008-12-17 14:58:32] christian at elmerot dot se The following patch restores part of behaviour from 5.2.6 yet has an extra check to see if the URL contains "../" which is where the removal came from. It is not a 100% correct "fix" in that it still allows for unknown URL vectors to bypass safe_mode, however, it is less broken this way for us. Perhaps the patch will help someone else. Remember, this is a safe_mode bypass issue that was fixed and the underlying cause (URLs: http: mapping to a local file incorrectly) looks to me unfixed. To me it looks as if safe_mode fails in this case but it also do no "extra" harm that won't be allowed with safe_mode disabled. Have I missed something? diff -Nur php-5.2.8/main/safe_mode.c php-5.2.8_1/main/safe_mode.c --- php-5.2.8/main/safe_mode.c 2008-07-24 18:01:59.0 +0200 +++ php-5.2.8_1/main/safe_mode.c2008-12-17 15:01:07.502862702 +0100 @@ -52,6 +52,7 @@ long uid=0L, gid=0L, duid=0L, dgid=0L; char path[MAXPATHLEN]; char *s, filenamecopy[MAXPATHLEN]; + php_stream_wrapper *wrapper = NULL; TSRMLS_FETCH(); path[0] = '\0'; @@ -72,6 +73,15 @@ mode = CHECKUID_CHECK_FILE_AND_DIR; } } + + /* +* If given filepath is a URL, allow - safe mode stuff +* related to URL's is checked in individual functions +* Possibly/likely allows for safe_mode bypass!!! +*/ + wrapper = php_stream_locate_url_wrapper(filename, NULL, STREAM_LOCATE_WRAPPERS_ONLY TSRMLS_CC); + if ((wrapper != NULL) && (strstr(filename, "..\/") == NULL)) + return 1; /* First we see if the file is owned by the same user... * If that fails, passthrough and check directory... 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/46888 -- Edit this bug report at http://bugs.php.net/?id=46888&edit=1
#48701 [Opn->Fbk]: Size limit on XML nodes
ID: 48701
Updated by: sjo...@php.net
Reported By: luca at iv-srl dot it
-Status: Open
+Status: Feedback
Bug Type: DOM XML related
Operating System: Windows XP
PHP Version: 5.2.10
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2009-06-26 12:40:13] luca at iv-srl dot it
Description:
I submit an attachment and then send via XML inside a node. When I
attach a file larger than 12k this function creates an empty node with
no evident error report on php.
(This is only a sample of the real code)
Reproduce code:
---
function creaElem($name, $value="", $parent=null)
{
$el=$this->Document->createElement($name);
if ($value!="")
$el->appendChild($this->Document->createTextNode($value));
if ($parent!=null)
$parent->appendChild($el);
return $el;
}
function AttachFile($parentnode,$attachmentname)
{
\\
$packet->creaElem("nomefile",$attachmentname,$parentnode);
$newnode=$packet->creaElem("attach","",$parentnode);
$whatsinside=file_get_contents ($_FILES['attachment']['tmp_name']);
$cdata=$this->Document->createCDATASection(base64_encode($whatsinside));
$newnode->appendChild($cdata);
}
Expected result:
When I run AttachFile(..) and My attachment size is larger than 12k
this
function creates an empty node. With attachments<12k it works.
Any suggestion?
Thanks in advance
--
Edit this bug report at http://bugs.php.net/?id=48701&edit=1
#44248 [Opn->Bgs]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248
Updated by: sjo...@php.net
Reported By: jboffel at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: SOAP related
Operating System: Linux RedHat Enterprise
PHP Version: 5.2.9
New Comment:
Thank you for your bug report.
I could not reproduce your problem. It is possible it has already been
fixed in the meantime.
This is the request the SoapClient sends to the proxy server in my
setup:
POST http://ws1.webservices.nl:80/address/soap.php HTTP/1.1
Host: ws1.webservices.nl
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.2.11RC2-dev
Content-Type: text/xml; charset=utf-8
SOAPAction:
"http://ws1.webservices.nl/address/soap.php/addressReeksPostcodeSearch";
Content-Length: 552
... etc. etc.
Please reopen this bug if you still have this problem.
Previous Comments:
[2009-06-16 08:15:35] garyxemily at hotmail dot co dot uk
gary the 4 ed mam is called jaki rolo she is the last dinosour in the
world if u see her phone the millatery :D
[2009-05-02 12:10:19] jboffel at gmail dot com
sorry small mistake on my previous comment...
Good fix is:
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
if (phpurl->port != 80) {
smart_str_append_const(&soap_headers, ":");
smart_str_append_unsigned(&soap_headers, phpurl->port);
}
smart_str_append_const(&soap_headers, "\r\n");
[2009-04-30 07:58:36] jboffel at gmail dot com
I'll even give you a link on another bug related to our problem :
http://bugs.php.net/bug.php?id=30359
This bug show us that "Host: " field was previously in the code (in
2004) and there was a bug on this field (about the port) which complet
my fix to avoid repeating his bug.
So apparently you need to add this code to be compliant to all RFC
requests:
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_append_const(&soap_headers, "\r\n");
if (phpurl->port != 80) {
smart_str_append_const(&soap_headers, ":");
smart_str_append_unsigned(&soap_headers, phpurl->port);
}
[2009-04-28 19:47:01] jboffel at gmail dot com
I checked source code of last CVS snapshot you gave with your link.
I can't easily test in same conditions than before so I just compared
source code.
I could be wrong but I'm pretty sure there is no difference and that
the bug is still present.
smart_str_append_const(&soap_headers, "CONNECT ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_appendc(&soap_headers, ':');
smart_str_append_unsigned(&soap_headers, phpurl->port);
smart_str_append_const(&soap_headers, " HTTP/1.1\r\n");
proxy_authentication(this_ptr, &soap_headers TSRMLS_CC);
smart_str_append_const(&soap_headers, "\r\n");
proxy_authentication just add basic auth if necessary. Nothing to do
with "Host: " header parameter.
And it's still in HTTP/1.1, so for me, no news.
[2009-04-28 18:36:31] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
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/44248
--
Edit this bug report at http://bugs.php.net/?id=44248&edit=1
#44248 [Bgs->Opn]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248
Updated by: sjo...@php.net
Reported By: jboffel at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: SOAP related
Operating System: Linux RedHat Enterprise
PHP Version: 5.2.9
New Comment:
I misunderstood the problem. The request I posted was for HTTP, not for
HTTPS. For HTTPS, the Host header is indeed missing. I am not yet sure
that that is a bug.
Previous Comments:
[2009-09-01 17:02:47] sjo...@php.net
Thank you for your bug report.
I could not reproduce your problem. It is possible it has already been
fixed in the meantime.
This is the request the SoapClient sends to the proxy server in my
setup:
POST http://ws1.webservices.nl:80/address/soap.php HTTP/1.1
Host: ws1.webservices.nl
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.2.11RC2-dev
Content-Type: text/xml; charset=utf-8
SOAPAction:
"http://ws1.webservices.nl/address/soap.php/addressReeksPostcodeSearch";
Content-Length: 552
... etc. etc.
Please reopen this bug if you still have this problem.
[2009-06-16 08:15:35] garyxemily at hotmail dot co dot uk
gary the 4 ed mam is called jaki rolo she is the last dinosour in the
world if u see her phone the millatery :D
[2009-05-02 12:10:19] jboffel at gmail dot com
sorry small mistake on my previous comment...
Good fix is:
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
if (phpurl->port != 80) {
smart_str_append_const(&soap_headers, ":");
smart_str_append_unsigned(&soap_headers, phpurl->port);
}
smart_str_append_const(&soap_headers, "\r\n");
[2009-04-30 07:58:36] jboffel at gmail dot com
I'll even give you a link on another bug related to our problem :
http://bugs.php.net/bug.php?id=30359
This bug show us that "Host: " field was previously in the code (in
2004) and there was a bug on this field (about the port) which complet
my fix to avoid repeating his bug.
So apparently you need to add this code to be compliant to all RFC
requests:
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_append_const(&soap_headers, "\r\n");
if (phpurl->port != 80) {
smart_str_append_const(&soap_headers, ":");
smart_str_append_unsigned(&soap_headers, phpurl->port);
}
[2009-04-28 19:47:01] jboffel at gmail dot com
I checked source code of last CVS snapshot you gave with your link.
I can't easily test in same conditions than before so I just compared
source code.
I could be wrong but I'm pretty sure there is no difference and that
the bug is still present.
smart_str_append_const(&soap_headers, "CONNECT ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_appendc(&soap_headers, ':');
smart_str_append_unsigned(&soap_headers, phpurl->port);
smart_str_append_const(&soap_headers, " HTTP/1.1\r\n");
proxy_authentication(this_ptr, &soap_headers TSRMLS_CC);
smart_str_append_const(&soap_headers, "\r\n");
proxy_authentication just add basic auth if necessary. Nothing to do
with "Host: " header parameter.
And it's still in HTTP/1.1, so for me, no news.
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/44248
--
Edit this bug report at http://bugs.php.net/?id=44248&edit=1
#44248 [Bgs->Opn]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248
Updated by: sjo...@php.net
Reported By: jboffel at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: SOAP related
Operating System: Linux RedHat Enterprise
PHP Version: 5.2.9
New Comment:
Does the Apache proxy really need the Host header? Is this bug a
problem other than that it does not conform with the RFC?
Previous Comments:
[2009-09-01 17:14:32] jboffel at gmail dot com
Hi,
Thanks for your test, but you have to do it through HTTPS connection to
reproduce the bug.
In fact, the bug is linked to the use of an Apache proxy through HTTPS
connection and a SOAP call. If you connect through HTTP you don't do the
CONNECT command and you can't see the bug.
[2009-09-01 17:11:14] sjo...@php.net
I misunderstood the problem. The request I posted was for HTTP, not for
HTTPS. For HTTPS, the Host header is indeed missing. I am not yet sure
that that is a bug.
[2009-09-01 17:02:47] sjo...@php.net
Thank you for your bug report.
I could not reproduce your problem. It is possible it has already been
fixed in the meantime.
This is the request the SoapClient sends to the proxy server in my
setup:
POST http://ws1.webservices.nl:80/address/soap.php HTTP/1.1
Host: ws1.webservices.nl
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.2.11RC2-dev
Content-Type: text/xml; charset=utf-8
SOAPAction:
"http://ws1.webservices.nl/address/soap.php/addressReeksPostcodeSearch";
Content-Length: 552
... etc. etc.
Please reopen this bug if you still have this problem.
[2009-06-16 08:15:35] garyxemily at hotmail dot co dot uk
gary the 4 ed mam is called jaki rolo she is the last dinosour in the
world if u see her phone the millatery :D
[2009-05-02 12:10:19] jboffel at gmail dot com
sorry small mistake on my previous comment...
Good fix is:
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
if (phpurl->port != 80) {
smart_str_append_const(&soap_headers, ":");
smart_str_append_unsigned(&soap_headers, phpurl->port);
}
smart_str_append_const(&soap_headers, "\r\n");
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/44248
--
Edit this bug report at http://bugs.php.net/?id=44248&edit=1
#46539 [Opn->Bgs]: SoapClient uses HTTP/1.1 options over HTTP/1.0
ID: 46539 Updated by: sjo...@php.net Reported By: marques at displague dot com -Status: Open +Status: Bogus Bug Type: SOAP related Operating System: * PHP Version: 5.2.6 New Comment: Thank you for your bug report. While the usage of digest authentication with HTTP/1.0 may very well be a bug, we have no interest in fixing it in the 5.2 branch. Fixing it would be much work and users can use PHP 5.3 instead if they experience this bug. The Host header is allowed in HTTP/1.0. The difference with HTTP/1.1 is that it is _required_ in HTTP/1.1. Previous Comments: [2009-07-27 12:24:25] alayn at irontec dot com Confirmed. My problem disappeared with 5.3 Sorry again [2009-07-23 13:52:08] alayn at irontec dot com Up... It seems like my bug is more related to: http://bugs.php.net/bug.php?id=47021 I will try 5.3 as soon as i have time for it. Sorry :S [2009-07-23 11:42:50] alayn at irontec dot com Using HTTP/1.0 for the WSDL request against a JAX-WS service, makes PHP freeze until timeout arrives, eventhought it gets the complete response. Not sure if this is a JAX-WS or PHP related issue, but I think it should be possible to resolve it by performing an HTTP/1.1 request... A related bug is reported at Java's bug system too: https://jax-ws.dev.java.net/issues/show_bug.cgi?id=257 It seems they resolved the issue with wget, but I still having the same problem from PHP 5.2.9 :( [2008-11-10 22:01:49] marques at displague dot com Description: When setting the SoapClient option 'authorization' to SOAP_AUTHENTICATION_DIGEST, the SoapClient connection should attempt to GET with HTTP/1.1 rather than HTTP/1.0 since digest is HTTP/1.1 specific. I also noticed that the HTTP/1.0 WSDL request issued by the SoapClient class used "Host:" lines. I may be wrong, but I thought that implied HTTP/1.1. (I don't see it in the HTTP/1.0 RFC). -- Edit this bug report at http://bugs.php.net/?id=46539&edit=1
#49444 [Opn->Fbk]: $_GET variable
ID: 49444
Updated by: sjo...@php.net
Reported By: hafizanil at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Windows Xp
PHP Version: 5.3.0
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Previous Comments:
[2009-09-03 01:16:15] hafizanil at gmail dot com
Javascript (Page 1)
function sentMail() {
var url;
var to;
url = 'ml_compose_com.php?';
document.form.title.value='admin (sit: mr chang n mr sairi n mr
pzan)
,';
title = escape(document.form.title.value);
if(title){ url= url+'&title='+ title; }
location = url+"&sent_mail=1";
}
Page 2 (ml_compose_com.php)
".print_r($_GET)."";
var_dump($_GET);
?>
[2009-09-02 19:11:27] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-09-02 16:07:28] hafizanil at gmail dot com
Description:
Want to sent variable via javascript via $_GET method and the output
going hirewire.The varible sent also been escape
first(javascript).Tested using 5.29 and 5.3
Browser 1.Internet Explorer 7
2 Firefox 3.52
3. Opera 10
Reproduce code:
---
This is tested 5.29
[code]
$_GET['to']="admin (sit: mr chang n mr sairi n mr pzan)
,";
echo strlen($_GET['to'])
// out put 63
var_dump($_GET);
// output only showing admin (sit: mr chang n mr sairi n mr pzan)
[/code]
This is tested 5.30
[code]
$_GET['to']="admin (sit: mr chang n mr sairi n mr pzan)
,";
echo strlen($_GET['to'])
// out put 63
var_dump($_GET);
//output :Page going crazy.show all the php source
[/code]
Expected result:
var_dump or print_r $_GET array should understand the variable which
might contain "<>";
Actual result:
--
On 5.3 It show all the source php .
--
Edit this bug report at http://bugs.php.net/?id=49444&edit=1
#49456 [Opn->Bgs]: Script current working directory converted to real path cause require() errors
ID: 49456 Updated by: sjo...@php.net Reported By: michele dot manzato at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Ubuntu/Hardy PHP Version: 5.2.11RC1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Note that this behavior is the same as in a shell: cd b/c ls .. It shows the contents of /tmp, not the contents of /tmp/b. This works as it should. Previous Comments: [2009-09-03 14:36:40] michele dot manzato at gmail dot com Description: PHP script current working directory being converted to the real path cause error in relative files inclusion (see also bug #46814). As one can see in the reproduce code the script's getcwd() says '/tmp/a' although the script was run from '/tmp/b/c'. As a result the require() instruction fails because it can't find any '/inc.php'. '/tmp/b/inc.php' would have been found if the original symlinked path was preserved. Reproduce code: --- ~$ cd /tmp /tmp$ mkdir a /tmp$ mkdir b /tmp$ echo '' > a/test.php /tmp$ echo '' > b/inc.php /tmp$ ln -s /tmp/a b/c /tmp$ cd b/c/ /tmp/b/c$ php -f test.php Expected result: ok Actual result: -- /tmp/a Warning: require(../inc.php): failed to open stream: No such file or directory in /tmp/a/test.php on line 1 Fatal error: require(): Failed opening required '../inc.php' (include_path='.:/usr/share/php:/usr/share/pear') in /tmp/a/test.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=49456&edit=1
#49455 [Opn->Bgs]: eval works or not with __FILE__ and basename
ID: 49455
Updated by: sjo...@php.net
Reported By: djalmaoliveira at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Ubuntu
PHP Version: 5.2.10
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Basename does work. However __FILE__ contains the following:
/home/sjoerd/public_html/a.php(2) : eval()'d code
This makes basename(__FILE__) contain:
a.php(2) : eval()'d code
So the behavior is expected.
Previous Comments:
[2009-09-03 13:13:14] djalmaoliveira at gmail dot com
Description:
When I execute this code, the first eval() works, but the second
breaks.
It's a bug?
Reproduce code:
---
eval('echo dirname(__FILE__);');
echo "";
eval('echo basename(__FILE__);');
Expected result:
The second eval() works.
Actual result:
--
The second eval(): eval()'d code
--
Edit this bug report at http://bugs.php.net/?id=49455&edit=1
#49486 [Opn->Bgs]: socket_read couldn't detect the end of data
ID: 49486
Updated by: sjo...@php.net
Reported By: kernins at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Sockets related
Operating System: Debian 4.0, WinXP SP3
PHP Version: 5.2.9, 5.3.0
New Comment:
Thank you for your report.
Socket_read only returns false when the remote end has closed the
connection. It will not return false when the remote side has not closed
the connection but does not send data anymore. This is expected
behavior. Socket_read can not detect the "end of data", other than the
other side closing the connection.
Previous Comments:
[2009-09-06 13:34:50] kernins at gmail dot com
Description:
App description: Script should connect to socks4/5 or CONNECT proxy and
establish a tunnel to some host, google.com:80, for example.
Problem: socket_read() couldn't detect the end of data while reading
response from socks4/5 server (response to initial hello msg or connect
command) or from connect-proxy (response to connect command).
Reproduce code:
---
$host=gethostbyname("google.com"); $port=80;
$proxy_ip="212.27.33.4"; $proxy_port=8118;
if(!preg_match('/^(\d+)\.(\d+)\.(\d+)\.(\d+)$/',$host,$ip)) die();
$s5_init="\x05\x01\x00";
$s5_connect="\x05\x01\x00\x01".chr($ip[1]).chr($ip[2]).chr($ip[3]).chr($ip[4]).pack('n',$port);
$s4="\x04\x01".pack('n',$port).chr($ip[1]).chr($ip[2]).chr($ip[3]).chr($ip[4])."\x00";
$connect="CONNECT google.com:80 HTTP/1.1\r\nProxy-Connection:
keep-alive\r\n\r\n";
$sock=socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_set_option($sock,SOL_SOCKET,SO_SNDTIMEO,array('sec'=>5,'usec'=>0));
socket_set_option($sock,SOL_SOCKET,SO_RCVTIMEO,array('sec'=>15,'usec'=>0));
socket_connect($sock,$proxy_ip,$proxy_port);
echo "written: ".socket_write($sock,$connect).PHP_EOL;
//$data=socket_read($sock,1024,PHP_BINARY_READ);
while($data=socket_read($sock,1024,PHP_BINARY_READ)) var_dump($data);
$err=socket_last_error($sock);
$e=socket_get_option($sock,SOL_SOCKET,SO_ERROR);
var_dump($data,$err,socket_strerror($err),$e,socket_strerror($e));
Expected result:
In blocking mode:
while($data=socket_read($sock,1024,PHP_BINARY_READ))
will make two or more iterations, at last iteration socket_read will
return emty string indicating end of data.
In non-blocking mode:
socket_select will return socket two or more times as ready for
reading. Last time socket_read will return emty string indicating end of
data.
Actual result:
--
In blocking mode:
if I use a single socket_read($sock,1024,PHP_BINARY_READ) call, it
returns data without any significant delay or error. In that case there
are no problems.
But
while($data=socket_read($sock,1024,PHP_BINARY_READ))
will return all response in first iteration and then blocks until
timeout was reached (if I set it via socket_set_option) and return false
with EAGAIN error. If timeout is not set it will return epmty string and
no errors as expected, but before this block for couple of minutes.
In non-blocking:
Whole response was also successfully recieved after first socket_select
return, and then this socket has no more returned by socket_select as
ready for reading.
I've tested this on debian PHP 5.2.9-0.dotdeb.1 with Suhosin-Patch
0.9.7 and WinXP php 5.3.0 (binary from php.net) with some public socks
and connect proxies and with SHHTunnel 4.3.0.0 for Win which has built
in socks 4/5 proxy.
--
Edit this bug report at http://bugs.php.net/?id=49486&edit=1
#48216 [Opn]: PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra content at the end of the doc
ID: 48216
Updated by: sjo...@php.net
Reported By: mark at everytruckjob dot com
Status: Open
Bug Type: SOAP related
Operating System: CentOs 5.3
PHP Version: 5.3.0RC2
New Comment:
Thank you for your feedback.
It would be most helpful to us if you could supply us with the HTTP
transaction of the retrieval of the WSDL. You may use a sniffer like
Wireshark to obtain this information, or use this script I wrote
<http://www.gissen.nl/files/sniff.php>.
Previous Comments:
[2009-09-07 00:43:35] michael dot tibben at gmail dot com
We are experiencing a similar issue. However, the HTTP reply is using
chunked transfer encoding (Content-Length is NOT required when using
chunked)
HTTP/1.1 200 OK
Date: Sun, 06 Sep 2009 23:25:16 GMT
Server: Apache
X-Powered-By: Servlet/2.4 JSP/2.0
Transfer-Encoding: chunked
Content-Type: text/xml; charset=UTF-8
[2009-06-24 10:23:47] sjoerd-php at linuxonly dot nl
Thank you for your bug report.
The WSDL URL you supply does not send a Content-Length or
Transfer-Encoding header in some cases, which is mandatory in a response
with a body. In other words, it does not follow the HTTP protocol. You
should contact the provider of the WSDL about this.
GET /url HTTP/1.0
Host: example.com
HTTP/1.1 200 OK
Date: Wed, 24 Jun 2009 10:18:10 GMT
Server: Apache
Connection: close
Content-Type: text/xml
...
[2009-05-09 23:12:48] mark at everytruckjob dot com
Description:
Trying to set up a soapClient using the wsdl from the location found in
http://www.everytruckjob.com/php53-url.txt (this contains the url and is
not the wsdl file itself so I can remove the location once this report
is closed as it is not my soap server).
Copying the wsdl from the referenced location to my own
(http://www.everytruckjob.com/wsdl.php) or saving it to a local file
allows parsing to succeed, but while the file sizes seem to be the same,
I can't figure out what headers or content causes the "Extra content at
the end of the document" error.
This works as expected on php 5.2.9 compiled and in use on the same
client server with Centos 5.3 libxml2.x86_64 2.6.26-2.1.2.7.
Reproduce code:
---
http://www.everytruckjob.com/php53-url.txt'));
try {
$a = new SoapClient($wsdl);
} catch (SoapFault $e) {
var_dump(libxml_get_last_error());
var_dump($e);
}
?>
Expected result:
No SoapFault
Actual result:
--
object(LibXMLError)#1 (6) { ["level"]=> int(3) ["code"]=> int(5)
["column"]=> int(4) ["message"]=> string(41) "Extra content at the end
of the document " ["file"]=> string(55) "http://"; ["line"]=>
int(488) }
object(SoapFault)#2 (9) {
["message":protected]=> string(146) "SOAP-ERROR: Parsing WSDL:
Couldn't load from 'X' : Extra content at the end of the document "
--
Edit this bug report at http://bugs.php.net/?id=48216&edit=1
#47624 [Opn->Fbk]: SOAP response has int type for a key value that is out of range
ID: 47624 Updated by: sjo...@php.net Reported By: akshah123 at hotmail dot com -Status: Open +Status: Feedback Bug Type: SOAP related Operating System: Linux PHP Version: 5.3.0 New Comment: Thank you for your bug report. Could you please supply us with a piece of WSDL describing the array? Also, which client are you using which gives this error? If I understand correctly, the problem occurs with the soapenc:array type and the Axis 1 SOAP library. Previous Comments: [2009-09-01 21:26:28] akshah123 at hotmail dot com Hello, I have confirmed that this issue is in 5.3.0 and 5.2.10. [2009-03-20 15:06:49] akshah123 at hotmail dot com Is there any additional information that I can provide to perhaps speed up the process to resolve this ticket? [2009-03-11 14:49:18] akshah123 at hotmail dot com Description: It seems that instead of string, new version of PHP (5.2.9) has 884385070380 as opposed to for old version of PHP (5.2.2) returning 884385070380 for arrays in SOAP services. This causes the client to throw a soap fault error with "SOAP-ERROR: Encoding: Can't decode apache map, only Strings or Longs are allowd as keys". -- Edit this bug report at http://bugs.php.net/?id=47624&edit=1
#49499 [Opn->Bgs]: get and set are not fixed
ID: 49499
Updated by: sjo...@php.net
Reported By: ies_clan at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows XP home
PHP Version: 5.3.0
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The __get() function returns a reference to the array, and this
reference is used to change the array.
Previous Comments:
[2009-09-08 11:32:21] ies_clan at hotmail dot com
Description:
look @ the code
Reproduce code:
---
";
return $this->properties[$key];
}
public function __set($key, $val) {
echo "set $key to $val";
$this->properties[$key] = $val;
}
}
$c = new newclass;
$c->array['test'] = 'test';
Expected result:
get array
set array to test
Actual result:
--
get array
--
Edit this bug report at http://bugs.php.net/?id=49499&edit=1
#48524 [Opn]: Timeout setting is not considered on SOAP+HTTPS calls
ID: 48524
Updated by: sjo...@php.net
Reported By: valer_crisan at yahoo dot com
Status: Open
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.2.9
New Comment:
See also bug #41631
Previous Comments:
[2009-07-07 17:58:03] akomasinski at gmail dot com
I am seeing the same issue on PHP 5.3.0 on windows and linux. The
issue seems to be exactly as described.
[2009-06-10 19:06:43] valer_crisan at yahoo dot com
Description:
The default_socket_timeout option is not taken in consideration when
making SOAP requests to a HTTPS URL.
This causes big issues for us because, if the server hung for some
reason, the client waits forever to get a reply back.
The code works correctly when using HTTP URLs. But in our production
environment we need to use HTTPS so this is not a workaround.
Reproduce code:
---
SOAP Server code:
$Server = new SoapServer('ed.wsdl');
$Server->setClass('Ed');
$Server->handle();
class Ed{
public function hello($Input){
sleep(30);
return array('goodbye' => "Goodbye " . $Input->firstname);
}
}
SOAP client code:
echo "Start time: " . date('c') . "\n";
ini_set('soap.wsdl_cache_enabled', 0);
ini_set('default_socket_timeout', 5);
$Binding = new SoapClient('ed.wsdl', array('trace' => 1));
try {
$Return = $Binding->hello(array('firstname' => 'john'));
echo "Response: "; print_r($Return);
} catch( Exception $e ) {
echo "Exception: "; print_r($e);
}
echo "End time: " . date('c') . "\n";
Let me know if you need the wsdl file as well.
Expected result:
I expect a SOAP timeout exception to be thrown.
Actual result:
--
The client gets the server response after 30 seconds, as shown here:
Start time: 2009-06-10T11:58:30-07:00
Response: stdClass Object
(
[goodbye] => Goodbye john
)
End time: 2009-06-10T11:59:00-07:00
--
Edit this bug report at http://bugs.php.net/?id=48524&edit=1
#49512 [Opn->Bgs]: Not follow the Ooop's law
ID: 49512 Updated by: sjo...@php.net Reported By: binay dot kumar at osvin dot biz -Status: Open +Status: Bogus Bug Type: *Programming Data Structures Operating System: Any PHP Version: 5.2.10 New Comment: Thank you for your bug report. You should indeed use the static keyword if you want to call a method without creating an object instance. However, PHP allows it and generates an E_STRICT warning. This is meant to work like this, therefore this is not a bug. Previous Comments: [2009-09-09 12:44:35] binay dot kumar at osvin dot biz Description: ## in the above class i can access the class xyz method by "::", however i have not created the instance of the class. by the oop's law , we can access a method by this way,method defined as static method. its working fine in both case either create a object of the class or by "::" to access. can please describe me the things because its not following the oop's law. Regards Binay Kumar -- Edit this bug report at http://bugs.php.net/?id=49512&edit=1
#46130 [Opn->Fbk]: SOAP-ERROR: Parsing WSDL
ID: 46130
Updated by: sjo...@php.net
Reported By: cfelce at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: SOAP related
Operating System: GNU/Linux Ubuntu fesity
PHP Version: 5.2CVS-2008-09-19 (CVS)
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Previous Comments:
[2009-06-24 11:22:52] sjoerd-php at linuxonly dot nl
Thank you for your bug report.
The message "Unknown required WSDL extension" means that the WSDL uses
some extension and specifies that the client MUST understand it in order
to use the service. Appearantly, PHP SoapClient does not understand the
extension, thus causing this error.
Please provide the WSDL or information about the required extension.
[2009-03-11 19:35:13] michael dot schramm at gmail dot com
Same thing happens with PHP version 5.2.6:
SOAP-ERROR: Parsing WSDL: Unknown required WSDL extension
'http://schemas.xmlsoap.org/ws/2004/09/policy'
Changing the Service is not always an option!
[2008-12-31 11:12:18] omabil at gmail dot com
Hello everybody,
the work-around we used to avoid this problem is by using the standard
sap wsdl instead of the ws-policy one.
By replacing the "wspolicy" word by "standard" in the url of the wsdl
we've got a second wsdl which doesn't use the ws policies.
Regards,
--
Omabil
[2008-12-22 17:04:48] omabil at gmail dot com
Hello everybody,
someone has found some solution for this problem?
Thanks a lot,
--
Omabil
[2008-09-19 20:03:29] cfelce at gmail dot com
Description:
Hi experts,
I'm having some issues loading a wsdl file of a sap webservice and
the error comes as follows:
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Unknown required WSDL extension
'http://schemas.xmlsoap.org/ws/2004/09/policy' in /var/www/ws3.php:4
Stack trace: #0 /var/www/ws3.php(4): SoapClient-
>SoapClient('zws_panda.wsdl', Array) #1 {main} thrown in
/var/www/ws3.php on line 4
Reproduce code:
---
"cfelce",
'password' => "XX", 'compression' => SOAP_COMPRESSION_ACCEPT |
SOAP_COMPRESSION_GZIP, 'encoding' => 'utf-8' ));
print($client->ZWsPanda("123456789"));
?>
Expected result:
Information about the client
Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Unknown required WSDL extension
'http://schemas.xmlsoap.org/ws/2004/09/policy' in /var/www/ws3.php:4
Stack trace: #0 /var/www/ws3.php(4): SoapClient-
>SoapClient('zws_panda.wsdl', Array) #1 {main} thrown in
/var/www/ws3.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=46130&edit=1
#49169 [Opn->Ver]: SoapServer calls wrong function, although "SOAP action" header is correct
ID: 49169 Updated by: sjo...@php.net Reported By: jeroen at asystance dot nl -Status: Open +Status: Verified Bug Type: SOAP related Operating System: linux PHP Version: 5.2SVN-2009-08-05 (snap) New Comment: Could reproduce. Even though the soap action looked as follows: SOAPAction: "operation2" Operation 1 was called. Previous Comments: [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 s have the same API (that is, have the same s), the SoapServer calls the function corresponding to the _first_ specified in the , 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 s are listed in the 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_ 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 elements in the 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=49169&edit=1
#44248 [Opn->Ver]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248 Updated by: sjo...@php.net Reported By: jboffel at gmail dot com -Status: Open +Status: Verified Bug Type: SOAP related Operating System: Linux RedHat Enterprise PHP Version: 5.2.9 New Comment: Could reproduce. The SoapClient does indeed not send a Host parameter when doing a CONNECT, which is a bug because the RFC says it should. However, this causes no problems with any version of Apache I tried (1.3, 2.0, 2.2). Previous Comments: [2009-09-01 18:55:53] jboffel at gmail dot com The thing is that Apache server follow the RFC and really block (voluntarily that is not a bug) the request (there is no workaround to force Apache to do the job or I didn't find it). You can see in the error log file that Apache ask us to follow the RFC and add the Host parameter. So basically Apache used as a proxy doesn't really "need" Host parameter but it's to avoid bug when connecting, or example, to an Apache web server which uses VirtualHost based certificates configurations with HTTPS connections... So yes it's only linked to the RFC. [2009-09-01 18:43:54] sjo...@php.net Does the Apache proxy really need the Host header? Is this bug a problem other than that it does not conform with the RFC? [2009-09-01 17:14:32] jboffel at gmail dot com Hi, Thanks for your test, but you have to do it through HTTPS connection to reproduce the bug. In fact, the bug is linked to the use of an Apache proxy through HTTPS connection and a SOAP call. If you connect through HTTP you don't do the CONNECT command and you can't see the bug. [2009-09-01 17:11:14] sjo...@php.net I misunderstood the problem. The request I posted was for HTTP, not for HTTPS. For HTTPS, the Host header is indeed missing. I am not yet sure that that is a bug. [2009-09-01 17:02:47] sjo...@php.net Thank you for your bug report. I could not reproduce your problem. It is possible it has already been fixed in the meantime. This is the request the SoapClient sends to the proxy server in my setup: POST http://ws1.webservices.nl:80/address/soap.php HTTP/1.1 Host: ws1.webservices.nl Connection: Keep-Alive User-Agent: PHP-SOAP/5.2.11RC2-dev Content-Type: text/xml; charset=utf-8 SOAPAction: "http://ws1.webservices.nl/address/soap.php/addressReeksPostcodeSearch"; Content-Length: 552 ... etc. etc. Please reopen this bug if you still have this problem. 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/44248 -- Edit this bug report at http://bugs.php.net/?id=44248&edit=1
#49510 [Opn->Bgs]: boolean validation fails with FILTER_NULL_ON_FAILURE
ID: 49510
Updated by: sjo...@php.net
Reported By: m dot kurzyna at crystalpoint dot pl
-Status: Open
+Status: Bogus
Bug Type: Filter related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
This is exactly according to the documentation:
If FILTER_NULL_ON_FAILURE is set, FALSE is returned only for "0",
"false", "off", "no", and "", and NULL is returned for all non-boolean
values.
Note that "false" is in the list, but false is not. That is, the string
"false" will give a result, the boolean false will return null.
"Non-boolean" makes this a little bit confusing.
Note that the goal here is to convert a string to a boolean. Because
false is not a string, filter_var does not consider it valid input.
Previous Comments:
[2009-09-09 11:25:29] m dot kurzyna at crystalpoint dot pl
Description:
filter_var() when validating (boolean)false with FILTER_NULL_ON_FAILURE
returns null instead of false.
Reproduce code:
---
var_dump(
filter_var(false, FILTER_VALIDATE_BOOLEAN,
array("flags" => FILTER_NULL_ON_FAILURE)
)
);
Expected result:
false
Actual result:
--
null
--
Edit this bug report at http://bugs.php.net/?id=49510&edit=1
#44081 [Opn->Bgs]: Cannot execute queries while other unbuffered queries are active
ID: 44081
Updated by: sjo...@php.net
Reported By: abouzekry at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.9
New Comment:
Closing as requested.
Previous Comments:
[2009-09-09 11:42:47] webmaster at rdwonline dot com
I withdraw my bug report. I did not realize I was still using
libmysql. Apparently I need the new MySQL native driver to get the most
out of PDO_MYSQL.
[2009-09-06 14:46:05] webmaster at rdwonline dot com
I am using XAMPP (PHP 5.3.0 on Windows XP) and I am able to execute
succeeding prepared statements with no problem as long as I call
$PDOStatement->closeCursor() after I'm done with the previous one.
The problem arises with MySQL stored procedures. PDO will execute and
successfully retrieve records from the first stored procedure but all
other statements afterwards WILL NOT EXECUTE, and I too get the error
below:
"Cannot execute queries while other unbuffered queries are active.
Consider using PDOStatement::fetchAll(). Alternatively, if your code is
only ever going to run against mysql, you may enable query buffering by
setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute."
I tried adding in the aforemention attribute to no avail.
Here is a snippet from a script I used to test this:
$PDOStatement = $PDO->prepare('SELECT * FROM MagicCards WHERE cardID =
?');
$PDOStatement->bindValue(1, 1600);
$PDOStatement->execute();
$PDOStatement->setFetchMode(\PDO::FETCH_ASSOC);
$rows = $PDOStatement->fetchAll();
$PDOStatement->closeCursor();
$PDOStatement = NULL;
print_r($rows); // works as expected
$PDOStatement = $PDO->prepare('CALL uspGetMagicCardByKey(?)');
$PDOStatement->bindValue(1, 10);
$PDOStatement->execute();
$PDOStatement->setFetchMode(\PDO::FETCH_ASSOC);
$rows = $PDOStatement->fetchAll();
$PDOStatement->closeCursor();
$PDOStatement = NULL;
print_r($rows); //works as expected
$PDOStatement = $PDO->prepare('SELECT * FROM MagicCards WHERE cardID =
?');
$PDOStatement->bindValue(1, 1600);
$PDOStatement->execute(); //errors out right here with the HY000 error
$PDOStatement->setFetchMode(\PDO::FETCH_ASSOC);
$rows = $PDOStatement->fetchAll();
$PDOStatement->closeCursor();
$PDOStatement = NULL;
print_r($rows); //doesn't get this far
The workaround would be to drop in your SQL from your stored procedure
directly as an argument to $PDO->prepare(). But if you are doing any
other modifications before or after that main SELECT statement, this is
not a feasible solution.
This is a critical bug that needs to be fixed ASAP.
[2009-07-23 08:30:58] sebastien dot barbieri at gmail dot com
Same issue with PHP 5.2.10 (Linux/Mac/Windows) with a similar code:
$this->dbh = new PDO($this->options['dsn'], $this->options['username'],
$this->options['password'], array(PDO::MYSQL_ATTR_INIT_COMMAND => 'SET
NAMES '.$this->options['charset']));
$this->dbh->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, true);
$this->dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
$sth = $this->dbh->prepare($_stored_proc_1);
$sth->bindValue('I_bind', $value, PDO::PARAM_STR);
$sth->execute();
$object = $sth->fetchAll(PDO::FETCH_ASSOC);
$sth->closeCursor();
$sth = $this->dbh->prepare($_stored_proc_2);
$sth->bindValue('I_bind', $value, PDO::PARAM_STR);
$sth->execute();
$object = $sth->fetchAll(PDO::FETCH_ASSOC);
$sth->closeCursor();
However no problem at all if I install php 5.2.10 Zend Community
Edition ... :-)
[2009-06-10 21:49:52] stewart dot duncan at rocketmail dot com
Confirmed, still broken in latest snapshot.
[2009-05-16 20:12:05] abouzekry at gmail dot com
the bug wasn't resolved in the latest code snapshot, it's more than a
year now!!!
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/44081
--
Edit this bug report at http://bugs.php.net/?id=44081&edit=1
#49517 [Opn->Ver]: cURL's CURLOPT_FILE prevents file from being deleted after fclose
ID: 49517 Updated by: sjo...@php.net Reported By: niraj at bhawnani dot name -Status: Open +Status: Verified Bug Type: Filesystem function related Operating System: Windows Vista PHP Version: 5.3.0 New Comment: Could reproduce. Previous Comments: [2009-09-10 06:27:39] niraj at bhawnani dot name It is definitely related to Bug #48676, if I fclose($fp) twice, it works. Here's the same code with a workaround, that makes the unlink work fine: http://bugs.php.net/gifs/logo-bug.gif'); curl_setopt($curl, CURLOPT_FILE, $fp); curl_setopt($curl, CURLOPT_FAILONERROR, true); curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 10); // 10 sec curl_setopt($curl, CURLOPT_TIMEOUT, 600); // 10 mins curl_exec($curl); curl_close($curl); fclose($fp); if (is_resource($fp)) fclose($fp); unlink($filename); ?> [2009-09-10 06:16:30] niraj at bhawnani dot name Description: I spent hours debugging some code I'd written that wasn't working only to find that cURL is behaving strangely. I've taken the minimal parts of that code and put it in this bug report. Basically, if you open a file with fopen, fclose it and then unlink it, it works fine. But if between fopen and fclose, you give the file handle to cURL to do some writing into the file, then the unlink fails. Why this is happening is beyond me. I think it may be related to Bug #48676 I have not had the opportunity to test this on Linux, so I don't know if it's Windows-only. Reproduce code: --- http://bugs.php.net/gifs/logo-bug.gif'); curl_setopt($curl, CURLOPT_FILE, $fp); curl_setopt($curl, CURLOPT_FAILONERROR, true); curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 10); // 10 sec curl_setopt($curl, CURLOPT_TIMEOUT, 600); // 10 mins curl_exec($curl); curl_close($curl); fclose($fp); unlink($filename); ?> Expected result: No errors, file unlinks successfully. Actual result: -- Warning: unlink(tempfile) [function.unlink]: Permission denied in C:\...\blah.php on line 14 -- Edit this bug report at http://bugs.php.net/?id=49517&edit=1
#48676 [Bgs]: CURLOPT_FILE increases file handle refcount
ID: 48676
Updated by: sjo...@php.net
Reported By: felix-php at 7val dot com
Status: Bogus
Bug Type: cURL related
Operating System: Debian Linux (etch)
PHP Version: 5.2.10
New Comment:
This bug has been filed again as #49517.
Previous Comments:
[2009-06-29 12:43:58] felix-php at 7val dot com
I have installed the latest snapshot to check if bug #48518 has also
fixed my issue.
now the content can be read from the outfile directly after
curl_exec().
but:
1. the problem remains using the multi-api
2. my reproduce code still shows that fclose() does not close the
handle. it has to be called twice to actually have is_resouce() return
false.
i think the new fflush() call introduced in curl_exec() just
workarounds
the problem. fclose() will usually flush the file handle itself. thus
the reproduce code has worked with php 5.2.10 by fclose'ing twice.
[2009-06-26 23:19:00] j...@php.net
See bug #48518 (same issue)
[2009-06-24 14:21:44] felix-php at 7val dot com
The reproduce code is not completly correct: The curl_close() call was
meant to be after curl_exec() and before the first fclose().
But interestingly this does not change the behaviour in neither 5.2.9
nor 5.2.10.
[2009-06-24 14:17:57] felix-php at 7val dot com
Description:
When passing an open, writable file handle to Curl as the CURLOPT_FILE
option, the refcount to that file handle is increased without being
decreased when calling curl_close.
Thus the file handle has to be closed TWICE to actually being flushed
and closed. In the reproduce code the file handle is still a valid
resource after the first call to fclose().
The bug is reproducable in PHP 5.2.10. In 5.2.9 the code works as
expected.
In 5.2.10 in ext/curl/interface.c:1440 the call
zend_list_addref(Z_LVAL_PP(zvalue));
was added. Maybe the problem origins here, if there is no corresponding
delref in curl_close()?
Reproduce code:
---
$fh = fopen('curl.out', 'w');
$c = curl_init('http://example.com');
curl_setopt($c, CURLOPT_FILE, $fh);
curl_exec($c);
fclose($fh);
echo "content 1: ". file_get_contents('curl.out') ."\n";
if (is_resource($fh)) {
echo "file still open -> wrong\n";
} else {
echo "file closed -> correct\n";
exit;
}
fclose($fh);
if (is_resource($fh)) {
echo "file open 2\n";
}
curl_close($c);
echo "content 2: ". file_get_contents('curl.out') ."\n";
Expected result:
content 1:
Example Web Page
[..]
file closed -> correct
Actual result:
--
content 1:
file still open -> wrong
content 2:
Example Web Page
[..]
--
Edit this bug report at http://bugs.php.net/?id=48676&edit=1
#44248 [Ver->Asn]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248 Updated by: sjo...@php.net Reported By: jboffel at gmail dot com -Status: Verified +Status: Assigned Bug Type: SOAP related Operating System: Linux RedHat Enterprise PHP Version: 5.2.9 -Assigned To: +Assigned To: dmitry New Comment: Dmitry, you seem to be the expert on SOAP/HTTP connecting. Can you take this bug? Previous Comments: [2009-09-09 20:55:53] jboffel at gmail dot com Did you test to use Apache like web server or like proxy ? I had problem when used like proxy with Apache 1.3 You should get a 400 Bad Request error status code... The only case it could not return error is if the host is in fact an IP. In that case host parameter is supposed to be sent empty so it's possible they decided to accept without complaining requests in this particular case. [2009-09-09 19:46:28] sjo...@php.net Could reproduce. The SoapClient does indeed not send a Host parameter when doing a CONNECT, which is a bug because the RFC says it should. However, this causes no problems with any version of Apache I tried (1.3, 2.0, 2.2). [2009-09-01 18:55:53] jboffel at gmail dot com The thing is that Apache server follow the RFC and really block (voluntarily that is not a bug) the request (there is no workaround to force Apache to do the job or I didn't find it). You can see in the error log file that Apache ask us to follow the RFC and add the Host parameter. So basically Apache used as a proxy doesn't really "need" Host parameter but it's to avoid bug when connecting, or example, to an Apache web server which uses VirtualHost based certificates configurations with HTTPS connections... So yes it's only linked to the RFC. [2009-09-01 18:43:54] sjo...@php.net Does the Apache proxy really need the Host header? Is this bug a problem other than that it does not conform with the RFC? [2009-09-01 17:14:32] jboffel at gmail dot com Hi, Thanks for your test, but you have to do it through HTTPS connection to reproduce the bug. In fact, the bug is linked to the use of an Apache proxy through HTTPS connection and a SOAP call. If you connect through HTTP you don't do the CONNECT command and you can't see the bug. 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/44248 -- Edit this bug report at http://bugs.php.net/?id=44248&edit=1
#49510 [Asn]: boolean validation fails with FILTER_NULL_ON_FAILURE
ID: 49510
Updated by: sjo...@php.net
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Assigned
Bug Type: Filter related
Operating System: Linux
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Why do you think it is wrong that it returns null for an empty string?
Previous Comments:
[2009-09-10 08:53:11] m dot kurzyna at crystalpoint dot pl
Actually it is broken even more then i initially reported because it
also returns NULL for empty string:
filter_var('',FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE))
// got NULL, expected false
The problem is in ext/filter/logical_filters.c(233) - the check is done
by using string representation of zval being checked. For false value
it's an empty string and the switch from line 244 doesn't cover this
case (hence same result for false and empty string).
Something along the lines of following patch should fix the problem:
--- logical_filters.c 2009-06-10 21:01:17.0 +0200
+++ logical_filters.fixed.c 2009-09-10 10:48:59.953675880 +0200
@@ -242,6 +242,10 @@
* returns false for "0", "false", "off", "no", and ""
* null otherwise. */
switch (len) {
+ case 0:
+ ret = 0;
+ break;
+
case 1:
if (*str == '1') {
ret = 1;
On the side note: i was always wondering why (string)false == '' and
not '0'?
[2009-09-09 23:00:32] paj...@php.net
This case sounds wrong:
filter_var(false,FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
// got NULL, expected false
I have to check back the code, but this case does not make sense to me.
[2009-09-09 22:30:34] m dot kurzyna at crystalpoint dot pl
If this is, as you say, intended behaviour then sorry, but it's broken
by design. Although because of BC it'll never get fixed unfortunately so
i'll just vent my frustration.
In current state you have no way to use filters to *validate* boolean
input (note that this is filter_validate_boolean not
filter_sanitize_boolean - there is no such).
As a sanitizer it's also broken though because real boolean values
can't be used (or distinguished from error values when
FILTER_NULL_ON_FAILURE is given) so you'd have to first check whether
value is boolean and if not try to sanitize it to boolean using
validating filter. It even sound broken.
Also it's internally inconsistent. It works as expected for plain
filtering:
var_dump(
filter_var(true,FILTER_VALIDATE_BOOLEAN), // true
filter_var("true",FILTER_VALIDATE_BOOLEAN), // true
filter_var(1,FILTER_VALIDATE_BOOLEAN), // true
filter_var("1",FILTER_VALIDATE_BOOLEAN),// true
filter_var("on",FILTER_VALIDATE_BOOLEAN), // true
filter_var("yes",FILTER_VALIDATE_BOOLEAN) // true
);
var_dump(
filter_var(false,FILTER_VALIDATE_BOOLEAN), // false
filter_var("false",FILTER_VALIDATE_BOOLEAN),// false
filter_var(0,FILTER_VALIDATE_BOOLEAN), // false
filter_var("0",FILTER_VALIDATE_BOOLEAN),// false
filter_var("off",FILTER_VALIDATE_BOOLEAN), // false
filter_var("no",FILTER_VALIDATE_BOOLEAN)// false
);
var_dump(
filter_var(7,FILTER_VALIDATE_BOOLEAN), // false
filter_var("garbage",FILTER_VALIDATE_BOOLEAN) // false
);
But fails to keep consistency when i try to distinguish whether value
is "boolean" or not witch should be the sole role of *VALIDATE* filter:
var_dump(
filter_var(true,FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var("true",FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var(1,FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var("1",FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var("on",FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
// got true, expected true
filter_var("yes",FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE))
// got true, expected true
);
var_dump(
filter_var(false,FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
// got NULL, expected false
filter_var("false",FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
// got false, expected false
filter_var(0,FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
// got false, exp
#49518 [Opn->Fbk]: can't open encrypted sqlite3 database
ID: 49518
Updated by: sjo...@php.net
Reported By: wjzhhr at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: SQLite related
Operating System: windwos xp
PHP Version: 5.3.0
New Comment:
Does it work when you supply the right encryption key as the third
parameter?
SQLite3::__construct ( string $filename [, int $flags [, string
$encryption_key ]] )
Previous Comments:
[2009-09-10 08:15:49] wjzhhr at gmail dot com
Description:
can't open encrypted database which created by wxSQLite.
exec("PRAGMA KEY='1'");
$result = $db->query('SELECT * FROM xxx');
var_dump($result->fetchArray());
?>
Warning: SQLite3::query(): Unable to prepare statement: 26, file is
encrypted or is not a database
Reproduce code:
---
---
>From manual page: sqlite3.open
---
Expected result:
my table: CREATE TABLE xxx(iswho text,itimes int);
liming|1
xiaojie|2
two records.
Expected result:
array(4) {
[0]=>
string(6) "liming"
["iswho"]=>
string(6) "liming"
[1]=>
int(1)
["itimes"]=>
int(1)
}
Actual result:
--
Warning: SQLite3::query(): Unable to prepare statement: 26, file is
encrypted or is not a database
--
Edit this bug report at http://bugs.php.net/?id=49518&edit=1
#49510 [Asn]: boolean validation fails with FILTER_NULL_ON_FAILURE
ID: 49510
Updated by: sjo...@php.net
Reported By: m dot kurzyna at crystalpoint dot pl
Status: Assigned
Bug Type: Filter related
Operating System: Linux
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
I agree that filter_var() should return null for the empty string. I
think that this usage of filter_var() is meant to convert string
representations of booleans to boolean values. That is, "true", "on",
"1", "false", "off" and "0" should be converted, other strings should
return null.
Previous Comments:
[2009-09-10 09:05:53] m dot kurzyna at crystalpoint dot pl
Personally i think it's just fine (empty string ain't false - if
anything it's null) but in PHP world it is (both on PHP and C levels):
(string)false = ''
(boolean)'' == false
Z_STRLEN_P(value) = 0
Oh, and there is this little documentation thingy you like to cite from
time to time:
If FILTER_NULL_ON_FAILURE is set, FALSE is returned only for "0",
"false", "off", "no", and "", and NULL is returned for all non-boolean
values.
where empty string is explicitly stated as being false.
[2009-09-10 08:57:29] sjo...@php.net
Why do you think it is wrong that it returns null for an empty string?
[2009-09-10 08:53:11] m dot kurzyna at crystalpoint dot pl
Actually it is broken even more then i initially reported because it
also returns NULL for empty string:
filter_var('',FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE))
// got NULL, expected false
The problem is in ext/filter/logical_filters.c(233) - the check is done
by using string representation of zval being checked. For false value
it's an empty string and the switch from line 244 doesn't cover this
case (hence same result for false and empty string).
Something along the lines of following patch should fix the problem:
--- logical_filters.c 2009-06-10 21:01:17.0 +0200
+++ logical_filters.fixed.c 2009-09-10 10:48:59.953675880 +0200
@@ -242,6 +242,10 @@
* returns false for "0", "false", "off", "no", and ""
* null otherwise. */
switch (len) {
+ case 0:
+ ret = 0;
+ break;
+
case 1:
if (*str == '1') {
ret = 1;
On the side note: i was always wondering why (string)false == '' and
not '0'?
[2009-09-09 23:00:32] paj...@php.net
This case sounds wrong:
filter_var(false,FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
// got NULL, expected false
I have to check back the code, but this case does not make sense to me.
[2009-09-09 22:30:34] m dot kurzyna at crystalpoint dot pl
If this is, as you say, intended behaviour then sorry, but it's broken
by design. Although because of BC it'll never get fixed unfortunately so
i'll just vent my frustration.
In current state you have no way to use filters to *validate* boolean
input (note that this is filter_validate_boolean not
filter_sanitize_boolean - there is no such).
As a sanitizer it's also broken though because real boolean values
can't be used (or distinguished from error values when
FILTER_NULL_ON_FAILURE is given) so you'd have to first check whether
value is boolean and if not try to sanitize it to boolean using
validating filter. It even sound broken.
Also it's internally inconsistent. It works as expected for plain
filtering:
var_dump(
filter_var(true,FILTER_VALIDATE_BOOLEAN), // true
filter_var("true",FILTER_VALIDATE_BOOLEAN), // true
filter_var(1,FILTER_VALIDATE_BOOLEAN), // true
filter_var("1",FILTER_VALIDATE_BOOLEAN),// true
filter_var("on",FILTER_VALIDATE_BOOLEAN), // true
filter_var("yes",FILTER_VALIDATE_BOOLEAN) // true
);
var_dump(
filter_var(false,FILTER_VALIDATE_BOOLEAN), // false
filter_var("false",FILTER_VALIDATE_BOOLEAN),// false
filter_var(0,FILTER_VALIDATE_BOOLEAN), // false
filter_var("0",FILTER_VALIDATE_BOOLEAN),// false
filter_var("off",FILTER_VALIDATE_BOOLEAN), // false
filter_var("no",FILTER_VALIDATE_BOOLEAN)// false
);
var_dump(
filter_var(7,FILTER_VALIDATE_BOOLEAN), // false
filter_var("garbage",FILTER_VALIDATE_BOOLEAN) // false
);
But fails to keep consistency when i try to distinguish whether value
is "boolean" or not witch should be the sole role of *VALIDATE* filter:
var_dump(
filter_var(true,FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE)),
#49519 [Fbk->Bgs]: Passing tmpfile() to CURLOPT_FILE gives warning
ID: 49519 Updated by: sjo...@php.net Reported By: sjoerd-php at linuxonly dot nl -Status: Feedback +Status: Bogus Bug Type: cURL related Operating System: * PHP Version: 5.3.0 New Comment: Could not reproduce with latest 5.3 branch. Previous Comments: [2009-09-10 13:04:46] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine for me.. [2009-09-10 10:16:58] sjoerd-php at linuxonly dot nl Description: Passing a resource created by tmpfile() gives a warning that the resource is not writable. Reproduce code: --- Expected result: No warning. Actual result: -- Warning: curl_setopt(): the provided file handle is not writable in /Volumes/sjoerd-nfs/public_html/svnreps/test/a.php on line 4 -- Edit this bug report at http://bugs.php.net/?id=49519&edit=1
#48590 [Opn->Ver]: SOAP Client (redirect loop)
ID: 48590
Updated by: sjo...@php.net
Reported By: erik at datahack dot se
-Status: Open
+Status: Verified
Bug Type: SOAP related
Operating System: *
PHP Version: 5.3.0RC3
New Comment:
Could reproduce with latest 5.3.
Previous Comments:
[2009-06-17 21:11:45] erik at datahack dot se
The sample code has an extra comma after the "'stream_context' =>
$context,".
[2009-06-17 21:05:23] erik at datahack dot se
Description:
A SOAPClient can be stuck in a redirect loop (and in some cases crash).
Other PHP functions have solved this by a default redirection limit of
20 redirects (maybe a php.ini setting) or a custom value of a stream
context -> http -> max_redirects.
I provide two examples, one where PHP crashes after ~200 requests and
one where it just loops forever.
Reproduce code:
---
redirection-loop.php:
client code (crashes):
array('max_redirects' => 3))
);
$soap = new SOAPClient(NULL,
array(
'uri' => 'foo',
'location' => 'http://example.com/redirection-loop.php',
'stream_context' => $context,
)
);
$soap->test();
?>
client code (never finishes):
'foo',
'location' => 'http://example.com/redirection-loop.php'
)
);
$soap->test();
?>
Expected result:
I expect it to have a default limit of 20 but also respect the
max_requests value in the stream context. If the limit is reached I
would expect a SOAPFault with a similar error description as below.
When requesting the same file (redirection-loop.php) with
file_get_contents() you get a warning and a empty result is returned.
Warning: file_get_contents(http://example.com/redirection-loop.php):
failed to open stream: Redirection limit reached, aborting in Command
line code on line 1
Actual result:
--
This is what happens if you specify a stream_context and tries to make
it respect the max_requests (which is does not)...
(gdb) bt
#0 0x082e2c9e in php_stream_context_get_option (context=0xa2eb5b4,
wrappername=0x85eb353 "socket", optionname=0x8623e2a "bindto",
optionvalue=0xbf866d04) at
php-5.3.0RC3/main/streams/streams.c:2036
#1 0x082ef2e3 in php_tcp_sockop_set_option (stream=0xa2eac68,
option=7, value=0, ptrparam=0xbf866dd0)
at php-5.3.0RC3/main/streams/xp_socket.c:641
#2 0x082e27d2 in _php_stream_set_option (stream=0xa2eac68, option=7,
value=0, ptrparam=0xbf866dd0)
at php-5.3.0RC3/main/streams/streams.c:1175
#3 0x082ed90f in php_stream_xport_connect (stream=0xa2eac68,
name=0xa2eac16 "example.com:80", namelen=16, asynchronous=0,
timeout=0xbf866e84, error_text=0xbf866e8c, error_code=0x0) at
php-5.3.0RC3/main/streams/transports.c:230
#4 0x082edcca in _php_stream_xport_create (name=0xa2eac16
"example.org:80", namelen=16, options=12, flags=0, persistent_id=0x0,
timeout=0xbf866e84, context=0xa2eb5b4, error_string=0x0,
error_code=0x0)
at php-5.3.0RC3/main/streams/transports.c:143
#5 0x081d56c6 in make_http_soap_request (this_ptr=0xa2ea634,
buf=0xa35d5f0 "\nhttp://schemas.xmlsoap.org/soap/envelope/\";
xmlns:ns1=\"foo\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\";
xmlns:SOAP-ENC="..., buf_size=378,
location=0xa2eaa18 "http://example.com/redirection-loop.php";,
soapaction=0xa2eab9c "foo#test", soap_version=1,
buffer=0xa2eab1c, buffer_len=0xa2eab20) at
php-5.3.0RC3/ext/soap/php_http.c:120
#6 0x081b41d0 in zim_SoapClient___doRequest (ht=5,
return_value=0xa2eab1c, return_value_ptr=0xbf8673c8, this_ptr=0xa2ea634,
return_value_used=1) at php-5.3.0RC3/ext/soap/soap.c:3249
(gdb) f 0
#0 0x082e2c9e in php_stream_context_get_option (context=0xa2eb5b4,
wrappername=0x85eb353 "socket", optionname=0x8623e2a "bindto",
optionvalue=0xbf866d04) at
php-5.3.0RC3/main/streams/streams.c:2036
2036if (FAILURE == zend_hash_find(Z_ARRVAL_P(context->options),
(char*)wrappername, strlen(wrappername)+1, (void**)&wrapperhash)) {
--
Edit this bug report at http://bugs.php.net/?id=48590&edit=1
#49528 [Opn]: UTF-16 strings prefixed by BOMs wrondly converted
ID: 49528 Updated by: sjo...@php.net Reported By: moriyo...@php.net Status: Open Bug Type: mbstring related Operating System: N/A PHP Version: 5.3SVN-2009-09-11 (SVN) New Comment: It can be argued that the BOM character U+FEFF should never be converted, as it is no real character. I don't think it is the task of mb_convert_encoding to detect the byte order and interpret the BOM. Previous Comments: [2009-09-11 07:45:05] moriyo...@php.net Description: The first character of a UTF-16 string prefixed by "\xff\xfe" (LE BOM) gets converted to wrong Unicode codepoint. Moreover, the resulting string contains the BOM itself while it is uncalled for. Reproduce code: --- Expected result: string(8) "02010403" Actual result: -- string(12) "fe010403" -- Edit this bug report at http://bugs.php.net/?id=49528&edit=1
#44995 [Opn]: bcpowmod() using a scale function always returns 0
ID: 44995
Updated by: sjo...@php.net
Reported By: nat at fishtrap dot co dot uk
Status: Open
Bug Type: BC math related
Operating System: Linux
PHP Version: 5.2CVS-2008-05-14 (snap)
New Comment:
This seems to be a bug in the bc library. I asked jhasler to look into
it.
Previous Comments:
[2008-05-14 16:26:56] nat at fishtrap dot co dot uk
Description:
When using the 4th optional parameter of bcpowmod. The answer is always
zero and does not match the answer using bc directly.
This is also true if you set the scale using bcscale(1).
In short if the scale is non zero I can't find any way of getting
anything apart from zero as the result.
Reproduce code:
---
echo bcpowmod("4", "4", "3", 1 ) ,PHP_EOL;
Expected result:
0.1
in bc
scale =1;
4^4%3;
.1
Actual result:
--
0.0
--
Edit this bug report at http://bugs.php.net/?id=44995&edit=1
#46463 [Opn->Fbk]: fgetcsv() omits empty fields
ID: 46463
Updated by: sjo...@php.net
Reported By: php-bugs at christoph-jeschke dot de
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: GNU/Linux
PHP Version: 5.2CVS-2008-11-01
New Comment:
Thank you for your bug report.
Your example uses a strange delimeter. First, it contains multiple
characters. Second, it contains non-ASCII characters. The documentation
says that the delimeter should be one character. When I try your
example, the lines are not split at all, so I can not reproduce the
problem.
Can you reproduce the problem with an ASCII-delimeter consisting of
multiple characters? Can you reproduce the problem with a delimiter
which is a single non-ASCII character? Can you still reproduce the
problem with the latest PHP version?
Previous Comments:
[2008-11-02 13:53:59] php-bugs at christoph-jeschke dot de
# php -v
PHP 5.2.7RC3-dev (cli) (built: Nov 2 2008 14:49:46)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologie
Returns:
array(3) {
[0]=>
string(7) "line1f1"
[1]=>
string(7) "line1f2"
[2]=>
string(7) "line1f3"
}
array(3) {
[0]=>
string(7) "line2f1"
[1]=>
string(7) "line2f2"
[2]=>
string(7) "line2f3"
}
array(2) {
[0]=>
string(7) "line3f1"
[1]=>
string(7) "line3f3"
}
The empty field is still omitted.
[2008-11-02 09:26:57] php-bugs at christoph-jeschke dot de
Description:
Since PHP5, fgetcsv() omits empty fields instead returning a empty
string as did in PHP4.
Reproduce code:
---
csv.php
===
paragraph.csv
=
line1f1§line1f2§line1f3
line2f1§line2f2§line2f3
line3f1§§line3f3
Expected result:
array(3) {
[0]=>
string(7) "line1f1"
[1]=>
string(7) "line1f2"
[2]=>
string(7) "line1f3"
}
array(3) {
[0]=>
string(7) "line2f1"
[1]=>
string(7) "line2f2"
[2]=>
string(7) "line2f3"
}
array(3) {
[0]=>
string(7) "line3f1"
[1]=>
string(0) ""
[2]=>
string(7) "line3f3"
}
Actual result:
--
array(3) {
[0]=>
string(7) "line1f1"
[1]=>
string(7) "line1f2"
[2]=>
string(7) "line1f3"
}
array(3) {
[0]=>
string(7) "line2f1"
[1]=>
string(7) "line2f2"
[2]=>
string(7) "line2f3"
}
array(2) {
[0]=>
string(7) "line3f1"
[1]=>
string(7) "line3f3"
}
--
Edit this bug report at http://bugs.php.net/?id=46463&edit=1
#49278 [Opn->Ver]: SoapClient::__getLastResponseHeaders returns NULL if wsdl operation !has output
ID: 49278 Updated by: sjo...@php.net Reported By: jeroen at asystance dot nl -Status: Open +Status: Verified Bug Type: SOAP related Operating System: linux PHP Version: 5.3SVN-2009-08-17 (snap) New Comment: Thank you for your bug report. Apparently, the response is not parsed at all when the method returns nothing. This gives problems with getLastResponseHeaders, as the bug reporter described. Furthermore, if the server returns a HTTP status such as 404 Not Found or 500 Internal Error, the client should does not throw a SoapFault, where it should. See ext/soap/php_http.c:771. Previous Comments: [2009-08-17 10:07:52] jeroen at asystance dot nl Description: For s that do not have output, SoapClient does not return last response headers. Reproduce code: --- download http://jayvee.nl/soaptest3.tar change URL in interface.wsdl to point to SOAPtest.php SOAPtest.php contains both client and server code, so just run php SOAPtest.php Expected result: SoapClient::getLastResponseHeaders should return string Actual result: -- SoapClient::getLastResponseHeaders returns NULL -- Edit this bug report at http://bugs.php.net/?id=49278&edit=1
#49244 [Ver]: Floating point NaN cause garbage characters
ID: 49244
Updated by: sjo...@php.net
Reported By: ronlentjes at yahoo dot com dot au
Status: Verified
Bug Type: Scripting Engine problem
Operating System: Linux Fedora 8
PHP Version: 5.3.0
New Comment:
I can't commit things. Somebody with SVN access should apply my patch
and commit it. I've improved some things and added a testcase:
Index: ext/standard/formatted_print.c
===
--- ext/standard/formatted_print.c (revision 288201)
+++ ext/standard/formatted_print.c (working copy)
@@ -42,6 +42,8 @@
#define FLOAT_PRECISION 6
#define MAX_FLOAT_DIGITS 38
#define MAX_FLOAT_PRECISION 40
+#define NOT_A_NUMBER "NaN"
+#define INFINITE "INF"
#if 0
/* trick to control varargs functions through cpp */
@@ -231,15 +233,15 @@
if (zend_isnan(number)) {
is_negative = (number<0);
- php_sprintf_appendstring(buffer, pos, size, "NaN", 3, 0,
padding,
-alignment,
precision, is_negative, 0, always_sign);
+ php_sprintf_appendstring(buffer, pos, size, NOT_A_NUMBER,
strlen(NOT_A_NUMBER), 0, padding,
+ alignment, strlen(NOT_A_NUMBER),
is_negative, 0, always_sign);
return;
}
if (zend_isinf(number)) {
is_negative = (number<0);
- php_sprintf_appendstring(buffer, pos, size, "INF", 3, 0,
padding,
-alignment,
precision, is_negative, 0, always_sign);
+ php_sprintf_appendstring(buffer, pos, size, INFINITE,
strlen(INFINITE), 0, padding,
+ alignment, strlen(INFINITE),
is_negative, 0, always_sign);
return;
}
Index: ext/standard/tests/strings/bug49244.phpt
===
--- ext/standard/tests/strings/bug49244.phpt(revision 0)
+++ ext/standard/tests/strings/bug49244.phpt(revision 0)
@@ -0,0 +1,8 @@
+--TEST--
+Bug #49244 (Floating point NaN cause garbage characters)
+--FILE--
+
+--EXPECT--
+NaN
Previous Comments:
----
[2009-09-01 16:34:22] garre...@php.net
sjoerd -- That fix works fine for me.
Can you commit that?
----
[2009-08-20 19:19:13] sjoerd-php at linuxonly dot nl
The problem is with calling php_sprintf_appendstring. Its 9th parameter
is not precision, it is length.
Index: ext/standard/formatted_print.c
===
--- ext/standard/formatted_print.c (revision 287513)
+++ ext/standard/formatted_print.c (working copy)
@@ -232,14 +232,14 @@
if (zend_isnan(number)) {
is_negative = (number<0);
php_sprintf_appendstring(buffer, pos, size, "NaN", 3, 0,
padding,
-alignment,
precision, is_negative, 0, always_sign);
+alignment, 3,
is_negative, 0, always_sign);
return;
}
if (zend_isinf(number)) {
is_negative = (number<0);
php_sprintf_appendstring(buffer, pos, size, "INF", 3, 0,
padding,
-alignment,
precision, is_negative, 0, always_sign);
+alignment, 3,
is_negative, 0, always_sign);
return;
}
----
[2009-08-20 11:15:47] sjoerd-php at linuxonly dot nl
Could reproduce with PHP 5.2.10.
[2009-08-14 04:25:22] ronlentjes at yahoo dot com dot au
Perhaps you test it differently than I do. I'll give you the easiest
way to see it happen:
put this in a file called test.php:
---
---
Output will be (bash, Fedora 8, Linux):
# php test.php
---
NaN*A
---
Output for browser will be NaN??? or NaN???F or other variations of
that.
This is reporducable on versions 4.2.2 (crash), 5.2.4, 5.3.0 (as
indicated previously).
I just retried this now.
Cheers,
Ron Lentjes
LC CLS.
[2009-08-13 14:29:39] ras...@php.net
I am unable to reproduce this in neither 5.2 nor 5.3, and Valgrind is
clean on Debian.
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/49244
--
Edit this bug report at http://bugs.php.net/?id=49244&edit=1
#44995 [Opn]: bcpowmod() using a scale function always returns 0
ID: 44995
Updated by: sjo...@php.net
Reported By: nat at fishtrap dot co dot uk
Status: Open
Bug Type: BC math related
Operating System: Linux
PHP Version: 5.2CVS-2008-05-14 (snap)
New Comment:
John Hasler said:
The example in #44995 is wrong. "^" has higher precedence than "%" so
"4^4%3" means "(4^4)%3" or "256%3", not "4^(4%3). The latter gives a
runtime error in bc with scale=1, as it should as fractional exponents
are not supported.
>From number.c:
/* Raise BASE to the EXPO power, reduced modulo MOD. The result is
placed in RESULT. If a EXPO is not an integer,
only the integer part is used. */
...
...
...
/* Check the base for scale digits. */
if (base->n_scale != 0)
bc_rt_warn ("non-zero scale in base");
/* Check the exponent for scale digits. */
if (exponent->n_scale != 0)
{
bc_rt_warn ("non-zero scale in exponent");
bc_divide (exponent, _one_, &exponent, 0); /*truncate */
}
/* Check the modulus for scale digits. */
if (mod->n_scale != 0)
bc_rt_warn ("non-zero scale in modulus");
...
...
...
As you can see, non-zero scale is not supported. Thus the bug is in
bcpowmod(). It should not accept a scale, and the documentation
should
say so.
Previous Comments:
[2009-09-19 18:22:41] sjo...@php.net
This seems to be a bug in the bc library. I asked jhasler to look into
it.
[2008-05-14 16:26:56] nat at fishtrap dot co dot uk
Description:
When using the 4th optional parameter of bcpowmod. The answer is always
zero and does not match the answer using bc directly.
This is also true if you set the scale using bcscale(1).
In short if the scale is non zero I can't find any way of getting
anything apart from zero as the result.
Reproduce code:
---
echo bcpowmod("4", "4", "3", 1 ) ,PHP_EOL;
Expected result:
0.1
in bc
scale =1;
4^4%3;
.1
Actual result:
--
0.0
--
Edit this bug report at http://bugs.php.net/?id=44995&edit=1
#49561 [Opn]: mcrypt warns about having no IV in ECB mode
ID: 49561
Updated by: sjo...@php.net
Reported By: terrafr...@php.net
Status: Open
Bug Type: mcrypt related
Operating System: *
PHP Version: 5.2.10
New Comment:
I think this is a bug in mcrypt. The libmcrypt function
mcrypt_enc_get_iv_size returns 16 for ECB. The manual says: "If it is
Â’0Â’ then the IV is ignored in that algorithm," which implies that
mcrypt_enc_get_iv_size should return 0 when the mode is ECB.
C-code example:
#include "mcrypt.h"
#include
int main()
{
MCRYPT td = mcrypt_module_open(MCRYPT_RIJNDAEL_128, NULL, MCRYPT_ECB,
NULL);
printf("IV size for ECB: %d\n", mcrypt_enc_get_iv_size(td)); // prints
'16'
}
Previous Comments:
[2009-09-15 12:58:34] terrafr...@php.net
Description:
mcrypt complains about their being no IV even if ECB mode is being
used. Since ECB mode doesn't use IVs, it seems like no such warning
should be produced.
Bug #43143 is fairly similar to this one, except that that one produced
a slightly different error. Also, that one was closed on the basis that
it had been fixed.
Reproduce code:
---
Expected result:
I would expect that to just run its course and output nothing.
Actual result:
--
I get the following:
Warning: mcrypt_generic_init(): Iv size incorrect; supplied length: 0,
needed: 16 in C:\php\test.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=49561&edit=1
#49561 [Opn]: mcrypt warns about having no IV in ECB mode
ID: 49561
Updated by: sjo...@php.net
Reported By: terrafr...@php.net
Status: Open
Bug Type: mcrypt related
Operating System: *
PHP Version: 5.2.10
New Comment:
Filed bug:
https://sourceforge.net/tracker/?func=detail&aid=2863450&group_id=87941&atid=584893
Previous Comments:
[2009-09-20 18:17:57] sjo...@php.net
I think this is a bug in mcrypt. The libmcrypt function
mcrypt_enc_get_iv_size returns 16 for ECB. The manual says: "If it is
Â’0Â’ then the IV is ignored in that algorithm," which implies that
mcrypt_enc_get_iv_size should return 0 when the mode is ECB.
C-code example:
#include "mcrypt.h"
#include
int main()
{
MCRYPT td = mcrypt_module_open(MCRYPT_RIJNDAEL_128, NULL, MCRYPT_ECB,
NULL);
printf("IV size for ECB: %d\n", mcrypt_enc_get_iv_size(td)); // prints
'16'
}
[2009-09-15 12:58:34] terrafr...@php.net
Description:
mcrypt complains about their being no IV even if ECB mode is being
used. Since ECB mode doesn't use IVs, it seems like no such warning
should be produced.
Bug #43143 is fairly similar to this one, except that that one produced
a slightly different error. Also, that one was closed on the basis that
it had been fixed.
Reproduce code:
---
Expected result:
I would expect that to just run its course and output nothing.
Actual result:
--
I get the following:
Warning: mcrypt_generic_init(): Iv size incorrect; supplied length: 0,
needed: 16 in C:\php\test.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=49561&edit=1
#49561 [Opn->Ver]: mcrypt warns about having no IV in ECB mode
ID: 49561
Updated by: sjo...@php.net
Reported By: terrafr...@php.net
-Status: Open
+Status: Verified
Bug Type: mcrypt related
Operating System: *
PHP Version: 5.2.10
Previous Comments:
[2009-09-21 12:26:52] sjo...@php.net
Filed bug:
https://sourceforge.net/tracker/?func=detail&aid=2863450&group_id=87941&atid=584893
[2009-09-20 18:17:57] sjo...@php.net
I think this is a bug in mcrypt. The libmcrypt function
mcrypt_enc_get_iv_size returns 16 for ECB. The manual says: "If it is
Â’0Â’ then the IV is ignored in that algorithm," which implies that
mcrypt_enc_get_iv_size should return 0 when the mode is ECB.
C-code example:
#include "mcrypt.h"
#include
int main()
{
MCRYPT td = mcrypt_module_open(MCRYPT_RIJNDAEL_128, NULL, MCRYPT_ECB,
NULL);
printf("IV size for ECB: %d\n", mcrypt_enc_get_iv_size(td)); // prints
'16'
}
[2009-09-15 12:58:34] terrafr...@php.net
Description:
mcrypt complains about their being no IV even if ECB mode is being
used. Since ECB mode doesn't use IVs, it seems like no such warning
should be produced.
Bug #43143 is fairly similar to this one, except that that one produced
a slightly different error. Also, that one was closed on the basis that
it had been fixed.
Reproduce code:
---
Expected result:
I would expect that to just run its course and output nothing.
Actual result:
--
I get the following:
Warning: mcrypt_generic_init(): Iv size incorrect; supplied length: 0,
needed: 16 in C:\php\test.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=49561&edit=1
#49521 [Opn->Ver]: Bug in fetching objects
ID: 49521
Updated by: sjo...@php.net
Reported By: waps at pisem dot net
-Status: Open
+Status: Verified
Bug Type: PDO related
Operating System: Ubuntu 8.10 x64
PHP Version: 5.2.10
New Comment:
Confirmed. If the constructor sets default values for some fields, as
is typical, the constructor will overwrite the values just retrieved
from the database.
title = "Default";
}
}
$pdo = new PDO('mysql:dbname=books', 'root');
$statement = $pdo->prepare('SELECT * FROM book WHERE
title=\'Peopleware\'');
$statement->execute();
$obj = $statement->fetchObject('Book');
echo $obj->title; // Expected: Peopleware. Actual: Default
?>
Previous Comments:
[2009-09-10 11:45:31] waps at pisem dot net
Description:
Incorrect creating user object: set data before call constructor
method.
Reproduce code:
---
---
>From manual page: pdostatement.fetchobject
---
class Product {
public function __construct() {
echo 'create object, ';
}
public function __set($offset, $value) {
echo 'set value, ';
}
}
// fetch object
$stmt->fetchObject('Product', array());
Expected result:
Expected result: create object, set value,
Actual result:
--
Actual result: set value, create object,
--
Edit this bug report at http://bugs.php.net/?id=49521&edit=1
#44597 [Opn]: Postgres driver does not prepare booleans correctly
ID: 44597 Updated by: sjo...@php.net Reported By: kenaniah at gmail dot com Status: Open Bug Type: PDO related Operating System: Red Hat 4.1.1 PHP Version: 5.2.6 New Comment: I think this is not a bug but a limitation of execute(): it assumes the values in the array are string. If you want it interpreted differently, you should call bindParam() with a data_type parameter. I filed Bug #49614 "PDOStatement::execute assumes string values in array" to clarify the documentation. Previous Comments: [2009-09-13 20:55:01] kenaniah at gmail dot com This is still reproducible on 5.3.0 paired with PG 8.x [2009-09-13 19:08:46] ant at specialops dot ath dot cx I can still reproduce this on PHP 5.3.0 and PostgreSQL 8.4.1. [2009-06-14 11:53:21] execut3 at gmail dot com The issue is still not fixed, I'm with PHP 5.2.6 on Ubuntu and postgresql 8.3. ERROR: invalid input syntax for type boolean: "" [2009-05-03 01:00:12] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-04-25 15:02:13] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ 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/44597 -- Edit this bug report at http://bugs.php.net/?id=44597&edit=1
#49618 [Opn->Bgs]: spl_autoload_register destroys __autoload hook
ID: 49618 Updated by: sjo...@php.net Reported By: jost dot boekemeier at googlemail dot com -Status: Open +Status: Bogus Bug Type: SPL related Operating System: Any PHP Version: 5.2.11 New Comment: Thank you for your report. I do not think the behavior you describe is a bug. The documentation is clear about this: "If your code has an existing __autoload function then this function must be explicitly registered on the __autoload stack. This is because spl_autoload_register() will effectively replace the engine cache for the __autoload function by either spl_autoload() or spl_autoload_call()." Thus, calling spl_autoload_register() replaces __autoload(). Previous Comments: [2009-09-22 05:24:02] jost dot boekemeier at googlemail dot com Description: The first call to spl_autoload_register destroys an existing __autoload hook. Please either deprecate __autoload and/or register __autoload with spl_autoload. Complete problem description is here: http://sourceforge.net/mailarchive/forum.php? thread_name=3afa16cf0909210312v3e102491n18701bcca0f5e030%40mail.gmail.com &forum_name=php-java-bridge-users Reproduce code: --- Expected result: spl1 spl2 spl3 legacy Actual result: -- spl1 spl2 spl3 -- Edit this bug report at http://bugs.php.net/?id=49618&edit=1
#49616 [Opn]: Impossible to increase SOMAXCONN
ID: 49616
Updated by: sjo...@php.net
Reported By: ben at realitychecknetwork dot com
Status: Open
Bug Type: Sockets related
Operating System: Linux 2.6.18
PHP Version: 5.2.11
New Comment:
PHP uses the SOMAXCONN from sys/socket.h at compile time.
Previous Comments:
[2009-09-21 20:22:24] ben at realitychecknetwork dot com
Description:
Impossible to increase SOMAXCONN value by updating system OS variable.
PHP must be compiled with --enable-sockets for this bug to be produced.
OS setting updated with:
# sysctl -w net.core.somaxconn=2048
net.core.somaxconn = 2048
PHP will always return 128 for SOMAXCONN and will not respect the OS
setting. Additionally, it will ignore a define statement in PHP code and
return 128 as well.
Reproduce code:
---
define("SOMAXCONN", 2048);
echo SOMAXCONN;
Expected result:
Should return 2048
Actual result:
--
Returns 128
--
Edit this bug report at http://bugs.php.net/?id=49616&edit=1
#49617 [Opn->Ver]: Pointers problem
ID: 49617
Updated by: sjo...@php.net
Reported By: mstf at mstf dot name dot tr
-Status: Open
+Status: Verified
-Bug Type: *General Issues
+Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 5.3.0
New Comment:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
23568 Z_DELREF_PP(EX_T(opline->result.u.var).var.ptr_ptr);
(gdb) bt
#0 0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
#1 0x003ec80e in execute (op_array=0xa109f0) at zend_vm_execute.h:104
#2 0x003bd57a in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /Users/sjoerd/Sources/php-src-5.3/Zend/zend.c:1188
#3 0x0034193d in php_execute_script (primary_file=0xb7fc) at
/Users/sjoerd/Sources/php-src-5.3/main/main.c:2213
#4 0x0049650f in main (argc=4, argv=0xb8e8) at
/Users/sjoerd/Sources/php-src-5.3/sapi/cli/php_cli.c:1190
(gdb)
Previous Comments:
[2009-09-22 01:18:48] mstf at mstf dot name dot tr
Description:
Pointers problem.
Reproduce code:
---
$a = array('a' => array('b' => 'c'));
$b = &$a;
$b = &$b['a'];
$b = &$b['b'];
$b = &$b['c'];
echo $b;
Expected result:
NULL
Actual result:
--
Apache "Send Error Report"
Apache error.log:
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Child process is
running
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Acquired the start
mutex.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting 150 worker
threads.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to
listen on port 80.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to
listen on port 443.
--
Edit this bug report at http://bugs.php.net/?id=49617&edit=1
#49624 [Opn->Bgs]: xxxxxxxxxxxxxxxxxxxxx
ID: 49624 Updated by: sjo...@php.net Reported By: js8jim at msn dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: windows xpsp3 PHP Version: 5.3.0 New Comment: x Previous Comments: [2009-09-22 13:40:26] js8jim at msn dot com Description: i have screenshot to send. please reply. thank you. -jim Reproduce code: --- x Expected result: Actual result: -- xx -- Edit this bug report at http://bugs.php.net/?id=49624&edit=1
#49623 [Opn]: PHP shows deprication warning BEFORE compressed body
ID: 49623
Updated by: sjo...@php.net
Reported By: 3 at 14 dot by
Status: Open
Bug Type: Output Control
Operating System: 2.6.28-15-generic #49-Ubuntu SMP
PHP Version: 5.3.0
New Comment:
Thank you for your bug report.
That PHP shows a warning even though error reporting is disabled sounds
like bug #49362, "Deprecated php.ini options warnings output even with
display_errors=off".
Previous Comments:
[2009-09-22 16:11:25] 3 at 14 dot by
typo
[2009-09-22 13:32:23] 3 at 14 dot by
Description:
I have set Error_Reporting(0) both in the script & in the php.ini.
I have an PHPBB forum (3.0.6) with zlib compression turned on.
Most of the warnings are gone, but in some cases (when some data is
sent via POST), I am still getting a Notice "date(): It is not safe
to rely on the system's timezone settings.", and it is printed BEFORE
compressed page body, so that browser reports broken encoding.
After disabling zlib compression browser started to show notice and
page content. After setting date.timezone in php.ini Notice is gone.
Reproduce code:
---
Install PHPBB 3.0.6: turn zlib compression = on, make sure to unset
date.timezone in php.ini. Then try to reply to a private message.
Expected result:
No notices on the screen, no "broken encoding"
Actual result:
--
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 22 Sep 2009 13:09:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Expires: 0
Last-Modified: Tue, 22 Sep 2009 13:09:15 GMT
Cache-Control: private, no-cache="set-cookie"
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 3181
[phpBB Debug] PHP Notice: in file
/includes/functions_messenger.php on line 390: date():
It is not safe to rely on the system's timezone settings. You are
*required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'Europe/Moscow' for
'MSD/4.0/DST' instead
.n.8...
V.&I[[..\j[..4.)..l.@iu
.Cv_...%{.)..%i.S#.E...d>9.t,..w./.3..o../H..O.u._9...N..;^[fSw..{.T:.V<...i.:tF..ar..Dy[.t.http://bugs.php.net/?id=49623&edit=1
#49625 [Opn->Bgs]: spl_autoload and case sensitivity
ID: 49625
Updated by: sjo...@php.net
Reported By: jo at feuersee dot de
-Status: Open
+Status: Bogus
Bug Type: SPL related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
Thank you for your bug report.
Wontfix means: we agree that there is a bug, but there are reasons not
to fix it. The reason here is that is spl_autoload becomes case
sensitive, it will break scripts which depend on spl_autoload being case
insensitive.
Previous Comments:
[2009-09-22 16:01:15] jo at feuersee dot de
Description:
This is basically the same as PHP bug #48129.
Yes, I have read it "won't fix"
My opinion on this is "won't fix" is not an option because it _is_ a
bug and not fixing bugs does not work:
1) It is common practice in OO languages (including PHP) to give
classes case sensitive names. Even the classes of PHP itself are case
sensitive and usually start with capital letters (eg. DateTime,
Exception, ...). PHP related projects like PEAR, Zend Framework etc. do
the same.
2) In order to get a proper 1:1 mapping from class name to the file
containing the PHP class definition, projects like PEAR or Zend
Framework use the case sensitive class name, eg. System.php contains the
class System. Again, this is common practice in other OO languages like
C++.
3) What happens when the file system is case sensitive?
See example: the script fails because the PEAR class System will be
looked for in a file named system.php which does not exist because it is
called System.php
The workaround is using SPL_autoload_suxx instead. But look at the
code: there are several compatibility issues (include_path separator :
vs. ;), it does work but is not at all convenient.
4) What would happen if spl_autoload() wouldn't lowercase the class
name when looking for a class definition?
a) Filesystem is case sensitive
It would work!
The spl_autoload() would look for a file called System.php which
exists, thus will be require'd
b) Filesystem is not case sensitive
It would still work!
The spl_autoload() would look for a file called System.php
Because the file system is case insensitive, it would use either
System.php or system.php (or sYSTEM.PHP - you got the point?).
Because on case insentive filesystems both files "System.php" and
"system.php" are not allowed in the same directory, there is _no_ issue
with backward compatibility.
The only circumstances where it would break backwards compatibility
would be on filesystem which is case insensitive but does not allow
capital letters. Any real live examples of such a file system?
Conclusion:
The current specification of spl_autoload() with implicit lowercasing
is excactly wrong. There has been, is and never will be any gain in this
'feature' since the class name itself inside PHP is case sensitive.
Reproduce code:
---
System::which('mysql'),
'mysqlbinlog' => System::which('mysqlbinlog'),
'php' => System::which('php')
);
print_r($binaries);
?>
Expected result:
Array
(
[mysql] => /usr/bin/mysql
[mysqlbinlog] => /usr/bin/mysqlbinlog
[php] => /usr/local/bin/php
)
Actual result:
--
PHP Fatal error: Class 'System' not found in
/srv/www/vhosts/www.easy-sew.de/ftpjung/bin/autoload.php on line 38
--
Edit this bug report at http://bugs.php.net/?id=49625&edit=1
#49618 [Bgs]: spl_autoload_register destroys __autoload hook
ID: 49618
Updated by: sjo...@php.net
Reported By: jost dot boekemeier at googlemail dot com
Status: Bogus
Bug Type: SPL related
Operating System: Any
PHP Version: 5.2.11
New Comment:
If two or more of the libraries use __autoload, it won't work, and
there is nothing anybody can do about it.
If all of the libraries use spl_autoload_register, it works as it
should.
If one of the libraries uses __autoload and others use
spl_autoload_register, it is the task of the library that uses
spl_autoload_register to register __autoload as well, like this:
if (function_exists("__autoload")) spl_autoload_register("__autoload");
Previous Comments:
[2009-09-22 09:26:02] jost dot boekemeier at googlemail dot com
My code doesn't use __autoload.
My code uses spl_autoloload.
I have received a bug report because my code has destroyed an existing
library.
By issuing this bug report I have asked you to stop this, by either:
* deprecating __autoload altogether
* fix spl_autoload to honor an existing __autoload or
* let library authors check for an existing (or upcoming) __autoload so
that their
library doesn't destroy existing code
With the current behaviour I have no other choice but to not use
spl_autoload at all,
since I don't know whether the user will or will not include a library
which uses
__autoload later on.
[2009-09-22 09:11:12] sjo...@php.net
Thank you for your report.
I do not think the behavior you describe is a bug. The documentation is
clear about this:
"If your code has an existing __autoload function then this function
must be explicitly registered on the __autoload stack. This is because
spl_autoload_register() will effectively replace the engine cache for
the __autoload function by either spl_autoload() or
spl_autoload_call()."
Thus, calling spl_autoload_register() replaces __autoload().
[2009-09-22 05:24:02] jost dot boekemeier at googlemail dot com
Description:
The first call to spl_autoload_register destroys an existing __autoload
hook.
Please either deprecate __autoload and/or register __autoload with
spl_autoload.
Complete problem description is here:
http://sourceforge.net/mailarchive/forum.php?
thread_name=3afa16cf0909210312v3e102491n18701bcca0f5e030%40mail.gmail.com
&forum_name=php-java-bridge-users
Reproduce code:
---
Expected result:
spl1 spl2 spl3 legacy
Actual result:
--
spl1 spl2 spl3
--
Edit this bug report at http://bugs.php.net/?id=49618&edit=1
#41027 [Opn]: Executing prepared statement changes type of bound parameters to string
ID: 41027
Updated by: sjo...@php.net
Reported By: martin at bangaroo dot net
Status: Open
Bug Type: PDO related
Operating System: Gentoo Linux
PHP Version: 5.*, 6CVS (2009-04-27)
New Comment:
Thank you for your bug report.
A workaround would be to use bindValue instead of bindParam.
Previous Comments:
[2009-04-27 20:47:18] martin at bangaroo dot net
Same result with php5.3-200904271830:
Bug still present.
[2009-04-26 18:30:35] martin at bangaroo dot net
I just checked with the snapshot php5.2-200904261630.
Unfortunately the bug still exists.
[2007-04-09 14:31:34] martin at bangaroo dot net
Description:
Executing a prepared statement changes the type of bound parameters
to string (Tested only with pgsql driver).
This bite me when I wanted to execute an insert statement only when
the double value to be inserted actually changed, NULL being a
possible value. Unfortunatly, comparing the new value with the old
value with the !== operator didn't work, because the type-change
made the test always evaluate to TRUE.
Reproduce code:
---
query("CREATE TABLE test_table ( val REAL )");
$qry = $db->prepare("INSERT INTO test_table VALUES (:val)");
$qry->bindParam(":val",$bound_val);
$bound_val = 5.2;
echo "Type before execute(): ".gettype($bound_val)."\n";
$qry->execute();
echo "Type after execute(): ".gettype($bound_val)."\n";
$db->query("DROP TABLE test");
?>
Expected result:
Type before execute(): double
Type after execute(): double
Actual result:
--
Type before execute(): double
Type after execute(): string
--
Edit this bug report at http://bugs.php.net/?id=41027&edit=1
#44597 [Opn]: [PATCH] Postgres driver does not prepare booleans correctly
ID: 44597 Updated by: sjo...@php.net -Summary: Postgres driver does not prepare booleans correctly Reported By: kenaniah at gmail dot com Status: Open Bug Type: PDO related Operating System: Red Hat 4.1.1 PHP Version: 5.2.6 New Comment: Currently, every variable is assumed to be PDO_PARAM_STR. This patch changes this to PDO_PARAM_INT or PDO_PARAM_BOOL if the passed variable is a long or a bool, respectively. http://www.gissen.nl/files/bug44597.patch This may break existing scripts, which depend on false being converted to an empty string. Previous Comments: [2009-09-21 19:48:55] kenaniah at gmail dot com In response to sjoerd, this may very well be a product of bad documentation, but that does not exclude the functional use case. One could reasonably claim that proper detection of parameter types should in fact be part of the functional definition of execute(). Virtually every database interface built on top of PDO works around this boolean "bug" and allows support for mixed content in the parameter array to a prepared statement. IMHO, the PDO core should therefore be no different. Whether classified as a bug or a feature, I believe that this should still be addressed. [2009-09-21 19:18:21] sjo...@php.net I think this is not a bug but a limitation of execute(): it assumes the values in the array are string. If you want it interpreted differently, you should call bindParam() with a data_type parameter. I filed Bug #49614 "PDOStatement::execute assumes string values in array" to clarify the documentation. [2009-09-13 20:55:01] kenaniah at gmail dot com This is still reproducible on 5.3.0 paired with PG 8.x [2009-09-13 19:08:46] ant at specialops dot ath dot cx I can still reproduce this on PHP 5.3.0 and PostgreSQL 8.4.1. [2009-06-14 11:53:21] execut3 at gmail dot com The issue is still not fixed, I'm with PHP 5.2.6 on Ubuntu and postgresql 8.3. ERROR: invalid input syntax for type boolean: "" 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/44597 -- Edit this bug report at http://bugs.php.net/?id=44597&edit=1
#49017 [Opn->Bgs]: PDO::FETCH_ORI_REL not working
ID: 49017
Updated by: sjo...@php.net
Reported By: farkasmate_ at freemail dot hu
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: win XP sp2
PHP Version: 5.3.0
New Comment:
Thank you for your bug report.
Unfortunately, MySQL does not support scrollable cursors.
See also:
Bug #39310 PDO Scrolling cursors not available for Sqlite and don't
work for Mysql
Bug #34625 Scrollable cursor doesn't work with MySQL
Previous Comments:
[2009-07-22 14:25:39] farkasmate_ at freemail dot hu
Description:
pdo mysql error.
PDO::FETCH_ORI_REL not working
sql result about 1000 rows.
I need to catch 555. row item but i get always first row (0.) of
result.
Reproduce code:
---
$this->db_conn = new
PDO("mysql:host=$db;dbname=mysql;EnableScrollableCursors=1",$db_username,$db_password);//connect
mysql
$sql = "select * from tablename";
$this->db_conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT);
//$stmt = $this->db_conn->query($sql) or die("ERROR: " . implode(":",
$this->db_conn->errorInfo()));
$stmt = $this->db_conn->prepare($sql, array( PDO::ATTR_CURSOR =>
PDO::CURSOR_SCROLL ));
$stmt->execute();
$search_row = 555;
$row = $stmt->fetch(PDO::FETCH_NUM , PDO::FETCH_ORI_REL, $search_row
);
var_dump($row);
Expected result:
catch 555. row
Actual result:
--
catch first row
--
Edit this bug report at http://bugs.php.net/?id=49017&edit=1
#44639 [Opn]: PDO quotes integers in prepared statement
ID: 44639
Updated by: sjo...@php.net
Reported By: jgauld at blueyonder dot co dot uk
Status: Open
Bug Type: PDO related
Operating System: WinXP
PHP Version: 5.2.10
New Comment:
The third parameter to bindValue defaults to PDO::PARAM_STR. This is
different than the original bug reporter said, so it must be changed in
the meantime. Because the datatype is PDO::PARAM_STR, the int is cast to
a string and quoted.
It would make sense to use the PHP type to determine the most logical
PDO::PARAM_* type. See also bug #44597, which is essentially the same
problem but with booleans and execute() instead of bindValue().
Previous Comments:
[2009-08-17 17:38:15] j...@php.net
But you didn't bother updating the version field. Done now..
[2009-07-21 00:30:49] whistl0r+php at googlemail dot com
Hi,
this bug is still present in the current PHP version.
Tested with PHP 5.2.10 stable and snapshot on Windows.
MySQL client api: 5.1.35
[2008-10-21 11:59:03] jgauld at blueyonder dot co dot uk
Tried windows snapshot as suggested (5.2.7RC2-dev), but no joy. Result
is same, ie:
select * from my_table where id>'13'
If it helps, phpinfo() reports:
PDO Driver for MySQL, client library version5.0.51a
[2008-07-03 15:17:35] u...@php.net
This is not a driver issue. Its the PDO SQL driver messing up SQL
statements.
[2008-06-12 13:42:35] dobamail at gmail dot com
Hi.
PDO::MySQL
The code:
$stmt = $db->prepare('
SELECT id, hu_name, ord
FROMproducts
ORDER BY ord DESC, hu_name
LIMIT :offset, :limit
');
$stmt->bindValue(':offset', ($offset*$limit));
$stmt->bindValue(':limit', $limit);
$stmt->execute();
It is work on:
- PHP Version 5.2.0-8+etch11;
- PDO Driver for MySQL, client library version 5.0.32
- MySQL version: 5.0.32-Debian_7etch5-log
Not work on:
- PHP Version 5.2.3-1ubuntu6.3
- PDO Driver for MySQL, client library version 5.0.45
- 5.0.45-Debian_1ubuntu3.3
I hope this help you.
Best regards.
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/44639
--
Edit this bug report at http://bugs.php.net/?id=44639&edit=1
#49625 [Bgs]: spl_autoload and case sensitivity
ID: 49625
Updated by: sjo...@php.net
Reported By: jo at feuersee dot de
Status: Bogus
Bug Type: SPL related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
Trying both lowercased and original case could solve this without
breaking backwards compatibility. However, you could as well supply your
own autoload function defined in PHP to solve this.
Previous Comments:
[2009-09-22 19:37:20] jo at feuersee dot de
>The reason here is that is spl_autoload becomes case
>sensitive, it will break scripts which depend on spl_autoload being
>case insensitive.
spl_autoload() was introduced in PHP 5.1.2 which is case sensitive
concerning class names. This implies that if an operation on an unknown
class is done, spl_autoload() is triggered and executed with the case
sensitive name of the class.
Thus we have 4 different possibilities:
1) The class name all lower case, the file containing the class
definition is all lower case (eg. $foo = system::bar(); system.php)
This will work independent wether spl_autoload() is lowercasing or not,
since all is lowercased.
Note that if the class defined in the file system.php is actually named
System it wouldn't have ever worked because the class system is still
not defined, which would trigger an error.
2) The class name all lower case, the file containing the class
definition is uppercased (eg. $foo = system::bar(); System.php)
This wouldn't work anymore on file systems which are case sensitive if
spl_autoload() would skip lowercasing.
Note that this would only have worked if the file system is case
insensitive and the class definition in System.php would define a class
"system".
3) The class name contains upper case letters, the file containing the
class definition is lowercased (eg. $foo = System::bar(); system.php)
This is what currently isn't working at all but would work at least for
case insensitive file systems if lowercasing would be dropped.
Note that if the class defined in the file system.php is actually named
system it wouldn't have ever worked because the class System is still
not defined.
4) The class name contains upper case letters, the file containing the
class definition is uppercased (eg. $foo = System::bar(); System.php)
This is what should (and would) work, but currently doesn't.
Conclusion:
The only problem might be (2):
Class name: sample
Filename: Sample.php
Class definition in Sample.php: class sample { ... }
Note: this does work on case insensitive file systems only.
I really can't see any reason for maintaining the "Worse is better"
principle here, I really doubt that there is much code around relying on
the tolowercase feature/bug of spl_autoload().
As a compromise I propose the following:
1) spl_autoload() additionally tries to find a file _not_ lowercased.
2) Throw a E_DEPRECATED in case the filename had to be lowercased to
match.
Until then:
I really don't know why this lowercasing thing was introduced into
slp_autoload() to begin with, all it ever did was preventing classes to
be named with upper case letters on file systems which are case
sensitive. In other words: the only compatibility issue is that code
which currently works on platforms like Windows only would suddenly work
on UN*X like platforms too.
Pls confirm if this is the compatibility issue you are talking about.
[2009-09-22 16:22:22] sjo...@php.net
Thank you for your bug report.
Wontfix means: we agree that there is a bug, but there are reasons not
to fix it. The reason here is that is spl_autoload becomes case
sensitive, it will break scripts which depend on spl_autoload being case
insensitive.
[2009-09-22 16:01:15] jo at feuersee dot de
Description:
This is basically the same as PHP bug #48129.
Yes, I have read it "won't fix"
My opinion on this is "won't fix" is not an option because it _is_ a
bug and not fixing bugs does not work:
1) It is common practice in OO languages (including PHP) to give
classes case sensitive names. Even the classes of PHP itself are case
sensitive and usually start with capital letters (eg. DateTime,
Exception, ...). PHP related projects like PEAR, Zend Framework etc. do
the same.
2) In order to get a proper 1:1 mapping from class name to the file
containing the PHP class definition, projects like PEAR or Zend
Framework use the case sensitive class name, eg. System.php contains the
class System. Again, this is common practice in other OO languages like
C++.
3) What happens when the file system is case sensitive?
See example: the script fails because the PEAR class System will be
looked for in a file named system.php which does not exist because it is
called System.php
The workaround is using SPL_autoload_suxx instead. But look at the
#49618 [Bgs]: spl_autoload_register destroys __autoload hook
ID: 49618
Updated by: sjo...@php.net
Reported By: jost dot boekemeier at googlemail dot com
Status: Bogus
Bug Type: SPL related
Operating System: Any
PHP Version: 5.2.11
New Comment:
So the problem occurs with:
include('spl_autoload_register.php'); // uses spl_autoload_register
include('autoload.php'); // defines __autoload
Previous Comments:
[2009-09-22 17:39:32] jost dot boekemeier at googlemail dot com
> if (function_exists("__autoload")) spl_autoload_register("__
autoload")
Doesn't work. In line 7 __autoload is not yet defined.
Note that every line in the given example comes from a separate
include()d php
library.
This is a link-time problem which only php can resolve: it must save a
legacy
__autoload handler before creating the spl_autoload stack and call the
legacy
autoload after all other registered spl_autoload hooks.
[2009-09-22 17:26:38] sjo...@php.net
If two or more of the libraries use __autoload, it won't work, and
there is nothing anybody can do about it.
If all of the libraries use spl_autoload_register, it works as it
should.
If one of the libraries uses __autoload and others use
spl_autoload_register, it is the task of the library that uses
spl_autoload_register to register __autoload as well, like this:
if (function_exists("__autoload")) spl_autoload_register("__autoload");
[2009-09-22 09:26:02] jost dot boekemeier at googlemail dot com
My code doesn't use __autoload.
My code uses spl_autoloload.
I have received a bug report because my code has destroyed an existing
library.
By issuing this bug report I have asked you to stop this, by either:
* deprecating __autoload altogether
* fix spl_autoload to honor an existing __autoload or
* let library authors check for an existing (or upcoming) __autoload so
that their
library doesn't destroy existing code
With the current behaviour I have no other choice but to not use
spl_autoload at all,
since I don't know whether the user will or will not include a library
which uses
__autoload later on.
[2009-09-22 09:11:12] sjo...@php.net
Thank you for your report.
I do not think the behavior you describe is a bug. The documentation is
clear about this:
"If your code has an existing __autoload function then this function
must be explicitly registered on the __autoload stack. This is because
spl_autoload_register() will effectively replace the engine cache for
the __autoload function by either spl_autoload() or
spl_autoload_call()."
Thus, calling spl_autoload_register() replaces __autoload().
[2009-09-22 05:24:02] jost dot boekemeier at googlemail dot com
Description:
The first call to spl_autoload_register destroys an existing __autoload
hook.
Please either deprecate __autoload and/or register __autoload with
spl_autoload.
Complete problem description is here:
http://sourceforge.net/mailarchive/forum.php?
thread_name=3afa16cf0909210312v3e102491n18701bcca0f5e030%40mail.gmail.com
&forum_name=php-java-bridge-users
Reproduce code:
---
Expected result:
spl1 spl2 spl3 legacy
Actual result:
--
spl1 spl2 spl3
--
Edit this bug report at http://bugs.php.net/?id=49618&edit=1
#49636 [Opn]: PHP_INT_SIZE inconsistent with pack("i")
ID: 49636
Updated by: sjo...@php.net
Reported By: hsu at jean-david dot com
Status: Open
Bug Type: Math related
Operating System: linux
PHP Version: 5.2.11
New Comment:
Thank you for your bug report.
The integer in the pack documentation and the integer in the PHP
integer documentation refer to different things. The pack integer is a
C-style int. The PHP integer is implemented in a long. These do not need
to be the same size.
Previous Comments:
[2009-09-23 01:54:13] hsu at jean-david dot com
Description:
PHP pack documentation:
i signed integer (machine dependent size and byte order)
PHP integer documentation:
Integer size can be determined using the constant PHP_INT_SIZE
On some systems, I believe that the word "integer" will refer to
objects of different sizes, such that pack("i", _) could point to an
object of size X bytes and PHP_INT_SIZE return value Y which is
inconsistent.
/main/main.c l.1796:
REGISTER_MAIN_LONG_CONSTANT("PHP_INT_SIZE", sizeof(long),
CONST_PERSISTENT | CONST_CS);
/ext/standard/pack.c l.402-403:
php_pack(argv[currentarg++], sizeof(int), int_map,
&output[outputpos]);
outputpos += sizeof(int);
Reproduce code:
---
file_put_contents("test.bin",pack("I", 2));
var_dump(PHP_INT_SIZE === filesize("test.bin"));
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=49636&edit=1
#49641 [Opn->Bgs]: call-by-value does not work on objects
ID: 49641
Updated by: sjo...@php.net
Reported By: alhajaj at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.11
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
http://nl2.php.net/manual/en/language.oop5.references.php
Previous Comments:
[2009-09-23 10:52:29] alhajaj at yahoo dot com
Description:
when passing an object by value to a function it alters the original
object and not a copy of it. Here is a script to reproduce it. I
included the handling for passing strings which works as expected unlike
passing objects.
Reproduce code:
---
name = "tony";}
}
function changeUserByRef(&$user) { $user->name = "changeUserByRef";}
function changeUserByValue($user) { $user->name =
"changeUserByValue";}
function changeStringByRef(&$str) { $str = "changeStringByRef";}
function changeStringByValue($str) { $str = "changeStringByValue";}
$user = new User();
echo($user->name . '' );
changeUserByRef($user);
echo("changeUserByRef = " . $user->name . '' );
$user->name = "tony";
echo($user->name . '' );
changeUserByValue($user);
echo("changeUserByValue = ". $user->name . '' );
echo('');
$user->name = "tony";
echo($user->name . '' );
changeStringByRef($user->name);
echo("changeStringByRef = " . $user->name . '' );
$user->name = "tony";
echo($user->name . '' );
changeStringByValue($user->name);
echo("changeStringByValue = " . $user->name . '' );
?>
Expected result:
tony
changeUserByRef = changeUserByRef
tony
changeUserByValue = tony
---
tony
changeStringByRef = changeStringByRef
tony
changeStringByValue = tony
Actual result:
--
tony
changeUserByRef = changeUserByRef
tony
changeUserByValue = changeUserByValue
---
tony
changeStringByRef = changeStringByRef
tony
changeStringByValue = tony
--
Edit this bug report at http://bugs.php.net/?id=49641&edit=1
#49643 [Opn->Bgs]: Improper quoting on datetime bound parameters for postgresql
ID: 49643
Updated by: sjo...@php.net
Reported By: alandsidel at dnsstuff dot com
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: FreeBSD
PHP Version: 5.3.0
New Comment:
Thank you for your report.
The behavior you describe is not a bug. PDOStatement->execute() assumes
the values in the array are string. Furthermore, you pass a string in
the array. The result is that the value is escaped as it was a string.
This means that it is quoted.
Previous Comments:
[2009-09-23 12:21:51] alandsidel at dnsstuff dot com
Description:
Running PostGreSQL 8.4, given a simple table like:
When using a bound parameter in prepare (named or unnamed) to a
timestamp field, the parameter is improperly quoted resulting in errors
on INSERT or UPDATE statements that are using expressions rather than
simple datetime strings.
Reproduce code:
---
// In the postgresql database
CREATE TABLE foo
(
id SERIAL UNIQUE NOT NULL,
dtSometime TIMESTAMP WITH TIME ZONE NOT NULL
);
// Assuming $dbh is a connection to the above database
if ($stmt = $dbh->prepare('INSERT INTO foo (dtSometime) VALUES
(:dtsometime)')
{
if ($stmt->execute(array('now() + interval \'1 year\''))
{
print("ok!\n");
}
else
{
print_r($dbh->errorInfo());
}
}
Expected result:
Expect a row to be inserted and 'ok!' to print.
Actual result:
--
The following is printed on the console:
//--cut
(
[0] => 0
[1] => 7
[2] => ERROR: invalid input syntax for type timestamp with time
zone: "now() + interval '1 year'"
)
//--cut
A direct insert with the given SQL works fine as expected, so this must
be a quoting issue that is forcing postgresql to interpret the
expression as a literal datetime.
--
Edit this bug report at http://bugs.php.net/?id=49643&edit=1
#49618 [Bgs->Opn]: spl_autoload_register destroys __autoload hook
ID: 49618
Updated by: sjo...@php.net
Reported By: jost dot boekemeier at googlemail dot com
-Status: Bogus
+Status: Open
Bug Type: SPL related
Operating System: Any
PHP Version: 5.2.11
Previous Comments:
[2009-09-23 08:53:11] jost dot boekemeier at googlemail dot com
Right. In particular:
Please see the link posted with the bug report for all the details.
However, I think neither the user nor joomla nor I have to invent
strange
workarounds for bugs in the php implementation. Any new introduced PHP
feature
must be compatible with earlier PHP features, unless the earlier
features have been
deprecated and a clear migration path exists.
The old __autoload is neither deprecated nor is spl_autoload_register
compatible with
it. Whoever wrote it and the comment "This is because
spl_autoload_register() will
effectively replace the engine cache fo the __autoload function by
either
spl_autoload() or spl_autoload_call(). " wrote a bug.
> Thus, calling spl_autoload_register() replaces __autoload()
If spl_autoload_register is intended to replace the old __autoload
machinery, the old
__autoload should have been deprecated and a clear migration path
should have
been given to those using it.
[2009-09-23 07:23:07] sjo...@php.net
So the problem occurs with:
include('spl_autoload_register.php'); // uses spl_autoload_register
include('autoload.php'); // defines __autoload
[2009-09-22 17:39:32] jost dot boekemeier at googlemail dot com
> if (function_exists("__autoload")) spl_autoload_register("__
autoload")
Doesn't work. In line 7 __autoload is not yet defined.
Note that every line in the given example comes from a separate
include()d php
library.
This is a link-time problem which only php can resolve: it must save a
legacy
__autoload handler before creating the spl_autoload stack and call the
legacy
autoload after all other registered spl_autoload hooks.
[2009-09-22 17:26:38] sjo...@php.net
If two or more of the libraries use __autoload, it won't work, and
there is nothing anybody can do about it.
If all of the libraries use spl_autoload_register, it works as it
should.
If one of the libraries uses __autoload and others use
spl_autoload_register, it is the task of the library that uses
spl_autoload_register to register __autoload as well, like this:
if (function_exists("__autoload")) spl_autoload_register("__autoload");
[2009-09-22 09:26:02] jost dot boekemeier at googlemail dot com
My code doesn't use __autoload.
My code uses spl_autoloload.
I have received a bug report because my code has destroyed an existing
library.
By issuing this bug report I have asked you to stop this, by either:
* deprecating __autoload altogether
* fix spl_autoload to honor an existing __autoload or
* let library authors check for an existing (or upcoming) __autoload so
that their
library doesn't destroy existing code
With the current behaviour I have no other choice but to not use
spl_autoload at all,
since I don't know whether the user will or will not include a library
which uses
__autoload later on.
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/49618
--
Edit this bug report at http://bugs.php.net/?id=49618&edit=1
#49570 [Opn->Fbk]: $_POST is empty with large file uploads
ID: 49570 Updated by: sjo...@php.net Reported By: erikvernsmith at yahoo dot com -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Mac OS 10.6.1 PHP Version: 5.3.0 New Comment: Thank you for your bug report. To properly diagnose the problem, we need some more information from you. Have you enabled error reporting? Do you get any errors in the error log? Could the script stop because the max execution time expires? How long does it take for the script to stop? Does the script works fine other than that $_POST and $_FILES are empty? Previous Comments: [2009-09-16 13:48:18] erikvernsmith at yahoo dot com Description: I set upload_max_filesize in php.ini to 64M I'm using a simple html form to post/upload a file to a simple php script. If I upload files smaller than 8MB everything works fine. If I upload a file larger than 8MB, print_r( $_POST ) and print_r( $_FILES ) are empty. Important note: 8MB is not a magic number. On my localhost 10MB files do upload, but 50MB files do not. 8MB files will not work on my remote website, but 7MB files will work. Reproduce code: --- complete HTML file: Choose a file to upload: complete PHP file: '; echo $_POST['mytitle']; echo ''; print_r( $_POST ); echo ''; print_r( $_FILES ); ?> Expected result: I expect the $_POST and $_FILES arrays to have contents, like this: testing123 junkjunk and more junk Array ( [mytitle] => junkjunk and more junk ) Array ( [uploadedfile] => Array ( [name] => junk.bin [type] => application/macbinary [tmp_name] => /private/var/tmp/php0tupN2 [error] => 0 [size] => 10485760 ) ) Actual result: -- The $_POST and $_FILES arrays are empty, like this: testing123 Array ( ) Array ( ) -- Edit this bug report at http://bugs.php.net/?id=49570&edit=1
#49381 [Opn->Bgs]: PDO mysql prepare incorrectly quoting
ID: 49381 Updated by: sjo...@php.net Reported By: eprayner at gmail dot com -Status: Open +Status: Bogus Bug Type: PDO related Operating System: Linux PHP Version: 5.2SVN-2009-08-27 (SVN) New Comment: I am setting this bug to Bogus: the passed strings are properly escaped and PDO can not figure out that the passed strings are column names. Previous Comments: [2009-09-18 16:21:51] u...@php.net "The 'efficiency payoff' I was talking about is mentioned in various prepared statement documentation. The DB engine is meant to be able to save some prep time. Obviously mysql would not be saving time if 'column parameter markers' were allowed in PDO." Not every database supports prepared statements. And depending on the MySQL version not all statements can be prepared. Some databases offer named parameters others don't. MySQL doesn't. To overcome all the differences between the various databases PDO has to have an emulation layer. If the emulation gets used, you don't have server side prepared statments. Its kind of client side prepared statements. The two concepts are different. And, yes, with client side prepared statements you don't benefit from certain DB caches. However, different DB engines, different benefits of prepared statements vs. "regular" statements. In case of MySQL the time from getting a statement to start of query execution is rather short. The benefit of the prepare can be small. [2009-09-18 15:35:44] eprayner at gmail dot com A few comments about that. I think the PDO should attempt to be clear about what is supported and what isn't. If something doesn't work everywhere, that should be noted. The 'efficiency payoff' I was talking about is mentioned in various prepared statement documentation. The DB engine is meant to be able to save some prep time. Obviously mysql would not be saving time if 'column parameter markers' were allowed in PDO. 'The PDO SQL parser is provided by the PDO core.' Really? I thought it'd just translate to mysql prepared statements!?! Sure I read that somewhere. Either way, it could be fixed. 'What happens in this case is that PDO parses your statement, recognizes a placeholder and tries to replace it with the bound value. To prevent SQL inject attacks, PDO asks MySQL to escape the value that the PDO parser will insert for the placeholder. The PDO parser would need to learn that the placeholder is an identifier and you don't want escaping to happen.' I don't mind 'escaping', the final string should not be quoted though. '...take the safe but stony road of improving the PDO parser and teach it (for all SQL dialects!) what an identifier is.' Surely you've got to translate to an SQL dialect at some point. The trick is to do it right!--Not quote mysql identifiers for example. [2009-09-18 12:42:12] u...@php.net PDO is an API abstraction layer. It neither does abstract SQL differences nor does PDO pay much attention to provide a unified type system. Users need to pay attention to differences between SQL dialects on their own. I understand that it would be helpful to have summary on SQL differences somewhere but on the other hand I would understand the documentation team to just link to any such document but keep details itself out of the core documentation. Just my thoughts... I am not sure what you mean by "efficiency payoff". A client side emulation of PS has different properties than server side PS. IMHO there is no clear line on what is preferrable. The PDO SQL parser is provided by the PDO core. This is a tricky design decision because it is one SQL parser for all the different SQL dialects. The PDO SQL parser is very generic and you can find edge cases in the bug system where it fails. Even if the client side emulation may give you a feature you want, you should be aware of the overall design and not forget about its limitations. What happens in this case is that PDO parses your statement, recognizes a placeholder and tries to replace it with the bound value. To prevent SQL inject attacks, PDO asks MySQL to escape the value that the PDO parser will insert for the placeholder. The PDO parser would need to learn that the placeholder is an identifier and you don't want escaping to happen. Two solutions come to my mind: either you allow users to hint PDO that nothing shall be escaped or you take the safe but stony road of improving the PDO parser and teach it (for all SQL dialects!) what an identifier is. Both solutions would require changing the core of PDO. [2009-09-18 10:46:45] eprayner at gmail dot com OK. At http://dev.mysql.com/doc/refman/5.1/en/prepare.html it says 'Parameter m
