#45522 [Fbk->Opn]: FCGI_GET_VALUES request does not return supplied values
ID: 45522 User updated by: arnaud dot lb at gmail dot com Reported By: arnaud dot lb at gmail dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: * PHP Version: 5.3CVS-2008-07-15 (CVS) Assigned To: dmitry New Comment: PHP_FCGI_CHILDREN seems a good value for FCGI_MAX_CONNS and FCGI_MAX_REQS. FCGI_MAX_REQS equals FCGI_MAX_CONNS as there is no support for multiplexed connections. I think these values are relevant only for the backend the request was sent to (e.g. the manager runs 1 php-cgi backend process, asks it for FCGI_MAX_CONNS and run other backend processes depending on that value). Previous Comments: [2008-09-29 08:35:00] [EMAIL PROTECTED] The PHP/FastCGI execution model doesn't allow to identify the real value of FCGI_MAX_CONNS, as it depends on number of running php-cgi backends. FastCGI manager may decide to run more or less backend processes depending on load, but these processes don't communicate each other and can't know how many processes run in the moment. FCGI_MAX_REQS must be equal to FCGI_MAX_CONNS. Currently FCGI_MAX_CONNS and FCGI_MAX_REQS return 1 that mean the process can serve only one connection and one request in a moment. I don't like to fix the issue as it can't be fixed in general without significant complication (shared memory ...) ---- [2008-07-15 16:02:09] arnaud dot lb at gmail dot com Description: FastCGI specifies that a FastCGI application may return the values supplied by a FCGI_GET_VALUES request. Actually the FastCGI SAPI returns all standard values (FCGI_MAX_CONNS, FCGI_MAX_REQS, FCGI_MPXS_CONNS), *except* those supplied. Also, it seems that the returns values does not reflect the actual configuration (e.g. FCGI_MAX_CONNS and FCGI_MAX_REQS are always 1). Reproduce code: --- Requesting the FCGI_MAX_CONN value using a FCGI_GET_VALUES record in the FastCGI protocol. Expected result: Requesting the FCGI_MAX_CONN returns FCGI_MAX_CONN value. Actual result: -- Requesting the FCGI_MAX_CONN returns FCGI_MAX_REQS and FCGI_MPXS_CONNS values but not FCGI_MAX_CONN. -- Edit this bug report at http://bugs.php.net/?id=45522&edit=1
#45522 [NEW]: FCGI_GET_VALUES request does not returns supplied values
From: arnaud dot lb at gmail dot com Operating system: PHP version: 5.3CVS-2008-07-15 (CVS) PHP Bug Type: CGI related Bug description: FCGI_GET_VALUES request does not returns supplied values Description: FastCGI specifies that a FastCGI application may return the values supplied by a FCGI_GET_VALUES request. Actually the FastCGI SAPI returns all standard values (FCGI_MAX_CONNS, FCGI_MAX_REQS, FCGI_MPXS_CONNS), *except* those supplied. Also, it seems that the returns values does not reflect the actual configuration (e.g. FCGI_MAX_CONNS and FCGI_MAX_REQS are always 1). Reproduce code: --- Requesting the FCGI_MAX_CONN value using a FCGI_GET_VALUES record in the FastCGI protocol. Expected result: Requesting the FCGI_MAX_CONN returns FCGI_MAX_CONN value. Actual result: -- Requesting the FCGI_MAX_CONN returns FCGI_MAX_REQS and FCGI_MPXS_CONNS values but not FCGI_MAX_CONN. -- Edit bug report at http://bugs.php.net/?id=45522&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45522&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45522&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45522&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45522&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45522&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45522&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45522&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45522&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45522&r=support Expected behavior:http://bugs.php.net/fix.php?id=45522&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45522&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45522&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45522&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45522&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45522&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45522&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45522&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45522&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45522&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45522&r=mysqlcfg
#45492 [Fbk->Opn]: All tests fail with --disable-xml
ID: 45492 User updated by: arnaud dot lb at gmail dot com Reported By: arnaud dot lb at gmail dot com -Status: Feedback +Status: Open Bug Type:SOAP related PHP Version: 5.2.6 New Comment: Sorry, the reproduce procedure was incomplete. This configure line makes the bug reproducible: ./configure --disable-all --enable-libxml --enable-soap --enable-cli --with-pcre-regex Then, run: TESTS=ext/soap/tests/schema/*.phpt make test I just tested with php5.2-latest.tar.gz. Previous Comments: [2008-07-12 16:15:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi I can't reproduce: configure: error: SOAP extension requires LIBXML extension, add --enable-libxml [2008-07-12 14:34:10] arnaud dot lb at gmail dot com Description: When PHP compiled with --disable-xml, all SOAP tests are failing with the following error: $ cat ext/soap/tests/schema/schema085.diff 001+ Fatal error: Call to undefined function xml_parser_create() in /tmp/php-5.2.6/ext/soap/tests/schema/test_schema.inc on line 64 Reproduce code: --- ./configure --disable-all --enable-soap --enable-cli --with-pcre-regex make make test Expected result: All SOAP tests using xml_* functions should be skipped when the xml parser extension is not loaded Actual result: -- SOAP tests are not skipped and fail -- Edit this bug report at http://bugs.php.net/?id=45492&edit=1
#45493 [NEW]: gethostbynamel test should use canonical names
From: arnaud dot lb at gmail dot com
Operating system: Linux
PHP version: 5.2.6
PHP Bug Type: Network related
Bug description: gethostbynamel test should use canonical names
Description:
gethostbynamel test
ext/standard/tests/network/gethostbynamel_error.phpt should use
canonical name for the "Testing gethostbynamel() with an unknown
host" test:
var_dump(gethostbynamel("unknownhost_zzz_xxx_yyy"));
unknownhost_zzz_xxx_yyy may be expanded to
unknownhost_zzz_xxx_yyy._your_local_domain_ and resolv correctly, in
which case the test fails, even if it is actually not a bug.
The test may use a canonical name (a dot at the end for the name),
so that it will not be expanded, and never resolv:
var_dump(gethostbynamel("unknownhost_zzz_xxx_yyy."));
--
Edit bug report at http://bugs.php.net/?id=45493&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45493&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45493&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45493&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45493&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45493&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45493&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45493&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45493&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45493&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45493&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45493&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45493&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45493&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45493&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45493&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45493&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45493&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45493&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45493&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45493&r=mysqlcfg
#45492 [NEW]: All tests fail with --disable-xml
From: arnaud dot lb at gmail dot com Operating system: PHP version: 5.2.6 PHP Bug Type: SOAP related Bug description: All tests fail with --disable-xml Description: When PHP compiled with --disable-xml, all SOAP tests are failing with the following error: $ cat ext/soap/tests/schema/schema085.diff 001+ Fatal error: Call to undefined function xml_parser_create() in /tmp/php-5.2.6/ext/soap/tests/schema/test_schema.inc on line 64 Reproduce code: --- ./configure --disable-all --enable-soap --enable-cli --with-pcre-regex make make test Expected result: All SOAP tests using xml_* functions should be skipped when the xml parser extension is not loaded Actual result: -- SOAP tests are not skipped and fail -- Edit bug report at http://bugs.php.net/?id=45492&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45492&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45492&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45492&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45492&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45492&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45492&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45492&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45492&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45492&r=support Expected behavior:http://bugs.php.net/fix.php?id=45492&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45492&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45492&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45492&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45492&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45492&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45492&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45492&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45492&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45492&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45492&r=mysqlcfg
#42663 [Opn]: gzinflate() try to allocate all memory with truncated $data
ID: 42663
User updated by: arnaud dot lb at gmail dot com
Reported By: arnaud dot lb at gmail dot com
Status: Open
Bug Type: Zlib Related
Operating System: Linux 2.6
PHP Version: 5.2.4
New Comment:
I made a patch for this bug:
http://marc.info/?l=php-internals&m=121561206424622&w=1
Previous Comments:
[2007-09-29 02:15:24] arnaud dot lb at gmail dot com
I wrote a testcase for this bug:
http://s3.amazonaws.com/arnaud.lb/gzinflate-bug42663.phpt.txt
[2007-09-16 17:43:11] arnaud dot lb at gmail dot com
It works with any compressed data if you truncate it.
The yuicompressor-1.0.zip file used for this example can be found
here:
http://www.julienlecomte.net/yuicompressor/yuicompressor-1.0.zip
[2007-09-16 14:52:47] [EMAIL PROTECTED]
Can you please provide a URL to the file with corrupted data.
[2007-09-13 18:33:23] arnaud dot lb at gmail dot com
Example code in a more readable format:
[2007-09-13 18:28:28] arnaud dot lb at gmail dot com
Description:
gzinflate() try to allocate all memory with truncated $data:
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
Zlib version: 1.2.3.3
Reproduce code:
---
/tmp/php-5.2.4$ ./configure --disable-all --enable-cli --with-zlib &&
make -j4
/tmp/php-5.2.4$ sapi/cli/php -d memory_limit=-1 -r '$data =
gzdeflate(file_get_contents("/tmp/yuicompressor-1.0.zip"), 9); echo
"Compressed length: " . strlen($data) . "\n"; gzinflate($data); $data =
substr($data, 0, 65535); echo "Truncated length: " . strlen($data) .
"\n"; gzinflate($data);'
Expected result:
gzinflate() should return FALSE, without eating all memory
Actual result:
--
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
--
Edit this bug report at http://bugs.php.net/?id=42663&edit=1
#43008 [Com]: php://filter uris ignore url encoded filternames and can't handle slashes
ID: 43008 Comment by: arnaud dot lb at gmail dot com Reported By: php at benjaminschulz dot com Status: Assigned Bug Type: Streams related Operating System: linux PHP Version: 5.3CVS-2007-10-17 (CVS) Assigned To: hholzgra New Comment: A possible fix would be to urldecode() filter names in the php:// wrapper before passing them to the filter API: http://arnaud.lb.s3.amazonaws.com/url_encoded_filter-43008.patch Previous Comments: [2008-03-17 23:42:28] php at benjaminschulz dot com This should work because otherwise there is no way to pass valid and existing filternames as URIs to PHP. (This bug is approved by hartmut btw.) [2008-03-17 20:53:31] [EMAIL PROTECTED] And this should work because..? (IMO, it's expected, you pass invalid data -> you get an error..simple.) [2008-03-10 14:55:17] php at benjaminschulz dot com If the filtername is not URL encoded than i get this: Warning: readfile(): unable to create or locate filter "convert.iconv.ISO-8859-15" in ... Warning: readfile(): Unable to create filter (convert.iconv.ISO-8859-15) in ... Warning: readfile(): unable to locate filter "UTF-8" in ... Warning: readfile(): Unable to create filter (UTF-8) in ... [2007-10-17 17:04:40] php at benjaminschulz dot com Description: because filternames can contain slashes (convert.iconv.from-enc/to-enc) it should be possible to pass URL-encodet filternames to php://filter Reproduce code: --- http://bugs.php.net/?id=43008&edit=1
#43928 [Com]: Using periods in encapsulated variables returns white page
ID: 43928 Comment by: arnaud dot lb at gmail dot com Reported By: david dot reade at sbhelp dot co dot uk Status: Open Bug Type: Variables related Operating System: CentOS 5.1 PHP Version: 5.2.5 New Comment: PHP replaces "." with "_" in variables names. Try isset($_GET['this_is_a_test']) ;) Previous Comments: [2008-01-24 14:55:26] david dot reade at sbhelp dot co dot uk Reproduce code should actually read: [2008-01-24 14:54:08] david dot reade at sbhelp dot co dot uk Description: Using dots in queries, e.g. "/index.php?this.is.a.test", which returns a white page with no error, even with 'error_reporting(E_ALL)'. However using any other symbol, such as a colon, returns the correct result. Reproduce code: --- Expected result: It works! Actual result: -- /index.php?this.is.a.test = /index.php?this;is;a;test = 'It works!' /index.php?this:is:a:test = 'It works!' -- Edit this bug report at http://bugs.php.net/?id=43928&edit=1
#43896 [Opn]: htmlspecialchars returns empty string on invalid unicode sequence
ID: 43896 User updated by: arnaud dot lb at gmail dot com Reported By: arnaud dot lb at gmail dot com Status: Open -Bug Type: Unicode Function Upgrades relate +Bug Type: *General Issues Operating System: Any PHP Version: 5.2.5 New Comment: I made a patch for this bug: http://s3.amazonaws.com/arnaud.lb/php_htmlentities_utf.patch The internal get_next_char() function returns a status of FAILURE when it encounters a invalid or incomplete sequence, which causes the htmlspecialchars and htmlentities functions to return an empty string. This patch modify the behavior of these functions to skip invalid sequences, without discarding the whole string. This involves a very few changes and makes the behavior of theses functions more consistent with previous PHP versions. It also adds a few tests to htmlentities-utf.phpt. Previous Comments: [2008-01-20 02:12:01] arnaud dot lb at gmail dot com Description: htmlspecialchars/htmlentities returns an empty string when the input contains an invalid unicode sequence. I think these functions should just skip the invalid sequences or encode them byte by byte (e.g. 0xE9 => é), instead of discarding the whole string. Sometimes you have to display arbitrary strings of unknow encoding. So you make them more safe using htmlspecialchars($string, ENT_COMPAT, "site_encoding, utf-8 in my case"), but if there is at least one invalid sequence in the string, it returns an empty string :/ Reproduce code: --- $string = "Voil\xE0"; // "Voilà", in ISO-8859-15 var_dump(htmlspecialchars($string, ENT_COMPAT, "utf-8")); Expected result: string(4) "Voil" OR string(10) "Voilà" Actual result: -- string(0) "" -- Edit this bug report at http://bugs.php.net/?id=43896&edit=1
#43896 [NEW]: htmlspecialchars returns empty string on invalid unicode sequence
From: arnaud dot lb at gmail dot com Operating system: Any PHP version: 5.2.5 PHP Bug Type: Unicode Function Upgrades related Bug description: htmlspecialchars returns empty string on invalid unicode sequence Description: htmlspecialchars/htmlentities returns an empty string when the input contains an invalid unicode sequence. I think these functions should just skip the invalid sequences or encode them byte by byte (e.g. 0xE9 => é), instead of discarding the whole string. Sometimes you have to display arbitrary strings of unknow encoding. So you make them more safe using htmlspecialchars($string, ENT_COMPAT, "site_encoding, utf-8 in my case"), but if there is at least one invalid sequence in the string, it returns an empty string :/ Reproduce code: --- $string = "Voil\xE0"; // "Voilà", in ISO-8859-15 var_dump(htmlspecialchars($string, ENT_COMPAT, "utf-8")); Expected result: string(4) "Voil" OR string(10) "Voilà" Actual result: -- string(0) "" -- Edit bug report at http://bugs.php.net/?id=43896&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43896&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43896&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43896&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43896&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43896&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43896&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43896&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43896&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43896&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43896&r=support Expected behavior:http://bugs.php.net/fix.php?id=43896&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43896&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43896&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43896&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43896&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43896&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43896&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43896&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43896&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43896&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43896&r=mysqlcfg
#42718 [Fbk->Opn]: FILTER_UNSAFE_RAW not applied when configured as default filter, even with flags
ID: 42718
User updated by: arnaud dot lb at gmail dot com
Reported By: arnaud dot lb at gmail dot com
-Status: Feedback
+Status: Open
Bug Type:Filter related
PHP Version: 5.2.4
Assigned To: pajoye
New Comment:
Thanks for your reply.
I'm trying to strip low ascii characters from GET/POST/COOKIE using
the filter extension, and the only way to do that is to use the
unsafe_raw filter with the FILTER_FLAG_STRIP_LOW flag.
The string filter can do that with the FILTER_FLAG_STRIP_LOW flag,
but it strips HTML tags too, and I don't want to strip HTML tags.
>From the documentation, about the unsafe_raw filter:
"Do nothing, optionally strip or encode special characters."
It works as expected using filter_var() for example:
filter_var("a \000 c", FILTER_SANITIZE_STRING,
FILTER_FLAG_STRIP_LOW)
=> "a c" (the null char was striped, but the tag too)
filter_var("a \000 c", FILTER_UNSAFE_RAW, FILTER_FLAG_STRIP_LOW)
=> "a c" (only the null char was striped)
But it does not work as a default filter. The bug42718.phpt testcase
demonstrates that.
According to the documentation, I think that the unsafe_raw filter
may not be bypassed when default_flags are != 0. This is the only
change my patch do:
- if (!(IF_G(default_filter) == FILTER_UNSAFE_RAW)) {
+ if (!(IF_G(default_filter) == FILTER_UNSAFE_RAW) ||
IF_G(default_filter_flags) != 0) {
Previous Comments:
[2007-09-29 20:04:23] [EMAIL PROTECTED]
"The unsafe_raw filter does nothing by default, but it
can "optionally strip or encode special characters", and it is the
only filter which is able to do that without doing any other
filtering."
The string filter with the correct flags should work as you expected.
It is normal that the unsafe_raw filter does nothing.
What are you trying to achieve exactly? (ie using other filters but it
did not work as you expect)
----------------------------
[2007-09-24 17:37:09] arnaud dot lb at gmail dot com
I made a little (one-line) patch for this bug:
https://s3.amazonaws.com/arnaud.lb/filter-bug-42718.patch.txt
And a testcase:
https://s3.amazonaws.com/arnaud.lb/bug42718.phpt.txt
And an other test case to check if the patch does not modify the
behavior of the php_sapi_filter() function:
- Apply filter, only if filter will do something (unsafe_raw with no
flags do nothing)
- Else, fallback to magic_quotes_gpc if enabled
https://s3.amazonaws.com/arnaud.lb/052.phpt.txt
----------------------------
[2007-09-20 16:54:55] arnaud dot lb at gmail dot com
Description:
The "unsafe_raw" filter is not applied when configured as default
filter.
I found that the php_sapi_filter() internal function in
ext/filter/filter.c intentionally bypass this filter:
if (!(IF_G(default_filter) == FILTER_UNSAFE_RAW)){
(apply default filter)
} else [...]
The unsafe_raw filter does nothing by default, but it
can "optionally strip or encode special characters", and it is the
only filter which is able to do that without doing any other
filtering.
Reproduce code:
---
- Prints filter.default and filter.default_flags values,
- Check if $_GET['a'] contains a null byte (null bytes may be filtered
by FILTER_UNSAFE_RAW with the FILTER_FLAG_STRIP_LOW flag
- Check if $_GET['a'] though filter_input() with the same filter/flags
contains a null byte.
\n";
echo "filter.default_flags = " . ini_get('filter.default_flags') . "
\n";
echo "";
echo "\$_GET['a'] contains \\0: " . (strpos($_GET['a'], "\0") !== false
? 'Yes' : 'No') . " \n";
echo "";
echo "\$_GET['a'] throught filter_var() contains \\0: " .
(strpos(filter_var($_GET['a'], FILTER_UNSAFE_RAW,
FILTER_FLAG_STRIP_LOW), "\0") !== false ? 'Yes' : 'No') . "";
echo "";
?>
Expected result:
filter.default: unsafe_raw
filter.default_flags: 4
$_GET['a'] contains \0: No
$_GET['a'] through filter_var() contains \0: No
Actual result:
--
filter.default: unsafe_raw
filter.default_flags: 4
$_GET['a'] contains \0: Yes
$_GET['a'] through filter_var() contains \0: No
--
Edit this bug report at http://bugs.php.net/?id=42718&edit=1
#42663 [Opn]: gzinflate() try to allocate all memory with truncated $data
ID: 42663
User updated by: arnaud dot lb at gmail dot com
Reported By: arnaud dot lb at gmail dot com
Status: Open
Bug Type: Zlib Related
Operating System: Linux 2.6
PHP Version: 5.2.4
New Comment:
I wrote a testcase for this bug:
http://s3.amazonaws.com/arnaud.lb/gzinflate-bug42663.phpt.txt
Previous Comments:
[2007-09-16 17:43:11] arnaud dot lb at gmail dot com
It works with any compressed data if you truncate it.
The yuicompressor-1.0.zip file used for this example can be found
here:
http://www.julienlecomte.net/yuicompressor/yuicompressor-1.0.zip
[2007-09-16 14:52:47] [EMAIL PROTECTED]
Can you please provide a URL to the file with corrupted data.
[2007-09-13 18:33:23] arnaud dot lb at gmail dot com
Example code in a more readable format:
[2007-09-13 18:28:28] arnaud dot lb at gmail dot com
Description:
gzinflate() try to allocate all memory with truncated $data:
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
Zlib version: 1.2.3.3
Reproduce code:
---
/tmp/php-5.2.4$ ./configure --disable-all --enable-cli --with-zlib &&
make -j4
/tmp/php-5.2.4$ sapi/cli/php -d memory_limit=-1 -r '$data =
gzdeflate(file_get_contents("/tmp/yuicompressor-1.0.zip"), 9); echo
"Compressed length: " . strlen($data) . "\n"; gzinflate($data); $data =
substr($data, 0, 65535); echo "Truncated length: " . strlen($data) .
"\n"; gzinflate($data);'
Expected result:
gzinflate() should return FALSE, without eating all memory
Actual result:
--
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
--
Edit this bug report at http://bugs.php.net/?id=42663&edit=1
#42718 [Opn]: FILTER_UNSAFE_RAW not applied when configured as default filter, even with flags
ID: 42718
User updated by: arnaud dot lb at gmail dot com
-Summary: "unsafe_raw" not applied has default filter
Reported By: arnaud dot lb at gmail dot com
Status: Open
Bug Type:Filter related
PHP Version: 5.2.4
New Comment:
I made a little (one-line) patch for this bug:
https://s3.amazonaws.com/arnaud.lb/filter-bug-42718.patch.txt
And a testcase:
https://s3.amazonaws.com/arnaud.lb/bug42718.phpt.txt
And an other test case to check if the patch does not modify the
behavior of the php_sapi_filter() function:
- Apply filter, only if filter will do something (unsafe_raw with no
flags do nothing)
- Else, fallback to magic_quotes_gpc if enabled
https://s3.amazonaws.com/arnaud.lb/052.phpt.txt
Previous Comments:
[2007-09-20 16:54:55] arnaud dot lb at gmail dot com
Description:
The "unsafe_raw" filter is not applied when configured as default
filter.
I found that the php_sapi_filter() internal function in
ext/filter/filter.c intentionally bypass this filter:
if (!(IF_G(default_filter) == FILTER_UNSAFE_RAW)){
(apply default filter)
} else [...]
The unsafe_raw filter does nothing by default, but it
can "optionally strip or encode special characters", and it is the
only filter which is able to do that without doing any other
filtering.
Reproduce code:
---
- Prints filter.default and filter.default_flags values,
- Check if $_GET['a'] contains a null byte (null bytes may be filtered
by FILTER_UNSAFE_RAW with the FILTER_FLAG_STRIP_LOW flag
- Check if $_GET['a'] though filter_input() with the same filter/flags
contains a null byte.
\n";
echo "filter.default_flags = " . ini_get('filter.default_flags') . "
\n";
echo "";
echo "\$_GET['a'] contains \\0: " . (strpos($_GET['a'], "\0") !== false
? 'Yes' : 'No') . " \n";
echo "";
echo "\$_GET['a'] throught filter_var() contains \\0: " .
(strpos(filter_var($_GET['a'], FILTER_UNSAFE_RAW,
FILTER_FLAG_STRIP_LOW), "\0") !== false ? 'Yes' : 'No') . "";
echo "";
?>
Expected result:
filter.default: unsafe_raw
filter.default_flags: 4
$_GET['a'] contains \0: No
$_GET['a'] through filter_var() contains \0: No
Actual result:
--
filter.default: unsafe_raw
filter.default_flags: 4
$_GET['a'] contains \0: Yes
$_GET['a'] through filter_var() contains \0: No
--
Edit this bug report at http://bugs.php.net/?id=42718&edit=1
#42718 [NEW]: "unsafe_raw" not applied has default filter
From: arnaud dot lb at gmail dot com
Operating system:
PHP version: 5.2.4
PHP Bug Type: Filter related
Bug description: "unsafe_raw" not applied has default filter
Description:
The "unsafe_raw" filter is not applied when configured as default
filter.
I found that the php_sapi_filter() internal function in
ext/filter/filter.c intentionally bypass this filter:
if (!(IF_G(default_filter) == FILTER_UNSAFE_RAW)){
(apply default filter)
} else [...]
The unsafe_raw filter does nothing by default, but it
can "optionally strip or encode special characters", and it is the
only filter which is able to do that without doing any other
filtering.
Reproduce code:
---
- Prints filter.default and filter.default_flags values,
- Check if $_GET['a'] contains a null byte (null bytes may be filtered by
FILTER_UNSAFE_RAW with the FILTER_FLAG_STRIP_LOW flag
- Check if $_GET['a'] though filter_input() with the same filter/flags
contains a null byte.
\n";
echo "filter.default_flags = " . ini_get('filter.default_flags') . " \n";
echo "";
echo "\$_GET['a'] contains \\0: " . (strpos($_GET['a'], "\0") !== false ?
'Yes' : 'No') . " \n";
echo "";
echo "\$_GET['a'] throught filter_var() contains \\0: " .
(strpos(filter_var($_GET['a'], FILTER_UNSAFE_RAW, FILTER_FLAG_STRIP_LOW),
"\0") !== false ? 'Yes' : 'No') . "";
echo "";
?>
Expected result:
filter.default: unsafe_raw
filter.default_flags: 4
$_GET['a'] contains \0: No
$_GET['a'] through filter_var() contains \0: No
Actual result:
--
filter.default: unsafe_raw
filter.default_flags: 4
$_GET['a'] contains \0: Yes
$_GET['a'] through filter_var() contains \0: No
--
Edit bug report at http://bugs.php.net/?id=42718&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42718&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42718&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42718&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42718&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42718&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42718&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42718&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42718&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42718&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42718&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42718&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42718&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42718&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42718&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42718&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42718&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42718&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42718&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42718&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42718&r=mysqlcfg
#42711 [NEW]: Unable to chown/chgrp of a symlink
From: arnaud dot lb at gmail dot com
Operating system: Linux
PHP version: 5.2.4
PHP Bug Type: Filesystem function related
Bug description: Unable to chown/chgrp of a symlink
Description:
There is no way to change the owner or group of a symlink.
Using chown and chgrp functions on a symlink affect the file
referenced by the symbolic link, rather than the symbolic link
itself.
There should have a "$dereference" argument to be able to affect the
file referenced by the symlink or the symlink itself.
Reproduce code:
---
&1');
echo "Original owners: \n";
echo shell_exec("ls -l test-referent test-symlink") . "\n";
// Test changing symlink owner with PHP's chown() function
chown('test-symlink', 'root');
echo "New owners: \n";
echo shell_exec("ls -l test-referent test-symlink");
?>
Expected result:
chown should affect symlink owner instead of the referenced file
Original owners:
-rw-r--r-- 1 nobody root 0 2007-09-19 16:04 test-referent
lrwxrwxrwx 1 nobody root 13 2007-09-19 16:04 test-symlink ->
test-referent
New owners:
-rw-r--r-- 1 nobody root 0 2007-09-19 16:04 test-referent
lrwxrwxrwx 1 root root 13 2007-09-19 16:04 test-symlink ->
test-referent
Actual result:
--
chown has affected the referenced file instead of the symlink itself
Original owners:
-rw-r--r-- 1 nobody root 0 2007-09-19 16:04 test-referent
lrwxrwxrwx 1 nobody root 13 2007-09-19 16:04 test-symlink ->
test-referent
New owners:
-rw-r--r-- 1 root root 0 2007-09-19 16:04 test-referent
lrwxrwxrwx 1 nobody root 13 2007-09-19 16:04 test-symlink ->
test-referent
--
Edit bug report at http://bugs.php.net/?id=42711&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42711&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42711&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42711&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42711&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42711&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42711&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42711&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42711&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42711&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42711&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42711&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42711&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42711&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42711&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42711&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42711&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42711&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42711&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42711&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42711&r=mysqlcfg
#42705 [NEW]: Defining sys/stat.h's constants in PHP
From: arnaud dot lb at gmail dot com Operating system: PHP version: 5.2.4 PHP Bug Type: Feature/Change Request Bug description: Defining sys/stat.h's constants in PHP Description: It would be very useful to have the sys/stat.h constants (S_*, e.g. S_ISUID for the setuid bit) defined in PHP, to be able to more easily use the values returned by functions such as fileperms() or stat(). I actually use this to define them (from stat(2) man page), but I guess it's not portable: This make me able to do things like ($fileperms & S_IROTH) instead of ($fileperms & 4) to know if a file is world readable. -- Edit bug report at http://bugs.php.net/?id=42705&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42705&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42705&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42705&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42705&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42705&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42705&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42705&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42705&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42705&r=support Expected behavior:http://bugs.php.net/fix.php?id=42705&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42705&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42705&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42705&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42705&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42705&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42705&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42705&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42705&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42705&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42705&r=mysqlcfg
#42663 [Fbk->Opn]: gzinflate() try to allocate all memory with truncated $data
ID: 42663
User updated by: arnaud dot lb at gmail dot com
Reported By: arnaud dot lb at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Zlib Related
Operating System: Linux 2.6
PHP Version: 5.2.4
New Comment:
It works with any compressed data if you truncate it.
The yuicompressor-1.0.zip file used for this example can be found
here:
http://www.julienlecomte.net/yuicompressor/yuicompressor-1.0.zip
Previous Comments:
[2007-09-16 14:52:47] [EMAIL PROTECTED]
Can you please provide a URL to the file with corrupted data.
[2007-09-13 18:33:23] arnaud dot lb at gmail dot com
Example code in a more readable format:
[2007-09-13 18:28:28] arnaud dot lb at gmail dot com
Description:
gzinflate() try to allocate all memory with truncated $data:
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
Zlib version: 1.2.3.3
Reproduce code:
---
/tmp/php-5.2.4$ ./configure --disable-all --enable-cli --with-zlib &&
make -j4
/tmp/php-5.2.4$ sapi/cli/php -d memory_limit=-1 -r '$data =
gzdeflate(file_get_contents("/tmp/yuicompressor-1.0.zip"), 9); echo
"Compressed length: " . strlen($data) . "\n"; gzinflate($data); $data =
substr($data, 0, 65535); echo "Truncated length: " . strlen($data) .
"\n"; gzinflate($data);'
Expected result:
gzinflate() should return FALSE, without eating all memory
Actual result:
--
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
--
Edit this bug report at http://bugs.php.net/?id=42663&edit=1
#42663 [Opn]: gzinflate() try to allocate all memory with truncated $data
ID: 42663
User updated by: arnaud dot lb at gmail dot com
Reported By: arnaud dot lb at gmail dot com
Status: Open
Bug Type: Zlib Related
Operating System: Linux 2.6
PHP Version: 5.2.4
New Comment:
Example code in a more readable format:
Previous Comments:
[2007-09-13 18:28:28] arnaud dot lb at gmail dot com
Description:
gzinflate() try to allocate all memory with truncated $data:
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
Zlib version: 1.2.3.3
Reproduce code:
---
/tmp/php-5.2.4$ ./configure --disable-all --enable-cli --with-zlib &&
make -j4
/tmp/php-5.2.4$ sapi/cli/php -d memory_limit=-1 -r '$data =
gzdeflate(file_get_contents("/tmp/yuicompressor-1.0.zip"), 9); echo
"Compressed length: " . strlen($data) . "\n"; gzinflate($data); $data =
substr($data, 0, 65535); echo "Truncated length: " . strlen($data) .
"\n"; gzinflate($data);'
Expected result:
gzinflate() should return FALSE, without eating all memory
Actual result:
--
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
--
Edit this bug report at http://bugs.php.net/?id=42663&edit=1
#42663 [NEW]: gzinflate() try to allocate all memory with truncated $data
From: arnaud dot lb at gmail dot com
Operating system: Linux 2.6
PHP version: 5.2.4
PHP Bug Type: Zlib Related
Bug description: gzinflate() try to allocate all memory with truncated $data
Description:
gzinflate() try to allocate all memory with truncated $data:
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
Zlib version: 1.2.3.3
Reproduce code:
---
/tmp/php-5.2.4$ ./configure --disable-all --enable-cli --with-zlib && make
-j4
/tmp/php-5.2.4$ sapi/cli/php -d memory_limit=-1 -r '$data =
gzdeflate(file_get_contents("/tmp/yuicompressor-1.0.zip"), 9); echo
"Compressed length: " . strlen($data) . "\n"; gzinflate($data); $data =
substr($data, 0, 65535); echo "Truncated length: " . strlen($data) . "\n";
gzinflate($data);'
Expected result:
gzinflate() should return FALSE, without eating all memory
Actual result:
--
Fatal error: Out of memory (allocated 1074003968) (tried to allocate
2147450880 bytes) in Command line code on line 1
--
Edit bug report at http://bugs.php.net/?id=42663&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42663&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42663&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42663&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42663&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42663&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42663&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42663&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42663&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42663&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42663&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42663&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42663&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42663&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42663&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42663&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42663&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42663&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42663&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42663&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42663&r=mysqlcfg
#35793 [Com]: General error: 2050
ID: 35793 Comment by: arnaud dot lb at gmail dot com Reported By: deadman_great at mail dot ru Status: No Feedback Bug Type: PDO related Operating System: RH Fedora Core 2 PHP Version: 5CVS-2005-12-25 (snap) Assigned To: Wez New Comment: I have the same problem with php-5.2, mysql-5.0.26 on Debian system. Fixed the problem using the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY option. It seems that closeCursor() does not works properly. Previous Comments: [2006-11-01 15:11:55] richard at phase dot org $this->pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true); (a suggested fix above) fails on 5.2.RC6 as PDO::ATTR_EMULATE_PREPARES appears no longer to be defined. [2006-10-17 01:15:58] michal dot vrchota at seznam dot cz I think I have solved this problem: You have to free your PDOStatement instance Of course You have to call closeCursor() method to be sure, but if you have more queries and still using same identifier ($stmt) you have free it by passing NULL value Sample: $stmt->closeCursor(); $stmt = NULL; // now it works ;) [2006-10-16 14:46:09] andiesPostfach at web dot de The Problem still exists in PHP 5.2 RC5 !! System ist SUSE-Linux 9.3 MySQL Version 5.0.18 [2006-08-23 11:14:46] tjerk dot meesters at gmail dot com This problem still occurs with: PHP-5.1.5 MySQL-5.0.22 Linux platform Using PDO::ATTR_EMULATE_PREPARES doesn't resolve the problem, the error message remains: SQLSTATE[HY000]: General error: 2050 Row retrieval was canceled by mysql_stmt_close() call [2006-08-01 20:52:55] mass at carlsoft dot net Can we at least change this error message to be more specific, perhaps suggesting to emulate prepares (as wez @ php . net suggested)? or better yet make the emulation default? 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/35793 -- Edit this bug report at http://bugs.php.net/?id=35793&edit=1
