Bug #16122 Updated: FileUpload: $userfile can work, but $_REQUEST["userfile"] can't
ID: 16122 Updated by: [EMAIL PROTECTED] -Summary: FileUpload: $userfile can work, but $_REQUEST["userfile"] can't Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Win2000pro + IIS5 PHP Version: 4.1.1 New Comment: Use $_FILES['userfile']['tmp_name']. Also, read this page: http://www.php.net/manual/en/features.file-upload.php Not a bug. Previous Comments: [2002-03-17 00:54:48] [EMAIL PROTECTED] move_uploaded_file() also has same problem! [2002-03-17 00:16:25] [EMAIL PROTECTED] when handling upload files (use the example in the PHP manual) is_upload_file($userfile) returns true but if I use is_upload_file($_REQUEST["userfile"]), it returns false $userfile = $_REQUEST["userfile"], isn't it ? -- Edit this bug report at http://bugs.php.net/?id=16122&edit=1
Bug #16122 Updated: FileUpload: $userfile can work, but $_REQUEST["userfile"] can't
ID: 16122 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Win2000pro + IIS5 PHP Version: 4.1.1 New Comment: move_uploaded_file() also has same problem! Previous Comments: [2002-03-17 00:16:25] [EMAIL PROTECTED] when handling upload files (use the example in the PHP manual) is_upload_file($userfile) returns true but if I use is_upload_file($_REQUEST["userfile"]), it returns false $userfile = $_REQUEST["userfile"], isn't it ? -- Edit this bug report at http://bugs.php.net/?id=16122&edit=1
Bug #16122: FileUpload: $userfile can work, but $_REQUEST["userfile"] can't
From: [EMAIL PROTECTED] Operating system: Win2000pro + IIS5 PHP version: 4.1.1 PHP Bug Type: Scripting Engine problem Bug description: FileUpload: $userfile can work, but $_REQUEST["userfile"] can't when handling upload files (use the example in the PHP manual) is_upload_file($userfile) returns true but if I use is_upload_file($_REQUEST["userfile"]), it returns false $userfile = $_REQUEST["userfile"], isn't it ? -- Edit bug report at http://bugs.php.net/?id=16122&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16122&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16122&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16122&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16122&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16122&r=support Expected behavior: http://bugs.php.net/fix.php?id=16122&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16122&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16122&r=submittedtwice
Bug #15156 Updated: apache segmentation fault (11) with php4
ID: 15156 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: RedHat Linux, 2.4.2 kernel PHP Version: 4.1.1 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-02-02 19:08:22] [EMAIL PROTECTED] > > AddType application/x-httpd-php .php4 .php3 .phtml .php > AddType application/x-httpd-php-source .phps > > > # The following is for PHP3: > > AddType application/x-httpd-php3 .php3 > AddType application/x-httpd-php3-source .phps > > > # The following is for PHP/FI (PHP2): > > AddType application/x-httpd-php .phtml > You *CANNOT* specify the same extension for PHP4/PHP3/PHPFI. Just don't do that, then it should work. We cannot anything for it, probably. (i.e. It's simply does not work and there may not be good way to prevend segfault for such configuration) [2002-02-01 20:10:20] [EMAIL PROTECTED] I did as you suggested. New apache and apache-devel rpms. Then installed PHP 4.1.1 All is well regarding segmentation faults. However, in order to get apache to process the embedded php code, I had to slightly modify the httpd.conf file. This was the code that didn't work: AddType application/x-httpd-php .php4 .php3 .phtml .php AddType application/x-httpd-php-source .phps # The following is for PHP3: AddType application/x-httpd-php3 .php3 AddType application/x-httpd-php3-source .phps # The following is for PHP/FI (PHP2): AddType application/x-httpd-php .phtml I moved the AddType directives outside of the block and now it works. Thanks for your help! [2002-02-01 00:31:20] [EMAIL PROTECTED] I suggest you to install from scrach (including all config files related) Make sure you do "rpm -e" for all apache/php related package including -devel one. Delete or move all httpd.conf/php.ini. If you still have segfault problem, report it again. [2002-01-31 18:55:54] [EMAIL PROTECTED] In spite of my prior 'make clean' commands, I found that copies of libphp3.so and libphp4.so were present on my system. I deleted these files and reinstalled PHP 4.1.1 from a fresh tarball distribution (configuration options as before). I also scrutinized my httpd.conf file and found that 'LoadModule libphp4.so' appeared twice, each with a different path. In order to satisfy apache, I had previously created a symbolic link from the second directory to modules/libphp4.so. I subsequently deleted the symbolic link and the Apache directive that refered to it. I continue to have the problems but there are some differences. The server starts fine. Documents with .html or .php extensions fail to load in the browser and result in a child process segmentation fault in the error_log. Occasionally, one browser request results in multiple child seg. faults. I tried to get a backtrace but strangely, when I run httpd with the -X flag, the server does not crash. However, PHP code is not processed. The core file is nowhere to be found. Incidentally, commenting out the AddModule directive: ... LoadModule php4_modulemodules/libphp4.so ... # AddModule mod_php4.c ... restores functionality to the server (without PHP enabled). Scripts in the cgi-bin directory seem to work fine and text documents (with .txt extensions) load fine from the html directory. Any advice? [2002-01-30 14:29:33] [EMAIL PROTECTED] Sorry if this is a stupid question but how do I turn off the xbit hack directive? Here are the answers to your questions: 1) I followed directions for an Apache module installation. If PHP4 is installed as a CGI version as well, then I am not aware of it. How can I confirm that the CGI version is not installed? 2) PHP3 was installed on this machine as part of the RedHat 7.1 distribution. I removed it (rpm -e php) prior to installing PHP4. Should I check for some remnant of the previous installation that might be causing a conflict? 3) Here are the relevant lines from my httpd.conf file AddType application/x-httpd-php .php4 .php3 .phtml .php AddType application/x-httpd-php-source .phps # The following is for PHP3: AddType application/x-httpd-php3 .php3 AddType application/x-httpd-php3-source .phps # The following is for PHP
Bug #14880 Updated: _SESSION will NOT automatically register it as a session variable
ID: 14880
Updated by: [EMAIL PROTECTED]
-Reported By: [EMAIL PROTECTED]
+Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Session related
Operating System: Debian 3.0 (Woody)
PHP Version: 4.1.0
New Comment:
Your PHP is too old, try current CVS version.
If you still have the problem, could you open _new_ bug report? (Since
the cause would be differ from originally reported)
Previous Comments:
[2002-03-16 19:17:19] [EMAIL PROTECTED]
I am running 4.2.0-dev also and $_SESSION is not stored properly i.e.
not accessible after it has been set.
e.g.
";
$_SESSION["foo"] = "foo is registered";
}
?>
so first time through, it should set it - subsequent reloads it should
be already set?
[2002-02-14 02:31:57] [EMAIL PROTECTED]
I've looked at the (updated) documentation.
--snip
If you are using $HTTP_SESSION_VARS/$_SESSION, do not use
session_register(), session_is_registered() and session_unregister()
unless you know internal of session module.
--snap
that's it!
thx yohgaki
btw. the following works
session_start();
$_SESSION["foo"] = "foo is registered";
if ($_SESSION["foo"]){
echo $_SESSION["foo"];
}else{
echo "foo is not registered";
}
[2002-02-03 20:05:39] [EMAIL PROTECTED]
To reporter: Just a reminder. Please report the result when you check
[2002-01-13 12:31:29] [EMAIL PROTECTED]
I tried both. (files/mm)
I killed my dev-system and I'm to busy to fix it. I'm out for a month.
(I have exams and I must learn!)
Thanks for your patience.
[2002-01-12 21:05:53] [EMAIL PROTECTED]
What is your session save handler? mm?
If so, you *MUST* use session_module_name() before starting session to
use mm save handler for now. (There is bug in module loading It's a
known issue ;) For some reason, mm save hanlder stopped working for me
recently :(
Anyway. Here is my configure.
'./configure' \
'--with-apxs' \
'--without-mysql' \
'--with-bz2' \
'--with-crack=/usr/local' \
'--with-curl' \
'--with-ftp' \
'--with-iconv' \
'--with-mhash' \
'--with-mcrypt' \
'--with-msession' \
'--with-mm' \
'--with-openssl' \
'--with-pgsql' \
'--with-regex=system' \
'--with-zlib' \
'--with-dom' \
'--with-dom-xslt' \
'--with-snmp' \
'--with-gd' \
'--enable-gd-native-ttf' \
'--with-freetype-dir=/usr' \
'--with-jpeg-dir=usr' \
'--with-png-dir=/usr' \
'--with-xpm-dir=/usr/X11R6' \
'--enable-ctype' \
'--enable-shmop' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sockets' \
'--enable-mbstring' \
'--enable-mbstr-enc-trans' \
'--enable-mbregex' \
'--enable-memory-limit' \
'--enable-wddx' \
'--enable-mailparse' \
'--with-xml' \
'--with-xmlprc' \
'--enable-debug' \
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/14880
--
Edit this bug report at http://bugs.php.net/?id=14880&edit=1
Bug #16121: fsockopen can't handle unix sockets created in abstract namespace
From: [EMAIL PROTECTED] Operating system: any PHP version: 4.0.6 PHP Bug Type: Sockets related Bug description: fsockopen can't handle unix sockets created in abstract namespace fsockopen can't handle unix sockets created in abstract namespace (unix sockets with the associated pathname starting with '\0'; see UNIX(4) of the 'Linux Programmer's Manual' for details). This bug is 'caused since the implementation of fsockopen in PHP 4.0.6 uses strlcpy to copy from $hostname to unix_addr.sun_path without looking at the first byte of $hostname (fsock.c, line 240). One possible solution would be to change line 240 from strlcpy(unix_addr.sun_path, (*args[0])->value.str.val, sizeof(unix_addr.sun_path)); to pathofs = ((*args[0])->value.str.val[0] ? 0 : 1); strlcpy(unix_addr.sun_path + pathofs, (*args[0])->value.str.val + pathofs, sizeof(unix_addr.sun_path) - pathofs); where pathofs would be of type "size_t". Another solution avoiding the ugly '\0' byte would be to introduce separate scheme prefixes like "file:" and "abstract:" for UNIX domain sockets. Ciao, Mathias -- Edit bug report at http://bugs.php.net/?id=16121&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16121&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16121&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16121&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16121&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16121&r=support Expected behavior: http://bugs.php.net/fix.php?id=16121&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16121&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16121&r=submittedtwice
Bug #16102 Updated: >1 session variables not getting set correctly
ID: 16102 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Session related Operating System: Windows 2000/XP PHP Version: 4.1.2 New Comment: Here's a pretty simple test case, hopefully it's the same problem: index.php Test Home Page '; echo 'testtwo = '.$_SESSION['testtwo'].''; ?> Go to test test.php Untitled '; echo 'testtwo = '.$_SESSION['testtwo']; ?> Output from index.php: testone = 1 testtwo = 2 and the link Output from test.php after clicking on the link: Warning: Undefined index: testone in c:\htdocs\ebbs\test.php on line 9 testone = Warning: Undefined index: testtwo in c:\htdocs\ebbs\test.php on line 10 testtwo = Hopefully everything is valid, but things had been working fine prior to upgrading to 4.1.2 from 4.1.1. Previous Comments: [2002-03-16 00:06:27] [EMAIL PROTECTED] This will be fixed in 4.2.0, probably. [2002-03-15 23:39:48] [EMAIL PROTECTED] I am having a similar problem. It seems that POST variables are not getting set. It works in 4.1.1, and in the version of 4.1.2 available at http://www.zend.com/zend/week/week77.php, but not in 4.1.2 from http://www.php.net/downloads.php, nor in the version of 4.1.2 available from http://www.php4win.com/builds/latest-build.php. [2002-03-15 14:52:17] [EMAIL PROTECTED] The script below works fine on PHP 4.1.1, but fails on 4.1.2. The script sets two session variables. Only the most recent variable seems to get set, with the previous variable getting reset. -Script- $varValue) echo "$varKey => $varValue"; ?> --Script End--- The script should be saved as sesstest.php The modules configured are GD and XSLT If you need more information, please contact me. -- Martin -- Edit this bug report at http://bugs.php.net/?id=16102&edit=1
Bug #16114 Updated: fputs doesn't send all data
ID: 16114
Updated by: [EMAIL PROTECTED]
-Summary: fputs doesn't send all data
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Sockets related
Operating System: Windows 2000 AS
PHP Version: 4.1.1
New Comment:
Have you tried fflush($p) before you fclose()?
Previous Comments:
[2002-03-16 15:16:57] [EMAIL PROTECTED]
A few months ago, I was doing transfers using socket functions, it all
worked fine(php 4.0.4 or php 4.0.5).
I code something like this:
$p = fsockopen( $url, $port );
if (!$p) die('Cannot connect');
$l = fputs( $p, $data );
fclose( $p );
With this I sent up to 5MBs to a server. Now, the web server's
administrator has upgrade to 4.1.1. The php.ini file has:
post_max_size=10M
upload_max_filesize=5M
The fact is that it works but doesn't sending large streams. I make a
test with a string of 100Kb of text, and the server received only
8Kb(and sometimes less).
I inserted a dead loop before fclose and still the server got the
client disconnection before de php_max_execution_time elapsed.
The same thing happens in php 4.0.6.
Manu.
--
Edit this bug report at http://bugs.php.net/?id=16114&edit=1
Bug #16120: PHP 4.1.2 and Vpopmail 5.2 will not compile together
From: [EMAIL PROTECTED] Operating system: Red Hat 7.2 PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: PHP 4.1.2 and Vpopmail 5.2 will not compile together I have confirmed this on 2 server both running red hat 7.2 it will also not compile in the current cvs version compile string LIBS="-lmcrypt -lltdl" ./configure --with-mysql=/usr --with-curl --with-apache=../apache_1.3.23/ --enable-wddx --enable-dbx --enable-track-vars --with-mcrypt --with-mhash --with-xml --with-OpenSSL=/usr --enable-bcmath --enable-calendar --enable-ftp --enable-sockets --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-tiff-dir=/usr/lib --with-vpopmail Output from make Making all in vpopmail make[2]: Entering directory `/usr/src/httpd/php-4.1.2/ext/vpopmail' make[3]: Entering directory `/usr/src/httpd/php-4.1.2/ext/vpopmail' gcc -I. -I/usr/src/httpd/php-4.1.2/ext/vpopmail -I/usr/src/httpd/php-4.1.2/main -I/usr/src/httpd/php-4.1.2 -I/usr/src/httpd/apache_1.3.23/src/include -I/usr/src/httpd/apache_1.3.23/src/os/unix -I/usr/src/httpd/php-4.1.2/Zend -I/usr/local/include -I/usr/include/mysql -I/home/vpopmail/include -I/usr/src/httpd/php-4.1.2/ext/xml/expat -I/usr/src/httpd/php-4.1.2/TSRM -g -O2 -c php_vpopmail.c && touch php_vpopmail.lo php_vpopmail.c:925:8: warning: extra tokens at end of #endif directive php_vpopmail.c: In function `zif_vpopmail_add_alias_domain': php_vpopmail.c:288: warning: passing arg 3 of `add_domain_assign' makes pointer from integer without a cast php_vpopmail.c:288: too few arguments to function `add_domain_assign' make[3]: *** [php_vpopmail.lo] Error 1 make[3]: Leaving directory `/usr/src/httpd/php-4.1.2/ext/vpopmail' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/httpd/php-4.1.2/ext/vpopmail' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/httpd/php-4.1.2/ext' make: *** [all-recursive] Error 1 -- Edit bug report at http://bugs.php.net/?id=16120&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16120&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16120&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16120&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16120&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16120&r=support Expected behavior: http://bugs.php.net/fix.php?id=16120&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16120&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16120&r=submittedtwice
Bug #14880 Updated: _SESSION will NOT automatically register it as a session variable
ID: 14880
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Session related
Operating System: Debian 3.0 (Woody)
PHP Version: 4.1.0
New Comment:
I am running 4.2.0-dev also and $_SESSION is not stored properly i.e.
not accessible after it has been set.
e.g.
";
$_SESSION["foo"] = "foo is registered";
}
?>
so first time through, it should set it - subsequent reloads it should
be already set?
Previous Comments:
[2002-02-14 02:31:57] [EMAIL PROTECTED]
I've looked at the (updated) documentation.
--snip
If you are using $HTTP_SESSION_VARS/$_SESSION, do not use
session_register(), session_is_registered() and session_unregister()
unless you know internal of session module.
--snap
that's it!
thx yohgaki
btw. the following works
session_start();
$_SESSION["foo"] = "foo is registered";
if ($_SESSION["foo"]){
echo $_SESSION["foo"];
}else{
echo "foo is not registered";
}
[2002-02-03 20:05:39] [EMAIL PROTECTED]
To reporter: Just a reminder. Please report the result when you check
[2002-01-13 12:31:29] [EMAIL PROTECTED]
I tried both. (files/mm)
I killed my dev-system and I'm to busy to fix it. I'm out for a month.
(I have exams and I must learn!)
Thanks for your patience.
[2002-01-12 21:05:53] [EMAIL PROTECTED]
What is your session save handler? mm?
If so, you *MUST* use session_module_name() before starting session to
use mm save handler for now. (There is bug in module loading It's a
known issue ;) For some reason, mm save hanlder stopped working for me
recently :(
Anyway. Here is my configure.
'./configure' \
'--with-apxs' \
'--without-mysql' \
'--with-bz2' \
'--with-crack=/usr/local' \
'--with-curl' \
'--with-ftp' \
'--with-iconv' \
'--with-mhash' \
'--with-mcrypt' \
'--with-msession' \
'--with-mm' \
'--with-openssl' \
'--with-pgsql' \
'--with-regex=system' \
'--with-zlib' \
'--with-dom' \
'--with-dom-xslt' \
'--with-snmp' \
'--with-gd' \
'--enable-gd-native-ttf' \
'--with-freetype-dir=/usr' \
'--with-jpeg-dir=usr' \
'--with-png-dir=/usr' \
'--with-xpm-dir=/usr/X11R6' \
'--enable-ctype' \
'--enable-shmop' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sockets' \
'--enable-mbstring' \
'--enable-mbstr-enc-trans' \
'--enable-mbregex' \
'--enable-memory-limit' \
'--enable-wddx' \
'--enable-mailparse' \
'--with-xml' \
'--with-xmlprc' \
'--enable-debug' \
[2002-01-11 09:08:22] [EMAIL PROTECTED]
Could you please post your configline?
I get rid of most of the configline => same outcome
'../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs' '--with-
regex=system' '--with-config-file-path=/etc/php4/apache' '--
disable-rpath' '--disable-debug' '--enable-memory-limit' '--
enable-trans-sid' '--with-pcre-regex=/usr' '--without-pgsql' '--
disable-static' '--with-layout=GNU' '--with-mm'
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/14880
--
Edit this bug report at http://bugs.php.net/?id=14880&edit=1
Bug #16119: Swapping two elements of an array
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.2 PHP Bug Type: Feature/Change Request Bug description: Swapping two elements of an array I must be getting old, but I cannot seem to find a function that swaps the data of two array entries. Like so: $ar[0] = "second"; $ar[1] = "first"; array_swap ($ar, 0, 1); I have not overlooked the sort functions, that is not what I am after. But I may have overlooked other possibilities. Searching for "swap" in the PHP .CHM (fairly recent) yielded no hits. -- Edit bug report at http://bugs.php.net/?id=16119&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16119&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16119&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16119&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16119&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16119&r=support Expected behavior: http://bugs.php.net/fix.php?id=16119&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16119&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16119&r=submittedtwice
Bug #8440 Updated: fopen on a url returns "success" as an error
ID: 8440
Updated by: [EMAIL PROTECTED]
-Summary: fopen on a url returns "success" as an error
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: HTTP related
Operating System: Debian Linux 2.2.14
PHP Version: 4.0.4pl1
New Comment:
You can try a snapshot from snaps.php.net, I beilieve it's fixed in the
PHP 4.2.x branch.
Derick
Previous Comments:
[2002-03-16 17:29:57] [EMAIL PROTECTED]
Warning:
fopen("ftp://ftp.edome.net/mirror/seriously/general/wallpapers/samwallpaper9_800x600.zip";,
"r") - Success in /home/serioussam/cgi-bin/files/admin/functions.php on
line 184
*groan* I get this error a lot, and it seems to be only from certain
servers, only some of the time. It's really driving me and my site's
users/admins crazy. Anyone know how to fix it? The file is obviously
there, and it happens for more than one server. I'm running PHP 4.1.2.
[2001-12-07 09:02:38] [EMAIL PROTECTED]
Its been awhile, reopen if still present, and you have a concrete
setup/example of how it fails
[2001-11-09 14:46:46] [EMAIL PROTECTED]
Reopened.
[2001-10-18 15:21:23] [EMAIL PROTECTED]
Any news on this yet?
[2001-04-27 22:09:34] [EMAIL PROTECTED]
I don't believe it has happened since the Apache MaxRequestsPerChild
was reduced. I shall suspend this until I have a chance to test more
thoroughly.
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/8440
--
Edit this bug report at http://bugs.php.net/?id=8440&edit=1
Bug #8440 Updated: fopen on a url returns "success" as an error
ID: 8440
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: HTTP related
Operating System: Debian Linux 2.2.14
PHP Version: 4.0.4pl1
New Comment:
Warning:
fopen("ftp://ftp.edome.net/mirror/seriously/general/wallpapers/samwallpaper9_800x600.zip";,
"r") - Success in /home/serioussam/cgi-bin/files/admin/functions.php on
line 184
*groan* I get this error a lot, and it seems to be only from certain
servers, only some of the time. It's really driving me and my site's
users/admins crazy. Anyone know how to fix it? The file is obviously
there, and it happens for more than one server. I'm running PHP 4.1.2.
Previous Comments:
[2001-12-07 09:02:38] [EMAIL PROTECTED]
Its been awhile, reopen if still present, and you have a concrete
setup/example of how it fails
[2001-11-09 14:46:46] [EMAIL PROTECTED]
Reopened.
[2001-10-18 15:21:23] [EMAIL PROTECTED]
Any news on this yet?
[2001-04-27 22:09:34] [EMAIL PROTECTED]
I don't believe it has happened since the Apache MaxRequestsPerChild
was reduced. I shall suspend this until I have a chance to test more
thoroughly.
[2001-04-27 21:56:00] [EMAIL PROTECTED]
Any example scripts? Works just fine for me with latest CVS.
--Jani
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/8440
--
Edit this bug report at http://bugs.php.net/?id=8440&edit=1
Bug #16117 Updated: php.h / ap_config.h conflict (XtOffsetOf)
ID: 16117 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Linux PHP Version: 4.1.2 New Comment: It's also defined in Zend/zend_ini.h Previous Comments: [2002-03-16 16:53:12] [EMAIL PROTECTED] php.h tries to redefine XtOffsetOf when you are compiling with apxs. It is already defined in Apache's ap_config.h. The offending lines are from about 339-343. Someone fix this! :P -- Edit this bug report at http://bugs.php.net/?id=16117&edit=1
Bug #16118: Request for new feature: textlen() or textlength()
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.2 PHP Bug Type: Feature/Change Request Bug description: Request for new feature: textlen() or textlength() It would be nice with a companion to strlen() that basically first did a strip_tags (all tags) and then a strlen(). Yes, I know I can write this function myself, but the same could be said for many function included in the "core" PHP library. -- Edit bug report at http://bugs.php.net/?id=16118&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16118&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16118&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16118&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16118&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16118&r=support Expected behavior: http://bugs.php.net/fix.php?id=16118&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16118&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16118&r=submittedtwice
Bug #16117: php.h / ap_config.h conflict (XtOffsetOf)
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: php.h / ap_config.h conflict (XtOffsetOf) php.h tries to redefine XtOffsetOf when you are compiling with apxs. It is already defined in Apache's ap_config.h. The offending lines are from about 339-343. Someone fix this! :P -- Edit bug report at http://bugs.php.net/?id=16117&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16117&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16117&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16117&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16117&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16117&r=support Expected behavior: http://bugs.php.net/fix.php?id=16117&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16117&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16117&r=submittedtwice
Bug #16116: MYSQL_UNIX_ADDR
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: MYSQL_UNIX_ADDR If you compile mysql with a specific .sock location, and then compile php with your local mysql libraries, php tries to redefine MYSQL_UNIX_ADDR. The problem lies in php_config.h. Basically, #define MYSQL_UNIX_ADDR "/var/run/mysql/mysql.sock" (that path probably isn't right, I already changed it on mine) should be #ifndef MYSQL_UNIX_ADDR #define MYSQL_UNIX_ADDR "/var/run/mysql/mysql.sock" #endif But I don't know how to fix whatever needs to be fixed so that this php_config.h, which seems to be a generated file, is generated like that. -- Edit bug report at http://bugs.php.net/?id=16116&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16116&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16116&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16116&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16116&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16116&r=support Expected behavior: http://bugs.php.net/fix.php?id=16116&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16116&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16116&r=submittedtwice
Bug #16115 Updated: readline prints errors if compiled along with apxs
ID: 16115 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Debian (Sid) Linux PHP Version: 4.0CVS-2002-03-16 New Comment: hmmm, I get the same with the ncurses extention (but not readline) Derick Previous Comments: [2002-03-16 15:18:51] [EMAIL PROTECTED] If you compile PHP with readline and apxs then every invocation of the CLI will print the following errors: PHP Warning: Function registration failed - duplicate name - readline in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_info in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_add_history in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_clear_history in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_list_history in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_read_history in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_write_history in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_completion_function in Unknown on line 0 PHP Warning: readline: Unable to register functions, unable to load in Unknown on line 0 In despite of these errors, everything (including readline) works fine. To be completely clear, this is my configure line: ./configure --with-readline --with-apxs=/usr/local/apache/bin/apxs Any other configure line (without apxs) seems to work fine. Note: only 4.3.0-dev (ok, 4.2.1-dev :) seems to be affected, 4.2.0-dev NOT. -- Edit this bug report at http://bugs.php.net/?id=16115&edit=1
Bug #15122 Updated: binary output
ID: 15122 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed -Bug Type: Output Control +Bug Type: Apache2 related Operating System: win xp pro corporate 2600 PHP Version: 4.1.1 New Comment: this symptoms is due to a bug in apache2 on windows. the browser says dns error after trying to load the page. this is not a php bug at all ! thx. piem. Previous Comments: [2002-03-16 15:41:43] [EMAIL PROTECTED] this symptoms is due to a bug in apache2 on windows. the browser says dns error after trying to load the page. this is not a php bug at all ! thx. piem. [2002-03-16 00:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-01-20 09:37:10] [EMAIL PROTECTED] I don't what makes you think this is a PHP problem and what are you trying to explain. I'll mark this bug report as "not a bug" unless you provide infomation that is surely a PHP problem :) [2002-01-20 04:48:12] [EMAIL PROTECTED] my server is up and running well. i've installed phpMyChat, it works great for me. it works also great for a friend of mine. but for most others tried ip, i get either : - a DNS error (even with the trailing slash) - strange ascii chars : this is an exemple of lynx output : ^ Error: illegal character number 0 Error: illegal character number 0 Line 112 ...Line 112, column 50: 10... $I30|$I30A$I30A$I30A$I30A ... 30|$I30A$I30A$I30A$I ...^ i'm using a web redirector like virtualhost.redirector.com. plz send me any feedback via mail. thx, piem. -- Edit this bug report at http://bugs.php.net/?id=15122&edit=1
Bug #15122 Updated: binary output
ID: 15122 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Output Control Operating System: win xp pro corporate 2600 PHP Version: 4.1.1 New Comment: this symptoms is due to a bug in apache2 on windows. the browser says dns error after trying to load the page. this is not a php bug at all ! thx. piem. Previous Comments: [2002-03-16 00:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-01-20 09:37:10] [EMAIL PROTECTED] I don't what makes you think this is a PHP problem and what are you trying to explain. I'll mark this bug report as "not a bug" unless you provide infomation that is surely a PHP problem :) [2002-01-20 04:48:12] [EMAIL PROTECTED] my server is up and running well. i've installed phpMyChat, it works great for me. it works also great for a friend of mine. but for most others tried ip, i get either : - a DNS error (even with the trailing slash) - strange ascii chars : this is an exemple of lynx output : ^ Error: illegal character number 0 Error: illegal character number 0 Line 112 ...Line 112, column 50: 10... $I30|$I30A$I30A$I30A$I30A ... 30|$I30A$I30A$I30A$I ...^ i'm using a web redirector like virtualhost.redirector.com. plz send me any feedback via mail. thx, piem. -- Edit this bug report at http://bugs.php.net/?id=15122&edit=1
Bug #16115: readline prints errors if compiled along with apxs
From: [EMAIL PROTECTED] Operating system: Debian (Sid) Linux PHP version: 4.0CVS-2002-03-16 PHP Bug Type: *Configuration Issues Bug description: readline prints errors if compiled along with apxs If you compile PHP with readline and apxs then every invocation of the CLI will print the following errors: PHP Warning: Function registration failed - duplicate name - readline in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_info in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_add_history in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_clear_history in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_list_history in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_read_history in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_write_history in Unknown on line 0 PHP Warning: Function registration failed - duplicate name - readline_completion_function in Unknown on line 0 PHP Warning: readline: Unable to register functions, unable to load in Unknown on line 0 In despite of these errors, everything (including readline) works fine. To be completely clear, this is my configure line: ./configure --with-readline --with-apxs=/usr/local/apache/bin/apxs Any other configure line (without apxs) seems to work fine. Note: only 4.3.0-dev (ok, 4.2.1-dev :) seems to be affected, 4.2.0-dev NOT. -- Edit bug report at http://bugs.php.net/?id=16115&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16115&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16115&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16115&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16115&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16115&r=support Expected behavior: http://bugs.php.net/fix.php?id=16115&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16115&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16115&r=submittedtwice
Bug #16114: fputs doesn't send all data
From: [EMAIL PROTECTED]
Operating system: Windows 2000 AS
PHP version: 4.1.1
PHP Bug Type: Sockets related
Bug description: fputs doesn't send all data
A few months ago, I was doing transfers using socket functions, it all
worked fine(php 4.0.4 or php 4.0.5).
I code something like this:
$p = fsockopen( $url, $port );
if (!$p) die('Cannot connect');
$l = fputs( $p, $data );
fclose( $p );
With this I sent up to 5MBs to a server. Now, the web server's
administrator has upgrade to 4.1.1. The php.ini file has:
post_max_size=10M
upload_max_filesize=5M
The fact is that it works but doesn't sending large streams. I make a test
with a string of 100Kb of text, and the server received only 8Kb(and
sometimes less).
I inserted a dead loop before fclose and still the server got the client
disconnection before de php_max_execution_time elapsed.
The same thing happens in php 4.0.6.
Manu.
--
Edit bug report at http://bugs.php.net/?id=16114&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16114&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16114&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16114&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16114&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16114&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16114&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16114&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16114&r=submittedtwice
Bug #15639 Updated: detecting end of UDP packets
ID: 15639
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: *Network Functions
Operating System: All
PHP Version: 4.1.1
New Comment:
It also says it should only be used in connected sockets.
Here is a working exemple from a porky sourcecode I have :
loop:
len = recvfrom(sock, data, 50, 0, (struct sockaddr *)&sai, &s_sai);
printf("%d bytes from %s:%d -
%s\n",len,inet_ntoa(sai.sin_addr),ntohs(sai.sin_port),data);
goto loop;
The default size is 50, if the UDP packet is < 50 (ie:42) it will print
: 42 bytes from 192.168.0.1:8000 - This is only a test. This is only a
test!!
So if you modify the recv call to a recvfrom call, it won't break TCP
and will make UDP work a better way.
Previous Comments:
[2002-03-16 12:16:29] [EMAIL PROTECTED]
My man page says that recv is identical to recvfrom with
a NULL from parameter, so I don't see how this can fix
it.
I still don't think this is technically possible over UDP.
If you can show me some real working C code where it works,
I will implement it.
[2002-02-21 20:07:45] [EMAIL PROTECTED]
In C, recvfrom() takes a length argument, but behaves with UDP like
fread should : "Reading stops when length bytes have been read or EOF
is reached, whichever comes first."
Using recvfrom() with length set to 4096 will get the 20 bytes packets
without blocking anything.
The bug has prolly something to do with the use of recv() versus
recvfrom().
[2002-02-20 22:42:53] [EMAIL PROTECTED]
I'll look into UDP sockets in PHP in more detail soon.
In the meantime, I'm not sure that what you are suggesting is possible,
since UDP is a connectionless protocol, how can we detect the end of a
packet/stream?
UDP is supposed to be used with known packet sizes.
If you can show me some C code where what you propose works, I'll
integrate it with the new PHP streams code.
--Wez.
[2002-02-20 07:02:31] [EMAIL PROTECTED]
In fact it's worst than that, setting the socket non-blocking makes
fread not working on unix/win.
[2002-02-20 06:41:24] [EMAIL PROTECTED]
It will kill Windows compatibility, fixing the functions is way better.
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/15639
--
Edit this bug report at http://bugs.php.net/?id=15639&edit=1
Bug #16113: Circulaire includes makes Apache hang.
From: [EMAIL PROTECTED] Operating system: Any? (Mine: Linux 2.4.13) PHP version: 4.1.2 PHP Bug Type: Scripting Engine problem Bug description: Circulaire includes makes Apache hang. Hello, Althought its the user responsibility to verify his scripts, my user did not have enough knowledge of PHP to be able to verify all his scripts and my Apache died. The problem? In short, i reproduced the problem by making 2 files: file1.php: http://host.name/file2.php";); ?> file2.php http://host.name/file1.php";); ?> When you open http://host.name/file1.php you will see an enormous amount of Apache childs. And apache hangs (it does not respond to new requests!). I know its the user his fault, but when you have a very complicated website this might happen because of bugs in your scripts. Because of this my Apache webserver died and I had to restart Apache to make it work again. Perhaps its a good idea to add somekind of check to prevent things like this? -- Edit bug report at http://bugs.php.net/?id=16113&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16113&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16113&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16113&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16113&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16113&r=support Expected behavior: http://bugs.php.net/fix.php?id=16113&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16113&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16113&r=submittedtwice
Bug #15639 Updated: detecting end of UDP packets
ID: 15639 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Network Functions Operating System: All PHP Version: 4.1.1 New Comment: My man page says that recv is identical to recvfrom with a NULL from parameter, so I don't see how this can fix it. I still don't think this is technically possible over UDP. If you can show me some real working C code where it works, I will implement it. Previous Comments: [2002-02-21 20:07:45] [EMAIL PROTECTED] In C, recvfrom() takes a length argument, but behaves with UDP like fread should : "Reading stops when length bytes have been read or EOF is reached, whichever comes first." Using recvfrom() with length set to 4096 will get the 20 bytes packets without blocking anything. The bug has prolly something to do with the use of recv() versus recvfrom(). [2002-02-20 22:42:53] [EMAIL PROTECTED] I'll look into UDP sockets in PHP in more detail soon. In the meantime, I'm not sure that what you are suggesting is possible, since UDP is a connectionless protocol, how can we detect the end of a packet/stream? UDP is supposed to be used with known packet sizes. If you can show me some C code where what you propose works, I'll integrate it with the new PHP streams code. --Wez. [2002-02-20 07:02:31] [EMAIL PROTECTED] In fact it's worst than that, setting the socket non-blocking makes fread not working on unix/win. [2002-02-20 06:41:24] [EMAIL PROTECTED] It will kill Windows compatibility, fixing the functions is way better. [2002-02-20 06:35:09] [EMAIL PROTECTED] What if you set the socket in non-blocking mode? Look for socket_set_blocking in the manual. 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/15639 -- Edit this bug report at http://bugs.php.net/?id=15639&edit=1
Bug #5865 Updated: fopen with ssl support
ID: 5865
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Feature/Change Request
Operating System: ANY
PHP Version: 4.0.1pl2
Assigned To: wez
New Comment:
Implemented in PHP 4.3.0.
Sorry it took so long :-)
Previous Comments:
[2001-08-12 15:40:32] [EMAIL PROTECTED]
It's in the pipeline.
Assigning to myself.
--Wez.
[2001-08-12 15:29:26] [EMAIL PROTECTED]
User Response:
While working on #5865, you could also add generic SSL socket support
to fsockopen,
something like
fsockopen("ssl://example.com", ...)
don't forget to add support for client certificates/keys, including
passing the password
to unlock 'em (ok, this would probably require a completely new
function).
for connecting to a single server, one solution is running a stunnel
daemon:
stunnel -c -d 127.0.0.1:1000 -r example.com:123 -p /certs/blah.pem
and then fsockopen()ing to that port;
however, this is both a security problem (anyone on the machine can
connect to that port)
and useless, if one wishes to connect to a host that is not known in
advance.
another option would be to allow php to talk to exec'd processes
(hopefully stunnel works
this way; it doesn't when piped), but this requires an extra process
per request which is
a resource hog. and, well, this is all in openssl already, so ...
[2000-07-31 08:18:14] [EMAIL PROTECTED]
reopened as the report clearly stated that curl
was not the desired option ...
[2000-07-31 01:44:58] [EMAIL PROTECTED]
You can use PHP's built-in CURL support in the latest CVS.
[2000-07-31 01:26:28] [EMAIL PROTECTED]
I would love to see fopen can "talk" to a SSL enabled server. This
feature is crucial for server-to-server secure
communication/automation. Currently I use curl to acheive this. Curl is
a ~1 MB beast, obviously this creates considerable startup costs.
--
Edit this bug report at http://bugs.php.net/?id=5865&edit=1
Bug #13522 Updated: openssl_seal always returns FALSE
ID: 13522
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: OpenSSL related
Operating System: SunOS 5.7
PHP Version: 4.0.6
New Comment:
Have you resolved this problem yet?
Previous Comments:
[2001-10-11 15:09:41] [EMAIL PROTECTED]
I *probably* could, but I really wouldn't want to put
RC on that machine. Also I don't think PHP version
is the problem - the function should work on
PHP 4 >= 4.0.4... it must be something in the
configuration.
Are there any scripts I could use to test if the
openssl extension is set up properly?
[2001-10-08 18:22:34] [EMAIL PROTECTED]
The same script works just fine for me with PHP 4.0.7RC3.
Could you try it out too?
http://www.php.net/~zeev/php-4.0.7RC3.tar.gz
--Wez.
[2001-10-08 12:42:10] [EMAIL PROTECTED]
Below is the *whole* script. The only output I get is
"There were errors". It can't seal the data, returning
FALSE, but no error messages are generated.
";
else{
echo "There were errors";
while ($text = openssl_error_string())
echo "$text ";
}
openssl_free_key($pk1);
openssl_free_key($pk2);
?>
[2001-10-05 16:29:39] [EMAIL PROTECTED]
Upgraded to 4.0.6, so now I can use the openssl_error_string()
function. However, I still don't see any errors generated
by openssl_seal(). Below is how I use it:
if (openssl_seal($data, $sealed, $ekeys, array($pk1,$pk2))) {
echo "Sealed: $sealed\n";
}
else{
echo "Could not seal data\n";
while ($text = openssl_error_string())
echo "$text \n";
}
This reports no errors. When I try to open the 'encrypted'
data, I do get some errors (I think these are expected):
error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type
is not 02
error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check
failed
[2001-10-03 08:57:46] [EMAIL PROTECTED]
Please try with PHP 4.0.6 or PHP 4.0.7RC3.
If you are still getting a false return, try using
the openssl_error_string() as mentioned in the online
manual.
--Wez.
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/13522
--
Edit this bug report at http://bugs.php.net/?id=13522&edit=1
Bug #15662 Updated: iptcembed FotoWare
ID: 15662 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Graphics related -Operating System: Windows 2000 +Operating System: All PHP Version: 4.1.1 New Comment: OS Previous Comments: [2002-02-21 12:31:19] [EMAIL PROTECTED] The function iptcembed only embed the iptc text in the beginning of the image file. Products from Fotoware (FotoStation, ColorFactory, Fotoweb, IndexManager) embed the iptc both at the beginning and at the end of the file. However FotoWare products as default reads the IPTC-info from the end. Therefore, if IPTC allready has been embeded from FotoWare, iptcembed can not modify the text in an order FotoWare will understand. -- Edit this bug report at http://bugs.php.net/?id=15662&edit=1
Bug #16111 Updated: PHP will not run
ID: 16111 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: PWS related Operating System: Win98SE -PHP Version: 4.1.2 +PHP Version: 4.1.2 Installer New Comment: The files I downloaded are what are on the download page Latest version of PHP Before you download, make sure you're using a mirror close to you. You can change mirrors at the bottom of the page. ect.. PHP 4.1.2 zip package [5,824Kb] - 12 March 2002 (CGI binary (with security fixes) plus server API versions for Apache, AOLserver, ISAPI and NSAPI. MySQL support built-in, many extensions included, packaged as zip) PHP 4.1.2 installer [920Kb] - 12 March 2002 (CGI only (with fixes), MySQL support built-in, packaged as Windows installer to install and configure PHP, and automatically configure IIS, PWS and Xitami, with manual configuration for other servers. N.B. no external extensions included) Previous Comments: [2002-03-16 06:56:44] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Ooops... clicked wrong link. Your version of PHP is not too old, but you shouldn't ask support questions here. [2002-03-16 06:54:42] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". [2002-03-15 23:05:22] [EMAIL PROTECTED] Following the instruction with the CGI/Manual instalation does not work with PWS on a Win98 system. Security Alert! PHP CGI cannot be accessed directly. This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set. This variable is set, for example, by Apache's Action directive redirect. You may disable this restriction by recompiling the PHP binary with the --disable-force-cgi-redirect switch. If you do this and you have your PHP CGI binary accessible somewhere in your web tree, people will be able to circumvent .htaccess security by loading files through the PHP parser. A good way around this is to define doc_root in your php.ini file to something other than your top-level DOCUMENT_ROOT. This way you can separate the part of your web space which uses PHP from the normal part using .htaccess security. If you do not have any .htaccess restrictions anywhere on your site you can leave doc_root undefined. If you are running IIS, you may safely set cgi.force_redirect=0 in php.ini. -- Edit this bug report at http://bugs.php.net/?id=16111&edit=1
Bug #16109 Updated: zlib.output_compression and generated pictures
ID: 16109 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Open Bug Type: Zlib Related Operating System: linux PHP Version: 4.1.2 New Comment: Which bug number is it ? I tried to find a bug report, but didn't found any. Previous Comments: [2002-03-16 06:54:00] [EMAIL PROTECTED] This has already been reported. [2002-03-15 16:53:11] [EMAIL PROTECTED] Hello, It seems a problem occurs when using zlib.output_compression=Yes and generating pictures from a script; The content of the picture seems to be compressed, and not recognize by a browser ( Netscape ). It occurs with jpeg and png files. Strange because, if using mod_gzip with Apache the picture is compressed __but__ still recognized by the browser. What is nice with zlib.output_compression is that nothing needs to be modified in the scripts themselves, but i was not able to find a way to stop compressing in a particular script. Anyhow, thanks again to all, for the nice job done here. Patrick -- Edit this bug report at http://bugs.php.net/?id=16109&edit=1
Bug #16111 Updated: PHP will not run
ID: 16111 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: PWS related Operating System: Win98SE PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Ooops... clicked wrong link. Your version of PHP is not too old, but you shouldn't ask support questions here. Previous Comments: [2002-03-16 06:54:42] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". [2002-03-15 23:05:22] [EMAIL PROTECTED] Following the instruction with the CGI/Manual instalation does not work with PWS on a Win98 system. Security Alert! PHP CGI cannot be accessed directly. This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set. This variable is set, for example, by Apache's Action directive redirect. You may disable this restriction by recompiling the PHP binary with the --disable-force-cgi-redirect switch. If you do this and you have your PHP CGI binary accessible somewhere in your web tree, people will be able to circumvent .htaccess security by loading files through the PHP parser. A good way around this is to define doc_root in your php.ini file to something other than your top-level DOCUMENT_ROOT. This way you can separate the part of your web space which uses PHP from the normal part using .htaccess security. If you do not have any .htaccess restrictions anywhere on your site you can leave doc_root undefined. If you are running IIS, you may safely set cgi.force_redirect=0 in php.ini. -- Edit this bug report at http://bugs.php.net/?id=16111&edit=1
Bug #16111 Updated: PHP will not run
ID: 16111 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: PWS related Operating System: Win98SE PHP Version: 4.1.2 New Comment: The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Previous Comments: [2002-03-15 23:05:22] [EMAIL PROTECTED] Following the instruction with the CGI/Manual instalation does not work with PWS on a Win98 system. Security Alert! PHP CGI cannot be accessed directly. This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set. This variable is set, for example, by Apache's Action directive redirect. You may disable this restriction by recompiling the PHP binary with the --disable-force-cgi-redirect switch. If you do this and you have your PHP CGI binary accessible somewhere in your web tree, people will be able to circumvent .htaccess security by loading files through the PHP parser. A good way around this is to define doc_root in your php.ini file to something other than your top-level DOCUMENT_ROOT. This way you can separate the part of your web space which uses PHP from the normal part using .htaccess security. If you do not have any .htaccess restrictions anywhere on your site you can leave doc_root undefined. If you are running IIS, you may safely set cgi.force_redirect=0 in php.ini. -- Edit this bug report at http://bugs.php.net/?id=16111&edit=1
Bug #16110 Updated: ibase_query() crashes the PHP
ID: 16110 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: InterBase related Operating System: WinNT4 SP6a, 2000 Pro, XP PHP Version: 4.1.2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Previous Comments: [2002-03-15 17:00:36] [EMAIL PROTECTED] trying to execute any SQL statement like "select col_name from table_name" causes PHP.exe crash. problem occured in earlier versions of PHP I used win binaries from php.net and php4win.de (any difference ?) on some tables works fine if they lack primary key. any suggestions are appreciated and desired. HLP!!! -- Edit this bug report at http://bugs.php.net/?id=16110&edit=1
Bug #16109 Updated: zlib.output_compression and generated pictures
ID: 16109 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Zlib Related Operating System: linux PHP Version: 4.1.2 New Comment: This has already been reported. Previous Comments: [2002-03-15 16:53:11] [EMAIL PROTECTED] Hello, It seems a problem occurs when using zlib.output_compression=Yes and generating pictures from a script; The content of the picture seems to be compressed, and not recognize by a browser ( Netscape ). It occurs with jpeg and png files. Strange because, if using mod_gzip with Apache the picture is compressed __but__ still recognized by the browser. What is nice with zlib.output_compression is that nothing needs to be modified in the scripts themselves, but i was not able to find a way to stop compressing in a particular script. Anyhow, thanks again to all, for the nice job done here. Patrick -- Edit this bug report at http://bugs.php.net/?id=16109&edit=1
Bug #16112 Updated: unverbose parse error
ID: 16112 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-03-15 23:28:19] [EMAIL PROTECTED] a nicer parse error would be usefull for the error when you comment a line that invokes )"; I know this isn't valid code because I'm already in http://bugs.php.net/?id=16112&edit=1
Bug #16106 Updated: LDAP + IMAP = PROBLEM
ID: 16106 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: Conectiva 7.0 PHP Version: 4.1.1 New Comment: I guess you're using packages from your linux-distribution? Previous Comments: [2002-03-15 16:10:18] [EMAIL PROTECTED] My softwares imap-2000c-6cl php4-4.1.1-1U70_4cl php4-ldap-4.1.1-1U70_4cl mod_php4-4.1.1-1U70_4cl php4-imap-4.1.1-1U70_4cl php4-ldap-4.1.1-1U70_4cl openldap-client-2.0.21-1U70_2cl openldap-server-2.0.21-1U70_2cl openldap-2.0.21-1U70_2cl My php.ini (LDAP connections working) extension_dir = /usr/lib/php4 extension=mysql.so extension=pgsql.so extension=ldap.so ;extension=imap.so extension=odbc.so My php.ini (IMAP connections working) extension_dir = /usr/lib/php4 extension=mysql.so extension=pgsql.so ;extension=ldap.so extension=imap.so extension=odbc.so My php.ini (Apache not working withou any log, just not start) extension_dir = /usr/lib/php4 extension=mysql.so extension=pgsql.so extension=ldap.so extension=imap.so extension=odbc.so [2002-03-15 16:03:10] [EMAIL PROTECTED] What's your configure line? Which version of c-client/wu-imapd and ldap are you using? Can you provide a backtrace of the core-dump (see http://bugs.php.net/bugs-generating-backtrace.php)? Does it work if you compile imap and ldap statically? [2002-03-15 15:36:11] [EMAIL PROTECTED] Dear, If I use extension=ldap.so alone it's work fine, if I use extension=imap.so alone it's work fine, but if I use extension=imap.so and extension=ldap.so the Apache Core dumped and if I use extension=ldap.so extension=imap.so the Apache don't start. Please Help Me RONIE LIMA -- Edit this bug report at http://bugs.php.net/?id=16106&edit=1
