#49443 [NEW]: Special characters in section name breaks parse_ini_file
From: eric dot caron at gmail dot com
Operating system: N/A
PHP version: 5.3.0
PHP Bug Type: Filesystem function related
Bug description: Special characters in section name breaks parse_ini_file
Description:
PHP 5.3 changes to parse_ini_*() functions breaks scripts that have
special characters, {}|&~![()^", in the section titles. (Previous versions
worked, which I assume was proper behavior because section titles can have
those characters according to community understood INI standards).
There is no documentation stating that special characters can not be used
in section titles. While the INI_SCANNER_RAW parameter provides an opening
for a workaround for this solution, to be useful, the characters
{}|&~![()^" should be usable in section titles (not to be confuse with
keys, where they shouldn't be used).
Reproduce code:
---
Array
(
[Crawler] => 1
)
[Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)] => Array
(
[Crawler] => 1
)
)
Actual result:
--
Warning: parse error, expecting `']'' in FOOFCCA.tmp on line 4 in
parseBug.php on line 10
--
Edit bug report at http://bugs.php.net/?id=49443&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49443&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49443&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49443&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49443&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49443&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49443&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49443&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49443&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49443&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49443&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49443&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49443&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49443&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49443&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49443&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49443&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49443&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49443&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49443&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49443&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49443&r=mysqlcfg
#49443 [Bgs]: Special characters in section name breaks parse_ini_file
ID: 49443
User updated by: eric dot caron at gmail dot com
Reported By: eric dot caron at gmail dot com
Status: Bogus
Bug Type: Filesystem function related
Operating System: N/A
PHP Version: 5.3.0
New Comment:
The raw option, though, does not convert the string "true"/"false" to
its boolean.
If you change the print_r in my demo code to a var_dump:
*** PHP 5.2 RESULTS ***
array(2) {
["Ask"]=>
array(1) {
["Crawler"]=>
string(1) "1"
}
["Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)"]=>
array(1) {
["Crawler"]=>
string(1) "1"
}
}
*** PHP 5.3 RESULTS ***
array(2) {
["Ask"]=>
array(1) {
["Crawler"]=>
string(4) "true"
}
["Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)"]=>
array(1) {
["Crawler"]=>
string(4) "true"
}
}
Previous Comments:
[2009-09-02 19:12:19] j...@php.net
The raw option is just for this and it's NOT a workaround but exactly
the thing you're supposed to use here. No bug here.
[2009-09-02 15:52:10] eric dot caron at gmail dot com
Description:
PHP 5.3 changes to parse_ini_*() functions breaks scripts that have
special characters, {}|&~![()^", in the section titles. (Previous
versions worked, which I assume was proper behavior because section
titles can have those characters according to community understood INI
standards).
There is no documentation stating that special characters can not be
used in section titles. While the INI_SCANNER_RAW parameter provides an
opening for a workaround for this solution, to be useful, the characters
{}|&~![()^" should be usable in section titles (not to be confuse with
keys, where they shouldn't be used).
Reproduce code:
---
Array
(
[Crawler] => 1
)
[Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)] => Array
(
[Crawler] => 1
)
)
Actual result:
--
Warning: parse error, expecting `']'' in FOOFCCA.tmp on line 4 in
parseBug.php on line 10
--
Edit this bug report at http://bugs.php.net/?id=49443&edit=1
#49443 [Bgs]: Special characters in section name breaks parse_ini_file
ID: 49443
User updated by: eric dot caron at gmail dot com
Reported By: eric dot caron at gmail dot com
Status: Bogus
Bug Type: Filesystem function related
Operating System: N/A
PHP Version: 5.3.0
New Comment:
The logic difficulty is better showcased with "false" values.
*** PHP 5.2 (GOOD) ***
array(2) {
["Ask"]=>
array(1) {
["Crawler"]=>
string(0) ""
}
["Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)"]=>
array(1) {
["Crawler"]=>
string(1) "1"
}
}
*** PHP 5.3 (BAD) ***
array(2) {
["Ask"]=>
array(1) {
["Crawler"]=>
string(5) "false"
}
["Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)"]=>
array(1) {
["Crawler"]=>
string(4) "true"
}
}
Previous Comments:
[2009-09-02 19:49:13] eric dot caron at gmail dot com
The raw option, though, does not convert the string "true"/"false" to
its boolean.
If you change the print_r in my demo code to a var_dump:
*** PHP 5.2 RESULTS ***
array(2) {
["Ask"]=>
array(1) {
["Crawler"]=>
string(1) "1"
}
["Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)"]=>
array(1) {
["Crawler"]=>
string(1) "1"
}
}
*** PHP 5.3 RESULTS ***
array(2) {
["Ask"]=>
array(1) {
["Crawler"]=>
string(4) "true"
}
["Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)"]=>
array(1) {
["Crawler"]=>
string(4) "true"
}
}
--------------------
[2009-09-02 19:12:19] j...@php.net
The raw option is just for this and it's NOT a workaround but exactly
the thing you're supposed to use here. No bug here.
[2009-09-02 15:52:10] eric dot caron at gmail dot com
Description:
PHP 5.3 changes to parse_ini_*() functions breaks scripts that have
special characters, {}|&~![()^", in the section titles. (Previous
versions worked, which I assume was proper behavior because section
titles can have those characters according to community understood INI
standards).
There is no documentation stating that special characters can not be
used in section titles. While the INI_SCANNER_RAW parameter provides an
opening for a workaround for this solution, to be useful, the characters
{}|&~![()^" should be usable in section titles (not to be confuse with
keys, where they shouldn't be used).
Reproduce code:
---
Array
(
[Crawler] => 1
)
[Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)] => Array
(
[Crawler] => 1
)
)
Actual result:
--
Warning: parse error, expecting `']'' in FOOFCCA.tmp on line 4 in
parseBug.php on line 10
--
Edit this bug report at http://bugs.php.net/?id=49443&edit=1
#27777 [Com]: basic authentication broken
ID: 2 Comment by: eric dot caron at gmail dot com Reported By: mikx at mikx dot de Status: No Feedback Bug Type: SOAP related Operating System: Windows XP Pro PHP Version: 5.0.0RC1 New Comment: Still having this problem as of PHP 5.3.2-dev on my Linux boxes. PHP 5.3.1 on my Windows box did not have this problem. Previous Comments: [2009-05-07 13:32:47] Christian dot Reingruber at gmail dot com still a problem in 5.2.8 i guess... any ideas? [2008-06-19 14:16:33] trippinbilly25 at gmail dot com This is still a problem in 5.2.6. [2007-04-05 15:21:57] jgarcia at tdg-i dot com Bug still open in PHP 5.1.2 Found information from user post: Arjan van Bentem 12-Aug-2005 08:31 When using HTTP basic authentication, PHP will only send the credentials when invoking the service, not when fetching the WSDL. [2006-05-19 09:01:20] peter at adkins dot nl This is still a problem with 5.1.1. [2005-04-12 14:33:55] lobbin at localhost dot nu This is still a problem. The soap-extension is not able to get a password-protected wsdl even though the credentials are provided and used when posting the real soap-request. 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/2 -- Edit this bug report at http://bugs.php.net/?id=2&edit=1
Bug #48607 [Com]: fwrite() doesn't check reply from ftp server before exiting
Edit report at http://bugs.php.net/bug.php?id=48607&edit=1
ID: 48607
Comment by: eric dot caron at gmail dot com
Reported by:karachi at mail dot ru
Summary:fwrite() doesn't check reply from ftp server before
exiting
Status: Verified
Type: Bug
Package:Streams related
Operating System: FreeBSD
PHP Version:5.2.10
Block user comment: N
New Comment:
I can reproduce this on my CentOS 5 box running PHP 5.3.3. It occurs
when sending a large file across a slow network. Wireshark reports
getting the QUIT before the FTP server sends TRANSFER COMPLETE. Adding
the sleep before the close fixes the issue.
Reproduce code:
--
wrapperdata;
-
+
+ /* For write modes close data stream first to signal EOF to
server */
+ if (strpbrk(stream->mode, "wa+")) {
+ if (stream && controlstream) {
+ php_stream_close(stream);
+ stream = NULL;
+
+ result = GET_FTP_RESULT(controlstream);
+ if (result != 226 && result != 250) {
+ php_error_docref(NULL TSRMLS_CC,
E_WARNING, "FTP server reports %s", tmp_line);
+ ret = EOF;
+ }
+ } else {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Broken streams to FTP server");
+ ret = EOF;
+ }
+ }
+
if (controlstream) {
php_stream_write_string(controlstream, "QUIT\r\n");
php_stream_close(controlstream);
- stream->wrapperdata = NULL;
+ if (stream)
+ stream->wrapperdata = NULL;
}
- return 0;
+ return ret;
}
Also make sure that I or somebody else afterwards really does not call
something on/in the streams after closing and probably freeing them
(didn't really check out the internals of _php_stream_free() et al. --
and the control stream sort of being embedded within the data stream
here, but me having to close them the other way round due to the FTP
protocol, didn't really help in understanding what might go wrong
somewhere deep in your API). But as I said, for me the patch works.
[2009-12-17 20:17:41] b dot vontobel at meteonews dot ch
Just stumbled across this (still in 5.3.1) a few days ago, trying to
transmit data to three different FTP servers. One of the servers
_never_ got a file, one got files, but in 9 out of 10 runs the last
part of the files was cut off, only the last one got the files intact
in about 8 of 10 runs (with the others also corrupted).
I didn't find this bug report at first and so I opened up the PHP
source for the first time in my life and was rather shocked: There's
really no way that write operations using the ftp stream wrapper ever
could've worked. If it works, it's out of pure luck. Was this never
tested?
The problem is, that FTP (see RFC959) uses the tear down of the
_data_stream_ as its EOF marker. What this code does on the other
hand, is just send a QUIT on the control stream and then tear down
that one. So from the perspective of the FTP server it looks like an
abort (transmission still in progress, but control channel lost). Now
it just depends on the implementation of the server and sometimes some
random timing issues (which TCP close is handled first) what the
outcome is: Some FTP servers just annihilate everything that was
transmitted so far (realizing it was a client abort during
transmission or a network glitch - and the file probably corrupted
anyway), others keep what they got so far. Only sometimes (out of
luck) they maybe get the close on the data stream first and are still
able to send the okay on the control stream (which is not handled by
the current code, but what sjoerd added in his first idea of a patch).
Now, I'm not really familiar with the PHP stream wrapper API at all,
but below is my imagination of how this code could be made to work (I
actually run it on a 30+ vhosts cluster): If we were only reading from
the stream, it's probably okay to not care about a clean shutdown
(especially because in this code part nothing really tells us reliably
what exact state the FTP session is in). But if we have written to the
FTP server, we MUST close the data stream first, then wait for a
confirmation from the server - and only then both of us know, the data
was sent completely:
--- php-5.3.1/ext/standard/ftp_fopen_wrapper.c 2008-12-31
11:15:49.0 +
+++ php-5.3.1-ftp_fopen_wrapper_patch/ext/standard/ftp_fopen_wr
#42491 [Com]: Segmentation fault during install-pear-installer
ID: 42491 Comment by: eric dot caron at gmail dot com Reported By: bernard dot prevosto at ifremer dot fr Status: Feedback Bug Type: Compile Failure Operating System: solaris 5.8 PHP Version: 5.2.4 New Comment: I'm having a very similar result on a system that's running 5.2.2 fine. Except I don't get to the segfault point - it goes to "Installing PEAR environment:" and then will just sit there - I've waiting hours. If I kill the process at this point, PHP will load/execute but the processes never die. Since I'm not getting a segfault, how can I provide useful debugging information to you? Previous Comments: [2007-08-31 11:22:45] [EMAIL PROTECTED] 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. [2007-08-31 10:56:22] bernard dot prevosto at ifremer dot fr Description: Make install of php-5.2.4 seems not to work our servers. Configure goes well, make seems to work also, but we've got a segmentation fault during make install. Everything was OK with PHP 5.1.6 . (it's the sams problem that Bug #40474) Reproduce code: --- ./configure --prefix=/home/services/logiciels/compilateurs/php-5.2.4 --with-ldap=/home/services/bibli/openldap --with-mysql=/home/services/bibli/mysql --with-pgsql=/home/services/logiciels/compilateurs/php-5.2.4/bases/pgsql --with-oci8=/home/services/logiciels/compilateurs/php-5.2.4/bases/ora920 --with-gd --with-zlib-dir=/home/services/bibli/zlib --enable-zip --with-jpeg-dir=/home/services/bibli/jpeglib --with-png-dir=/home/services/bibli/pnglib --with-gettext=/home/services/logiciels/gettext --with-libxml-dir=/home/services/bibli/xml2lib --with-iconv --enable-calendar --enable-mbstring=all --enable-exif --disable-pdo --with-config-file-path=/home/services/logiciels/compilateurs/php-5.2.4 #(it's OK) make (it's OK) make install (segmentation fault) Expected result: no segmentation fault Actual result: -- louet>47% make install Installing PHP SAPI module: cgi Installing PHP CGI binary: /home/services/logiciels/compilateurs/php-5.2.4/bin/ Installing PHP CLI binary: /home/services/logiciels/compilateurs/php-5.2.4/bin/ Installing PHP CLI man page: /home/services/logiciels/compilateurs/php-5.2.4/man/man1/ Installing build environment: /home/services/logiciels/compilateurs/php-5.2.4/lib/php/build/ Installing header files: /home/services/logiciels/compilateurs/php-5.2.4/include/php/ Installing helper programs: /home/services/logiciels/compilateurs/php-5.2.4/bin/ program: phpize program: php-config Installing man pages: /home/services/logiciels/compilateurs/php-5.2.4/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /home/services/logiciels/compilateurs/php-5.2.4/lib/php/ Segmentation Fault gmake[1]: *** [install-pear-installer] Error 139 gmake: *** [install-pear] Error 2 - I have the same problem whith: louet>138% sapi/cli/php pear/install-pear-nozlib.phar Segmentation Fault -- Edit this bug report at http://bugs.php.net/?id=42491&edit=1
#37276 [Com]: problems witch $_POST array
ID: 37276 Comment by: eric dot caron at gmail dot com Reported By: puovils at gmail dot com Status: Open Bug Type:*General Issues PHP Version: 5.1.3 New Comment: I really don't mean to be "chicken little", but isn't this serious enough that it warrants 5.1.3.1 and/or a recall of 5.1.3? Its happening on all the linux boxes I've tried. Previous Comments: [2006-05-02 21:25:17] mjackson at datahost dot com To add to puovils at gmail dot com's comments, you get the expected results if the form is submitted via GET. [2006-05-02 14:17:39] puovils at gmail dot com Description: problems witch $_POST array Reproduce code: --- "; print_r($_POST); echo ""; ?> test Expected result: Array ( [masivasid] => Array ( [id_1] => Nzzz1 [id_2] => Nzzz2 ) ) Actual result: -- Array ( [masivasid] => Array ( [id_1] => Nzzz1 [id_2] => Array ( [id_1] => Nzzz2 ) ) ) -- Edit this bug report at http://bugs.php.net/?id=37276&edit=1
Bug #48607 [Com]: fwrite() doesn't check reply from ftp server before exiting
Edit report at http://bugs.php.net/bug.php?id=48607&edit=1
ID: 48607
Comment by: eric dot caron at gmail dot com
Reported by:karachi at mail dot ru
Summary:fwrite() doesn't check reply from ftp server before
exiting
Status: Closed
Type: Bug
Package:FTP related
Operating System: FreeBSD
PHP Version:5.2.10
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
What are the steps involved in having this bug moved from SVN into the
current 5.3.x branch? It is a bug fix, no new features are added nor
does any functionality change, yet two 5.3.x releases have come out
since this bug was marked CLOSED and they don't include this fix.
Previous Comments:
[2010-12-13 17:53:37] il...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2010-12-13 17:53:28] il...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=306342
Log: Fixed bug #48607 (fwrite() doesn't check reply from ftp server
before exiting)
[2010-10-14 19:41:54] eric dot caron at gmail dot com
I can reproduce this on my CentOS 5 box running PHP 5.3.3. It occurs
when sending a large file across a slow network. Wireshark reports
getting the QUIT before the FTP server sends TRANSFER COMPLETE. Adding
the sleep before the close fixes the issue.
Reproduce code:
--
wrapperdata;
-
+
+ /* For write modes close data stream first to signal EOF to
server */
+ if (strpbrk(stream->mode, "wa+")) {
+ if (stream && controlstream) {
+ php_stream_close(stream);
+ stream = NULL;
+
+ result = GET_FTP_RESULT(controlstream);
+ if (result != 226 && result != 250) {
+ php_error_docref(NULL TSRMLS_CC,
E_WARNING, "FTP server reports %s", tmp_line);
+ ret = EOF;
+ }
+ } else {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING,
"Broken streams to FTP server");
+ ret = EOF;
+ }
+ }
+
if (controlstream) {
php_stream_write_string(controlstream, "QUIT\r\n");
php_stream_close(controlstream);
- stream->wrapperdata = NULL;
+ if (stream)
+ stream->wrapperdata = NULL;
}
- return 0;
+ return ret;
}
Also make sure that I or somebody else afterwards really does not call
something on/in the streams after closing and probably freeing them
(didn't really check out the internals of _php_stream_free() et al. --
and the control stream sort of being embedded within the data stream
here, but me having to close them the other way round due to the FTP
protocol, didn't really help in understanding what might go wrong
somewhere deep in your API). But as I said, for me the patch works.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=48607
--
Edit this bug report at http://bugs.php.net/bug.php?id=48607&edit=1
