[PHP-BUG] Bug #60668 [NEW]: Setting user_agent can send other headers
From: vrana Operating system: Irrelevant PHP version: 5.4.0RC5 Package: HTTP related Bug Type: Bug Bug description:Setting user_agent can send other headers Description: Setting 'user_agent' INI value to a string containing a newline causes sending a new header. This behavior is even documented: http://php.net/wrappers.http#wrappers.http.example.custom.headers It is wrong for two reasons: 1. 'user_agent' INI setting should be used only for setting a User-Agent header and not for anything else. 2. It is a potential security risk (header injection) similar to the one fixed in PHP 5.1.2 (but with low impact). (See also bug #52979 but I believe that I am providing a better reasoning.) Test script: --- http://private/service.php'); ?> Expected result: Sending just a User-Agent header, not X-Command header. Actual result: -- Sending User-Agent and X-Command headers. If http://private/service.php accepts connections only from trusted sources and parses its commands from headers then it will execute the malicious action. -- Edit bug report at https://bugs.php.net/bug.php?id=60668&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60668&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60668&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60668&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60668&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60668&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60668&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60668&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60668&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60668&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60668&r=support Expected behavior: https://bugs.php.net/fix.php?id=60668&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60668&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60668&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60668&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60668&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60668&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60668&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60668&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60668&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60668&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60668&r=mysqlcfg
[PHP-BUG] Bug #60670 [NEW]: When under load, PHP-FPM master process silently crashes
From: Operating system: Debian Lenny PHP version: 5.3.8 Package: FPM related Bug Type: Bug Bug description:When under load, PHP-FPM master process silently crashes Description: I ran some load tests on a virtual machine which has 16GB ram and four 8Ghz VCores. The tests were run using JMeter. When ~300 simultaneous connections (10 request loop per connection) to FPM exist (through NGinx), The master process crashes and I get 502 errors. The remaining child processes continue executing their scripts then terminate. I use a static pool configuration, and no matter what the child processes number is, it crashes. -- Edit bug report at https://bugs.php.net/bug.php?id=60670&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60670&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60670&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60670&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60670&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60670&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60670&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60670&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60670&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60670&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60670&r=support Expected behavior: https://bugs.php.net/fix.php?id=60670&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60670&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60670&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60670&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60670&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60670&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60670&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60670&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60670&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60670&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60670&r=mysqlcfg
Bug #60670 [Opn->Fbk]: When under load, PHP-FPM master process silently crashes
Edit report at https://bugs.php.net/bug.php?id=60670&edit=1 ID: 60670 Updated by: f...@php.net Reported by:gwenmael dot rouxel at neovote dot com Summary:When under load, PHP-FPM master process silently crashes -Status: Open +Status: Feedback Type: Bug Package:FPM related Operating System: Debian Lenny PHP Version:5.3.8 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. Previous Comments: [2012-01-06 13:35:41] gwenmael dot rouxel at neovote dot com Description: I ran some load tests on a virtual machine which has 16GB ram and four 8Ghz VCores. The tests were run using JMeter. When ~300 simultaneous connections (10 request loop per connection) to FPM exist (through NGinx), The master process crashes and I get 502 errors. The remaining child processes continue executing their scripts then terminate. I use a static pool configuration, and no matter what the child processes number is, it crashes. -- Edit this bug report at https://bugs.php.net/bug.php?id=60670&edit=1
Bug #60598 [Com]: cli/apache sapi segfault on objects manipulation
Edit report at https://bugs.php.net/bug.php?id=60598&edit=1
ID: 60598
Comment by: daan at react dot com
Reported by:arekm at maven dot pl
Summary:cli/apache sapi segfault on objects manipulation
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.4.0RC3
Block user comment: N
Private report: N
New Comment:
Looks alot like https://bugs.php.net/bug.php?id=39346
Curiously, the segfault looks alot like https://bugs.php.net/bug.php?id=60457 -
but that might just be PHPs reaction to memory corruption.
Previous Comments:
[2011-12-22 22:33:07] arekm at maven dot pl
Description:
[arekm@ixion-pld php-5.4.0RC3]$ export LC_ALL=C
[arekm@ixion-pld php-5.4.0RC3]$ ./sapi/cli/php -n ~/a.php
If you see this, try to increase OBJECT_COUNT to 100,000Segmentation fault
[arekm@ixion-pld php-5.4.0RC3]$ ./sapi/cli/php -n --version
PHP 5.4.0RC3 (cli) (built: Dec 22 2011 23:19:37)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies
Test script:
---
_guid = self::$maxGuid++] = $this;
}
public function __destruct() {
unset(self::$world[$this->_guid]);
}
}
for ($i = 0; $i < OBJECT_COUNT; ++$i) {
new Object();
}
// You probably won't see this because of the "zend_mm_heap corrupted"
echo 'If you see this, try to increase OBJECT_COUNT to 100,000';
?>
Expected result:
cli not segfaulting
Actual result:
--
Starting program: /home/users/arekm/rpm/BUILD/php-5.4.0RC3/sapi/cli/.libs/php
-n
/home/users/arekm/a.php
[Thread debugging using libthread_db enabled]
If you see this, try to increase OBJECT_COUNT to 100,000
Program received signal SIGSEGV, Segmentation fault.
0x77a462b9 in gc_zval_possible_root (zv=0x75677420) at
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0 0x77a462b9 in gc_zval_possible_root (zv=0x75677420) at
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_gc.c:143
#1 0x77a48ba2 in zend_object_std_dtor (object=0x756773d0) at
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_objects.c:54
#2 0x77a48bd9 in zend_objects_free_object_storage
(object=0x756773d0) at /home/users/arekm/rpm/BUILD/php-
5.4.0RC3/Zend/zend_objects.c:137
#3 0x77a4e56f in zend_objects_store_free_object_storage
(objects=0x77dda700)
at /home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_objects_API.c:92
#4 0x77a18c83 in shutdown_executor () at
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_execute_API.c:297
#5 0x77a27555 in zend_deactivate () at /home/users/arekm/rpm/BUILD/php-
5.4.0RC3/Zend/zend.c:934
#6 0x779c820f in php_request_shutdown (dummy=) at
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/main/main.c:1781
#7 0x00405538 in do_cli (argc=3, argv=0x7fffea38) at
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/sapi/cli/php_cli.c:1169
#8 0x00404d4c in main (argc=3, argv=0x7fffea38) at
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/sapi/cli/php_cli.c:1356
(gdb) frame 0
#0 0x77a462b9 in gc_zval_possible_root (zv=0x75677420) at
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) print zv
$1 = (zval *) 0x75677420
(gdb) print *zv
$2 = {
value = {
lval = 140737303870936,
dval = 6.9533466930949762e-310,
str = {
val = 0x7500fdd8 "\270",
len = -184485184
},
ht = 0x7500fdd8,
obj = {
handle = 4110482904,
handlers = 0x7500fac0
}
},
refcount__gc = 4294967295,
type = 5 '\005',
is_ref__gc = 0 '\000'
}
(gdb)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60598&edit=1
[PHP-BUG] Bug #60671 [NEW]: fread does not fail when operating on a write only stream
From: Operating system: Ubuntu 11.04 PHP version: 5.3.8 Package: Streams related Bug Type: Bug Bug description:fread does not fail when operating on a write only stream Description: fread does not throw or generate any error when attempting to read from a write only file stream. Test script: --- Expected result: Either feof to return false indicating end of file Or fread erroring or returning false as a result of attempting to read a write-only stream. Actual result: -- An infinite loop will occur. feof will never end (doesn't reach the end of the file because it's in write mode) fread will never error despite attempting to read from a write only stream. -- Edit bug report at https://bugs.php.net/bug.php?id=60671&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60671&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60671&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60671&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60671&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60671&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60671&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60671&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60671&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60671&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60671&r=support Expected behavior: https://bugs.php.net/fix.php?id=60671&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60671&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60671&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60671&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60671&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60671&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60671&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60671&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60671&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60671&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60671&r=mysqlcfg
Bug #60671 [Com]: fread does not fail when operating on a write only stream
Edit report at https://bugs.php.net/bug.php?id=60671&edit=1
ID: 60671
Comment by: phpmpan at mpan dot pl
Reported by:james dot turner dot phpninja at gmail dot com
Summary:fread does not fail when operating on a write only
stream
Status: Open
Type: Bug
Package:Streams related
Operating System: Ubuntu 11.04
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
CONFIRMED for both 5.3.8 and 5.3.7 on Arch64, and for 5.3.4 on an unknown Linux.
Note however, that the test script provided by OP is wrong. It should be:
BEGIN CODE
$tmp = tempnam(sys_get_temp_dir(), 'test_');
$stream = fopen($tmp, 'w');
$data = "";
while(!feof($stream)){
if(false === ($data = fread($stream, 8192))){
break; // ^ no dot here
};
}
- END CODE -
OP's code will fail regardless of the bug, because .= always produces a string.
Previous Comments:
[2012-01-06 14:29:43] james dot turner dot phpninja at gmail dot com
Description:
fread does not throw or generate any error when attempting to read from a write
only file stream.
Test script:
---
Expected result:
Either feof to return false indicating end of file
Or fread erroring or returning false as a result of attempting to read a
write-only stream.
Actual result:
--
An infinite loop will occur.
feof will never end (doesn't reach the end of the file because it's in write
mode)
fread will never error despite attempting to read from a write only stream.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60671&edit=1
[PHP-BUG] Bug #60672 [NEW]: ELSEIF/ELSE IF doesn't work
From:
Operating system: Windows XP
PHP version: Irrelevant
Package: Variables related
Bug Type: Bug
Bug description:ELSEIF/ELSE IF doesn't work
Description:
$x = 0;
$y = "some_string";
if( $x == 2 ) {
echo "X = 2.";
echo "Inner first IF";
} elseif ( $x == $y ) {
echo "We are at the elseif condition.";
} else {
echo "I don't know what's X value.";
}
Test script:
---
1st - That's my first time using bug report on php.net.
2nd - I'm brazilia(sorry my english).
3rd - I don't know I'm using the correct channel to report this.
I used WAMPServer2.1 to discover this bug.
The current PHP version used on used WAMPServer2.1 is 5.3.5.
This prints "We are at the elseif condition.".
The same happens if the $y value is false.
Expected result:
Expected result would be: "I don't know what's X value.".
Actual result:
--
Actual result would be: "I don't know what's X value.".
--
Edit bug report at https://bugs.php.net/bug.php?id=60672&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60672&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60672&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60672&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60672&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60672&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60672&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60672&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60672&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60672&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60672&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60672&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60672&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60672&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60672&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60672&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60672&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60672&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60672&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60672&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60672&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60672&r=mysqlcfg
Bug #60672 [Opn]: ELSEIF/ELSE IF doesn't work
Edit report at https://bugs.php.net/bug.php?id=60672&edit=1
ID: 60672
User updated by:danillo dot paiva dot toledo at gmail dot com
Reported by:danillo dot paiva dot toledo at gmail dot com
Summary:ELSEIF/ELSE IF doesn't work
Status: Open
Type: Bug
Package:Variables related
Operating System: Windows XP
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
$x = 0;
$y = "some_string";
if( $x == 2 ) {
echo "X = 2.";
echo "Inner first IF";
} elseif ( $x == $y ) {
echo "We are at the elseif condition.";
} else {
echo "I don't know what's X value.";
}
1st - That's my first time using bug report on php.net.
2nd - I'm brazilia(sorry my english).
3rd - I don't know I'm using the correct channel to report this.
I used WAMPServer2.1 to discover this bug.
The current PHP version used on used WAMPServer2.1 is 5.3.5.
This prints "We are at the elseif condition.".
The same happens if the $y value is false.
Previous Comments:
[2012-01-06 16:11:19] danillo dot paiva dot toledo at gmail dot com
Description:
$x = 0;
$y = "some_string";
if( $x == 2 ) {
echo "X = 2.";
echo "Inner first IF";
} elseif ( $x == $y ) {
echo "We are at the elseif condition.";
} else {
echo "I don't know what's X value.";
}
Test script:
---
1st - That's my first time using bug report on php.net.
2nd - I'm brazilia(sorry my english).
3rd - I don't know I'm using the correct channel to report this.
I used WAMPServer2.1 to discover this bug.
The current PHP version used on used WAMPServer2.1 is 5.3.5.
This prints "We are at the elseif condition.".
The same happens if the $y value is false.
Expected result:
Expected result would be: "I don't know what's X value.".
Actual result:
--
Actual result would be: "I don't know what's X value.".
--
Edit this bug report at https://bugs.php.net/bug.php?id=60672&edit=1
Bug #60660 [Opn->Bgs]: curl_errno returns 0 instead of 6
Edit report at https://bugs.php.net/bug.php?id=60660&edit=1
ID: 60660
Updated by: pierr...@php.net
Reported by:bart at ajaxer dot net
Summary:curl_errno returns 0 instead of 6
-Status: Open
+Status: Bogus
Type: Bug
Package:cURL related
Operating System: Win XP
PHP Version:5.3.8
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
If you're using curl_multi_exec you need to use curl_multi_info_read to get the
curl error code
Previous Comments:
[2012-01-04 21:16:13] bart at ajaxer dot net
Description:
This issue concerns only multi curl.
Single handle curl works correct and returns error no. 6 when host is not
resolved.
In the same situation multi curl returns 0 with curl_errno function despite the
fact that curl_error returns error message.
See codes of 2 examples below
Test script:
---
http://osms.pl');
// Execute
curl_exec($ch);
// Check if any error occured
if(curl_errno($ch))
{
echo 'Curl error: ' . curl_error($ch) . ' - ' .curl_errno($ch);
}
// Close handle
curl_close($ch);
?>
---
http://404.php.net/";);
//create the multiple cURL handle
$mh = curl_multi_init();
curl_multi_add_handle($mh,$ch1);
$active = null;
//execute the handles
do {
$mrc = curl_multi_exec($mh, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
while ($active && $mrc == CURLM_OK) {
if (curl_multi_select($mh) != -1) {
do {
$mrc = curl_multi_exec($mh, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
}
}
echo 'Curl error: ' . curl_error($ch1) . ' - ' .curl_errno($ch1);
//close the handles
curl_multi_remove_handle($mh, $ch1);
curl_multi_close($mh);
?>
Expected result:
in first example:
Curl error: Could not resolve host: osms.pl; Host not found - 6
in second:
Curl error: Could not resolve host: (nil); Host not found - 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=60660&edit=1
Bug #60672 [Com]: ELSEIF/ELSE IF doesn't work
Edit report at https://bugs.php.net/bug.php?id=60672&edit=1
ID: 60672
Comment by: anon at anon dot anon
Reported by:danillo dot paiva dot toledo at gmail dot com
Summary:ELSEIF/ELSE IF doesn't work
Status: Open
Type: Bug
Package:Variables related
Operating System: Windows XP
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
This occurs because 0 == "some_string" is true, and 0 == false is true. See:
http://php.net/manual/en/types.comparisons.php
Use === instead of == (and !== instead of !=) to stop type conversion in
comparisons.
Previous Comments:
[2012-01-06 16:14:32] danillo dot paiva dot toledo at gmail dot com
$x = 0;
$y = "some_string";
if( $x == 2 ) {
echo "X = 2.";
echo "Inner first IF";
} elseif ( $x == $y ) {
echo "We are at the elseif condition.";
} else {
echo "I don't know what's X value.";
}
1st - That's my first time using bug report on php.net.
2nd - I'm brazilia(sorry my english).
3rd - I don't know I'm using the correct channel to report this.
I used WAMPServer2.1 to discover this bug.
The current PHP version used on used WAMPServer2.1 is 5.3.5.
This prints "We are at the elseif condition.".
The same happens if the $y value is false.
[2012-01-06 16:11:19] danillo dot paiva dot toledo at gmail dot com
Description:
$x = 0;
$y = "some_string";
if( $x == 2 ) {
echo "X = 2.";
echo "Inner first IF";
} elseif ( $x == $y ) {
echo "We are at the elseif condition.";
} else {
echo "I don't know what's X value.";
}
Test script:
---
1st - That's my first time using bug report on php.net.
2nd - I'm brazilia(sorry my english).
3rd - I don't know I'm using the correct channel to report this.
I used WAMPServer2.1 to discover this bug.
The current PHP version used on used WAMPServer2.1 is 5.3.5.
This prints "We are at the elseif condition.".
The same happens if the $y value is false.
Expected result:
Expected result would be: "I don't know what's X value.".
Actual result:
--
Actual result would be: "I don't know what's X value.".
--
Edit this bug report at https://bugs.php.net/bug.php?id=60672&edit=1
Req #29005 [Opn->Csd]: fopen() can't open NT named pipes on local computer
Edit report at https://bugs.php.net/bug.php?id=29005&edit=1
ID: 29005
Updated by: the...@php.net
Reported by:cleong at nflc dot org
Summary:fopen() can't open NT named pipes on local computer
-Status: Open
+Status: Closed
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: Windows 2000
PHP Version:4.3.6
-Assigned To:
+Assigned To:thekid
Block user comment: N
Private report: N
New Comment:
This has been fixed in PHP 5.3 in the meantime:
$ F:\Programme\php-5.3.0-Win32\php.exe -r 'var_dump(fopen(".\\pipe\\mysql",
"r+"));'
resource(5) of type (stream)
Previous Comments:
[2010-01-13 14:08:48] bob at peret dot net
I got around this by replacing the "." with my local address
".\\pipe\\pipename"
"127.0.0.1\\pipe\\pipename"
[2004-07-06 16:47:11] cleong at nflc dot org
But it's just a matter of not corrupting the filepath. This is a bug in a way,
as, for the same reason, the function cannot handle "\\.\C:\filename.ext",
which is a valid Win32 path.
[2004-07-06 16:32:20] poll...@php.net
Indeed, Wez and I both have our eyes on named pipe support. With luck it'll
show up in 5.1, in any case it should be a simple backport to make it available
to 5.0 via a PECL extension.
[2004-07-05 09:49:10] der...@php.net
Let's make this a feature request as it's currently not meant to work.
[2004-07-04 00:06:58] cleong at nflc dot org
Description:
fopen() can't handle path names like "\\.\pipe\pipename" because the internal
function virtual_file_ex() see the ".\" part, thinks that it means current
directory, and promptly removes it.
The manual doesn't mention named pipes but I think this is worth fixing as it
will give PHP Win32 a robust interprocess communication mechanism that's fairly
easy to implement. The fix is easy enough. Insert the following at line 413 in
tsrm_virtual_cwd.c, right after the else if (!IS_DIRECTORY_CURRENT(ptr,
ptr_length)) loop:
#ifdef TSRM_WIN32
/* '.' should be retained if the first two
chars are '\' as it stands for local machine
done mainly for paths to NT named pipes
(\\.\pipe\pipename) */
} else if(state->cwd_length == 2 && state->cwd[0] ==
'\\' && state->cwd[1] == '\\') {
state->cwd = (char *) realloc(state->cwd,
state->cwd_length+ptr_length+1);
memcpy(&state->cwd[state->cwd_length], ptr,
ptr_length+1);
state->cwd_length += ptr_length;
#endif
}
Reproduce code:
---
Set break point at line 1975 in streams.c
fd = open(realpath, open_flags, 0666);
then run . Inspect realpath.
Expected result:
realpath => \\.\pipe\pipename
Actual result:
--
realpath => \\pipe\pipename
--
Edit this bug report at https://bugs.php.net/bug.php?id=29005&edit=1
Req #53946 [Asn->Csd]: add json_encode option for not escaping unnecessary character
Edit report at https://bugs.php.net/bug.php?id=53946&edit=1 ID: 53946 Updated by: ir...@php.net Reported by:christian dot pernot at pingroom dot net Summary:add json_encode option for not escaping unnecessary character -Status: Assigned +Status: Closed Type: Feature/Change Request Package:JSON related PHP Version:5.3.5 Assigned To:scottmac Block user comment: N Private report: N Previous Comments: [2011-08-29 16:21:52] gwy...@php.net Automatic comment from SVN on behalf of gwynne Revision: http://svn.php.net/viewvc/?view=revision&revision=315718 Log: Add documentation for the JSON_UNESCAPED_UNICODE flag (bug #53946) [2011-08-29 15:08:57] gwy...@php.net Automatic comment from SVN on behalf of gwynne Revision: http://svn.php.net/viewvc/?view=revision&revision=315710 Log: Added NEWS note for #53946 [2011-08-29 14:57:42] gwy...@php.net Automatic comment from SVN on behalf of gwynne Revision: http://svn.php.net/viewvc/?view=revision&revision=315708 Log: Add test for #53946 to 5.4 (missed it when committing revision 315707) [2011-08-29 14:56:09] gwy...@php.net Automatic comment from SVN on behalf of gwynne Revision: http://svn.php.net/viewvc/?view=revision&revision=315707 Log: Add unescaped Unicode encoding to json_encode(). Closes bug #53946. Patch by Irker and Gwynne. [2011-08-29 14:04:14] gwy...@php.net The following patch has been added/updated: Patch Name: json_unescaped_unicode Revision: 1314626654 URL: https://bugs.php.net/patch-display.php?bug=53946&patch=json_unescaped_unicode&revision=1314626654 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 https://bugs.php.net/bug.php?id=53946 -- Edit this bug report at https://bugs.php.net/bug.php?id=53946&edit=1
[PHP-BUG] Bug #60674 [NEW]: SoapClient::__soapCall sends null parameters
From:
Operating system: Windows XP SP3
PHP version: 5.3.8
Package: SOAP related
Bug Type: Bug
Bug description:SoapClient::__soapCall sends null parameters
Description:
---
>From manual page:
http://www.php.net/soapclient.soapcall#refsect1-soapclient.soapcall-parameters
---
Sample function provided will not pass parameters to the given SOAP
function, whether associative or ordered array. This is confirmed from the
WSDL side.
Test script:
---
function doSOAP($wsdl,$func,$param) {
try {
$response = new DOMDocument();
$soap = new soapClient($wsdl, array('trace'=>true,
'exceptions'=>true));
$result = $soap->__soapCall($func,$param);
if(is_soap_fault($result)) {
return $result;
}
else {
$response->loadXML($soap->__getLastResponse());
return $response;
}
}
catch(Exception $exc) {
return $exc;
}
}
--
Edit bug report at https://bugs.php.net/bug.php?id=60674&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60674&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60674&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60674&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60674&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60674&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60674&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60674&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60674&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60674&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60674&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60674&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60674&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60674&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60674&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60674&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60674&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60674&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60674&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60674&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60674&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60674&r=mysqlcfg
Bug #60671 [Opn->Bgs]: fread does not fail when operating on a write only stream
Edit report at https://bugs.php.net/bug.php?id=60671&edit=1
ID: 60671
Updated by: cataphr...@php.net
Reported by:james dot turner dot phpninja at gmail dot com
Summary:fread does not fail when operating on a write only
stream
-Status: Open
+Status: Bogus
Type: Bug
Package:Streams related
Operating System: Ubuntu 11.04
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This is not a bug. fread only returns false if given invalid arguments. The bug
is that you try to read from a stream that's write-only.
This C program has analogous behavior:
#include
int main(void)
{
FILE *f = fopen("/tmp/foobaz", "w");
printf("feof: %d\n", feof(f));
printf("read: %zd\n", fread((char[100]) {}, 1, 100, f));
printf("feof: %d\n", feof(f));
return 0;
}
gcc --std=c99 h.c && ./a.out
feof: 0
read: 0
feof: 0
Previous Comments:
[2012-01-06 16:01:07] phpmpan at mpan dot pl
CONFIRMED for both 5.3.8 and 5.3.7 on Arch64, and for 5.3.4 on an unknown Linux.
Note however, that the test script provided by OP is wrong. It should be:
BEGIN CODE
$tmp = tempnam(sys_get_temp_dir(), 'test_');
$stream = fopen($tmp, 'w');
$data = "";
while(!feof($stream)){
if(false === ($data = fread($stream, 8192))){
break; // ^ no dot here
};
}
- END CODE -
OP's code will fail regardless of the bug, because .= always produces a string.
[2012-01-06 14:29:43] james dot turner dot phpninja at gmail dot com
Description:
fread does not throw or generate any error when attempting to read from a write
only file stream.
Test script:
---
Expected result:
Either feof to return false indicating end of file
Or fread erroring or returning false as a result of attempting to read a
write-only stream.
Actual result:
--
An infinite loop will occur.
feof will never end (doesn't reach the end of the file because it's in write
mode)
fread will never error despite attempting to read from a write only stream.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60671&edit=1
[PHP-BUG] Bug #60675 [NEW]: htmlentities(ENT_COMPAT, windows-1251) for ISO-8859-1 encoded scripts
From: danielc Operating system: ubuntu 10.0.4 / lucid PHP version: 5.4SVN-2012-01-06 (SVN) Package: *General Issues Bug Type: Bug Bug description:htmlentities(ENT_COMPAT, windows-1251) for ISO-8859-1 encoded scripts Description: The behavior htmlentities() (or PHP's parser/whatever) has changed between 5.3 and 5.4. I will put a phpt file in svn once the bug number is known. Test script: --- $in = 'Ãåñòèðóåì'; echo htmlentities($in, ENT_COMPAT, 'windows-1251'); Expected result: Тестируем Actual result: -- illegible -- Edit bug report at https://bugs.php.net/bug.php?id=60675&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60675&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60675&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60675&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60675&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60675&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60675&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60675&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60675&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60675&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60675&r=support Expected behavior: https://bugs.php.net/fix.php?id=60675&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60675&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60675&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60675&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60675&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60675&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60675&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60675&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60675&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60675&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60675&r=mysqlcfg
Bug #60672 [Opn->Bgs]: ELSEIF/ELSE IF doesn't work
Edit report at https://bugs.php.net/bug.php?id=60672&edit=1
ID: 60672
Updated by: fel...@php.net
Reported by:danillo dot paiva dot toledo at gmail dot com
Summary:ELSEIF/ELSE IF doesn't work
-Status: Open
+Status: Bogus
Type: Bug
Package:Variables related
Operating System: Windows XP
PHP Version:Irrelevant
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:
[2012-01-06 16:22:00] anon at anon dot anon
This occurs because 0 == "some_string" is true, and 0 == false is true. See:
http://php.net/manual/en/types.comparisons.php
Use === instead of == (and !== instead of !=) to stop type conversion in
comparisons.
[2012-01-06 16:14:32] danillo dot paiva dot toledo at gmail dot com
$x = 0;
$y = "some_string";
if( $x == 2 ) {
echo "X = 2.";
echo "Inner first IF";
} elseif ( $x == $y ) {
echo "We are at the elseif condition.";
} else {
echo "I don't know what's X value.";
}
1st - That's my first time using bug report on php.net.
2nd - I'm brazilia(sorry my english).
3rd - I don't know I'm using the correct channel to report this.
I used WAMPServer2.1 to discover this bug.
The current PHP version used on used WAMPServer2.1 is 5.3.5.
This prints "We are at the elseif condition.".
The same happens if the $y value is false.
[2012-01-06 16:11:19] danillo dot paiva dot toledo at gmail dot com
Description:
$x = 0;
$y = "some_string";
if( $x == 2 ) {
echo "X = 2.";
echo "Inner first IF";
} elseif ( $x == $y ) {
echo "We are at the elseif condition.";
} else {
echo "I don't know what's X value.";
}
Test script:
---
1st - That's my first time using bug report on php.net.
2nd - I'm brazilia(sorry my english).
3rd - I don't know I'm using the correct channel to report this.
I used WAMPServer2.1 to discover this bug.
The current PHP version used on used WAMPServer2.1 is 5.3.5.
This prints "We are at the elseif condition.".
The same happens if the $y value is false.
Expected result:
Expected result would be: "I don't know what's X value.".
Actual result:
--
Actual result would be: "I don't know what's X value.".
--
Edit this bug report at https://bugs.php.net/bug.php?id=60672&edit=1
Bug #60675 [Com]: htmlentities(ENT_COMPAT, windows-1251) for ISO-8859-1 encoded scripts
Edit report at https://bugs.php.net/bug.php?id=60675&edit=1 ID: 60675 Comment by: dani...@php.net Reported by:dani...@php.net Summary:htmlentities(ENT_COMPAT, windows-1251) for ISO-8859-1 encoded scripts Status: Open Type: Bug Package:*General Issues Operating System: ubuntu 10.0.4 / lucid PHP Version:5.4SVN-2012-01-06 (SVN) Block user comment: N Private report: N New Comment: The test script is in PHP_5_4 and trunk as ext/standard/tests/strings/bug60675.phpt Previous Comments: [2012-01-06 22:09:36] dani...@php.net Automatic comment from SVN on behalf of danielc Revision: http://svn.php.net/viewvc/?view=revision&revision=321841 Log: Test for bug 60675. [2012-01-06 22:08:47] dani...@php.net Automatic comment from SVN on behalf of danielc Revision: http://svn.php.net/viewvc/?view=revision&revision=321840 Log: Test for bug 60675. [2012-01-06 21:58:01] dani...@php.net Description: The behavior htmlentities() (or PHP's parser/whatever) has changed between 5.3 and 5.4. I will put a phpt file in svn once the bug number is known. Test script: --- $in = 'Ãåñòèðóåì'; echo htmlentities($in, ENT_COMPAT, 'windows-1251'); Expected result: Тестируем Actual result: -- illegible -- Edit this bug report at https://bugs.php.net/bug.php?id=60675&edit=1
Bug #43731 [Com]: socket_getpeername: cannot use on stdin with inetd
Edit report at https://bugs.php.net/bug.php?id=43731&edit=1
ID: 43731
Comment by: edo888 at gmail dot com
Reported by:uth3r_p3ndrag0n at yahoo dot com
Summary:socket_getpeername: cannot use on stdin with inetd
Status: Closed
Type: Bug
Package:Sockets related
Operating System: Linux, Debian Etch 4.0r1
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
Doesn't seem to work for me.
# php -v
PHP 5.3.8 with Suhosin-Patch (cli) (built: Dec 23 2011 18:46:04)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
# php -r "fsockopen('php://stdin');"
Warning: fsockopen(): unable to connect to php://stdin:-1 (Unable to find the
socket transport "php" - did you forget to enable it when you configured PHP?)
in Command line code on line 1
Previous Comments:
[2008-11-04 21:06:25] lbarn...@php.net
This bug has been fixed in CVS.
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.
Fixed, now stream_socket_get_name(STDIN, true) should work in the cli.
[2008-01-02 19:58:17] uth3r_p3ndrag0n at yahoo dot com
Description:
When running a php script via inetd, I cannot get the remote address due to
socket_getpeername's parameter type.
There seems no way to treat the stdin as a socket for this function. The C
system call, getpeerbyname (in ) takes a file descriptor. When
called by inetd, passing 0 (or stdin) returns the peer information of the
socket which is mapped to the stdin of the running process.
There may not be anyway to work around this considering the way sockets were
designed in php. I tried opening php://stdin and using the resource returned,
but that isn't a Socket resource.
I would have expected to be able get a socket resource of stdin via
'fsockopen("php://stdin")', as specified in
http://www.php.net/manual/en/wrappers.php.php, but despite it's url style
naming, fsockopen returns 'Unable to find the socket transport "php"'
Reproduce code:
---
$stdin = fopen('php://stdin');
socket_getpeername($stdin, $addr, $port);
OR
$stdin = fsockopen('php://stdin');
socket_getpeername($stdin, $addr, $port);
Expected result:
$addr and $port should have been populated with the ip address and port #.
Actual result:
--
Warning: socket_getpeername(): supplied resource is not a valid Socket resource
in [script name] on line X
OR
Warning: fsockopen(): unable to connect to php://stdin:-1 (Unable to find the
socket transport "php" - did you forget to enable it when you configured PHP?)
in [script_name] on line X
--
Edit this bug report at https://bugs.php.net/bug.php?id=43731&edit=1
[PHP-BUG] Req #60676 [NEW]: Add ability to specify default proxy server for soap extension
From:
Operating system:
PHP version: 5.3.8
Package: SOAP related
Bug Type: Feature/Change Request
Bug description:Add ability to specify default proxy server for soap extension
Description:
I found that there is no way to change default SoapClient settings. I have
a project installed in proxy environment and i want to avoid major code
changes.
Proposed changes will add 3 ini variables:
1) soap.proxy_host
2) soap.proxy_port
3) soap.proxy_login
4) soap.proxy_password
If this settings are specified in ini (or using ini_set()) then SoapClient
will use them by default. It is still possible to override them in the
object parameters array.
Test script:
---
Any SoapClient call without parameters in the proxy-only network.
Expected result:
After this patch and setting ini variables proxy will be used.
This is example from my test machine:
ini_set("soap.wsdl_cache_enabled", "0");
ini_set("soap.proxy_port", 3128);
ini_set("soap.proxy_host", "127.0.0.1");
//ini_set("soap.proxy_login", "test");
//ini_set("soap.proxy_password", "test");
--
Edit bug report at https://bugs.php.net/bug.php?id=60676&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60676&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60676&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60676&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60676&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60676&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60676&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60676&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60676&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60676&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60676&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60676&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60676&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60676&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60676&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60676&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60676&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60676&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60676&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60676&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60676&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60676&r=mysqlcfg
[PHP-BUG] Bug #60677 [NEW]: CGI doesn't properly validate shebang line contains #!
From: Operating system: N/A PHP version: trunk-SVN-2012-01-07 (SVN) Package: CGI/CLI related Bug Type: Bug Bug description:CGI doesn't properly validate shebang line contains #! Description: When running in CGI, PHP attempts to look for a shebang. However there is a bug where if the first character of the first line is a hash character/pound character (#), PHP doesn't validate that the next character is an exclamation mark and thus a properly formed shebang line (e.g. #!). Instead PHP just skips the entire line ignoring any PHP code that might be on that line. The code in question from a quick examination appears to be here in trunk: http://svn.php.net/viewvc/php/php-src/trunk/sapi/cgi/cgi_main.c? revision=321634&view=markup On lines 2361, 2379 and 2396. And on the PHP 5.4 branch: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/sapi/cgi/cgi_main.c? revision=321634&view=markup On lines 2362, 2380 and 2397. This has been replicated on PHP 5.3.3 and PHP 5.3.5 as well as being in current trunk. Test script: --- # Second line. Expected result: X-Powered-By: PHP/5.3.3-7+squeeze3 Content-type: text/html #Hello World Second line. Actual result: -- X-Powered-By: PHP/5.3.3-7+squeeze3 Content-type: text/html Second line. -- Edit bug report at https://bugs.php.net/bug.php?id=60677&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60677&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60677&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60677&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60677&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60677&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60677&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60677&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60677&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60677&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60677&r=support Expected behavior: https://bugs.php.net/fix.php?id=60677&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60677&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60677&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60677&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60677&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60677&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60677&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60677&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60677&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60677&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60677&r=mysqlcfg
Bug #60677 [Com]: CGI doesn't properly validate shebang line contains #!
Edit report at https://bugs.php.net/bug.php?id=60677&edit=1 ID: 60677 Comment by: pasamio at gmail dot com Reported by:pasamio at gmail dot com Summary:CGI doesn't properly validate shebang line contains #! Status: Open Type: Bug Package:CGI/CLI related Operating System: N/A PHP Version:trunk-SVN-2012-01-07 (SVN) Block user comment: N Private report: N New Comment: This appears to have been introduced with this change: http://svn.php.net/viewvc/php/php-src/trunk/sapi/cgi/cgi_main.c? r1=288080&r2=288081& Previous Comments: [2012-01-07 02:39:51] pasamio at gmail dot com Description: When running in CGI, PHP attempts to look for a shebang. However there is a bug where if the first character of the first line is a hash character/pound character (#), PHP doesn't validate that the next character is an exclamation mark and thus a properly formed shebang line (e.g. #!). Instead PHP just skips the entire line ignoring any PHP code that might be on that line. The code in question from a quick examination appears to be here in trunk: http://svn.php.net/viewvc/php/php-src/trunk/sapi/cgi/cgi_main.c? revision=321634&view=markup On lines 2361, 2379 and 2396. And on the PHP 5.4 branch: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/sapi/cgi/cgi_main.c? revision=321634&view=markup On lines 2362, 2380 and 2397. This has been replicated on PHP 5.3.3 and PHP 5.3.5 as well as being in current trunk. Test script: --- # Second line. Expected result: X-Powered-By: PHP/5.3.3-7+squeeze3 Content-type: text/html #Hello World Second line. Actual result: -- X-Powered-By: PHP/5.3.3-7+squeeze3 Content-type: text/html Second line. -- Edit this bug report at https://bugs.php.net/bug.php?id=60677&edit=1
Req #47708 [Opn->Bgs]: explode() with empty delimiter
Edit report at https://bugs.php.net/bug.php?id=47708&edit=1
ID: 47708
Updated by: dtajchre...@php.net
Reported by:david at grudl dot com
Summary:explode() with empty delimiter
-Status: Open
+Status: Bogus
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
PHP Version:5.3.0beta1
Block user comment: N
Private report: N
New Comment:
php.net/str_split
Previous Comments:
[2009-06-08 03:50:41] a at b dot c dot de
"It must be done using preg_split..."
Or str_split().
[2009-03-18 18:30:00] david at grudl dot com
Description:
Splitting a string into array of characters is not easy in PHP. It must be done
using preg_split (slow) and with a lot of parameters:
$chars = preg_split('//', $str, -1, PREG_SPLIT_NO_EMPTY);
Feature request: allow function explode() to split string into characters.
Usage:
$chars = explode('', $str);
Rationale: there is counterpart function implode() which allows to use empty
separator:
$str = explode('', $chars); // works
--
Edit this bug report at https://bugs.php.net/bug.php?id=47708&edit=1
Bug #60677 [Opn->Bgs]: CGI doesn't properly validate shebang line contains #!
Edit report at https://bugs.php.net/bug.php?id=60677&edit=1 ID: 60677 Updated by: dtajchre...@php.net Reported by:pasamio at gmail dot com Summary:CGI doesn't properly validate shebang line contains #! -Status: Open +Status: Bogus Type: Bug Package:CGI/CLI related Operating System: N/A PHP Version:trunk-SVN-2012-01-07 (SVN) Block user comment: N Private report: N New Comment: Lines that begin with a hash tag can also be comments... # This is a comment... http://us.php.net/manual/en/language.basic-syntax.comments.php Previous Comments: [2012-01-07 02:43:13] pasamio at gmail dot com This appears to have been introduced with this change: http://svn.php.net/viewvc/php/php-src/trunk/sapi/cgi/cgi_main.c? r1=288080&r2=288081& [2012-01-07 02:39:51] pasamio at gmail dot com Description: When running in CGI, PHP attempts to look for a shebang. However there is a bug where if the first character of the first line is a hash character/pound character (#), PHP doesn't validate that the next character is an exclamation mark and thus a properly formed shebang line (e.g. #!). Instead PHP just skips the entire line ignoring any PHP code that might be on that line. The code in question from a quick examination appears to be here in trunk: http://svn.php.net/viewvc/php/php-src/trunk/sapi/cgi/cgi_main.c? revision=321634&view=markup On lines 2361, 2379 and 2396. And on the PHP 5.4 branch: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/sapi/cgi/cgi_main.c? revision=321634&view=markup On lines 2362, 2380 and 2397. This has been replicated on PHP 5.3.3 and PHP 5.3.5 as well as being in current trunk. Test script: --- # Second line. Expected result: X-Powered-By: PHP/5.3.3-7+squeeze3 Content-type: text/html #Hello World Second line. Actual result: -- X-Powered-By: PHP/5.3.3-7+squeeze3 Content-type: text/html Second line. -- Edit this bug report at https://bugs.php.net/bug.php?id=60677&edit=1
Bug #60677 [Bgs->Ver]: CGI doesn't properly validate shebang line contains #!
Edit report at https://bugs.php.net/bug.php?id=60677&edit=1 ID: 60677 Updated by: dtajchre...@php.net Reported by:pasamio at gmail dot com Summary:CGI doesn't properly validate shebang line contains #! -Status: Bogus +Status: Verified Type: Bug Package:CGI/CLI related Operating System: N/A PHP Version:trunk-SVN-2012-01-07 (SVN) Block user comment: N Private report: N New Comment: I completely misunderstood what you were saying... forgive me. :) Taking a second look, you're right... the logic only checks the first character when cgi.check_shebang_line = 1. Previous Comments: [2012-01-07 05:20:05] dtajchre...@php.net Lines that begin with a hash tag can also be comments... # This is a comment... http://us.php.net/manual/en/language.basic-syntax.comments.php [2012-01-07 02:43:13] pasamio at gmail dot com This appears to have been introduced with this change: http://svn.php.net/viewvc/php/php-src/trunk/sapi/cgi/cgi_main.c? r1=288080&r2=288081& [2012-01-07 02:39:51] pasamio at gmail dot com Description: When running in CGI, PHP attempts to look for a shebang. However there is a bug where if the first character of the first line is a hash character/pound character (#), PHP doesn't validate that the next character is an exclamation mark and thus a properly formed shebang line (e.g. #!). Instead PHP just skips the entire line ignoring any PHP code that might be on that line. The code in question from a quick examination appears to be here in trunk: http://svn.php.net/viewvc/php/php-src/trunk/sapi/cgi/cgi_main.c? revision=321634&view=markup On lines 2361, 2379 and 2396. And on the PHP 5.4 branch: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/sapi/cgi/cgi_main.c? revision=321634&view=markup On lines 2362, 2380 and 2397. This has been replicated on PHP 5.3.3 and PHP 5.3.5 as well as being in current trunk. Test script: --- # Second line. Expected result: X-Powered-By: PHP/5.3.3-7+squeeze3 Content-type: text/html #Hello World Second line. Actual result: -- X-Powered-By: PHP/5.3.3-7+squeeze3 Content-type: text/html Second line. -- Edit this bug report at https://bugs.php.net/bug.php?id=60677&edit=1
Bug #60677 [Com]: CGI doesn't properly validate shebang line contains #!
Edit report at https://bugs.php.net/bug.php?id=60677&edit=1
ID: 60677
Comment by: pasamio at gmail dot com
Reported by:pasamio at gmail dot com
Summary:CGI doesn't properly validate shebang line contains
#!
Status: Verified
Type: Bug
Package:CGI/CLI related
Operating System: N/A
PHP Version:trunk-SVN-2012-01-07 (SVN)
Block user comment: N
Private report: N
New Comment:
The Apache 2 Handler appears to work properly though I can't find the code.
Additionally the PHP CLI handles this correctly:
http://svn.php.net/viewvc/php/php-src/trunk/sapi/cli/php_cli.c?
revision=321634&view=markup
Line 633 with:
if (c == '#' && (c = fgetc(file_handle->handle.fp)) == '!') {
And a later rewind. Should be sufficient for some of the CGI stuff but not all
three of the instances in question.
Previous Comments:
[2012-01-07 05:37:11] dtajchre...@php.net
I completely misunderstood what you were saying... forgive me. :) Taking a
second
look, you're right... the logic only checks the first character when
cgi.check_shebang_line = 1.
[2012-01-07 05:20:05] dtajchre...@php.net
Lines that begin with a hash tag can also be comments...
# This is a comment...
http://us.php.net/manual/en/language.basic-syntax.comments.php
[2012-01-07 02:43:13] pasamio at gmail dot com
This appears to have been introduced with this change:
http://svn.php.net/viewvc/php/php-src/trunk/sapi/cgi/cgi_main.c?
r1=288080&r2=288081&
[2012-01-07 02:39:51] pasamio at gmail dot com
Description:
When running in CGI, PHP attempts to look for a shebang. However there is a bug
where if the first character of the first line is a hash character/pound
character (#), PHP doesn't validate that the next character is an exclamation
mark and thus a properly formed shebang line (e.g. #!). Instead PHP just skips
the entire line ignoring any PHP code that might be on that line.
The code in question from a quick examination appears to be here in trunk:
http://svn.php.net/viewvc/php/php-src/trunk/sapi/cgi/cgi_main.c?
revision=321634&view=markup
On lines 2361, 2379 and 2396.
And on the PHP 5.4 branch:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/sapi/cgi/cgi_main.c?
revision=321634&view=markup
On lines 2362, 2380 and 2397.
This has been replicated on PHP 5.3.3 and PHP 5.3.5 as well as being in current
trunk.
Test script:
---
#
Second line.
Expected result:
X-Powered-By: PHP/5.3.3-7+squeeze3
Content-type: text/html
#Hello World
Second line.
Actual result:
--
X-Powered-By: PHP/5.3.3-7+squeeze3
Content-type: text/html
Second line.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60677&edit=1
