[PHP-BUG] Bug #64016 [NEW]: file_get_contents does not fill up $http_response_header via HEAD method
From: anil at saog dot net
Operating system: Centos 6.2
PHP version: 5.4.11
Package: *URL Functions
Bug Type: Bug
Bug description:file_get_contents does not fill up $http_response_header via
HEAD method
Description:
PHP is compiled with option --with-curlwrappers. Whenever a HEAD request
issued with file_get_contents, $http_response_header is not filled-up
but upon calling get_headers(), variable $http_response_header
auto-magically filled up.
Test script:
---
$url = 'http://www.google.com';
$ctx = stream_context_create();
stream_context_set_option($ctx, array('http' = array('method' =
'HEAD','timeout' = 60)));
$res = file_get_contents($url, false, $ctx);
var_dump($http_response_header); // NULL
get_headers($url);
var_dump($http_response_header); // filled up correctly
Expected result:
$http_response_header filled-up correctly
Actual result:
--
$http_response_header is always NULL
--
Edit bug report at https://bugs.php.net/bug.php?id=64016edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64016r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64016r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64016r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64016r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64016r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64016r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64016r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64016r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64016r=support
Expected behavior: https://bugs.php.net/fix.php?id=64016r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64016r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64016r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64016r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64016r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64016r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64016r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64016r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64016r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64016r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64016r=mysqlcfg
Req #54243 [Opn]: Shorter syntax for closures
Edit report at https://bugs.php.net/bug.php?id=54243edit=1
ID: 54243
User updated by:anil at saog dot net
Reported by:anil at saog dot net
Summary:Shorter syntax for closures
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Guys, please calm down. I have no idea why you write these comments in a heat
but this issue is just a wishing. Also, readability is a non-objective property
which generally differs person to person, but the key is shorter means
readable. By the way, did you ever inspect c# - linq syntax?
C# : ...Where((a,b) = a == b)
PHP : ...Where(function($a, $b){ return $a == $b; })
MY : ...Where($($a, $b, {$a == $b}))
readability? yes of course readability... so you think you are better than
microsoft on readability?
If you do not agree of course it is okay just tell it (like a human) otherwise
keep your ignoble and invaluable ideas to yourself.
Previous Comments:
[2012-03-19 11:13:20] ninzya at inbox dot lv
I think the proposed syntax is not readable at all. Rather it looks like you
have
been affected by a wannabe jQuery inventor. How do you come up with a dollar
sign being readable? How do you define readable code? If you read your
code,
you read it as dollar, dollar, bracket, dollar, dollar... whatever, dollar.
Is
this what you call readability?
However I do agree that the use() clause of closures sometimes bloats the
code a
little bit, especially if the closure is importing a lot of variables from its
context.
[2012-03-19 09:08:09] danko at very dot lv
Um, no, *that* is unreadable. The original syntax can easily be made readable
if you do care:
$myObject-MyMethod(
'abc',
function ($a) use ($b) {
return $a == $b;
}
);
There you go. As readable as it gets - just add some newlines and tabs. On the
other hand, a soup of brackets and dollar signs can't be readable regardless of
formatting.
[2011-03-13 16:16:45] anil at saog dot net
Changed package
[2011-03-13 16:09:36] anil at saog dot net
Description:
Current closure syntax makes the code a little bit unreadable and also
shortening the syntax of a handy thing like this seems more logical.
Test script:
---
As of now closure syntax is:
function ($a) use($b){ return $a == $b; }
Passing a closure to any other scope:
$myObject = new myObject ();
$myObject-MyMethod('abc', function ($a) use($b){ return $a == $b; });
Expected result:
My short syntax candidate is:
$([arg1],[arg2],[arg...], {[method body]},
[scope_var1],[scope_var2],[scope_var...])
So passing with use token syntax:
$myObject = new myObject ();
$myObject-MyMethod('abc', $($a, {$a == $b}, $b));
Without use token:
$myObject = new myObject ();
$myObject-MyMethod('abc', $($a, {$a == $b}));
With more than one method argument:
$myObject = new myObject ();
$myObject-MyMethod('abc', $($a,$k,$p,{$a == $b}));
--
Edit this bug report at https://bugs.php.net/bug.php?id=54243edit=1
[PHP-BUG] Bug #61328 [NEW]: segmentation fault while traversing big arrays with foreach
From:
Operating system: linux
PHP version: 5.4.0
Package: *General Issues
Bug Type: Bug
Bug description:segmentation fault while traversing big arrays with foreach
Description:
There happens a segmentation fault while traversing big arrays with
foreach.
A sample backtrace:
/opt/uwsgi/uwsgi(uwsgi_backtrace+0x2a) [0x807981a]
/opt/uwsgi/uwsgi(uwsgi_segfault+0x2c) [0x807990c]
/lib/libc.so.6 [0xb7b02e28]
/opt/php54/lib/libphp5.so(zend_object_std_dtor+0x88) [0xb6509948]
/opt/php54/lib/libphp5.so(zend_objects_free_object_storage+0x12)
[0xb6509982]
/opt/php54/lib/libphp5.so(zend_objects_store_free_object_storage+0x78)
[0xb650ed28]
/opt/php54/lib/libphp5.so [0xb64e021c]
/opt/php54/lib/libphp5.so [0xb64eb623]
/opt/php54/lib/libphp5.so(php_request_shutdown+0x172) [0xb648fe52]
./php_plugin.so(uwsgi_php_request+0x1e0) [0xb7fb8e90]
Seg-faulted code (probably with 100.000 items or more):
foreach ($options as $item) {
if ($item['value'] == $value) {
return $item['label'];
}
}
Expected result:
no segmentation fault
Actual result:
--
segmentation fault
--
Edit bug report at https://bugs.php.net/bug.php?id=61328edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61328r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61328r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61328r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61328r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61328r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61328r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61328r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61328r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61328r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61328r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61328r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61328r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61328r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61328r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61328r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61328r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61328r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61328r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61328r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61328r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61328r=mysqlcfg
[PHP-BUG] Req #54243 [NEW]: Shorter syntax for closures
From:
Operating system:
PHP version: Irrelevant
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Shorter syntax for closures
Description:
Current closure syntax makes the code a little bit unreadable and also
shortening the syntax of a handy thing like this seems more logical.
Test script:
---
As of now closure syntax is:
function ($a) use($b){ return $a == $b; }
Passing a closure to any other scope:
$myObject = new myObject ();
$myObject-MyMethod('abc', function ($a) use($b){ return $a == $b; });
Expected result:
My short syntax candidate is:
$([arg1],[arg2],[arg...], {[method body]},
[scope_var1],[scope_var2],[scope_var...])
So passing with use token syntax:
$myObject = new myObject ();
$myObject-MyMethod('abc', $($a, {$a == $b}, $b));
Without use token:
$myObject = new myObject ();
$myObject-MyMethod('abc', $($a, {$a == $b}));
With more than one method argument:
$myObject = new myObject ();
$myObject-MyMethod('abc', $($a,$k,$p,{$a == $b}));
--
Edit bug report at http://bugs.php.net/bug.php?id=54243edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54243r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54243r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54243r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54243r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54243r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54243r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54243r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54243r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54243r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54243r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54243r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54243r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54243r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54243r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54243r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54243r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54243r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54243r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54243r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54243r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54243r=mysqlcfg
Req #54243 [Opn]: Shorter syntax for closures
Edit report at http://bugs.php.net/bug.php?id=54243edit=1
ID: 54243
User updated by:anil at saog dot net
Reported by:anil at saog dot net
Summary:Shorter syntax for closures
Status: Open
Type: Feature/Change Request
-Package:Scripting Engine problem
+Package:*General Issues
-Operating System:
+Operating System: *
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Changed package
Previous Comments:
[2011-03-13 16:09:36] anil at saog dot net
Description:
Current closure syntax makes the code a little bit unreadable and also
shortening the syntax of a handy thing like this seems more logical.
Test script:
---
As of now closure syntax is:
function ($a) use($b){ return $a == $b; }
Passing a closure to any other scope:
$myObject = new myObject ();
$myObject-MyMethod('abc', function ($a) use($b){ return $a == $b; });
Expected result:
My short syntax candidate is:
$([arg1],[arg2],[arg...], {[method body]},
[scope_var1],[scope_var2],[scope_var...])
So passing with use token syntax:
$myObject = new myObject ();
$myObject-MyMethod('abc', $($a, {$a == $b}, $b));
Without use token:
$myObject = new myObject ();
$myObject-MyMethod('abc', $($a, {$a == $b}));
With more than one method argument:
$myObject = new myObject ();
$myObject-MyMethod('abc', $($a,$k,$p,{$a == $b}));
--
Edit this bug report at http://bugs.php.net/bug.php?id=54243edit=1
#47468 [Com]: enable readline for embed sapi
ID: 47468 Comment by: anil at saog dot net Reported By: admin at mateuszjanowski dot pl Status: Open Bug Type: Feature/Change Request Operating System: Ubuntu 8.10 Linux PHP Version: 5.2.8/5.2.9RC2 New Comment: Thank you very much, it works now. Before your solution I tried to change ext/pcntl/config.m4, a line in this file contains cli as a function variable; --- PHP_NEW_EXTENSION(pcntl, pcntl.c php_signal.c, $ext_shared, cli) +++ PHP_NEW_EXTENSION(pcntl, pcntl.c php_signal.c, $ext_shared) but i didnt try it, this may also help. Previous Comments: [2009-04-25 12:40:22] paul dot biggar at gmail dot com I believe this also applies to ncurses, pcntl, and libedit. Here is a patch to fix it: --- aclocal.m4.orig 2009-04-25 13:11:57.0 +0100 +++ aclocal.m4 2009-04-25 13:24:50.0 +0100 @@ -962,7 +962,7 @@ if test $3 != shared test $3 != yes test $4 = cli; then dnl -- CLI static module [PHP_]translit($1,a-z_-,A-Z__)[_SHARED]=no -if test $PHP_SAPI = cgi; then +if test $PHP_SAPI = cgi || test $PHP_SAPI = embed; then PHP_ADD_SOURCES(PHP_EXT_DIR($1),$2,$ac_extra,) EXT_STATIC=$EXT_STATIC $1 else I tested it by building PHP 5.2.6, 5.2.9 and php5.3-200902131730, building with ./configure --enable-embed --with-readline --enable-pcntl --with-ncurses and running nm .libs/libphp5.so | grep readline (and similarly for pcntl and ncurses) which verifies that the readline symbols are available. I also ran the test script from Mateusz through phc, and observed that calls to readline now succeeded. Can the patch be considered for 5.2.10, 5.3 and HEAD? [2009-02-23 19:41:07] admin at mateuszjanowski dot pl I'm sad that you have changed category name to Change Request. I think, that will make it very low priority ? [2009-02-23 16:44:52] j...@php.net This is not a bug but feature/change request, emphasis on change. [2009-02-23 16:12:09] admin at mateuszjanowski dot pl Category and Version updated. [2009-02-23 14:16:38] paul dot biggar at gmail dot com Here is the context: http://www.phpcompiler.org/lists/phc-general/2009-February/000907.html I would mark this as a bug, not a feature request. The readline functions are not available in the embed SAPI. However, there is no reason that it should be impossible for an embed user to have access to readline. 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/47468 -- Edit this bug report at http://bugs.php.net/?id=47468edit=1
#33252 [NEW]: failed to open stream: FTP server reports 220
From: anil at saog dot net Operating system: linux FC2 PHP version: 4.3.10 PHP Bug Type: Sockets related Bug description: failed to open stream: FTP server reports 220 Description: using fopen function for ftp connections on default port (21) without declaring port in function, brings an strange error; Reproduce code: --- $handle = fopen(ftp://[EMAIL PROTECTED]/bug.txt, r); $oldContent = fread($handle,500); fclose($handle1); Expected result: as you see port is default (21) and not declared in function, this code gives error; failed to open stream: FTP server reports 220 as you know 220 means connection accepted, and it is not an error. But if you change the remote port (for example 2122) and/or declare it in function, there will be no problem; $handle = fopen(ftp://[EMAIL PROTECTED]:2122/bug.txt, r); or if you can't change the remote port; $handle = fopen(ftp://[EMAIL PROTECTED]:21/bug.txt, r); -- Edit bug report at http://bugs.php.net/?id=33252edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33252r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33252r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33252r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33252r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33252r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33252r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33252r=needscript Try newer version: http://bugs.php.net/fix.php?id=33252r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33252r=support Expected behavior: http://bugs.php.net/fix.php?id=33252r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33252r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33252r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33252r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33252r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33252r=dst IIS Stability: http://bugs.php.net/fix.php?id=33252r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33252r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33252r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33252r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33252r=mysqlcfg
