Req #65646 [Opn-Asn]: re-enable CURLOPT_FOLLOWLOCATION with open_basedir or safe_mode
Edit report at https://bugs.php.net/bug.php?id=65646edit=1 ID: 65646 Updated by: ahar...@php.net Reported by:butesa at freenet dot de Summary:re-enable CURLOPT_FOLLOWLOCATION with open_basedir or safe_mode -Status: Open +Status: Assigned Type: Feature/Change Request Package:cURL related Operating System: any PHP Version:5.5.3 -Assigned To: +Assigned To:aharvey Block user comment: N Private report: N New Comment: I have an implementation of this on a branch in my GitHub fork, but don't have time to finish testing it tonight. I'll try to get back to it later in the week. Previous Comments: [2013-09-09 21:27:10] butesa at freenet dot de Description: CURLOPT_FOLLOWLOCATION is disabled when open_basedir is set or when safe_mode is on. Since 7.19.4, curl won't follow a location-header that uses the file-protocol. So using CURLOPT_FOLLOWLOCATION in combination with open_basedir or safe_mode should be fine. (Since 7.19.4, libcurl can limit what protocols it will automatically follow. The accepted protocols are set with CURLOPT_REDIR_PROTOCOLS and it excludes the FILE protocol by default. http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTFOLLOWLOCATION ) -- Edit this bug report at https://bugs.php.net/bug.php?id=65646edit=1
Req #65646 [Com]: re-enable CURLOPT_FOLLOWLOCATION with open_basedir or safe_mode
Edit report at https://bugs.php.net/bug.php?id=65646edit=1 ID: 65646 Comment by: sudanisayfree at gmail dot com Reported by:butesa at freenet dot de Summary:re-enable CURLOPT_FOLLOWLOCATION with open_basedir or safe_mode Status: Assigned Type: Feature/Change Request Package:cURL related Operating System: any PHP Version:5.5.3 Assigned To:aharvey Block user comment: N Private report: N New Comment: I use Nimbuzz! Developers Program in there website : ( http://developer.nimbuzz.com/page.php?page=manual ) To make the program work by downloading this folder : http://developer.nimbuzz.com/tools/docs/hello-world.rar there you should Extract this codebase and add the folder 'hello-world' in the document root of your server. So if your hosting is www.myhosting.com, try opening http://www.myhosting.com/hello- world/api.php, you should see the page return an xml response. This is the Callback URL for your chat buddy. Please provide us with this callback URL on developers.nimbuzz.com or mail us at developers.nimbuzz.com then you must Make config changes. Replace 'test123' with TESTJID provided by us in file configuration.php. Add your chat buddy to your roster using TESTJID provided by us. Use 'bot TESTJID' to add chat buddy to your roster on PC/MAC client. Previous Comments: [2013-09-10 06:26:40] ahar...@php.net I have an implementation of this on a branch in my GitHub fork, but don't have time to finish testing it tonight. I'll try to get back to it later in the week. [2013-09-09 21:27:10] butesa at freenet dot de Description: CURLOPT_FOLLOWLOCATION is disabled when open_basedir is set or when safe_mode is on. Since 7.19.4, curl won't follow a location-header that uses the file-protocol. So using CURLOPT_FOLLOWLOCATION in combination with open_basedir or safe_mode should be fine. (Since 7.19.4, libcurl can limit what protocols it will automatically follow. The accepted protocols are set with CURLOPT_REDIR_PROTOCOLS and it excludes the FILE protocol by default. http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTFOLLOWLOCATION ) -- Edit this bug report at https://bugs.php.net/bug.php?id=65646edit=1
Bug #65642 [Asn-Fbk]: sysconfdir broken in 64-bit Windows build
Edit report at https://bugs.php.net/bug.php?id=65642edit=1
ID: 65642
Updated by: a...@php.net
Reported by:krishean+php at gmail dot com
Summary:sysconfdir broken in 64-bit Windows build
-Status: Assigned
+Status: Feedback
Type: Bug
Package:LDAP related
Operating System: Windows 7 x64
PHP Version:5.5.3
Assigned To:ab
Block user comment: N
Private report: N
New Comment:
Please test the builds from here
http://windows.php.net/downloads/snaps/ostc/65642/ (if possible both x64 and
x86),
they should have correct compiled in path.
Previous Comments:
[2013-09-09 15:40:37] krishean+php at gmail dot com
Description:
When trying to bind to an ldap server over ssl, you need a file called
ldap.conf in the directory C:\openldap\sysconf with a few options in it (at
least on Windows, Linux is somewhere in /etc.) In the past (php 5.4 etc.) this
worked wonderfully, with php checking that directory, loading the file, and
connecting to the server just fine. In php 5.5.3 however, this is completely
broken. I used Process Monitor to check where it was searching for ldap.conf
and it seems to be searching as such:
G:\Documents\Projects\ProjectName\%SYSCONFDIR%\ldap.conf (the ProjectName
directory being where the currently executing script is located.) I checked and
php 5.4.18 checks in the correct directory: C:\openldap\sysconf\ldap.conf
Test script:
---
$host = 'ldaps://server01';
$port = 636;
$rdn = 'CN=Jeff Smith,CN=users,DC=fabrikam,DC=com';
$pwd = 'password';
if(($conn = @ldap_connect($host, $port)) != FALSE){
ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($conn, LDAP_OPT_REFERRALS, 0);
// bind to ldap connection
if(($r = @ldap_bind($conn, $rdn, $pwd)) != FALSE){
echo(Successfully connected to LDAP.\n);
}else{
echo(Error: Failed to bind to LDAP.\n); // this happens
if($conn){
ldap_unbind($conn);
}
$conn = null;
}
}else echo(Error: Failed to connect to LDAP.\n);
Expected result:
Script should bind to ldap server over ssl (ldaps://) and report success.
Actual result:
--
Script fails to bind to ldap server over ssl.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65642edit=1
[PHP-BUG] Bug #65647 [NEW]: @list call behaves incorrectly and may cause Segmentation fault (11)
From: piotr dot m at shwrm dot com
Operating system: Linux / Ubuntu 13.04
PHP version: 5.5.3
Package: *General Issues
Bug Type: Bug
Bug description:@list call behaves incorrectly and may cause Segmentation fault
(11)
Description:
Call to @list on an array returned by function_get_args() will incorrectly
fill variables (only last one is filled) 80% of the time and will cause a
Segmentation fault (11) on the other 20%.
PHP 5.5.3 run on Apache 2.2.22
Test script:
---
function a() {
$opts = func_get_args();
@list($a, $b, $c) = $opts;
var_dump($a, $b, $c);
}
a('1','22', '333');
Expected result:
string '1' (length=1)
string '22' (length=2)
string '333' (length=3)
Actual result:
--
null
null
string '333' (length=3)
Or segfault:
[Tue Sep 10 10:57:46 2013] [notice] child pid 32315 exit signal
Segmentation fault (11), possible coredump in /etc/apache2
--
Edit bug report at https://bugs.php.net/bug.php?id=65647edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65647r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65647r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65647r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65647r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65647r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65647r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65647r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65647r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65647r=support
Expected behavior: https://bugs.php.net/fix.php?id=65647r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65647r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65647r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65647r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65647r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65647r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65647r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65647r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65647r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65647r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65647r=mysqlcfg
[PHP-BUG] Bug #65648 [NEW]: Check date error
From: manhchat dot it at gmail dot com Operating system: Linux, Windown PHP version: 5.5.4RC1 Package: Date/time related Bug Type: Bug Bug description:Check date error Description: function checkdate of PHP error: checkdate(009, 0023, 2013) will return true -- Edit bug report at https://bugs.php.net/bug.php?id=65648edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65648r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65648r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65648r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65648r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65648r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65648r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65648r=needscript Try newer version: https://bugs.php.net/fix.php?id=65648r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65648r=support Expected behavior: https://bugs.php.net/fix.php?id=65648r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65648r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65648r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65648r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65648r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65648r=dst IIS Stability: https://bugs.php.net/fix.php?id=65648r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65648r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65648r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65648r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65648r=mysqlcfg
Bug #65647 [Com]: @list call behaves incorrectly and may cause Segmentation fault (11)
Edit report at https://bugs.php.net/bug.php?id=65647edit=1
ID: 65647
Comment by: leight+bugs dot php at gmail dot com
Reported by:piotr dot m at shwrm dot com
Summary:@list call behaves incorrectly and may cause
Segmentation fault (11)
Status: Open
Type: Bug
Package:*General Issues
Operating System: Linux / Ubuntu 13.04
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Unable to reproduce with 5.5.3 or 5.6.0-dev on Debian 7 or OSX using PHP CLI
(unable to test with Apache at present).
Piotr do you get the same results using the CLI? What other modules do you have
loaded?
A backtrace of the coredump might also be useful.
Previous Comments:
[2013-09-10 09:21:08] piotr dot m at shwrm dot com
Description:
Call to @list on an array returned by function_get_args() will incorrectly fill
variables (only last one is filled) 80% of the time and will cause a
Segmentation fault (11) on the other 20%.
PHP 5.5.3 run on Apache 2.2.22
Test script:
---
function a() {
$opts = func_get_args();
@list($a, $b, $c) = $opts;
var_dump($a, $b, $c);
}
a('1','22', '333');
Expected result:
string '1' (length=1)
string '22' (length=2)
string '333' (length=3)
Actual result:
--
null
null
string '333' (length=3)
Or segfault:
[Tue Sep 10 10:57:46 2013] [notice] child pid 32315 exit signal Segmentation
fault (11), possible coredump in /etc/apache2
--
Edit this bug report at https://bugs.php.net/bug.php?id=65647edit=1
Bug #65647 [Opn]: @list call behaves incorrectly and may cause Segmentation fault (11)
Edit report at https://bugs.php.net/bug.php?id=65647edit=1
ID: 65647
User updated by:piotr dot m at shwrm dot com
Reported by:piotr dot m at shwrm dot com
Summary:@list call behaves incorrectly and may cause
Segmentation fault (11)
Status: Open
Type: Bug
Package:*General Issues
Operating System: Linux / Ubuntu 13.04
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
No, the problem does not seem to persit when run in CLI mode. The code behaves
exactly as it should.
Here's a var_dump(get_loaded_extensions()):
0 = string 'Core' (length=4)
1 = string 'date' (length=4)
2 = string 'ereg' (length=4)
3 = string 'libxml' (length=6)
4 = string 'openssl' (length=7)
5 = string 'pcre' (length=4)
6 = string 'zlib' (length=4)
7 = string 'bcmath' (length=6)
8 = string 'bz2' (length=3)
9 = string 'calendar' (length=8)
10 = string 'ctype' (length=5)
11 = string 'dba' (length=3)
12 = string 'dom' (length=3)
13 = string 'hash' (length=4)
14 = string 'fileinfo' (length=8)
15 = string 'filter' (length=6)
16 = string 'ftp' (length=3)
17 = string 'gettext' (length=7)
18 = string 'SPL' (length=3)
19 = string 'iconv' (length=5)
20 = string 'json' (length=4)
21 = string 'mbstring' (length=8)
22 = string 'session' (length=7)
23 = string 'standard' (length=8)
24 = string 'posix' (length=5)
25 = string 'Reflection' (length=10)
26 = string 'Phar' (length=4)
27 = string 'shmop' (length=5)
28 = string 'SimpleXML' (length=9)
29 = string 'soap' (length=4)
30 = string 'sockets' (length=7)
31 = string 'exif' (length=4)
32 = string 'sysvmsg' (length=7)
33 = string 'sysvsem' (length=7)
34 = string 'sysvshm' (length=7)
35 = string 'tokenizer' (length=9)
36 = string 'wddx' (length=4)
37 = string 'xml' (length=3)
38 = string 'xmlreader' (length=9)
39 = string 'xmlwriter' (length=9)
40 = string 'zip' (length=3)
41 = string 'apache2handler' (length=14)
42 = string 'PDO' (length=3)
43 = string 'curl' (length=4)
44 = string 'imap' (length=4)
45 = string 'memcached' (length=9)
46 = string 'pdo_pgsql' (length=9)
47 = string 'pgsql' (length=5)
48 = string 'readline' (length=8)
49 = string 'redis' (length=5)
50 = string 'mhash' (length=5)
51 = string 'Zend OPcache' (length=12)
52 = string 'xdebug' (length=6)
Unfortunately the coredump does not get created - any ideas on how i might
force the generation of one?
Previous Comments:
[2013-09-10 09:52:06] leight+bugs dot php at gmail dot com
Unable to reproduce with 5.5.3 or 5.6.0-dev on Debian 7 or OSX using PHP CLI
(unable to test with Apache at present).
Piotr do you get the same results using the CLI? What other modules do you have
loaded?
A backtrace of the coredump might also be useful.
[2013-09-10 09:21:08] piotr dot m at shwrm dot com
Description:
Call to @list on an array returned by function_get_args() will incorrectly fill
variables (only last one is filled) 80% of the time and will cause a
Segmentation fault (11) on the other 20%.
PHP 5.5.3 run on Apache 2.2.22
Test script:
---
function a() {
$opts = func_get_args();
@list($a, $b, $c) = $opts;
var_dump($a, $b, $c);
}
a('1','22', '333');
Expected result:
string '1' (length=1)
string '22' (length=2)
string '333' (length=3)
Actual result:
--
null
null
string '333' (length=3)
Or segfault:
[Tue Sep 10 10:57:46 2013] [notice] child pid 32315 exit signal Segmentation
fault (11), possible coredump in /etc/apache2
--
Edit this bug report at https://bugs.php.net/bug.php?id=65647edit=1
Bug #65645 [Csd-Nab]: interactive shell doesn't support finally block
Edit report at https://bugs.php.net/bug.php?id=65645edit=1
ID: 65645
Updated by: ras...@php.net
Reported by:schavery at gmail dot com
Summary:interactive shell doesn't support finally block
-Status: Closed
+Status: Not a bug
Type: Bug
Package:CGI/CLI related
Operating System: OS X 10.8.4
PHP Version:5.4.19
Block user comment: N
Private report: N
Previous Comments:
[2013-09-09 19:24:27] schavery at gmail dot com
Only works with 5.5+, and I was running 5.4
[2013-09-09 18:48:42] schavery at gmail dot com
Description:
---
From manual page: http://www.php.net/features.commandline.interactive
---
Using php -a
try { echo 'try'; } catch(Exception $e) { echo 'catch'; } finally { echo
'finally'; }
returns:
PHP Parse error: parse error in php shell code on line 1
and:
php try {
php { echo '1';
php { } catch(Exception $e) {
php { echo '2';
php { } finally { -- line 5
php { echo '3';
php { }
PHP Parse error: parse error in php shell code on line 5
Test script:
---
?php
try {
echo '1';
} catch (Exception $e) {
echo '2';
} finally {
echo '3';
}
Expected result:
expected result is:
13
Actual result:
--
PHP Parse error
--
Edit this bug report at https://bugs.php.net/bug.php?id=65645edit=1
Bug #65647 [Opn-Fbk]: @list call behaves incorrectly and may cause Segmentation fault (11)
Edit report at https://bugs.php.net/bug.php?id=65647edit=1
ID: 65647
Updated by: johan...@php.net
Reported by:piotr dot m at shwrm dot com
Summary:@list call behaves incorrectly and may cause
Segmentation fault (11)
-Status: Open
+Status: Feedback
Type: Bug
Package:*General Issues
Operating System: Linux / Ubuntu 13.04
PHP Version:5.5.3
Block user comment: N
Private report: N
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.
The above has guidance on creating a backtrace, but please disable Zend
Optimizer and XDebug first.
Previous Comments:
[2013-09-10 10:43:53] piotr dot m at shwrm dot com
No, the problem does not seem to persit when run in CLI mode. The code behaves
exactly as it should.
Here's a var_dump(get_loaded_extensions()):
0 = string 'Core' (length=4)
1 = string 'date' (length=4)
2 = string 'ereg' (length=4)
3 = string 'libxml' (length=6)
4 = string 'openssl' (length=7)
5 = string 'pcre' (length=4)
6 = string 'zlib' (length=4)
7 = string 'bcmath' (length=6)
8 = string 'bz2' (length=3)
9 = string 'calendar' (length=8)
10 = string 'ctype' (length=5)
11 = string 'dba' (length=3)
12 = string 'dom' (length=3)
13 = string 'hash' (length=4)
14 = string 'fileinfo' (length=8)
15 = string 'filter' (length=6)
16 = string 'ftp' (length=3)
17 = string 'gettext' (length=7)
18 = string 'SPL' (length=3)
19 = string 'iconv' (length=5)
20 = string 'json' (length=4)
21 = string 'mbstring' (length=8)
22 = string 'session' (length=7)
23 = string 'standard' (length=8)
24 = string 'posix' (length=5)
25 = string 'Reflection' (length=10)
26 = string 'Phar' (length=4)
27 = string 'shmop' (length=5)
28 = string 'SimpleXML' (length=9)
29 = string 'soap' (length=4)
30 = string 'sockets' (length=7)
31 = string 'exif' (length=4)
32 = string 'sysvmsg' (length=7)
33 = string 'sysvsem' (length=7)
34 = string 'sysvshm' (length=7)
35 = string 'tokenizer' (length=9)
36 = string 'wddx' (length=4)
37 = string 'xml' (length=3)
38 = string 'xmlreader' (length=9)
39 = string 'xmlwriter' (length=9)
40 = string 'zip' (length=3)
41 = string 'apache2handler' (length=14)
42 = string 'PDO' (length=3)
43 = string 'curl' (length=4)
44 = string 'imap' (length=4)
45 = string 'memcached' (length=9)
46 = string 'pdo_pgsql' (length=9)
47 = string 'pgsql' (length=5)
48 = string 'readline' (length=8)
49 = string 'redis' (length=5)
50 = string 'mhash' (length=5)
51 = string 'Zend OPcache' (length=12)
52 = string 'xdebug' (length=6)
Unfortunately the coredump does not get created - any ideas on how i might
force the generation of one?
[2013-09-10 09:52:06] leight+bugs dot php at gmail dot com
Unable to reproduce with 5.5.3 or 5.6.0-dev on Debian 7 or OSX using PHP CLI
(unable to test with Apache at present).
Piotr do you get the same results using the CLI? What other modules do you have
loaded?
A backtrace of the coredump might also be useful.
[2013-09-10 09:21:08] piotr dot m at shwrm dot com
Description:
Call to @list on an array returned by function_get_args() will incorrectly fill
variables (only last one is filled) 80% of the time and will cause a
Segmentation fault (11) on the other 20%.
PHP 5.5.3 run on Apache 2.2.22
Test script:
---
function a() {
$opts = func_get_args();
@list($a, $b, $c) = $opts;
var_dump($a, $b, $c);
}
a('1','22', '333');
Expected result:
string '1' (length=1)
string '22' (length=2)
string '333' (length=3)
Actual result:
--
null
null
string '333' (length=3)
Or segfault:
[Tue Sep 10 10:57:46 2013] [notice] child pid 32315 exit signal Segmentation
fault (11), possible coredump in /etc/apache2
--
Edit this bug report at https://bugs.php.net/bug.php?id=65647edit=1
Bug #65648 [Opn-Nab]: Check date error
Edit report at https://bugs.php.net/bug.php?id=65648edit=1 ID: 65648 Updated by: johan...@php.net Reported by:manhchat dot it at gmail dot com Summary:Check date error -Status: Open +Status: Not a bug Type: Bug Package:Date/time related Operating System: Linux, Windown PHP Version:5.5.4RC1 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 A number prefixed by 0 is interpreted as octal. Please see http://php.net/integer Previous Comments: [2013-09-10 09:50:06] manhchat dot it at gmail dot com Description: function checkdate of PHP error: checkdate(009, 0023, 2013) will return true -- Edit this bug report at https://bugs.php.net/bug.php?id=65648edit=1
Bug #65647 [Fbk-Opn]: @list call behaves incorrectly and may cause Segmentation fault (11)
Edit report at https://bugs.php.net/bug.php?id=65647edit=1 ID: 65647 User updated by:piotr dot m at shwrm dot com Reported by:piotr dot m at shwrm dot com Summary:@list call behaves incorrectly and may cause Segmentation fault (11) -Status: Feedback +Status: Open Type: Bug Package:*General Issues Operating System: Linux / Ubuntu 13.04 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: As requested i disabled XDebug and Zend Optimizer. All of a sudden the code acts properly and as expected. I managed to narrow the problem down to Zend Optimizer. If it's activated the problem occurs, once disabled everything goes back to normal. Here's a gdb backtrace with Zend Optimizer on: Program received signal SIGSEGV, Segmentation fault. 0x741313b7 in ?? () from /usr/lib/apache2/modules/libphp5.so (gdb) bt #0 0x741313b7 in ?? () from /usr/lib/apache2/modules/libphp5.so #1 0x741154f8 in execute_ex () from /usr/lib/apache2/modules/libphp5.so #2 0x740a8059 in zend_execute_scripts () from /usr/lib/apache2/modules/libphp5.so #3 0x7404651c in php_execute_script () from /usr/lib/apache2/modules/libphp5.so #4 0x74158a4a in ?? () from /usr/lib/apache2/modules/libphp5.so #5 0x555964b0 in ap_run_handler (r=0x752b16c8) at config.c:159 #6 0x555968fb in ap_invoke_handler (r=r@entry=0x752b16c8) at config.c:377 #7 0x555a609c in ap_internal_redirect (new_uri=optimized out, r=optimized out) at http_request.c:554 #8 0x7fffefb50908 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #9 0x555964b0 in ap_run_handler (r=0x752bc0a0) at config.c:159 #10 0x555968fb in ap_invoke_handler (r=r@entry=0x752bc0a0) at config.c:377 #11 0x555a6a28 in ap_process_request (r=r@entry=0x752bc0a0) at http_request.c:282 #12 0x555a38d8 in ap_process_http_connection (c=0x77dff290) at http_core.c:190 #13 0x5559ce80 in ap_run_process_connection (c=0x77dff290) at connection.c:43 #14 0x5559d268 in ap_process_connection (c=c@entry=0x77dff290, csd=optimized out) at connection.c:190 #15 0x555ab646 in child_main (child_num_arg=child_num_arg@entry=0) at prefork.c:667 #16 0x555abd5e in make_child (s=0x77fea818, slot=0) at prefork.c:712 #17 0x555ac4e2 in ap_mpm_run (_pconf=_pconf@entry=0x77ff0028, plog=optimized out, s=s@entry=0x77fea818) at prefork.c:988 #18 0x5558124e in main (argc=2, argv=0x7fffe5c8) at main.c:755 I hope this helps. Previous Comments: [2013-09-10 11:11:07] johan...@php.net 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. The above has guidance on creating a backtrace, but please disable Zend Optimizer and XDebug first. [2013-09-10 10:43:53] piotr dot m at shwrm dot com No, the problem does not seem to persit when run in CLI mode. The code behaves exactly as it should. Here's a var_dump(get_loaded_extensions()): 0 = string 'Core' (length=4) 1 = string 'date' (length=4) 2 = string 'ereg' (length=4) 3 = string 'libxml' (length=6) 4 = string 'openssl' (length=7) 5 = string 'pcre' (length=4) 6 = string 'zlib' (length=4) 7 = string 'bcmath' (length=6) 8 = string 'bz2' (length=3) 9 = string 'calendar' (length=8) 10 = string 'ctype' (length=5) 11 = string 'dba' (length=3) 12 = string 'dom' (length=3) 13 = string 'hash' (length=4) 14 = string 'fileinfo' (length=8) 15 = string 'filter' (length=6) 16 = string 'ftp' (length=3) 17 = string 'gettext' (length=7) 18 = string 'SPL' (length=3) 19 = string 'iconv' (length=5) 20 = string 'json' (length=4) 21 = string 'mbstring' (length=8) 22 = string 'session' (length=7) 23 = string 'standard' (length=8) 24 = string 'posix' (length=5) 25 = string 'Reflection' (length=10) 26 = string 'Phar' (length=4) 27 = string 'shmop' (length=5) 28 = string 'SimpleXML' (length=9) 29 = string 'soap' (length=4) 30 = string 'sockets' (length=7) 31 = string 'exif' (length=4) 32 = string 'sysvmsg' (length=7) 33 = string 'sysvsem' (length=7) 34 = string 'sysvshm' (length=7) 35 = string 'tokenizer' (length=9) 36 = string 'wddx' (length=4) 37 = string 'xml' (length=3) 38 = string 'xmlreader' (length=9) 39 = string
Bug #65642 [Com]: sysconfdir broken in 64-bit Windows build
Edit report at https://bugs.php.net/bug.php?id=65642edit=1
ID: 65642
Comment by: krishean+php at gmail dot com
Reported by:krishean+php at gmail dot com
Summary:sysconfdir broken in 64-bit Windows build
Status: Feedback
Type: Bug
Package:LDAP related
Operating System: Windows 7 x64
PHP Version:5.5.3
Assigned To:ab
Block user comment: N
Private report: N
New Comment:
I tested both the x86 and x64 builds of the php_ldap (threadsafe) extension and
they both seem to work as intended, checking the
C:\openldap\sysconf\ldap.conf file for configuraton parameters before
successfully connecting to the ldap server over ssl.
Previous Comments:
[2013-09-10 08:10:40] a...@php.net
Please test the builds from here
http://windows.php.net/downloads/snaps/ostc/65642/ (if possible both x64 and
x86),
they should have correct compiled in path.
[2013-09-09 15:40:37] krishean+php at gmail dot com
Description:
When trying to bind to an ldap server over ssl, you need a file called
ldap.conf in the directory C:\openldap\sysconf with a few options in it (at
least on Windows, Linux is somewhere in /etc.) In the past (php 5.4 etc.) this
worked wonderfully, with php checking that directory, loading the file, and
connecting to the server just fine. In php 5.5.3 however, this is completely
broken. I used Process Monitor to check where it was searching for ldap.conf
and it seems to be searching as such:
G:\Documents\Projects\ProjectName\%SYSCONFDIR%\ldap.conf (the ProjectName
directory being where the currently executing script is located.) I checked and
php 5.4.18 checks in the correct directory: C:\openldap\sysconf\ldap.conf
Test script:
---
$host = 'ldaps://server01';
$port = 636;
$rdn = 'CN=Jeff Smith,CN=users,DC=fabrikam,DC=com';
$pwd = 'password';
if(($conn = @ldap_connect($host, $port)) != FALSE){
ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($conn, LDAP_OPT_REFERRALS, 0);
// bind to ldap connection
if(($r = @ldap_bind($conn, $rdn, $pwd)) != FALSE){
echo(Successfully connected to LDAP.\n);
}else{
echo(Error: Failed to bind to LDAP.\n); // this happens
if($conn){
ldap_unbind($conn);
}
$conn = null;
}
}else echo(Error: Failed to connect to LDAP.\n);
Expected result:
Script should bind to ldap server over ssl (ldaps://) and report success.
Actual result:
--
Script fails to bind to ldap server over ssl.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65642edit=1
Bug #65647 [Opn-Fbk]: @list call behaves incorrectly and may cause Segmentation fault (11)
Edit report at https://bugs.php.net/bug.php?id=65647edit=1 ID: 65647 Updated by: larue...@php.net Reported by:piotr dot m at shwrm dot com Summary:@list call behaves incorrectly and may cause Segmentation fault (11) -Status: Open +Status: Feedback Type: Bug Package:*General Issues Operating System: Linux / Ubuntu 13.04 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.5-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2013-09-10 12:43:58] piotr dot m at shwrm dot com As requested i disabled XDebug and Zend Optimizer. All of a sudden the code acts properly and as expected. I managed to narrow the problem down to Zend Optimizer. If it's activated the problem occurs, once disabled everything goes back to normal. Here's a gdb backtrace with Zend Optimizer on: Program received signal SIGSEGV, Segmentation fault. 0x741313b7 in ?? () from /usr/lib/apache2/modules/libphp5.so (gdb) bt #0 0x741313b7 in ?? () from /usr/lib/apache2/modules/libphp5.so #1 0x741154f8 in execute_ex () from /usr/lib/apache2/modules/libphp5.so #2 0x740a8059 in zend_execute_scripts () from /usr/lib/apache2/modules/libphp5.so #3 0x7404651c in php_execute_script () from /usr/lib/apache2/modules/libphp5.so #4 0x74158a4a in ?? () from /usr/lib/apache2/modules/libphp5.so #5 0x555964b0 in ap_run_handler (r=0x752b16c8) at config.c:159 #6 0x555968fb in ap_invoke_handler (r=r@entry=0x752b16c8) at config.c:377 #7 0x555a609c in ap_internal_redirect (new_uri=optimized out, r=optimized out) at http_request.c:554 #8 0x7fffefb50908 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #9 0x555964b0 in ap_run_handler (r=0x752bc0a0) at config.c:159 #10 0x555968fb in ap_invoke_handler (r=r@entry=0x752bc0a0) at config.c:377 #11 0x555a6a28 in ap_process_request (r=r@entry=0x752bc0a0) at http_request.c:282 #12 0x555a38d8 in ap_process_http_connection (c=0x77dff290) at http_core.c:190 #13 0x5559ce80 in ap_run_process_connection (c=0x77dff290) at connection.c:43 #14 0x5559d268 in ap_process_connection (c=c@entry=0x77dff290, csd=optimized out) at connection.c:190 #15 0x555ab646 in child_main (child_num_arg=child_num_arg@entry=0) at prefork.c:667 #16 0x555abd5e in make_child (s=0x77fea818, slot=0) at prefork.c:712 #17 0x555ac4e2 in ap_mpm_run (_pconf=_pconf@entry=0x77ff0028, plog=optimized out, s=s@entry=0x77fea818) at prefork.c:988 #18 0x5558124e in main (argc=2, argv=0x7fffe5c8) at main.c:755 I hope this helps. [2013-09-10 11:11:07] johan...@php.net 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. The above has guidance on creating a backtrace, but please disable Zend Optimizer and XDebug first. [2013-09-10 10:43:53] piotr dot m at shwrm dot com No, the problem does not seem to persit when run in CLI mode. The code behaves exactly as it should. Here's a var_dump(get_loaded_extensions()): 0 = string 'Core' (length=4) 1 = string 'date' (length=4) 2 = string 'ereg' (length=4) 3 = string 'libxml' (length=6) 4 = string 'openssl' (length=7) 5 = string 'pcre' (length=4) 6 = string 'zlib' (length=4) 7 = string 'bcmath' (length=6) 8 = string 'bz2' (length=3) 9 = string 'calendar' (length=8) 10 = string 'ctype' (length=5) 11 = string 'dba' (length=3) 12 = string 'dom' (length=3) 13 = string 'hash' (length=4) 14 = string 'fileinfo' (length=8) 15 = string 'filter' (length=6) 16 = string 'ftp' (length=3) 17 = string 'gettext' (length=7) 18 = string 'SPL' (length=3) 19 = string 'iconv' (length=5) 20 = string 'json' (length=4) 21 = string 'mbstring' (length=8) 22 = string 'session' (length=7) 23 = string 'standard' (length=8) 24 = string 'posix' (length=5) 25 = string 'Reflection' (length=10) 26 = string 'Phar' (length=4) 27 = string 'shmop' (length=5) 28 = string 'SimpleXML' (length=9) 29 = string 'soap' (length=4) 30 = string 'sockets' (length=7) 31 = string 'exif' (length=4) 32 = string
[PHP-BUG] Bug #65650 [NEW]: Using proc_open with file handles fails on large buffers
From: romain at neutron dot io
Operating system: Irrelevant
PHP version: 5.4.19
Package: Program Execution
Bug Type: Bug
Bug description:Using proc_open with file handles fails on large buffers
Description:
When using proc_open with file handles instead of pipes (required on
Windows,
because of bug https://bugs.php.net/bug.php?id=51800), when reading large
outputs,
the result might not retrieve what's expected.
The problem has been mentioned when compiling large sass files to stdout on
windows. The output may sometimes be different than the actual output you
can get
running the command in console.
The provided script fails 3 times on 5 on windows environment. Nearly
everytime on
OSX.
Test script:
---
?php
error_reporting(E_ALL);
$cmd = sprintf('php -r %s', escapeshellarg('fwrite(STDOUT, $in =
file_get_contents(\'php://stdin\')); fwrite(STDERR, $in);'));
$stdout = tmpfile();
$stderr = tmpfile();
$descriptors = array(
array('pipe', 'r'),
$stdout,
$stderr,
);
$handles = array(
$stdout, $stderr
);
$datastdin = str_repeat('*!', 8192*128);
$options = array_merge(array('suppress_errors' = true, 'binary_pipes' =
true, 'bypass_shell' = false));
$process = proc_open($cmd, $descriptors, $pipes, getcwd(), array(),
$options);
fwrite($pipes[0], $datastdin);
fclose($pipes[0]);
unset($pipes[0]);
$read = array();
while ($handles) {
$status = proc_get_status($process);
if (!$status['running']) {
proc_close($process);
}
$h = $handles;
foreach ($h as $offset = $handle) {
fseek($handle, isset($read[$offset]) ? strlen($read[$offset]) :
0);
if (!isset($read[$offset])) {
$read[$offset] = '';
}
$read[$offset] .= fread($handle, 8192);
if (false === $status['running'] feof($handle)) {
fclose($handle);
unset($handles[$offset]);
}
}
}
foreach ($read as $r) {
assert($r === $datastdin);
}
Expected result:
No errors, assertion is good.
Actual result:
--
PHP Warning: assert(): Assertion failed in
C:\symfony\src\Symfony\Component\Pro
cess\bug.php on line 47
PHP Warning: assert(): Assertion failed in
C:\symfony\src\Symfony\Component\Pro
cess\bug.php on line 47
--
Edit bug report at https://bugs.php.net/bug.php?id=65650edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65650r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65650r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65650r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65650r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65650r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65650r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65650r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65650r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65650r=support
Expected behavior: https://bugs.php.net/fix.php?id=65650r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65650r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65650r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65650r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65650r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65650r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65650r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65650r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65650r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65650r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65650r=mysqlcfg
Bug #65650 [Opn]: Using proc_open with file handles fails on large buffers
Edit report at https://bugs.php.net/bug.php?id=65650edit=1
ID: 65650
User updated by:imprec at gmail dot com
Reported by:imprec at gmail dot com
Summary:Using proc_open with file handles fails on large
buffers
Status: Open
Type: Bug
Package:Program Execution
Operating System: Irrelevant
PHP Version:5.4.19
Block user comment: N
Private report: N
New Comment:
Update email
Previous Comments:
[2013-09-10 15:04:25] imprec at gmail dot com
Description:
When using proc_open with file handles instead of pipes (required on Windows,
because of bug https://bugs.php.net/bug.php?id=51800), when reading large
outputs,
the result might not retrieve what's expected.
The problem has been mentioned when compiling large sass files to stdout on
windows. The output may sometimes be different than the actual output you can
get
running the command in console.
The provided script fails 3 times on 5 on windows environment. Nearly everytime
on
OSX.
Test script:
---
?php
error_reporting(E_ALL);
$cmd = sprintf('php -r %s', escapeshellarg('fwrite(STDOUT, $in =
file_get_contents(\'php://stdin\')); fwrite(STDERR, $in);'));
$stdout = tmpfile();
$stderr = tmpfile();
$descriptors = array(
array('pipe', 'r'),
$stdout,
$stderr,
);
$handles = array(
$stdout, $stderr
);
$datastdin = str_repeat('*!', 8192*128);
$options = array_merge(array('suppress_errors' = true, 'binary_pipes' = true,
'bypass_shell' = false));
$process = proc_open($cmd, $descriptors, $pipes, getcwd(), array(), $options);
fwrite($pipes[0], $datastdin);
fclose($pipes[0]);
unset($pipes[0]);
$read = array();
while ($handles) {
$status = proc_get_status($process);
if (!$status['running']) {
proc_close($process);
}
$h = $handles;
foreach ($h as $offset = $handle) {
fseek($handle, isset($read[$offset]) ? strlen($read[$offset]) : 0);
if (!isset($read[$offset])) {
$read[$offset] = '';
}
$read[$offset] .= fread($handle, 8192);
if (false === $status['running'] feof($handle)) {
fclose($handle);
unset($handles[$offset]);
}
}
}
foreach ($read as $r) {
assert($r === $datastdin);
}
Expected result:
No errors, assertion is good.
Actual result:
--
PHP Warning: assert(): Assertion failed in C:\symfony\src\Symfony\Component\Pro
cess\bug.php on line 47
PHP Warning: assert(): Assertion failed in C:\symfony\src\Symfony\Component\Pro
cess\bug.php on line 47
--
Edit this bug report at https://bugs.php.net/bug.php?id=65650edit=1
Bug #65642 [Fbk-Csd]: sysconfdir broken in 64-bit Windows build
Edit report at https://bugs.php.net/bug.php?id=65642edit=1
ID: 65642
Updated by: a...@php.net
Reported by:krishean+php at gmail dot com
Summary:sysconfdir broken in 64-bit Windows build
-Status: Feedback
+Status: Closed
Type: Bug
Package:LDAP related
Operating System: Windows 7 x64
PHP Version:5.5.3
Assigned To:ab
Block user comment: N
Private report: N
New Comment:
Thanks for testing. Please use that DLLs with 5.5.3, the regular fix will come
into the next release. In the mean time the fix can be checked in the 5.5 or
master snapshots http://windows.php.net/downloads/snaps/php-5.5/ (check in a
couple of days if interested).
Thanks.
Previous Comments:
[2013-09-10 15:12:27] krishean+php at gmail dot com
I tested both the x86 and x64 builds of the php_ldap (threadsafe) extension and
they both seem to work as intended, checking the
C:\openldap\sysconf\ldap.conf file for configuraton parameters before
successfully connecting to the ldap server over ssl.
[2013-09-10 08:10:40] a...@php.net
Please test the builds from here
http://windows.php.net/downloads/snaps/ostc/65642/ (if possible both x64 and
x86),
they should have correct compiled in path.
[2013-09-09 15:40:37] krishean+php at gmail dot com
Description:
When trying to bind to an ldap server over ssl, you need a file called
ldap.conf in the directory C:\openldap\sysconf with a few options in it (at
least on Windows, Linux is somewhere in /etc.) In the past (php 5.4 etc.) this
worked wonderfully, with php checking that directory, loading the file, and
connecting to the server just fine. In php 5.5.3 however, this is completely
broken. I used Process Monitor to check where it was searching for ldap.conf
and it seems to be searching as such:
G:\Documents\Projects\ProjectName\%SYSCONFDIR%\ldap.conf (the ProjectName
directory being where the currently executing script is located.) I checked and
php 5.4.18 checks in the correct directory: C:\openldap\sysconf\ldap.conf
Test script:
---
$host = 'ldaps://server01';
$port = 636;
$rdn = 'CN=Jeff Smith,CN=users,DC=fabrikam,DC=com';
$pwd = 'password';
if(($conn = @ldap_connect($host, $port)) != FALSE){
ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($conn, LDAP_OPT_REFERRALS, 0);
// bind to ldap connection
if(($r = @ldap_bind($conn, $rdn, $pwd)) != FALSE){
echo(Successfully connected to LDAP.\n);
}else{
echo(Error: Failed to bind to LDAP.\n); // this happens
if($conn){
ldap_unbind($conn);
}
$conn = null;
}
}else echo(Error: Failed to connect to LDAP.\n);
Expected result:
Script should bind to ldap server over ssl (ldaps://) and report success.
Actual result:
--
Script fails to bind to ldap server over ssl.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65642edit=1
Bug #65634 [Nab]: HTTP wrapper is very slow with protocol_version 1.1
Edit report at https://bugs.php.net/bug.php?id=65634edit=1
ID: 65634
User updated by:butesa at freenet dot de
Reported by:butesa at freenet dot de
Summary:HTTP wrapper is very slow with protocol_version 1.1
Status: Not a bug
Type: Bug
Package:HTTP related
Operating System: Ubuntu 12.04 x64
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
I looked into RFC 2616 today. It says:
HTTP/1.1 applications that do not support persistent connections MUST include
the close connection option in every message.
Obviously, the HTTP wrapper can't handle persistent connections correctly. So
it should automatically add a Connection: close header when protocol_version is
set to 1.1.
Previous Comments:
[2013-09-09 23:52:31] butesa at freenet dot de
I don't see how it can be not a bug if a http request takes 100 seconds.
If the server uses connection: keep-alive, then the client has to close the
connection if it doesn't want to make any further requests.
[2013-09-09 23:03:47] ahar...@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
www.google.de responds with a keep-alive connection when a HTTP/1.1 request is
made and no Connection request header is included, which is valid in RFC 2616.
Sending a Connection: close request header restores the 1.0 behaviour.
[2013-09-08 16:27:47] butesa at freenet dot de
Description:
Loading a website with the http wrapper takes very long if protocol_version is
set to 1.1. The time it takes depends on the timeout. On some servers the
problem doesn't occur.
I tested also on Ubuntu 10.04 (PHP 5.3.2-1ubuntu4.19) and Ubuntu 12.04 (PHP
5.3.10-1ubuntu3.7), both 64bit.
Test script:
---
?php
$url = 'http://www.google.de/intl/de/policies/?fg=1';
foreach(array(1.0,1.1) as $proto)
{
for ($timeout = 1; $timeout 60; $timeout+=10)
{
$st = microtime(true);
$opt = array(
'http' = array(
'timeout' = $timeout,
'protocol_version' = $proto,
),
);
$context = stream_context_create($opt);
$content = file_get_contents($url,false,$context);
printf(%2d %.1f %f %s\n, $timeout, $proto, microtime(true) -
$st, md5($content));
}
}
?
Expected result:
The request takes the same time, no matter what timeout and protocol_version is
set.
Actual result:
--
Output of the test script:
For $url='http://www.google.de/intl/de/policies/?fg=1':
1 1.0 0.279102 60bf7bc72d2a06b337c8a8464e0f9e66
11 1.0 0.277956 60bf7bc72d2a06b337c8a8464e0f9e66
21 1.0 0.283753 60bf7bc72d2a06b337c8a8464e0f9e66
31 1.0 0.285862 60bf7bc72d2a06b337c8a8464e0f9e66
41 1.0 0.277894 60bf7bc72d2a06b337c8a8464e0f9e66
51 1.0 0.285653 60bf7bc72d2a06b337c8a8464e0f9e66
1 1.1 2.284301 60bf7bc72d2a06b337c8a8464e0f9e66
11 1.1 22.305424 60bf7bc72d2a06b337c8a8464e0f9e66
21 1.1 42.309270 60bf7bc72d2a06b337c8a8464e0f9e66
31 1.1 62.355997 60bf7bc72d2a06b337c8a8464e0f9e66
41 1.1 82.360794 60bf7bc72d2a06b337c8a8464e0f9e66
51 1.1 102.379933 60bf7bc72d2a06b337c8a8464e0f9e66
For $url='http://www.example.com':
1 1.0 0.491382 09b9c392dc1f6e914cea287cb6be34b0
11 1.0 0.426191 09b9c392dc1f6e914cea287cb6be34b0
21 1.0 0.428513 09b9c392dc1f6e914cea287cb6be34b0
31 1.0 0.423852 09b9c392dc1f6e914cea287cb6be34b0
41 1.0 0.423751 09b9c392dc1f6e914cea287cb6be34b0
51 1.0 0.431590 09b9c392dc1f6e914cea287cb6be34b0
1 1.1 1.420486 09b9c392dc1f6e914cea287cb6be34b0
11 1.1 6.143113 09b9c392dc1f6e914cea287cb6be34b0
21 1.1 5.994384 09b9c392dc1f6e914cea287cb6be34b0
31 1.1 5.991940 09b9c392dc1f6e914cea287cb6be34b0
41 1.1 6.012121 09b9c392dc1f6e914cea287cb6be34b0
51 1.1 6.007920 09b9c392dc1f6e914cea287cb6be34b0
For $url='http://www.php.net':
1 1.0 1.673016 2dcc6fe85b335205a35d9980a9095735
11 1.0 1.93 2dcc6fe85b335205a35d9980a9095735
21 1.0 1.648235 2dcc6fe85b335205a35d9980a9095735
31 1.0 1.637566 2dcc6fe85b335205a35d9980a9095735
41 1.0 1.633473 2dcc6fe85b335205a35d9980a9095735
51 1.0 1.718051 2dcc6fe85b335205a35d9980a9095735
1 1.1 1.647803 2dcc6fe85b335205a35d9980a9095735
11 1.1 1.863799 2dcc6fe85b335205a35d9980a9095735
21 1.1 1.673567 2dcc6fe85b335205a35d9980a9095735
31 1.1 1.651704 2dcc6fe85b335205a35d9980a9095735
41 1.1 1.657976 2dcc6fe85b335205a35d9980a9095735
51 1.1 1.635651 2dcc6fe85b335205a35d9980a9095735
Req #65646 [Asn-Csd]: re-enable CURLOPT_FOLLOWLOCATION with open_basedir or safe_mode
Edit report at https://bugs.php.net/bug.php?id=65646edit=1 ID: 65646 Updated by: ahar...@php.net Reported by:butesa at freenet dot de Summary:re-enable CURLOPT_FOLLOWLOCATION with open_basedir or safe_mode -Status: Assigned +Status: Closed Type: Feature/Change Request Package:cURL related Operating System: any PHP Version:5.5.3 Assigned To:aharvey Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Implemented on master: https://github.com/php/php-src/commit/fba290c061027c24e4c8effdba37addd3430c3d4 Previous Comments: [2013-09-10 07:08:39] sudanisayfree at gmail dot com I use Nimbuzz! Developers Program in there website : ( http://developer.nimbuzz.com/page.php?page=manual ) To make the program work by downloading this folder : http://developer.nimbuzz.com/tools/docs/hello-world.rar there you should Extract this codebase and add the folder 'hello-world' in the document root of your server. So if your hosting is www.myhosting.com, try opening http://www.myhosting.com/hello- world/api.php, you should see the page return an xml response. This is the Callback URL for your chat buddy. Please provide us with this callback URL on developers.nimbuzz.com or mail us at developers.nimbuzz.com then you must Make config changes. Replace 'test123' with TESTJID provided by us in file configuration.php. Add your chat buddy to your roster using TESTJID provided by us. Use 'bot TESTJID' to add chat buddy to your roster on PC/MAC client. [2013-09-10 06:26:40] ahar...@php.net I have an implementation of this on a branch in my GitHub fork, but don't have time to finish testing it tonight. I'll try to get back to it later in the week. [2013-09-09 21:27:10] butesa at freenet dot de Description: CURLOPT_FOLLOWLOCATION is disabled when open_basedir is set or when safe_mode is on. Since 7.19.4, curl won't follow a location-header that uses the file-protocol. So using CURLOPT_FOLLOWLOCATION in combination with open_basedir or safe_mode should be fine. (Since 7.19.4, libcurl can limit what protocols it will automatically follow. The accepted protocols are set with CURLOPT_REDIR_PROTOCOLS and it excludes the FILE protocol by default. http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTFOLLOWLOCATION ) -- Edit this bug report at https://bugs.php.net/bug.php?id=65646edit=1
