Req #43588 [Com]: Deadlock-free exec function
Edit report at http://bugs.php.net/bug.php?id=43588&edit=1 ID: 43588 Comment by: obones at free dot fr Reported by:tstarling at wikimedia dot org Summary:Deadlock-free exec function Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Windows PHP Version:5.2.5 Block user comment: N Private report: N New Comment: Hello, This would indeed be very convenient as right now it makes it very hard to understand why the server is down. There are numerous reports of the freeze/hands with exec() and Apache under windows, two of which are those: http://bugs.php.net/bug.php?id=44942 http://bugs.php.net/bug.php?id=44994 In my case, it's by using the SourceSVN plugin inside a Mantis installation that I stumbled across this very annoying behavior. While someone imports the latest SVN changes, nobody can work with Apache anymore which is very very annoying, especially the need to force close the server. Previous Comments: [2007-12-13 12:34:03] tstarling at wikimedia dot org Description: I would like to request the addition of a deadlock-free shell execution function to PHP on Windows. PHP already has one of these on the Linux platform, and I think it would be a useful addition to the Windows platform as well. PHP deadlocks whenever an exec function is called, if another thread is waiting for a file lock that the executing thread holds. This is the expected behaviour and is not a bug, see bug 42064. But some applications may benefit from the ability to call a shell execution function during a file-lock-protected critical section without risking a permanent deadlock of the participating threads. That is why I am making this feature request. Reproduce code: --- EOT; } ?> Expected result: The two frames should both display "Hello", after a delay of 2 seconds. Actual result: -- The frames take forever to load. Requires a force quit of Apache. -- Edit this bug report at http://bugs.php.net/bug.php?id=43588&edit=1
Bug #44994 [NoF->Asn]: exec() produces zombie processes on Windows, hangs Apache
Edit report at http://bugs.php.net/bug.php?id=44994&edit=1
ID: 44994
Updated by: paj...@php.net
Reported by:dbarrett at vistaprint dot com
Summary:exec() produces zombie processes on Windows, hangs
Apache
-Status: No Feedback
+Status: Assigned
Type: Bug
Package:Program Execution
Operating System: win32 only - 2003 Server, 64-bit
PHP Version:5.2.6
Assigned To:pajoye
Block user comment: N
Private report: N
Previous Comments:
[2010-01-06 17:35:17] patrick dot bueker at triangle-solutions dot de
I once had the problem too. I had the feeling that it has something to
do with threadsafe or non-threadsafe versions of PHP. I still have the
problem on some installations, others work.
[2009-09-01 18:42:09] garre...@php.net
I'm trying to come up with a reproducible test case for this bug.
If anyone has a complete test scenario for this please post it. I simply
can't replicate the effects here.
G
[2009-08-27 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-19 19:06:40] garre...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-08-19 17:26:55] garre...@php.net
I've seen this happen in other languages too.
This happens when the pipe between the parent and child fills up, and
cmd.exe ends up blocking and creates a race condition. (Windows script
host languages trip up on this quickly)
in popen_ex() ( in tsrm_win32.c) the pipe is creates with a 2k buffer:
if (!str_len || !CreatePipe(&in, &out, &security, 2048L)) {
this should probably be significantly larger. I'd certainly go with at
least 16k or 32k. (hey, it's only memory :D)
as well, the elimination of the unrequired cmd.exe as the immediate
child process would eliminate the possibility that *it's* buffer gets
overwhelmed too. (which solves bug #43327, and I've passed a patch to
Pierre for that.)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=44994
--
Edit this bug report at http://bugs.php.net/bug.php?id=44994&edit=1
[PHP-BUG] Bug #53775 [NEW]: parseCurrency returns 0 instead of false
From:
Operating system: win xp
PHP version: 5.3SVN-2011-01-18 (SVN)
Package: Unknown/Other Function
Bug Type: Bug
Bug description:parseCurrency returns 0 instead of false
Description:
Hi! :)
I think i have found a bug in NumberFormatter.
parseCurrency() returns 0 instead of false in the following test script.
Same Problem with parse().
Test script:
---
$fmt=new NumberFormatter('de_DE',NumberFormatter::CURRENCY);
$result=$fmt->parseCurrency('aaa',$currency);
//$result=$fmt->parse('aaa');
// results:
var_dump($result); // float(0)
var_dump($currency); // string(0) ""
// no errors!!
var_dump($fmt->getErrorCode()); // int(0)
var_dump($fmt->getErrorMessage()); // string(12)
"U_ZERO_ERROR"
var_dump(intl_is_failure($fmt->getErrorCode())); // bool(false)
--
Edit bug report at http://bugs.php.net/bug.php?id=53775&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53775&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53775&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53775&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53775&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53775&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53775&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53775&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53775&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53775&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53775&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53775&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53775&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53775&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53775&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53775&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53775&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53775&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53775&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53775&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53775&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53775&r=mysqlcfg
Req #41191 [Com]: Request for method to always retrieve POST body
Edit report at http://bugs.php.net/bug.php?id=41191&edit=1 ID: 41191 Comment by: novikov at doroga dot tv Reported by:jfrim at idirect dot com Summary:Request for method to always retrieve POST body Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Win98 PHP Version:5.2.1 Block user comment: N Private report: N New Comment: When the Java MIDP client sends wrong multipart/form-data message because of wrong Java implementation, I don't have a chance to fix the problem on the server side using PHP, just because I don't have any way to get a raw POST data. Previous Comments: [2007-04-25 20:12:36] jfrim at idirect dot com Description: Currently there exists no way in PHP to retrieve the POST body when a form is sent using multipart/form-data. This is a problem for implementing protocols like HTTP digest authentication, which require the server to calculate a hash of the received POST body. If making the POST body available on the php://input stream AT ALL TIMES regardless of the encoding type is impractical (possibly due to memory requirements when the POST body is very large), an alternative would be to stream the POST body, unaltered, directly to a temporary file. (Similar to the way files uploaded with HTML forms are streamed to temporary files referenced in the $_FILES[] superglobal.) This would allow authors to fully implement HTTP digest authentication in their scripts, and open up any other other possible situations where one might require an exact bit-accurate copy of the POST body. -- Edit this bug report at http://bugs.php.net/bug.php?id=41191&edit=1
[PHP-BUG] Bug #53776 [NEW]: soap module does not allow to use underlying persistent connections
From: Operating system: Linux PHP version: 5.3.5 Package: SOAP related Bug Type: Bug Bug description:soap module does not allow to use underlying persistent connections Description: While investigating, we found the soap module (SoapClient) is able to request a keep-alive HTTP persistent connection (if http/persistent_connection context option is set to 1.1, the default): 1/ if you send multiple requests within the same test script, it will correctly reuse the connection 2/ whenever the script ends, connection is released and future calls to the same script will end in re-establishing a new HTTP connection (which can be CPU intensive when SSL is used) We found the issue being related to a call to php_stream_xport_create within ext/soap/php_http.c where persistent_id parameter is hard coded to be NULL. Proposed patch will look at a new stream options named "soap/http_persistent": - if it set to true, it will fill-in persistent_id param with connection name (ex: tcp://host:port or ssl://host:port) - if it is not set or set to false, persistent_id param remains NULL and actual behavior is kept -- Edit bug report at http://bugs.php.net/bug.php?id=53776&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53776&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53776&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53776&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53776&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53776&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53776&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53776&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53776&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53776&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53776&r=support Expected behavior: http://bugs.php.net/fix.php?id=53776&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53776&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53776&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53776&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53776&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53776&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53776&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53776&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53776&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53776&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53776&r=mysqlcfg
Bug #53775 [Opn->Bgs]: parseCurrency returns 0 instead of false
Edit report at http://bugs.php.net/bug.php?id=53775&edit=1
ID: 53775
Updated by: il...@php.net
Reported by:_coola_ at arcor dot de
Summary:parseCurrency returns 0 instead of false
-Status: Open
+Status: Bogus
Type: Bug
Package:I18N and L10N related
Operating System: win xp
PHP Version:5.3SVN-2011-01-18 (SVN)
Block user comment: N
Private report: N
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 parseCurrency() expects the 1st parameter to be a float, when given
a string
PHP automatically casts it to float resulting in 0.
Previous Comments:
[2011-01-18 09:56:58] _coola_ at arcor dot de
Description:
Hi! :)
I think i have found a bug in NumberFormatter.
parseCurrency() returns 0 instead of false in the following test
script.
Same Problem with parse().
Test script:
---
$fmt=new NumberFormatter('de_DE',NumberFormatter::CURRENCY);
$result=$fmt->parseCurrency('aaa',$currency);
//$result=$fmt->parse('aaa');
// results:
var_dump($result); // float(0)
var_dump($currency); // string(0) ""
// no errors!!
var_dump($fmt->getErrorCode()); // int(0)
var_dump($fmt->getErrorMessage()); // string(12)
"U_ZERO_ERROR"
var_dump(intl_is_failure($fmt->getErrorCode())); // bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53775&edit=1
Bug #53755 [Opn->Bgs]: FILTER_SANITIZE_STRING truncates string with unmatched
Edit report at http://bugs.php.net/bug.php?id=53755&edit=1
ID: 53755
Updated by: il...@php.net
Reported by:pgarvin76 at gmail dot com
Summary:FILTER_SANITIZE_STRING truncates string with
unmatched <
-Status: Open
+Status: Bogus
Type: Bug
Package:Filter related
Operating System: Ubuntu/Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
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
Previous Comments:
[2011-01-17 14:39:49] il...@php.net
The fix is not correct, since it would not change the fact that "four is
<6" would
return "four is "
[2011-01-15 01:50:01] pgarvin76 at gmail dot com
The bugtracker would let me upload my diff so I created a Gist for it on
Github.
https://gist.github.com/780577
I tested this solves the problem on 5.3.5.
Also here is a PHPT test for the bug.
https://gist.github.com/780574
[2011-01-15 01:40:56] pgarvin76 at gmail dot com
Description:
If a string containing an unmatched "<" character is run through the
FILTER_SANITIZE_STRING filter the string is truncated at the <.
The problem seems to stem from the last parameter in the call to
php_strip_tags_ex(). That parameter tells php_strip_tags_ex() ignore
spaces trailing "<" characters. I checked how php_strip_tags_ex() is
called in the PHP function strip_tags() and it tells php_strip_tags_ex
to allow spaced after a "<".
See ext/filter/santitizing_filters.c line 203 and ext/standard/string.c
line 4023 in PHP 5.3.5.
Test script:
---
echo filter_var('four is < 6', FILTER_SANITIZE_STRING);
Expected result:
four is < 6
Actual result:
--
four is
--
Edit this bug report at http://bugs.php.net/bug.php?id=53755&edit=1
Bug #53722 [Opn->Bgs]: FILTER_VALIDATE_EMAIL fails on numeric TLDs
Edit report at http://bugs.php.net/bug.php?id=53722&edit=1
ID: 53722
Updated by: il...@php.net
Reported by:romain dot riviere at gmail dot com
Summary:FILTER_VALIDATE_EMAIL fails on numeric TLDs
-Status: Open
+Status: Bogus
Type: Bug
Package:Filter related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
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
There are no numeric TLDs, the e-mail filters supports IP based e-mail
addresses
however.
Previous Comments:
[2011-01-12 13:48:58] romain dot riviere at gmail dot com
Description:
Although FILTER_VALIDATE_EMAIL accepts non-existent TLDs, it refuses to
validate
numeric TLDs.
AFAIK, there is no technical justification for this: numeric TLDs just
work out of
the box as far as the DNS know about them.
I suggest that the filter should validate numeric TLDs, or that a
FILTER_FLAG_ALLOW_NUMTLD be created to alter the default behaviour of
the filter.
Test script:
---
filter_var("johndoe@domain.123", FILTER_SANITIZE_EMAIL) ; // returns
false
--
Edit this bug report at http://bugs.php.net/bug.php?id=53722&edit=1
Bug #53722 [Bgs]: FILTER_VALIDATE_EMAIL fails on numeric TLDs
Edit report at http://bugs.php.net/bug.php?id=53722&edit=1
ID: 53722
User updated by:romain dot riviere at gmail dot com
Reported by:romain dot riviere at gmail dot com
Summary:FILTER_VALIDATE_EMAIL fails on numeric TLDs
Status: Bogus
Type: Bug
Package:Filter related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
There ARE numeric TLDs, even though they are not made public. I have one
on my
LAN.
The filter should probably not rely on what is believed to exist, but on
what is
technically feasible.
In other words, if I can get email on the address johndoe@domain.123
(and again,
YES, it works), then FILTER_VALIDATE_EMAIL should not reject such an
address.
Previous Comments:
[2011-01-18 14:03:15] il...@php.net
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
There are no numeric TLDs, the e-mail filters supports IP based e-mail
addresses
however.
[2011-01-12 13:48:58] romain dot riviere at gmail dot com
Description:
Although FILTER_VALIDATE_EMAIL accepts non-existent TLDs, it refuses to
validate
numeric TLDs.
AFAIK, there is no technical justification for this: numeric TLDs just
work out of
the box as far as the DNS know about them.
I suggest that the filter should validate numeric TLDs, or that a
FILTER_FLAG_ALLOW_NUMTLD be created to alter the default behaviour of
the filter.
Test script:
---
filter_var("johndoe@domain.123", FILTER_SANITIZE_EMAIL) ; // returns
false
--
Edit this bug report at http://bugs.php.net/bug.php?id=53722&edit=1
[PHP-BUG] Req #53777 [NEW]: PHP-FPM error log date format is different from PHP error_log
From: Operating system: Linux (Ubuntu) PHP version: 5.3.5 Package: FPM related Bug Type: Feature/Change Request Bug description:PHP-FPM error log date format is different from PHP error_log Description: The date format used for PHP error_log is "[25-Dec-2010 12:57:43]" The date format for PHP-FPM error log is "Dec 25 13:16:14.610146" Anyway this can be unified? I usually log all PHP related errors to a single log file (PHP-FPM included) and this different date formatting is a bit weirdo. I have marked this as Feature/Change request rather than a bug. If there are any important reasons for keeping it this way (or any BC breaks) - please ignore me. -- Edit bug report at http://bugs.php.net/bug.php?id=53777&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53777&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53777&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53777&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53777&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53777&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53777&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53777&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53777&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53777&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53777&r=support Expected behavior: http://bugs.php.net/fix.php?id=53777&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53777&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53777&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53777&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53777&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53777&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53777&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53777&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53777&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53777&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53777&r=mysqlcfg
Req #53777 [Opn]: PHP-FPM error log date format is different from PHP error_log
Edit report at http://bugs.php.net/bug.php?id=53777&edit=1 ID: 53777 Updated by: der...@php.net Reported by:simast at gmail dot com Summary:PHP-FPM error log date format is different from PHP error_log Status: Open Type: Feature/Change Request Package:FPM related Operating System: Linux (Ubuntu) PHP Version:5.3.5 Block user comment: N Private report: N New Comment: I would actually suggest changing both formats to: -mm-dd hh:ii:ss Previous Comments: [2011-01-18 15:52:29] simast at gmail dot com Description: The date format used for PHP error_log is "[25-Dec-2010 12:57:43]" The date format for PHP-FPM error log is "Dec 25 13:16:14.610146" Anyway this can be unified? I usually log all PHP related errors to a single log file (PHP-FPM included) and this different date formatting is a bit weirdo. I have marked this as Feature/Change request rather than a bug. If there are any important reasons for keeping it this way (or any BC breaks) - please ignore me. -- Edit this bug report at http://bugs.php.net/bug.php?id=53777&edit=1
Req #53777 [Opn]: PHP-FPM error log date format is different from PHP error_log
Edit report at http://bugs.php.net/bug.php?id=53777&edit=1 ID: 53777 Updated by: f...@php.net Reported by:simast at gmail dot com Summary:PHP-FPM error log date format is different from PHP error_log Status: Open Type: Feature/Change Request Package:FPM related Operating System: Linux (Ubuntu) PHP Version:5.3.5 Block user comment: N Private report: N New Comment: It should be the same. Then, I would say "don't change error_log format and move FPM log format to fit error_log". Previous Comments: [2011-01-18 15:59:52] der...@php.net I would actually suggest changing both formats to: -mm-dd hh:ii:ss [2011-01-18 15:52:29] simast at gmail dot com Description: The date format used for PHP error_log is "[25-Dec-2010 12:57:43]" The date format for PHP-FPM error log is "Dec 25 13:16:14.610146" Anyway this can be unified? I usually log all PHP related errors to a single log file (PHP-FPM included) and this different date formatting is a bit weirdo. I have marked this as Feature/Change request rather than a bug. If there are any important reasons for keeping it this way (or any BC breaks) - please ignore me. -- Edit this bug report at http://bugs.php.net/bug.php?id=53777&edit=1
[PHP-BUG] Bug #53778 [NEW]: strtotime returning wrong result
From: Operating system: CentOS PHP version: 5.2.17 Package: Date/time related Bug Type: Bug Bug description:strtotime returning wrong result Description: strtotime is incorrectly evaluating second Tuesday for any month that starts on Tuesday. Test script: --- Expected result: 02-08-2011 03-08-2011 04-12-2011 Actual result: -- 02-15-2011 03-15-2011 04-12-2011 -- Edit bug report at http://bugs.php.net/bug.php?id=53778&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53778&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53778&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53778&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53778&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53778&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53778&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53778&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53778&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53778&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53778&r=support Expected behavior: http://bugs.php.net/fix.php?id=53778&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53778&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53778&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53778&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53778&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53778&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53778&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53778&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53778&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53778&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53778&r=mysqlcfg
[PHP-BUG] Req #53779 [NEW]: New class ReflectionConstant along the lines of ReflectionProperty
From: Operating system: Irrelevant PHP version: 5.3SVN-2011-01-18 (SVN) Package: Reflection related Bug Type: Feature/Change Request Bug description:New class ReflectionConstant along the lines of ReflectionProperty Description: Using ReflectionClass->getConstants() returns all constants defined in the class tree as a simple array, irrespective of the defining class. In comparison to that ReflectionClass->getProperties() returns a collection of ReflectionProperty, allowing you to filter the find the properties for a single class. So, would it be possible to have a similar mechanism for constants, replacing the simplistic array with a collection of RefelctionConstant. -- Edit bug report at http://bugs.php.net/bug.php?id=53779&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53779&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53779&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53779&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53779&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53779&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53779&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53779&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53779&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53779&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53779&r=support Expected behavior: http://bugs.php.net/fix.php?id=53779&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53779&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53779&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53779&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53779&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53779&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53779&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53779&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53779&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53779&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53779&r=mysqlcfg
[PHP-BUG] Bug #53780 [NEW]: Iterating twice over an array changes the array
From:
Operating system: Ubuntu 11.04
PHP version: 5.3.5
Package: *General Issues
Bug Type: Bug
Bug description:Iterating twice over an array changes the array
Description:
When using foreach to iterate over an array using the reference (&$value)
syntax, and using foreach a second time using the same variable name
changes the original array by overwriting the array's last item with the
second-last.
This is obviously wrong...
Hint: note the missing object's id #4 in the actual result
Test script:
---
// the example uses objects to show the object's id in the output, but this
error also occurs works with scalars
class A {}
$c = array(new A(), new A(), new A(), new A());
$arr = $c; // to keep the reference
var_dump($arr);
foreach ($arr as &$value) {}
var_dump($arr);
// using the same variable name
foreach ($arr as $value) {}
var_dump($arr);
Expected result:
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
object(A)#4 (0) {
}
}
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
object(A)#4 (0) {
}
}
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
object(A)#4 (0) {
}
}
Actual result:
--
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
object(A)#4 (0) {
}
}
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
&object(A)#4 (0) {
}
}
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
&object(A)#3 (0) {
}
}
--
Edit bug report at http://bugs.php.net/bug.php?id=53780&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53780&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53780&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53780&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53780&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53780&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53780&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53780&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53780&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53780&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53780&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53780&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53780&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53780&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53780&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53780&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53780&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53780&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53780&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53780&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53780&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53780&r=mysqlcfg
Bug #53780 [Opn->Bgs]: Iterating twice over an array changes the array
Edit report at http://bugs.php.net/bug.php?id=53780&edit=1
ID: 53780
Updated by: cataphr...@php.net
Reported by:daniel dot seif at castex dot de
Summary:Iterating twice over an array changes the array
-Status: Open
+Status: Bogus
Type: Bug
Package:*General Issues
Operating System: Ubuntu 11.04
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
This is not a bug, it's an unfortunate consequence of the nonexistence
of block-scoped variables in PHP.
When the first foreach loop ends, $value will still exist and the last
element of $arr will be in the same reference set.
When the second foreach loop is running, $value will be written on each
iteration; when that happens, the last element of the array, which is in
the same reference set, will be changed too. From here, we can see that
the last of such assignments to have any effect is the penultimate,
since in the last assignment an element of the reference set is written
onto another such element, so it has no effect.
Previous Comments:
[2011-01-18 17:06:45] daniel dot seif at castex dot de
Description:
When using foreach to iterate over an array using the reference
(&$value) syntax, and using foreach a second time using the same
variable name changes the original array by overwriting the array's last
item with the second-last.
This is obviously wrong...
Hint: note the missing object's id #4 in the actual result
Test script:
---
// the example uses objects to show the object's id in the output, but
this error also occurs works with scalars
class A {}
$c = array(new A(), new A(), new A(), new A());
$arr = $c; // to keep the reference
var_dump($arr);
foreach ($arr as &$value) {}
var_dump($arr);
// using the same variable name
foreach ($arr as $value) {}
var_dump($arr);
Expected result:
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
object(A)#4 (0) {
}
}
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
object(A)#4 (0) {
}
}
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
object(A)#4 (0) {
}
}
Actual result:
--
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
object(A)#4 (0) {
}
}
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
&object(A)#4 (0) {
}
}
array(4) {
[0]=>
object(A)#1 (0) {
}
[1]=>
object(A)#2 (0) {
}
[2]=>
object(A)#3 (0) {
}
[3]=>
&object(A)#3 (0) {
}
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=53780&edit=1
Bug #52674 [Com]: [FPM] Status page returns inconsistent Content-Type headers
Edit report at http://bugs.php.net/bug.php?id=52674&edit=1 ID: 52674 Comment by: 1 dot david dot michael at gmail dot com Reported by:php-bugs at majkl578 dot cz Summary:[FPM] Status page returns inconsistent Content-Type headers Status: Closed Type: Bug Package:FPM related Operating System: Linux Debian PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: Is there a work around with apache to avoid upgrading to 5.3.4 or 5.3.5? Or is upgrading the only option? Previous Comments: [2010-08-23 22:41:56] f...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-08-23 22:40:46] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=302721 Log: - Fixed bug #52674 (FPM Status page returns inconsistent Content-Type headers). [2010-08-23 10:38:51] f...@php.net Moreover, the Content-Type used for json was not the best choice. It was application/jsonrequest. As specified in RFC4627, it should be application/json. [2010-08-23 10:28:43] f...@php.net The status page does not return a valid Content-Type header: ... text/plain Content-type: text/plain ... it should be ... Content-type: text/plain ... It affects apache but also any other front web servers. Nginx is more tolerant and ignores unknown / malformed headers but text/html was use instead. [2010-08-23 04:23:08] php-bugs at majkl578 dot cz Description: Apache 2 ends up with an error while trying to get content of /status url. Ping url works fine. Same problem with /status?json and /status?html. Apache version: 2.2.16, mpm-worker mod_fastcgi version: 2.4.6 Test script: --- FastCGIExternalServer /php5-fpm-handler -socket "/var/run/php5-fpm.sock" AddHandler php5-fcgi .php SetHandler php5-fcgi-virt Action php5-fcgi-virt /php5-fpm-handler.fcgi virtual Action php5-fcgi /php5-fpm-handler.fcgi ScriptAlias /php5-fpm-handler.fcgi /php5-fpm-handler Expected result: FPM status page Actual result: -- 500 Internal error Logged in Apache's error log: [Mon Aug 23 04:16:55 2010] [error] [client 127.0.0.1] FastCGI: comm with server "/php5-fpm-handler" aborted: error parsing headers: malformed header 'text/plain' -- Edit this bug report at http://bugs.php.net/bug.php?id=52674&edit=1
Bug #52674 [Csd]: [FPM] Status page returns inconsistent Content-Type headers
Edit report at http://bugs.php.net/bug.php?id=52674&edit=1 ID: 52674 Updated by: f...@php.net Reported by:php-bugs at majkl578 dot cz Summary:[FPM] Status page returns inconsistent Content-Type headers Status: Closed Type: Bug Package:FPM related Operating System: Linux Debian PHP Version:5.3.3 Assigned To:fat Block user comment: N Private report: N New Comment: this is an upgrade option only Previous Comments: [2011-01-18 20:26:41] 1 dot david dot michael at gmail dot com Is there a work around with apache to avoid upgrading to 5.3.4 or 5.3.5? Or is upgrading the only option? [2010-08-23 22:41:56] f...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-08-23 22:40:46] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=302721 Log: - Fixed bug #52674 (FPM Status page returns inconsistent Content-Type headers). [2010-08-23 10:38:51] f...@php.net Moreover, the Content-Type used for json was not the best choice. It was application/jsonrequest. As specified in RFC4627, it should be application/json. [2010-08-23 10:28:43] f...@php.net The status page does not return a valid Content-Type header: ... text/plain Content-type: text/plain ... it should be ... Content-type: text/plain ... It affects apache but also any other front web servers. Nginx is more tolerant and ignores unknown / malformed headers but text/html was use instead. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52674 -- Edit this bug report at http://bugs.php.net/bug.php?id=52674&edit=1
Req #39771 [Opn->Csd]: DOMDocument->saveHTML does not accept an optional DOMNode like saveXML
Edit report at http://bugs.php.net/bug.php?id=39771&edit=1 ID: 39771 Updated by: cataphr...@php.net Reported by:dave dot lane at gmx dot net Summary:DOMDocument->saveHTML does not accept an optional DOMNode like saveXML -Status: Open +Status: Closed Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Linux PHP Version:5.2.0 -Assigned To: +Assigned To:cataphract Block user comment: N Private report: N New Comment: Implemented for PHP 5.3 and trunk. Previous Comments: [2011-01-18 20:45:40] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=307561 Log: - Implemented FR #39771 (Made DOMDocument::saveHTML accept an optional DOMNode like DOMDocument::saveXML). [2006-12-07 19:34:19] dave dot lane at gmx dot net Description: DOMDocument->saveHTML does not accept an optional DOMNode like DOMDocument->saveXML. In saveXML this functionality is implemented using xmlNodeDump. libxml2 offers the html equivalent htmlNodeDump. Is there a good reason why this is not implemented? -- Edit this bug report at http://bugs.php.net/bug.php?id=39771&edit=1
[PHP-BUG] Bug #53782 [NEW]: foreach throws irrelevant exception
From:
Operating system: Windows 7
PHP version: Irrelevant
Package: PDO related
Bug Type: Bug
Bug description:foreach throws irrelevant exception
Description:
Iteration using foreach throws "previous" and irrelevant exception.
Exception is throwed after last iteration.
Test script:
---
$conn = new PDO("mysql:dbname=test");
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$res = $conn->query('SELECT * FROM categories');
try {
$conn->query('ERROR');
} catch (PDOException $e) { // exception is catched
}
foreach ($res as $k => $v); // now is throwed exception $e !!!
Expected result:
do nothing
--
Edit bug report at http://bugs.php.net/bug.php?id=53782&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53782&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53782&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53782&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53782&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53782&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53782&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53782&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53782&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53782&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53782&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53782&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53782&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53782&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53782&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53782&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53782&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53782&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53782&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53782&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53782&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53782&r=mysqlcfg
Bug #53572 [Com]: Bug appeared in php 5.2.15, FastCGI
Edit report at http://bugs.php.net/bug.php?id=53572&edit=1 ID: 53572 Comment by: anthon dot pang at gmail dot com Reported by:admin at xaker1 dot ru Summary:Bug appeared in php 5.2.15, FastCGI Status: Open Type: Bug Package:Unknown/Other Function Operating System: FreeBSD 8.1 PHP Version:5.2.16 Block user comment: N Private report: N New Comment: Just an observation, but ini the php.ini for the affected account, the open_basedir setting has spaces in the paths. Previous Comments: [2011-01-14 17:42:37] admin at xaker1 dot ru Error disappears if you disable open_basedir [2010-12-20 19:36:53] markusb at gmx dot at Same probleme We use php (cgi) and open_basedir > all php scrips > No input file specified. [2010-12-19 09:05:26] admin at xaker1 dot ru The problem exists on php 5.2.15 and php 5.2.16. I'm using php 5.2.14, as work is needed for all sites. php.ini on the affected account: register_globals = Off display_errors = Off log_errors = On max_execution_time = 30 memory_limit = 128M upload_max_filesize = 16M post_max_size = 16M session.save_path = "/ home/saki2/data/tmp" upload_tmp_dir = "/ home/saki2/data/tmp" open_basedir = "/ home/saki2: / tmp: / var / tmp" ; [suhosin] ; suhosin.log.syslog = E_ALL & ~ S_SQL ; suhosin.log.sapi = E_ALL & ~ S_SQL ; suhosin.executor.include.max_traversal = 4 ; suhosin.executor.func.blacklist = popen, dl, passthru, system, exec, proc_open, shell_exec, proc_close, symlink ; WARNING ; Or eAccelerator or Zend!!! ; Not twice!!! ; [eAccelerator] ; zend_extension = "/ usr/local/lib/php/20060613/eaccelerator.so" ; eaccelerator.cache_dir = "/ home/saki2/data/tmp" ; eaccelerator.debug = "0" ; eaccelerator.shm_size = "16" ; [Zend] ; zend_optimizer.optimization_level = 15 ; zend_extension_manager.optimizer = "/ usr/local/lib/php/20060613/Optimizer" ; zend_extension_manager.optimizer_ts = "/ usr/local/lib/php/20060613/Optimizer_TS" ; zend_extension = "/ usr/local/lib/php/20060613/ZendExtensionManager.so" ; zend_extension_ts = "/ usr/local/lib/php/20060613/ZendExtensionManager_TS.so" php.ini in the working account: register_globals= Off display_errors= On log_errors= On max_execution_time= 900 memory_limit= 512M upload_max_filesize= 16M post_max_size = 16M session.save_path = "/home/bravohost/data/tmp" upload_tmp_dir="/home/bravohost/data/tmp" open_basedir = "/home/bravohost:/tmp:/var/tmp" ;[suhosin] ;suhosin.log.syslog = E_ALL & ~S_SQL ;suhosin.log.sapi = E_ALL & ~S_SQL ;suhosin.executor.include.max_traversal = 4 ;suhosin.executor.func.blacklist = popen,dl,passthru,system,exec,proc_open,shell_exec,proc_close,symlink ; WARNING ; or eAccelerator or Zend!!! ; not twice!!! [eAccelerator] zend_extension="/usr/local/lib/php/20060613/eaccelerator.so" eaccelerator.cache_dir="/home/bravohost/data/tmp" eaccelerator.debug="0" eaccelerator.shm_size="16" ;[Zend] ;zend_optimizer.optimization_level=15 ;zend_extension_manager.optimizer="/usr/local/lib/php/20060613/Optimizer" ;zend_extension_manager.optimizer_ts="/usr/local/lib/php/20060613/Optimizer_TS" ;zend_extension="/usr/local/lib/php/20060613/ZendExtensionManager.so" ;zend_extension_ts="/usr/local/lib/php/20060613/ZendExtensionManager_TS.so ;extension = filter.so php modules are used: [PHP Modules] bcmath bz2 calendar ctype curl date dom filter gd gettext hash iconv imap ionCube Loader json libxml mbstring mcrypt mhash mysql mysqli openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML sockets SPL SQLite standard suhosin tokenizer xml xmlreader xmlwriter Zend Optimizer zip zlib [Zend Modules] Zend Extension Manager Zend Optimizer the ionCube PHP Loader [2010-12-18 22:14:48] cataphr...@php.net We'd need more information than what you gave. First, are you using 5.2.15 or 5.2.16. If you're using 5.2.15, upgrade. Then, what exactly is causing this (not a vague it may be root folder or name/group or open_basedir) and, preferably, steps to reproduce, would go a long way. Thanks. [2010-12-18 18:03:27] admin at xaker1 dot ru If you downgrade to 5.2.14, the error disappears. At the moment the causes of errors are found, ask for help. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53572 -- Edit this bug report at http://
Bug #32544 [Com]: cannot parse elements with dashes in names
Edit report at http://bugs.php.net/bug.php?id=32544&edit=1
ID: 32544
Comment by: thinkswan at gmail dot com
Reported by:mbishton at yahoo dot com
Summary:cannot parse elements with dashes in names
Status: Bogus
Type: Bug
Package:SimpleXML related
Operating System: Windows XP Prof. Version 5.1.260
PHP Version:5.0.3
Block user comment: N
Private report: N
New Comment:
You must encapsulate entries containing dashes.
$test = $meta[1]->{'yea-total'}; will work.
Previous Comments:
[2005-04-02 17:27:58] der...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
.
[2005-04-02 17:20:32] mbishton at yahoo dot com
Description:
U.S. library of congress displays house voting activity in xml file. For
example: $xml =
simplexml_load_file('http://clerk.house.gov/evs/1999/roll610.xml') ;
Many of the elements have dashes in them. For example:
Party
Yeas
Nays
Answered “Present”
Not Voting
Any reference to an element, like;
$xml->totals-by-party-header->party-header->yea-header
will not work.
Reproduce code:
---
It works just fine if the element does not have dashes in it, like:
simplexml_load_file('http://clerk.house.gov/evs/1999/roll610.xml') ;
$vmeta = $xml->xpath('//vote-metadata' );
echo 'congress = ' . $vmeta[0]->congress ;
In the following example, $test will produce an error.
simplexml_load_file('http://clerk.house.gov/evs/1999/roll610.xml') ;
$meta = $xml->xpath('//totals-by-party' );
$test = $meta[1]->yea-total ;
Expected result:
I expected it to return an array or the content of an element, depending
on what I was referencing.
Actual result:
--
Notice: Use of undefined constant total - assumed 'total' in C:\Program
Files\Apache2\htdocs\test01.php on line 9
--
Edit this bug report at http://bugs.php.net/bug.php?id=32544&edit=1
Bug #53577 [Dup->Csd]: Regression (5.3.3-5.3.4) in open_basedir with a trailing forward slash
Edit report at http://bugs.php.net/bug.php?id=53577&edit=1
ID: 53577
Updated by: paj...@php.net
Reported by:lekensteyn at gmail dot com
Summary:Regression (5.3.3-5.3.4) in open_basedir with a
trailing forward slash
-Status: Duplicate
+Status: Closed
Type: Bug
Package:Safe Mode/open_basedir
Operating System: Windows 7
PHP Version:5.3.4
-Assigned To:
+Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
fixed in revision 307563
Previous Comments:
[2011-01-18 23:22:31] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=307564
Log: - #53577 and cleanup
[2010-12-20 17:41:44] lekensteyn at gmail dot com
This is related to bug #53352 , but not an exact duplicate.
I've just added a patch on fopen_wrappers.c from the PHP 5.3 branch,
r305698 (
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/fopen_wrappers.c?view=markup&pathrev=305698
)
The patch fixed it for me.
[2010-12-20 07:34:40] ahar...@php.net
Duplicate of bug #53352.
[2010-12-19 23:58:32] lekensteyn at gmail dot com
I'm just guessing, replacing the following:
-- snip --
if (basedir[strlen(basedir) - 1] == PHP_DIR_SEPARATOR) {
if (resolved_basedir[resolved_basedir_len - 1] !=
PHP_DIR_SEPARATOR)
{
resolved_basedir[resolved_basedir_len] =
PHP_DIR_SEPARATOR;
resolved_basedir[++resolved_basedir_len] = '\0';
}
} else {
resolved_basedir[resolved_basedir_len++] =
PHP_DIR_SEPARATOR;
resolved_basedir[resolved_basedir_len] = '\0';
}
-- snip --
with
-- snip --
if (basedir[strlen(basedir) - 1] == PHP_DIR_SEPARATOR) {
if (resolved_basedir[resolved_basedir_len - 1] !=
PHP_DIR_SEPARATOR)
{
resolved_basedir[resolved_basedir_len] =
PHP_DIR_SEPARATOR;
resolved_basedir[++resolved_basedir_len] = '\0';
}
#if defined(PHP_WIN32) || defined(NETWARE)
} else if (basedir[strlen(basedir) - 1] != '/') {
#else
} else {
#endif
resolved_basedir[resolved_basedir_len++] =
PHP_DIR_SEPARATOR;
resolved_basedir[resolved_basedir_len] = '\0';
}
-- snip --
should work.
Under Windows, PHP_DIR_SEPARATOR is a backslash. So we check here if it
is a forward slash.
[2010-12-19 23:44:46] lekensteyn at gmail dot com
Description:
Downloaded PHP 5.3.3 from:
http://windows.php.net/downloads/releases/archives/php-5.3.3-nts-Win32-VC9-x86.zip
Downloaded PHP 5.3.4 from:
http://windows.php.net/downloads/releases/php-5.3.4-nts-Win32-VC9-x86.zip
The following settings has the expected results in both PHP 5.3.3 and
PHP 5.3.4
open_basedir="C:\twlan\"
open_basedir="C:\twlan"
open_basedir="C:/twlan"
open_basedir="C:/twlan\"
The following setting breaks open_basedir in PHP 5.3.4, but works fine
in 5.3.3.
open_basedir="C:/twlan/"
So, the trailing forward slash on open_basedir makes every path
invalid.
Changes between 5.3.3 and 5.3.4:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/fopen_wrappers.c?r1=301440&r2=306091
I think the bug was introduced in
http://svn.php.net/viewvc/php/php-src/trunk/main/fopen_wrappers.c?r1=305098&r2=305698
--- begin code ---
@@ -228,6 +234,9 @@
resolved_basedir[resolved_basedir_len] =
PHP_DIR_SEPARATOR;
resolved_basedir[++resolved_basedir_len] = '\0';
}
+ } else {
+ resolved_basedir[resolved_basedir_len++] =
PHP_DIR_SEPARATOR;
+ resolved_basedir[resolved_basedir_len] = '\0';
}
resolved_name_len = strlen(resolved_name);
--- end code ---
PHP_DIR_SEPARATOR is "\\" on Windows.
Test script:
---
Expected result:
string(22) "C:\twlan\htdocs\combot"
string(15) "C:\twlan\htdocs"
string(8) "C:\twlan"
Warning: realpath(): open_basedir restriction in effect. File(C:\) is
not within the allowed path(s): (C:/twlan/) in
C:\twlan\htdocs\combot\php-bug.php on line 7
bool(false)
Actual result
Bug #53778 [Opn->Bgs]: strtotime returning wrong result
Edit report at http://bugs.php.net/bug.php?id=53778&edit=1 ID: 53778 Updated by: ahar...@php.net Reported by:mark at atlasdesignsolutions dot com Summary:strtotime returning wrong result -Status: Open +Status: Bogus Type: Bug Package:Date/time related Operating System: CentOS PHP Version:5.2.17 Block user comment: N Private report: N New Comment: This works in PHP 5.3 with the correct format, ie: Outputs: 02-08-2011 03-08-2011 04-12-2011 Closing, since this works in 5.3 and 5.2 is end of lifed. Previous Comments: [2011-01-18 16:26:02] mark at atlasdesignsolutions dot com Description: strtotime is incorrectly evaluating second Tuesday for any month that starts on Tuesday. Test script: --- Expected result: 02-08-2011 03-08-2011 04-12-2011 Actual result: -- 02-15-2011 03-15-2011 04-12-2011 -- Edit this bug report at http://bugs.php.net/bug.php?id=53778&edit=1
[PHP-BUG] Req #53785 [NEW]: Way to query a X.509 certificate fingerprint
From: Operating system: Debian PHP version: 5.3.5 Package: OpenSSL related Bug Type: Feature/Change Request Bug description:Way to query a X.509 certificate fingerprint Description: When reading a X.509 certificate file (or fetching the certificate from an SSL connection) there is no straight forward way to query the certificate's fingerprint as shown by browsers when viewing the site's certificate. The output of openssl_x509_parse doesn't contain the fingerprint while openssl_x509_export might contain it in a hard to parse string representation. -- Edit bug report at http://bugs.php.net/bug.php?id=53785&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53785&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53785&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53785&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53785&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53785&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53785&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53785&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53785&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53785&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53785&r=support Expected behavior: http://bugs.php.net/fix.php?id=53785&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53785&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53785&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53785&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53785&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53785&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53785&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53785&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53785&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53785&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53785&r=mysqlcfg
