Bug #45966 [NoF->ReO]: SoapServer does not report WSDL validation errors
Edit report at http://bugs.php.net/bug.php?id=45966&edit=1
ID: 45966
Updated by: c...@php.net
Reported by:chammers at netcologne dot de
Summary:SoapServer does not report WSDL validation errors
-Status: No Feedback
+Status: Re-Opened
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.6
Block user comment: N
New Comment:
As feel so free to re-open this bug as other users reported that it is
still valid in the latest version.
Previous Comments:
[2010-09-20 16:14:03] wim at godden dot net
The problem (which still exists in 5.3.3) is a little worse than thought
: the SoapServer doesn't mention invalid elements (elements that
basically shouldn't be there), it also doesn't complain about missing
elements.
Basically, it seems there's no decent validation code in the PHP
SoapServer. Is this something on the roadmap ?
[2010-07-05 07:26:44] ccorliss at gmail dot com
Despite the comment below, this issue is still not fixed in 5.3.2.
Missing
required elements are quietly skipped.
[2009-05-03 01:00:17] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, 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".
[2009-04-25 16:24:34] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-09-01 17:24:00] chammers at netcologne dot de
Description:
When receiving a SOAP request, SoapServer does not properly validate if
it matches the given WSDL.
Invalid elements are simply surpressed and not passed through to the
called function.
I would expect the SoapServer->handler() to raise an Exception so that
the program can decide if it terminates or go ahead with all parameters
it can get.
bye,
-christian-
Reproduce code:
---
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="http://www.foo.de/services/exampleService";>
1000
815
EOF;
$server = new SoapServer("chammers.wsdl");
$server->setClass('DummyClass');
$server->handle($HTTP_RAW_POST_DATA);
And the WSDL (here "chammers.wsdl")
http://schemas.xmlsoap.org/wsdl/http/";
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:tns="http://www.foo.de/services/exampleService";
targetNamespace="http://www.foo.de/services/exampleService";>
http://www.w3.org/2001/XMLSchema";
targetNamespace="http://www.foo.de/services/exampleService";>
http://schemas.xmlsoap.org/soap/http"/>
http://soap.foo.de/services/example"/>
http://localhost:4080/services/exampleServices"/>
Expected result:
As the request parameter "aaa" has a typo and is actually written as
"" I would expect an Exception or at least some kind of warning.
Actual result:
--
... but the handler class just gets the "bbb" parameter:
$ php chammers.php
Method example was called with array (
0 =>
stdClass::__set_state(array(
'bbb' => 815,
)),
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=45966&edit=1
Req #54502 [Fbk]: Add support for the "BITS" datatype
Edit report at https://bugs.php.net/bug.php?id=54502&edit=1
ID: 54502
Updated by: c...@php.net
Reported by:c...@php.net
Summary:Add support for the "BITS" datatype
Status: Feedback
Type: Feature/Change Request
Package:SNMP related
PHP Version:trunk-SVN-2011-04-10 (SVN)
Assigned To:lytboris
Block user comment: N
Private report: N
New Comment:
The new default SNMP->valueretrieval = SNMP_VALUE_LIBRARY gives at least the
amount of information that snmpwalk does.
Still, before you close this bug, please consider at least adding something
like the following method. It would add a bit of the convenience that one
expects from a PHP class while still leave the low-level methods untouched.
/** Returns the name of a bit value.
*
* The NetSNMP library returns values of OIDs of the BIT type like
* "BITS: 80 notification(0)". This method can be used to extract
* just the name "notification" from this output.
*
* @param string $raw_value The return of a walk() or get() request.
* @return string The name of the BIT value.
*/
public static function parseBitName($raw_value) {
preg_match('/^BITS: [0-9a-f]+ (.*)\(\d+\)\s+$/i', $raw_value, $match);
if (!isset($match[1])) {
throw new Exception("Cannot parse BIT value from '$raw_value'!");
}
return $match[1];
}
Previous Comments:
[2011-07-17 13:26:55] lytbo...@php.net
Automatic comment from SVN on behalf of lytboris
Revision: http://svn.php.net/viewvc/?view=revision&revision=31
Log: fix FR #54502: allow user to change OID value output mode when
SNMP_VALUE_OBJECT is used.
[2011-07-17 13:25:30] lytbo...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Now you can combine SNMP_VALUE_OBJECT with one of SNMP_VALUE_PLAIN or
SNMP_VALUE_LIBRARY to alter 'value' output mode.
As for
>The value is not even numerical, it has to be converted to 0x80 using
>bin2hex()!
This is normal, because this is exactly what php-snmp receives from remote SNMP
agent.
[2011-07-17 13:18:27] lytbo...@php.net
Automatic comment from SVN on behalf of lytboris
Revision: http://svn.php.net/viewvc/?view=revision&revision=313331
Log: fix FR #54502: allow user to change OID value output mode when
SNMP_VALUE_OBJECT is used.
[2011-07-17 09:18:04] lytbo...@php.net
There is support for BITS datatype actually when SNMP_VALUE_LIBRARY is enabled
for value processing. When you enable other SNMP_VALUE_* modes no value
processing is performed and output from remote SNMP agent is passed through
SNMP library.
[2011-04-10 15:34:01] c...@php.net
Description:
The SNMP command line tools are able to translate the numeric return values for
OIDs of the "BITS" datatype back to meaningful string values by parsing the
relevant parts of the MIB. The PHP functions currently seem unable to do that.
I.e. in the following example I would like to get the string "notification" or
"set" as return value but only get "0" or "1". As there is no other method to
find and parse the MIB I'm left with hardcoding the values in the PHP script:
$ snmptranslate -Td DISMAN-EVENT-MIB::mteEventActions
DISMAN-EVENT-MIB::mteEventActions
mteEventActions OBJECT-TYPE
-- FROM DISMAN-EVENT-MIB
SYNTAXBITS {notification(0), set(1)}
Test script:
---
>From commandline (mind the strange quotes, they're neccessary!):
$ snmpwalk -v2c -c private localhost
"DISMAN-EVENT-MIB::mteEventActions.\"_snmpd\".'_linkDown'"
DISMAN-EVENT-MIB::mteEventActions."_snmpd".'_linkDown' = BITS: 80
notification(0)
With PHP:
snmp_set_valueretrieval(SNMP_VALUE_OBJECT);
$snmp = new SNMP(SNMP_VERSION_2C, 'localhost', 'private');
$x =
$snmp->get("DISMAN-EVENT-MIB::mteEventActions.\"_snmpd\".'_linkDown'");
var_dump($x);
var_dump(bin2hex($x->value));
I get:
object(stdClass)#190 (2) {
["type"]=> int(4)
["value"]=> string(1) "�"
}
string(2) "80"
The value is not even numerical, it has to be converted to 0x80 using bin2hex()!
Expected result:
Maybe
* the SNMP_VALUE_OBJECT representation object can be enhanced to include
alternative representations:
object(stdClass)#190 (2) {
["type"]=> int(4)
["value"]=> string(1) "�"
["bits_value"]=> string(15) "notification(0)"
}
* or the the snmp_set_enum_
Req #55312 [Wfx]: Please change SNMP::VERSION_ constants to sensible values
Edit report at https://bugs.php.net/bug.php?id=55312&edit=1 ID: 55312 Updated by: c...@php.net Reported by:c...@php.net Summary:Please change SNMP::VERSION_ constants to sensible values Status: Wont fix Type: Feature/Change Request Package:SNMP related PHP Version:5.4.0alpha2 Assigned To:lytboris Block user comment: N Private report: N New Comment: Why don't you just swap SNMP_VERSION_2c to "2" and SNMP_VERSION_2u to "1"? Then (accidently) specify "2" would lead to a sensible result. Previous Comments: [2011-08-15 07:20:33] lytbo...@php.net There are some drawbacks. Look at this portion of code from snmp.h:#ifndef == NETSNMP_DISABLE_SNMPV1 #define SNMP_VERSION_1 0 #endif #ifndef NETSNMP_DISABLE_SNMPV2C #define SNMP_VERSION_2c1 #endif #define SNMP_VERSION_2u2/* not (will never be) supported by this code */ #define SNMP_VERSION_3 3 /* * versions not based on a version field */ #define SNMP_VERSION_sec 128 /* not (will never be) supported by this code */ #define SNMP_VERSION_2p129 /* no longer supported by this code (> 4.0) */ #define SNMP_VERSION_2star 130 /* not (will never be) supported by this code */ = There are 4 versions of protocol that are glued to major "second" version. I am not sure that any user specifying '2' in SNMP constructor call would mean 2c. I will fix constructor manual adding note that version parameter should be a SNMP class version constant and not an ordinary integer. [2011-07-28 23:26:50] c...@php.net Description: Currently the SNMP::VERSION class constants have the following internal values: const integer SNMP::VERSION_1 = 0 ; const integer SNMP::VERSION_2C = 1 ; const integer SNMP::VERSION_2c = 1 ; const integer SNMP::VERSION_3 = 3 ; As PHP does not yet have the concept of Enums the documentation just says that the first parameter has to be numeric so people will be tempted to enter 1, 2 or 3 as paramter which results in hard to debug errors (it mostly works just some OIDs do not). Would there be any drawbacks if we change the internal values to 1, 2, 2, 3? It's still Alpha so no Backward Compatibility problems. -- Edit this bug report at https://bugs.php.net/bug.php?id=55312&edit=1
Req #55542 [->Opn]: SNMP class should use Exceptions instead of PHP Errors
Edit report at https://bugs.php.net/bug.php?id=55542&edit=1 ID: 55542 Updated by: c...@php.net Reported by:c...@php.net Summary:SNMP class should use Exceptions instead of PHP Errors -Status: To be documented +Status: Open Type: Feature/Change Request Package:SNMP related PHP Version:5.4.0alpha3 Assigned To:lytboris Block user comment: N Private report: N New Comment: Thanks for implementing this so quickly. But the constructor still says: "snmp_object->exceptions_enabled = 0;", as this is a class one would rather expect OOP style exceptions as default, or? Previous Comments: [2011-09-02 10:13:21] lytbo...@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. A new SNMP object property is introduced: exceptions_enabled. Setting this property to ORed combination of SNMP::ERRNO_* errors will enable exception throwing on these errors. SNMP::ERRNO_ANY may be used to enable all posslible SNMP::ERRNO_* errors at once. [2011-09-02 10:13:19] lytbo...@php.net Automatic comment from SVN on behalf of lytboris Revision: http://svn.php.net/viewvc/?view=revision&revision=316032 Log: merge from trunk added SNMPException class, enabling ability to throw exceptions when a known SNMP error has occured FR #55542 [2011-09-02 10:04:08] lytbo...@php.net Automatic comment from SVN on behalf of lytboris Revision: http://svn.php.net/viewvc/?view=revision&revision=316029 Log: added SNMPException class, enabling ability to throw exceptions when a known SNMP error has occured FR #55542 [2011-08-30 22:15:06] c...@php.net Description: Hello Subject says all, IMHO it does not make sense to start writing a new class that does not use 100% exceptions. This bug is a follow up on #40816 which ended with: [2011-08-30 15:18 UTC] lytbo...@php.net > I have read a bunch of threads on php-dev about extensions throwing > exceptions and the last thing I remember that extension should not throw any > exception except object creation if there is no way to disable them. > Anyway, if to throw exceptions, library will throw an exception for each > error, not only parsing error. Please, please, convinced yourself that Exceptions are cool and worth refactoring the code. I'd be willing to help with writing tests :) I'd be curious about the threads you mentioned (a quick google found nothing but then the keywords are very common) but there are already some extensions (spl/php_spl.c, mysql/php_mysql.c, reflection/php_reflection.c) that do throw Exceptions. -- Edit this bug report at https://bugs.php.net/bug.php?id=55542&edit=1
Req #55542 [Asn]: SNMP class should use Exceptions instead of PHP Errors
Edit report at https://bugs.php.net/bug.php?id=55542&edit=1 ID: 55542 Updated by: c...@php.net Reported by:c...@php.net Summary:SNMP class should use Exceptions instead of PHP Errors Status: Assigned Type: Feature/Change Request Package:SNMP related PHP Version:5.4.0alpha3 Assigned To:lytboris Block user comment: N Private report: N New Comment: But PDO has a history back to PHP4 or the days where people where used to check every single return value for PEAR_Error. The SNMP class is new and could lead as good example for proper OOP style! (Or do you prefer C style $errno checking after every method call over try/catch statements? The chances that an error goes unnoticed is much lower with exceptions.) Previous Comments: [2011-09-02 11:48:34] lytbo...@php.net enable SNMP::ERRNO_ANY by default is not a good idea I think. PDO has the same default behavior for throwing exceptions. [2011-09-02 10:41:20] c...@php.net Thanks for implementing this so quickly. But the constructor still says: "snmp_object->exceptions_enabled = 0;", as this is a class one would rather expect OOP style exceptions as default, or? [2011-09-02 10:13:21] lytbo...@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. A new SNMP object property is introduced: exceptions_enabled. Setting this property to ORed combination of SNMP::ERRNO_* errors will enable exception throwing on these errors. SNMP::ERRNO_ANY may be used to enable all posslible SNMP::ERRNO_* errors at once. [2011-09-02 10:13:19] lytbo...@php.net Automatic comment from SVN on behalf of lytboris Revision: http://svn.php.net/viewvc/?view=revision&revision=316032 Log: merge from trunk added SNMPException class, enabling ability to throw exceptions when a known SNMP error has occured FR #55542 [2011-09-02 10:04:08] lytbo...@php.net Automatic comment from SVN on behalf of lytboris Revision: http://svn.php.net/viewvc/?view=revision&revision=316029 Log: added SNMPException class, enabling ability to throw exceptions when a known SNMP error has occured FR #55542 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55542 -- Edit this bug report at https://bugs.php.net/bug.php?id=55542&edit=1
#21566 [NEW]: problem with $_POST
From: [EMAIL PROTECTED] Operating system: Linux Red Hat 8 PHP version: 4.2.2 PHP Bug Type: Unknown/Other Function Bug description: problem with $_POST I submit data using form ... ..in page2.php I have "; ?> .. I submit myname as 'Jack' .. I get this.. My name is Jackmyname=Jack My PHP came and installed with Linux Red Hat 8. -- Edit bug report at http://bugs.php.net/?id=21566&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21566&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21566&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21566&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21566&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21566&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21566&r=support Expected behavior: http://bugs.php.net/fix.php?id=21566&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21566&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21566&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21566&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21566&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21566&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21566&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21566&r=gnused
#19532 [NEW]: cannot load php4apache.dll
From: [EMAIL PROTECTED] Operating system: Windows 98 PHP version: 4.2.3 PHP Bug Type: Apache2 related Bug description: cannot load php4apache.dll C:\WINDOWS\Plocha> c:\Progra~1\Apache~1\Apache2\bin\apache -k install Syntax error on line 177 of C:/Program Files/Apache Group/Apache2/conf/httpd.conf: Cannot load C:/php/sapi/php4apache.dll into server: -- Edit bug report at http://bugs.php.net/?id=19532&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19532&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19532&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19532&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19532&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19532&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19532&r=support Expected behavior: http://bugs.php.net/fix.php?id=19532&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19532&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19532&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19532&r=globals
#19918 [Opn]: no libphp4.so produced
ID: 19918 User updated by: mad at dactar dot ch Reported By: mad at dactar dot ch Status: Open Bug Type: Compile Failure Operating System: HP-UX 11.00 -PHP Version: 4.3.0 +PHP Version: 4.3.1 New Comment: This workarround (replace -lcrypt by -lc). Someone of php's staff can analyse this problem and correct it please ? Thanks @++ JC PS 4 kbrott : thanks very very much :)) Previous Comments: [2003-02-05 18:15:34] kbrott at eli dot net Reproduced bug on patched-to-current HP-UX 11.00 system trying to build php-4.3.0 against apache httpd 2.0.43 (as well as the php-200301290030.tar.gz snapshot). Have determined cause and offer working solution (well - it worked on my systems anyway). Here's the config.nice that I used for this instance: #! /bin/sh # # Created by configure CFLAGS='-O3' \ LDFLAGS='-L/opt/admin/lib -L/opt/tools/lib' \ CC='gcc' \ './configure' \ '--prefix=/opt/php4' \ '--with-apxs2=/opt/apache/sbin/apxs' \ '--enable-shared' \ '--enable-force-cgi-redirect' \ '--with-openssl=/opt/tools' \ '--with-zlib=/opt/tools' \ '--enable-bcmath' \ '--with-bz2=/opt/tools' \ '--enable-calendar' \ '--enable-dba' \ '--with-gdbm=/opt/tools' \ '--with-db3=/opt/tools' \ '--with-flatfile' \ '--enable-dbase' \ '--enable-dbx' \ '--enable-ftp' \ '--with-gmp=/opt/tools' \ '--with-mysql=/opt/mysql' \ '--enable-mime-magic' \ '--with-ldap=/opt/tools' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-readline=/opt/tools' \ "$@" HP's linker via libtool (apache2 or otherwise) cannot seem to use a lib(anything).a to make a shared library file (at least not in this instance - I gave up on it after a couple of months) - so the trick is to make sure not to call any static libraries. HP moved all of the shared crpyt functions into libc ( as of HP-UX 10.20 see <http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=20062689279> ). So all calls in ./configure for HP-UX 11.00 should use -lc instead of -lcrypt for the crypt_r/ calls (tested - it works). HP has completely deprecated termcap usage ( see <http://devrsrc1.external.hp.com/STK/impacts/i409.html>, <http://devrsrc1.external.hp.com/STK/partner/xcurses.html>, and more specifically <http://h21007.www2.hp.com/hpux-devtools/CXX/hpux-devtools.0012/0052.html> ) so you have to use libcurses instead if you want to access a shared library with those functions. So all calls in ./configure when OS=hpux11 should use -lcurses instead of -ltermcap for the tgetent calls (tested - it works). Making these changes to ./configure, executing ./config.nice, then doing make, make install allowed compilation and installation with no problems (well, once I rebuilt bzip2 with a shared libbz2 that is). Feel free to ping me with questions - I have a working php 4.3.0 install running on HP-UX 11.00 as a shared install under apache 2.0.43 now so I must have done something right. :) [2003-02-05 11:54:39] benoit dot bruckert at uniporc-ouest dot com oups ! it was with-apxs2 and not with-apxs... [2003-02-05 11:29:07] benoit dot bruckert at uniporc-ouest dot com OS : HP-UX11.00 (32 bits) gcc 2.95.2 PHP 4.3.0. apache 2.0.44 php config : ./configure --with-apxs=/home/apache2/bin/apxs --without-mysql --enable-track-vars make I have crypt warning about share libs !! Then I changed the Make file and removed -lcrypt make --> OK no more warning make install --> OK apachectl start --> no errors I started then it works, (I got the phpinfo page), What the lib crypt is made for ??? what functions are using it ? [2003-01-22 12:44:34] mathieu dot carbonneaux at free dot Fr i have the same probleme with PHP 4.3 + SAPI NSAPI on HP-UX 11! /bin/sh libtool --silent --mode=link gcc -g -O2 -DZTS -prefer-pic -rpath /opt/php43/php-4.3.0/libs -avoid-version -module -L/usr/lo cal/lib -L/opt/bzip2/lib -L/opt/jpeg-6/lib -L/opt/libpng/lib -L/opt/xpm/lib -L/opt/freetype/lib -L/opt/T1/lib -L/opt/gd/lib -R /usr /local/lib -R /opt/bzip2/lib -R /opt/jpeg-6/lib -R /opt/libpng/lib -R /opt/xpm/lib -R /opt/freetype/lib -R /opt/T1/lib -R /opt/gd/li b ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bz2/bz2.lo ext/ctype/ctype.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo e xt/ove
#19918 [Opn]: no libphp4.so produced
ID: 19918 User updated by: mad at dactar dot ch Reported By: mad at dactar dot ch Status: Open Bug Type: Compile Failure Operating System: HP-UX 11.00 PHP Version: 4.3.1 New Comment: This workarround (replace -lcrypt by -lc) works. Someone of php's staff can analyse this problem and correct it please ? Thanks @++ JC PS 4 kbrott : thanks very very much :)) Previous Comments: [2003-02-18 13:57:18] mad at dactar dot ch This workarround (replace -lcrypt by -lc). Someone of php's staff can analyse this problem and correct it please ? Thanks @++ JC PS 4 kbrott : thanks very very much :)) [2003-02-05 18:15:34] kbrott at eli dot net Reproduced bug on patched-to-current HP-UX 11.00 system trying to build php-4.3.0 against apache httpd 2.0.43 (as well as the php-200301290030.tar.gz snapshot). Have determined cause and offer working solution (well - it worked on my systems anyway). Here's the config.nice that I used for this instance: #! /bin/sh # # Created by configure CFLAGS='-O3' \ LDFLAGS='-L/opt/admin/lib -L/opt/tools/lib' \ CC='gcc' \ './configure' \ '--prefix=/opt/php4' \ '--with-apxs2=/opt/apache/sbin/apxs' \ '--enable-shared' \ '--enable-force-cgi-redirect' \ '--with-openssl=/opt/tools' \ '--with-zlib=/opt/tools' \ '--enable-bcmath' \ '--with-bz2=/opt/tools' \ '--enable-calendar' \ '--enable-dba' \ '--with-gdbm=/opt/tools' \ '--with-db3=/opt/tools' \ '--with-flatfile' \ '--enable-dbase' \ '--enable-dbx' \ '--enable-ftp' \ '--with-gmp=/opt/tools' \ '--with-mysql=/opt/mysql' \ '--enable-mime-magic' \ '--with-ldap=/opt/tools' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-readline=/opt/tools' \ "$@" HP's linker via libtool (apache2 or otherwise) cannot seem to use a lib(anything).a to make a shared library file (at least not in this instance - I gave up on it after a couple of months) - so the trick is to make sure not to call any static libraries. HP moved all of the shared crpyt functions into libc ( as of HP-UX 10.20 see <http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=20062689279> ). So all calls in ./configure for HP-UX 11.00 should use -lc instead of -lcrypt for the crypt_r/ calls (tested - it works). HP has completely deprecated termcap usage ( see <http://devrsrc1.external.hp.com/STK/impacts/i409.html>, <http://devrsrc1.external.hp.com/STK/partner/xcurses.html>, and more specifically <http://h21007.www2.hp.com/hpux-devtools/CXX/hpux-devtools.0012/0052.html> ) so you have to use libcurses instead if you want to access a shared library with those functions. So all calls in ./configure when OS=hpux11 should use -lcurses instead of -ltermcap for the tgetent calls (tested - it works). Making these changes to ./configure, executing ./config.nice, then doing make, make install allowed compilation and installation with no problems (well, once I rebuilt bzip2 with a shared libbz2 that is). Feel free to ping me with questions - I have a working php 4.3.0 install running on HP-UX 11.00 as a shared install under apache 2.0.43 now so I must have done something right. :) [2003-02-05 11:54:39] benoit dot bruckert at uniporc-ouest dot com oups ! it was with-apxs2 and not with-apxs... [2003-02-05 11:29:07] benoit dot bruckert at uniporc-ouest dot com OS : HP-UX11.00 (32 bits) gcc 2.95.2 PHP 4.3.0. apache 2.0.44 php config : ./configure --with-apxs=/home/apache2/bin/apxs --without-mysql --enable-track-vars make I have crypt warning about share libs !! Then I changed the Make file and removed -lcrypt make --> OK no more warning make install --> OK apachectl start --> no errors I started then it works, (I got the phpinfo page), What the lib crypt is made for ??? what functions are using it ? [2003-01-22 12:44:34] mathieu dot carbonneaux at free dot Fr i have the same probleme with PHP 4.3 + SAPI NSAPI on HP-UX 11! /bin/sh libtool --silent --mode=link gcc -g -O2 -DZTS -prefer-pic -rpath /opt/php43/php-4.3.0/libs -avoid-version -module -L/usr/lo cal/lib -L/opt/bzip2/lib -L/opt/jpeg-6/lib -L/opt/libpng/lib -L/opt/xpm/lib -L/opt/freetype/lib -L/opt/T1/lib -L/opt/gd/lib -R
#22308 [NEW]: passthru is extremely slow
From: uk at dataway dot ch
Operating system: Linux 2.2.18
PHP version: 4.3.0
PHP Bug Type: Performance problem
Bug description: passthru is extremely slow
Using passthru("whatever") is almost 100 times slower than doing the
equivalent $out = `whatever`;echo $out
I tested this using the following program (I use dd here to generate the
data, but the same results appear with any command, cat /etc/passwd etc.)
";
$mt = explode(' ', $start);
$mts = $mt[1] + $mt[0];
$mt = explode(' ', $end);
$mte = $mt[1] + $mt[0];
printf("%.3f seconds elapsed (passthru)", $mte - $mts);
echo "";
$mt = explode(' ', $start);
$mts = $mt[1] + $mt[0];
$mt = explode(' ', $end);
$mte = $mt[1] + $mt[0];
printf("%.3f seconds elapsed (backquotes)", $mte - $mts);
?>
On my machine (Pentium 400) this script outputs:
16.231 seconds elapsed (passthru)
0.266 seconds elapsed (backquotes)
Quite a difference, I think.
Compiled with:
./configure \
--bindir=/usr/local/apache/bin \
--libdir=/usr/local/apache/php/lib \
--with-apxs=/usr/local/apache/bin/apxs \
--with-config-file-path=/usr/local/apache/conf \
--with-exec-dir=/usr/local/apache/php/bin \
--with-pear=/usr/local/apache/php/lib \
--enable-safe-mode \
--with-openssl=/usr/local/ssl \
--with-imap=shared,/usr/local \
--enable-dbx=shared \
--enable-dio=shared \
--enable-ftp \
--with-sybase-ct=shared,/usr/local \
--with-mysql=shared,/usr/local/mysql \
--with-pgsql=shared,/usr/local/pgsql \
--with-gdbm=shared \
--with-zlib=/usr/local \
--with-gd=shared \
--enable-exif=shared \
--enable-ctype \
--with-gettext \
--with-xml=shared \
--with-expat-dir=/usr/local \
--enable-xslt=shared \
--with-xslt-sablot=/usr/local \
--enable-sockets=shared \
--enable-wddx=shared \
--enable-shmop=shared \
--enable-sysvmsg=shared \
--enable-sysvsem=shared \
--enable-sysvshm=shared
--
Edit bug report at http://bugs.php.net/?id=22308&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22308&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22308&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22308&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22308&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22308&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22308&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22308&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22308&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22308&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22308&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22308&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22308&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22308&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22308&r=gnused
#22354 [NEW]: ocilogon problem only in command line interface
From: tobi at blackswan dot ch Operating system: windows 2000 PHP version: 4.3.1 PHP Bug Type: OCI8 related Bug description: ocilogon problem only in command line interface hello i have a problem with the php cli (command line interface) in php (webbrowser) my script works perfect... when i test the script in cli i get the following error --> error - Fatal error: Call to undefined function: ocilogon() in D:\apps\Apache2\htdocs\test\scanner\test.php on line 9 script -- configuration - php 4.3.1 apache 2.0.43 oracle client 9.2.0.1.0 %PATH% is set to D:\Program\ora92\bin phpinfo --> oci enable thx & g tobi -- Edit bug report at http://bugs.php.net/?id=22354&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22354&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22354&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22354&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22354&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22354&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22354&r=support Expected behavior: http://bugs.php.net/fix.php?id=22354&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22354&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22354&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22354&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22354&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22354&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22354&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22354&r=gnused
#26423 [Com]: Queries Regarding PHP 4.3.3
ID: 26423
Comment by: sw at telemeida dot ch
Reported By: prashant at goodhealthnyou dot com
Status: Bogus
Bug Type: *General Issues
Operating System: Linux
PHP Version: 4.3.3
New Comment:
i have seen severe simmilar bug reports and i run into exactly the same
problem.
Environment:
PHP Version 4.3.3 (cobalt RH linux)
Server API Apache
Apache Version Apache/1.3.20
Apache Release 10320100
Apache API Version 19990320
PHP config:
---
file_uploadsOn On
gpc_order GPC GPC
post_max_size 8M 8M
safe_mode Off Off
upload_tmp_dir /home/tmp /home/tmp (does exist and is set to 777,
session handling uses the same dir and session files are written,
session handling works propperly )
upload_max_filesize 2M 2M
Example code:
-
");
print_r($_FILES);
print("");
?>
Expected result (tested with a 1K ascii file):
--
Array(
'blah' => Array(
'name' => 'test.txt',
'type' => 'text/plain',
'size' => 'a few bytes',
'tmp_name' => '/home/tmp/...whatever..',
'error' => ''
)
)
Actual Result:
--
Array()
iv'e done quiet some RTFM and i am pretty sure there is no
configuration problem. All file uploads scripts work well with php
4.2.x and and with $HTTP_POST_FILES in pre 4.1 versions, the problem
appeared with the use of a 4.3+ php version.
Can anybody confirm that this is a bug (or not) ? Any help is highly
appreciated.
Cheers,
Simon
Previous Comments:
[2003-11-26 08:59:29] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
This is not a support forum.
[2003-11-26 08:55:26] prashant at goodhealthnyou dot com
Description:
Hi,
There are some queries regarding PHP 4.1.As you mentioned in php 4.1
register_globals=off. are set for security reasons.
Is it Required to have Form attribute as enctype="multipart/form-data"
if i
have a File Upload on the Particular Form.
i.e
I am Facing a Problem as when i am removing the enctype attribute in
Form
object, i am able to pass form values data
from one form to another form i.e the destination form will able to
retrieve
the form values, but from the source form when i keep the enctype
attribute
in the source form object, i am unable to pass the values i.e the
destination form is unable to retrieve
the values passed from source form.
Second Problem is I am unable to retrieve the image name using
$_FILES['filename']['name']; in the Destination form.
The source form has the file upload html tag
i.e
Awaiting Your Prompt Reply,
Thanks & Regards,
Prashant S Akerkar
Reproduce code:
---
Source file
source.php3
Destination File
dest.php3
echo $_FILES['image1']['name'];
echo $_FILES['image1']['type'];
echo $_FILES['image1']['error'];
echo $HTTP_POST_FILES['image1']['name'];
echo $HTTP_POST_FILES['image1']['type'];
echo $HTTP_POST_FILES['image1']['size'];
copy
("$image1","../../../".$coname."/".$_POST['logname']."/".$image1_name);
Expected result:
The File Upload doesn't Work. The name of the File Uploaded is not
printed here as shown in the code.
Warning: Unable to open 'D:\\Prashant\\Novartisimages\\cropped\\69.jpg'
for reading: No such file or directory
Actual result:
--
The file upload should work i.e file should get uploaded on the web
server as well as all form objects data should get passed from source
to destination file.
--
Edit this bug report at http://bugs.php.net/?id=26423&edit=1
#17846 [Com]: Session randomly malfunctions
ID: 17846 Comment by: simon at infomaniak dot ch Reported By: fabian at ahrberg dot se Status: No Feedback Bug Type: Session related Operating System: Linux 2.4 kernel PHP Version: 4.2.1 New Comment: I'm experiencing the same problem too. I've noticed that even if it was set to 0 in php.ini, session.cookie_lifetime had random values at session start. I'm now trying to force it to 0 using ini_set( 'session.cookie_lifetime', 0); before the first session_start(). It seems to work but I'm not really sure for now, I have to test it more. Previous Comments: [2003-07-09 09:18:57] wieri420 at planet dot nl I had the random faillure of sessions too. Are you using cookies and sessions in one script? Try commenting all cookie related functions (setcookie etc..) and see if it solves the problem. It solved the session problem for me. I'm curious if it solves the problem for others too... [2002-08-20 21:47:01] rossr at reactive dot com I'm exeriencing the same bug, where the session randomly dissappears and the user is logged out of our site. This appears to be happening across different browsers and platforms as previously mentioned. The site is hosted on the same OS (Linux 2.4 Kernel) but the version of PHP is 4.2.2 The setting for "session.cookie_lifetime" is set to 0 in our php.ini file. [2002-08-03 01:00:12] php-bugs at lists dot php dot net 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-07-02 22:06:37] [EMAIL PROTECTED] Is session.cookie_lifetime = 0 in your php.ini? [2002-06-28 19:39:23] fabian at ahrberg dot se Hmm... I spent a whole day looking into this. The sessioncookie is set to die with the browser, and not time-out. HOWEVER: In 99% of the cases the cookie looked just fine but in a few cases the cookie was set for a limited lifetime even though it shouldn't. So I tried to use the function session_cookie_set (or whatever it's called =) ) in case of something mysterious and guess what? Since I set the lifetime to "0" with this function, just before I call session_start, I haven't experineced the problem and no vistor on the site neither... Hmm... so the question is, why does the session-cookie sometimes show up with a limited lifetime, when it in 99% shows up with what it should (till the browsers closes)... hmm 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/17846 -- Edit this bug report at http://bugs.php.net/?id=17846&edit=1
#16408 [NoF->Opn]: session handling does not work with IE6
ID: 16408
User updated by: sb at bpm dot ch
Reported By: sb at bpm dot ch
-Status: No Feedback
+Status: Open
Bug Type: Session related
Operating System: Windows NT (IIS) & AIX (Apache)
PHP Version: 4.1.1
New Comment:
This problem occures only, if the hostname of the server contains an
"_" (underscore). We have changed the hostname now.
Stephan
Previous Comments:
[2003-12-10 07:22:16] peter dot lerner at commerzbank dot com
If the session info is saved as a file, instead of a file called
sess_, you will find a file named 'sess_null'.
-rw--- 1 myuid mygid 1535549 Dec 10 12:57 sess_null
I'm running php4.3.4 on apache2 on a solaris8 box.
Browser is Internet Explorer 6.0.2800.1106CO.
Session management troubles happen only with IE6, but runs fine with
e.g. Mozilla 1.5.
The problem is *very*critical* for us, because _every_ user who logs on
with an IE6 gets user permissions from the sess_null. sess_null could
be the admin's session.
Vice versa it's also a problem if the first user to create a sess_null
was not-privileged, and the subsequent admin logon is "castrated" to
the non-privileged level.
[2002-07-10 01:00:05] php-bugs at lists dot php dot net
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-05-03 13:01:31] jan dot vlcinsky at cad-programs dot com
I thing, you forgot to place quotes around variable name
Instead of
session_register(User); BAD
use
session_register("User"); OK
[2002-04-03 09:46:55] [EMAIL PROTECTED]
Hmm. I use IE6+Linux/Apache and I don't have problem.
Could you look into packets using sniffer? and see if there is any
difference with IE6 and IE5.
Ehtereal works on a lot of platforms and very easy to use.
http://www.ethereal.com/
----
[2002-04-03 04:16:46] sb at bpm dot ch
In IE6 we have on some PCs the problem that the session data will not
saved:
First page:
session_start();
$User = "root";
session_register(User);
Second page:
session_start();
echo "$User";
Now nothing will displayed... :-(
This Problem occures only in IE6 an never in IE5.x
Stephan
--
Edit this bug report at http://bugs.php.net/?id=16408&edit=1
#16408 [Opn->Csd]: session handling does not work with IE6
ID: 16408
User updated by: sb at bpm dot ch
Reported By: sb at bpm dot ch
-Status: Open
+Status: Closed
Bug Type: Session related
Operating System: Windows NT (IIS) & AIX (Apache)
PHP Version: 4.1.1
New Comment:
this issue can be closed now.
Previous Comments:
[2003-12-10 07:28:54] sb at bpm dot ch
This problem occures only, if the hostname of the server contains an
"_" (underscore). We have changed the hostname now.
Stephan
[2003-12-10 07:22:16] peter dot lerner at commerzbank dot com
If the session info is saved as a file, instead of a file called
sess_, you will find a file named 'sess_null'.
-rw--- 1 myuid mygid 1535549 Dec 10 12:57 sess_null
I'm running php4.3.4 on apache2 on a solaris8 box.
Browser is Internet Explorer 6.0.2800.1106CO.
Session management troubles happen only with IE6, but runs fine with
e.g. Mozilla 1.5.
The problem is *very*critical* for us, because _every_ user who logs on
with an IE6 gets user permissions from the sess_null. sess_null could
be the admin's session.
Vice versa it's also a problem if the first user to create a sess_null
was not-privileged, and the subsequent admin logon is "castrated" to
the non-privileged level.
[2002-07-10 01:00:05] php-bugs at lists dot php dot net
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-05-03 13:01:31] jan dot vlcinsky at cad-programs dot com
I thing, you forgot to place quotes around variable name
Instead of
session_register(User); BAD
use
session_register("User"); OK
[2002-04-03 09:46:55] [EMAIL PROTECTED]
Hmm. I use IE6+Linux/Apache and I don't have problem.
Could you look into packets using sniffer? and see if there is any
difference with IE6 and IE5.
Ehtereal works on a lot of platforms and very easy to use.
http://www.ethereal.com/
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/16408
--
Edit this bug report at http://bugs.php.net/?id=16408&edit=1
#26627 [NEW]: I get source of php files instead of supposed output on random basis
From: info at gli dot ch Operating system: Linux 2.4.20 PHP version: 4.3.4 PHP Bug Type: Apache2 related Bug description: I get source of php files instead of supposed output on random basis Description: Randomly the php-source is displayed instead of the output (http://www.engstringen.ch/). This was the case when having installed apache 1.3 und php 4.1. After ugrading to apache 2 and php 4.3.4 the bug still occurs. But the browser shows now a file download dialog box for downloading the php -script instead of having executed it !!! The header of the response contains the php - mime type configured application/x-httpd-php. The apache config contains AddType application/x-httpd-php .php .php4 .php3 .phtml AddType application/x-httpd-php-source .phps Include conf/confixx_vhost.conf The confixx_vhost.conf contains lots of virtual host configured on a named vhost basis. php is minimally configured with './configure' '--with-mysql' '--with-apxs' -- Edit bug report at http://bugs.php.net/?id=26627&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26627&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26627&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26627&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26627&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26627&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26627&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26627&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26627&r=support Expected behavior: http://bugs.php.net/fix.php?id=26627&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26627&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26627&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26627&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26627&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26627&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26627&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26627&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26627&r=float
#26627 [Bgs]: I get source of php files instead of supposed output on random basis
ID: 26627 User updated by: info at gli dot ch Reported By: info at gli dot ch Status: Bogus Bug Type: Apache2 related Operating System: Linux 2.4.20 PHP Version: 4.3.4 New Comment: Well, I just want to be clear that that that php module doesn't decline the request for any reason. This could lead to this result. The Error_log doesnt' give any information about this. Previous Comments: [2003-12-15 07:23:36] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. please read the support page and post a question to pear-general first. [2003-12-15 04:42:17] info at gli dot ch Description: Randomly the php-source is displayed instead of the output (http://www.engstringen.ch/). This was the case when having installed apache 1.3 und php 4.1. After ugrading to apache 2 and php 4.3.4 the bug still occurs. But the browser shows now a file download dialog box for downloading the php -script instead of having executed it !!! The header of the response contains the php - mime type configured application/x-httpd-php. The apache config contains AddType application/x-httpd-php .php .php4 .php3 .phtml AddType application/x-httpd-php-source .phps Include conf/confixx_vhost.conf The confixx_vhost.conf contains lots of virtual host configured on a named vhost basis. php is minimally configured with './configure' '--with-mysql' '--with-apxs' -- Edit this bug report at http://bugs.php.net/?id=26627&edit=1
#26101 [Com]: FastCGI PHP fails as a local responder under Zeus 4.2
ID: 26101 Comment by: pmoor at netpeople dot ch Reported By: david at geektech dot com Status: Assigned Bug Type: CGI related Operating System: FreeBSD 4.9-STABLE PHP Version: 5CVS-2003-11-29 Assigned To: shane New Comment: sampe problem over here, using 5.0.0b3 and apache 1.3.29. php4, same config, worked like a charm. Previous Comments: [2003-11-29 06:37:41] [EMAIL PROTECTED] Assigned to the maintainer. [2003-11-03 17:27:20] david at geektech dot com Description: This actually applies to 5.0.0b2, but the bug reporting system doesn't include this version. Configure PHP with --enable-fastcgi. Copy the sapi/cgi/php binary to %zeushome%/php/php.fcgi. Enable PHP support in Zeus as a local responder using the easy "Enable PHP" section under "Third Party" in the web interface. Attempt to load a PHP page. Zeus will respond with a "502 Bad Gateway" error. PHP 4 works fine like this. One of the changes in PHP 5 broke it. PHP 5 works as a FastCGI remote responder using the -b option to the PHP binary. -- Edit this bug report at http://bugs.php.net/?id=26101&edit=1
#26081 [Com]: Broken pipo by incomplete headers
ID: 26081 Comment by: pmoor at netpeople dot ch Reported By: php at searchystats dot com Status: No Feedback Bug Type: CGI related Operating System: FreeBSD 4.8 PHP Version: 4.3.4RC3 New Comment: We've had the same problems, using apache 1.3.29 and mod_fastcgi 2.4.0. I could _always_ reproduce the error by sending a manual HTTP/1.1 POST request through telnet. Before sending the Postvars, i waited some seconds, and then entered some random data. There was always this "broken pipe"-thing happening. Now we upgraded to fastcgi version 2.4.2 and it works just perfectly! Previous Comments: [2003-11-17 18:15:28] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-11-02 12:00:14] [EMAIL PROTECTED] 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". Thank you for your interest in PHP. [2003-11-02 11:51:58] php at searchystats dot com Description: The problem is that php as FastCGI application occasionaly fails and produces this error log: [Sun Nov 2 17:40:17 2003] [error] [client %ip%] (32)Broken pipe: FastCGI: comm with server "/opt/guide/ppi.searchy.net/cgi-bin/php.fcgi" aborted: write failed [Sun Nov 2 17:40:17 2003] [error] [client %ip%] FastCGI: incomplete headers (0 bytes) received from server "/opt/guide/ppi.searchy.net/cgi-bin/php.fcgi" /opt/guide/ppi.searchy.net/cgi-bin/php.fcgi = the binary php compiled with the following configure command: ./configure --without-apache --enable-fastcgi --enable-force-cgi-redirect --prefix=/usr/local/php-4.3.4RC3-test --with-mysql=/usr/local/mysql --with-openssl I have not been able to reproduce the problem, it justs occures now and then. The apache configuration is as follows specific to php fastcgi in a virtualhost directive: FastCgiServer /opt/guide/ppi.searchy.net/cgi-bin/php.fcgi -appConnTimeout 0 -processes 5 -listen-queue-depth 100 -flush FastCgiConfig -maxProcesses 50 -minProcesses 6 -appConnTimeout 0 AddHandler php-fastcgi .fphp .php4 .php3 .php Action php-fastcgi /cgi-bin/php.fcgi Reproduce code: --- *any source code* -- Edit this bug report at http://bugs.php.net/?id=26081&edit=1
#26758 [Com]: FastCGI exits immediately with status 255
ID: 26758
Comment by: pmoor at netpeople dot ch
Reported By: tcarter at noggin dot com dot au
Status: Open
Bug Type: CGI related
Operating System: Linux
PHP Version: 5.0.0b3 (beta3)
New Comment:
seems to be related/the same as bug #26101.
the supplied patch worked for me.
Previous Comments:
[2003-12-31 20:50:36] tcarter at noggin dot com dot au
Description:
When launched from mod_fastcgi as a dynamic application
the FastCGI binary exits with status 255 without serving
any requests. The problem is present in the latest CVS,
but not present in v4.3.4. The problem does not occur
when running the FastCGI binary with a bindpath (-b)
option.
The problem seems to be that
php_handle_aborted_connection() is called from the parent
process in sapi_cgi_bin_flush() and zend_bailout() then
exits because there is no bailout address set.
Webserver is:
Apache 2.0.47 (Fedora Core 1)
mod_fastcgi 2.4.2
PHP Configuration is just:
./configure --enable-fastcgi
The following seems to fix the problem, but I'm not sure
it is the right way to fix it:
--- cgi_main.c.bak 2004-01-01 12:38:22.0
+1100
+++ cgi_main.c 2004-01-01 12:39:34.0 +1100
@@ -271,7 +271,7 @@
#if PHP_FASTCGI
if (!FCGX_IsCGI()) {
FCGX_Request *request = (FCGX_Request
*)server_context;
- if(!request || FCGX_FFlush( request->out )
== -1 ) {
+ if( !parent && (!request ||
FCGX_FFlush( request->out ) == -1) ) {
php_handle_aborted_connection();
}
return;
Expected result:
PHP should serve requests and not exit immediately
Actual result:
--
[Thu Jan 01 12:22:54 2004] [warn] FastCGI: scheduled the
start of the last (dynamic) server
"/var/www/fastcgi-bin/php-5" process: reached
dynamicMaxClassProcs (1)
[Thu Jan 01 12:22:54 2004] [warn] FastCGI: (dynamic)
server "/var/www/fastcgi-bin/php-5" started (pid 17770)
[Thu Jan 01 12:22:54 2004] [warn] FastCGI: (dynamic)
server "/var/www/fastcgi-bin/php-5" (pid 17770) terminated
by calling exit with status '255'
--
Edit this bug report at http://bugs.php.net/?id=26758&edit=1
#26844 [NEW]: Problems with --with-mime-magic
From: php at humbapa dot ch Operating system: Linux 2.4.22 (Debian unstable) PHP version: 5CVS-2004-01-08 (dev) PHP Bug Type: PHP options/info functions Bug description: Problems with --with-mime-magic Description: When I start apache2 with php5cvs as SAPI module the error_log contains: PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:22) '' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:59) 'audio/x-aiff ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:270) 'text/plain8bit' is not a valid mimetype, etry skipped in Unknown on line 0 I use the latest PHP5 from CVS and build with: --with-mime-magic=/usr/local/apache2/conf/magic (the magicfile that comes with apache2) - is it not possible to use the magicfile from apache2? - why do the startuperros show up when I set display_startup_errors = Off in php.ini? - Apache2 exit with segmentation fault when I call the function phpinfo() - etry should be entry :-) -- Edit bug report at http://bugs.php.net/?id=26844&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26844&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26844&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26844&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26844&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26844&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26844&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26844&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26844&r=support Expected behavior: http://bugs.php.net/fix.php?id=26844&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26844&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26844&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26844&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26844&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26844&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26844&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26844&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26844&r=float
#26844 [Opn]: Problems with --with-mime-magic
ID: 26844 User updated by: php at humbapa dot ch Reported By: php at humbapa dot ch Status: Open Bug Type: PHP options/info functions Operating System: Linux 2.4.22 (Debian unstable) PHP Version: 5CVS-2004-01-08 (dev) New Comment: With the latest PHP4.3.* from CVS --with-mime-magic=/usr/local/apache2/conf/magic works without any problems Previous Comments: [2004-01-08 09:00:05] php at humbapa dot ch Description: When I start apache2 with php5cvs as SAPI module the error_log contains: PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:22) '' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:59) 'audio/x-aiff ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:270) 'text/plain8bit' is not a valid mimetype, etry skipped in Unknown on line 0 I use the latest PHP5 from CVS and build with: --with-mime-magic=/usr/local/apache2/conf/magic (the magicfile that comes with apache2) - is it not possible to use the magicfile from apache2? - why do the startuperros show up when I set display_startup_errors = Off in php.ini? - Apache2 exit with segmentation fault when I call the function phpinfo() - etry should be entry :-) -- Edit this bug report at http://bugs.php.net/?id=26844&edit=1
#26844 [Fbk->Opn]: Problems with ext/mime_magic
ID: 26844 User updated by: php at humbapa dot ch Reported By: php at humbapa dot ch -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: Linux 2.4.22 (Debian unstable) PHP Version: 5CVS-2004-01-08 (dev) New Comment: PHP5.0.0RC1-dev php.ini: display_startup_errors = Off mime_magic.debug = 1 the startuperrors are still shown at startup phpinfo() shows (this time without seg fault): mime_magic support => invalid magic file, disabled Directive => Local Value => Master Value mime_magic.debug => 1 => 1 mime_magic.magicfile => /usr/local/apache2/conf/magic => /usr/local/apache2/conf/magic there is no problem with PHP4 I think there is something wrong with the magic-file parser in PHP5 (the same file works with PHP4) Previous Comments: [2004-01-13 14:38:21] [EMAIL PROTECTED] There's new php.ini option, mime_magic.debug, try enable that in your php.ini. (add line 'mime_magic.debug = 1' in it) [2004-01-13 14:34:07] [EMAIL PROTECTED] So PHP 4 CVS works, but PHP 5 doesn't? [2004-01-09 03:25:02] php at humbapa dot ch With the latest PHP4.3.* from CVS --with-mime-magic=/usr/local/apache2/conf/magic works without any problems [2004-01-08 09:00:05] php at humbapa dot ch Description: When I start apache2 with php5cvs as SAPI module the error_log contains: PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:22) '' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:59) 'audio/x-aiff ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:270) 'text/plain8bit' is not a valid mimetype, etry skipped in Unknown on line 0 I use the latest PHP5 from CVS and build with: --with-mime-magic=/usr/local/apache2/conf/magic (the magicfile that comes with apache2) - is it not possible to use the magicfile from apache2? - why do the startuperros show up when I set display_startup_errors = Off in php.ini? - Apache2 exit with segmentation fault when I call the function phpinfo() - etry should be entry :-) -- Edit this bug report at http://bugs.php.net/?id=26844&edit=1
#26844 [Fbk->Opn]: Problems with ext/mime_magic
ID: 26844 User updated by: php at humbapa dot ch Reported By: php at humbapa dot ch -Status: Feedback +Status: Open Bug Type: *General Issues -Operating System: Linux 2.4.22 (Debian unstable) +Operating System: Linux -PHP Version: 5CVS-2004-01-08 (dev) +PHP Version: 5CVS New Comment: build with: ./configure --prefix=/usr/local/apache2 --with-apxs2=/usr/local/apache2/bin/apxs --with-config-file-path=/usr/local/apache2/conf --with-mime-magic=/usr/local/apache2/conf/magic test with (display_startup_errors = On): ./sapi/cli/php -c /usr/local/apache2/conf/php5.ini -r 'phpinfo();' result: PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:22) '' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:32) '' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:46) '' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:59) 'audio/x-aiff ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:61) 'audio/x-aiff ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:63) 'audio/x-aiff ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:67) 'audio/unknown ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:71) 'audio/unknown ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:73) 'audio/unknown ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:75) 'audio/unknown ' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:96) 'audio/prs.sid' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:104) 'image/x-xbm 7bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:123) 'application/octet-stream x-compress' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:126) 'application/octet-stream x-gzip' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:210) 'image/x-portable-bitmap 7bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:212) 'image/x-portable-greymap 7bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:214) 'image/x-portable-pixmap 7bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:270) 'text/plain8bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:280) 'message/rfc8227bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:281) 'message/rfc8227bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:282) 'message/rfc8227bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:283) 'message/rfc8227bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:284) 'message/rfc8227bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:285) 'message/rfc8227bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:286) 'message/news 8bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:287) 'message/news 8bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:288) 'message/rfc8227bit' is not a valid mimetype, etry skipped in Unknown on line 0 PHP Warning: PHP Startup: : (/usr/local/apache2/conf/magic:289) 'message/news 8bit&#
#26828 [Com]: queried bit fields are space-padded
ID: 26828
Comment by: asuter at vianetworks dot ch
Reported By: jim dot hatfield at insignia dot com
Status: Bogus
Bug Type: Sybase (dblib) related
Operating System: FreeBSD 4.5-RELEASE
PHP Version: 4.3.4
Assigned To: iliaa
New Comment:
hello,
I have the same problem with php 4.3.4 connecting to mssql 2000 from
linux using dblib + freetds 0.61
all "bit" and "datetime" fields are padded with spaces when results are
returned. previously I used php 4.2.3 which hadn't that problem.
Previous Comments:
[2004-01-09 09:13:01] jim dot hatfield at insignia dot com
I have read #26835 and don't see how it is similar.
Also #26835 refers to VARCHAR types, whereas this is
for a BIT type.
I'm confused. How can padding a BIT with 19 spaces
be right? It means that in the example, if I say
if ($row[1])
then it always evaluates TRUE. I have to coerce to int
first to get the code to work. This is code which has been
working fine since mid-2002.
[2004-01-09 08:50:34] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Not a bug.
Read previous similar reports such as #26835, etc...
[2004-01-07 21:27:35] [EMAIL PROTECTED]
See bug #25777 (assigning this to Ilia who removed this trimming from
ext/sybase)
[2004-01-07 09:19:37] jim dot hatfield at insignia dot com
Description:
Retrieve one row from a Sybase database using
DB-Lib and Freetds 0.61_1.
"manager" is a smallint and "ts_admin" is a "bit".
The first record has field values 1 and 0 for these
fields respectively.
I did a "portupgrade lang/php4" between the two runs so I know the only
thing which changed was the PHP version.
Reproduce code:
---
$db = sybase_connect($server, $user, $pass);
sybase_select_db($dbname, $db);
res =
$sybase_query("select manager, ts_admin from employees", $db)
$row = sybase_fetch_row($res);
echo "Manager = \"$row[0]\"\n";
echo "TS_Admin = \"$row[1]\"\n";
Expected result:
4.3.3 returns:
Manager = "1"
TS_Admin = "0"
Actual result:
--
4.3.4 returns:
Manager = "1"
TS_Admin = "0"
note the space padding. When tested in
an if this returns TRUE when without the
padding it is FALSE
--
Edit this bug report at http://bugs.php.net/?id=26828&edit=1
#27239 [NEW]: PHP (CLI) argument passing
From: echo15 at delirium dot ch Operating system: Linux 2.4.20 PHP version: 4.3.4 PHP Bug Type: Feature/Change Request Bug description: PHP (CLI) argument passing Description: Hi Devs I guess since 4.3.3 the arguments passed to PHP (CLI) are handled differently. Here's an example: test.php reads: ".$text."<-\n" ?> with php 4.3.2: # php test.php "text=foobar" ->foobar<- with php 4.3.3: # php test.php "text=foobar" -><- The arguments are now found only in $argv. While this makes sense at first, some people use the PHP CLI to do subrequests. Let's assume you have two webservers, one delivering WWW and another one delivering WAP content. The WAP server is doing a subrequest to the WWW server (using PHP CLI) and piping the output through a conversion script 'html2wml'. In order for this to work, the PHP CLI should hold an option to allow passing the arguments to $_POST or $_GET instead of $argv. I don't see a way to do this as of now but by adding code to the page on the WWW server which is most clumsy as this code is not needed for pages delivered to a WWW user agent. How about a command line argument like: -x (--argv-to-request) xerox arguments to $_REQUEST Many thanks for giving it a thought. -- Edit bug report at http://bugs.php.net/?id=27239&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27239&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27239&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27239&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27239&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27239&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27239&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27239&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27239&r=support Expected behavior: http://bugs.php.net/fix.php?id=27239&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27239&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27239&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27239&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27239&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27239&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27239&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27239&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27239&r=float
#27239 [Opn]: PHP (CLI) argument passing
ID: 27239 User updated by: echo15 at delirium dot ch Reported By: echo15 at delirium dot ch Status: Open Bug Type: Feature/Change Request Operating System: Linux 2.4.20 PHP Version: 4.3.4 New Comment: Oops, near the end of the feature request, I wrote: "... to allow passing the arguments to $_POST or $_GET instead of $argv." Yet what I ment was: "... to allow passing the arguments to $_REQUEST instead of $argv." Previous Comments: [2004-02-13 07:55:50] echo15 at delirium dot ch Description: Hi Devs I guess since 4.3.3 the arguments passed to PHP (CLI) are handled differently. Here's an example: test.php reads: ".$text."<-\n" ?> with php 4.3.2: # php test.php "text=foobar" ->foobar<- with php 4.3.3: # php test.php "text=foobar" -><- The arguments are now found only in $argv. While this makes sense at first, some people use the PHP CLI to do subrequests. Let's assume you have two webservers, one delivering WWW and another one delivering WAP content. The WAP server is doing a subrequest to the WWW server (using PHP CLI) and piping the output through a conversion script 'html2wml'. In order for this to work, the PHP CLI should hold an option to allow passing the arguments to $_POST or $_GET instead of $argv. I don't see a way to do this as of now but by adding code to the page on the WWW server which is most clumsy as this code is not needed for pages delivered to a WWW user agent. How about a command line argument like: -x (--argv-to-request) xerox arguments to $_REQUEST Many thanks for giving it a thought. -- Edit this bug report at http://bugs.php.net/?id=27239&edit=1
#27239 [Opn]: PHP (CLI) argument passing
ID: 27239 User updated by: echo15 at delirium dot ch Reported By: echo15 at delirium dot ch Status: Open Bug Type: Feature/Change Request Operating System: Linux 2.4.20 PHP Version: 4.3.4 New Comment: And... no, creating a real HTTP subrequest to the WWW server in the example above does not always do the trick, specially not if the page is password protected. You don't want to have plain passwords in the PHP pages on the WAP server and it's slower than using PHP CLI. Previous Comments: [2004-02-13 07:58:55] echo15 at delirium dot ch Oops, near the end of the feature request, I wrote: "... to allow passing the arguments to $_POST or $_GET instead of $argv." Yet what I ment was: "... to allow passing the arguments to $_REQUEST instead of $argv." [2004-02-13 07:55:50] echo15 at delirium dot ch Description: Hi Devs I guess since 4.3.3 the arguments passed to PHP (CLI) are handled differently. Here's an example: test.php reads: ".$text."<-\n" ?> with php 4.3.2: # php test.php "text=foobar" ->foobar<- with php 4.3.3: # php test.php "text=foobar" -><- The arguments are now found only in $argv. While this makes sense at first, some people use the PHP CLI to do subrequests. Let's assume you have two webservers, one delivering WWW and another one delivering WAP content. The WAP server is doing a subrequest to the WWW server (using PHP CLI) and piping the output through a conversion script 'html2wml'. In order for this to work, the PHP CLI should hold an option to allow passing the arguments to $_POST or $_GET instead of $argv. I don't see a way to do this as of now but by adding code to the page on the WWW server which is most clumsy as this code is not needed for pages delivered to a WWW user agent. How about a command line argument like: -x (--argv-to-request) xerox arguments to $_REQUEST Many thanks for giving it a thought. -- Edit this bug report at http://bugs.php.net/?id=27239&edit=1
#27246 [NEW]: fastcgi segfaults on faulty pages
From: pmoor at netpeople dot ch Operating system: linux PHP version: 5.0.0b4 (beta4) PHP Bug Type: CGI related Bug description: fastcgi segfaults on faulty pages Description: When using php as a fastcgi application (with apache) it segfaults after reloading a page which contains php-errors two times. reproduce: - create page which contains errors - load page in browser - refresh once - refresh twice -> segfault (500 internal server error) log entry: ...terminated due to uncaught signal '11' (Segmentation fault) the same config for fastcgi worked with v4.x it also worked before (5.0.0RC1-dev). -- Edit bug report at http://bugs.php.net/?id=27246&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27246&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27246&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27246&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27246&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27246&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27246&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27246&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27246&r=support Expected behavior: http://bugs.php.net/fix.php?id=27246&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27246&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27246&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27246&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27246&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27246&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27246&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27246&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27246&r=float
#27246 [Fbk->Csd]: fastcgi segfaults on faulty pages
ID: 27246 User updated by: pmoor at netpeople dot ch Reported By: pmoor at netpeople dot ch -Status: Feedback +Status: Closed Bug Type: CGI related Operating System: linux PHP Version: 5.0.0b4 (beta4) New Comment: recompiled it and discovered problems with openssl libraries. (mysql libraries compiled with older ones than php). i disabled mysql and now it works like a charm. sorry for bothering you... Previous Comments: [2004-02-14 12:26:19] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-02-13 15:52:12] pmoor at netpeople dot ch Description: When using php as a fastcgi application (with apache) it segfaults after reloading a page which contains php-errors two times. reproduce: - create page which contains errors - load page in browser - refresh once - refresh twice -> segfault (500 internal server error) log entry: ...terminated due to uncaught signal '11' (Segmentation fault) the same config for fastcgi worked with v4.x it also worked before (5.0.0RC1-dev). -- Edit this bug report at http://bugs.php.net/?id=27246&edit=1
#27375 [NEW]: $DOCUMENT_ROOT sometimes empty when register_globals=on
From: oliver at update dot ch Operating system: Linux PHP version: 4CVS-2004-02-24 (stable) PHP Bug Type: Apache2 related Bug description: $DOCUMENT_ROOT sometimes empty when register_globals=on Description: The Global Variable $GLOBALS["DOCUMENT_ROOT"] or $DOCUMENT_ROOT is sometimes empty. After a reload $DOCUMENT_ROOT mostly contains the expected value. see also http://bugs.php.net/bug.php?id=25172 -- Edit bug report at http://bugs.php.net/?id=27375&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27375&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27375&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27375&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27375&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27375&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27375&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27375&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27375&r=support Expected behavior: http://bugs.php.net/fix.php?id=27375&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27375&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27375&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27375&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27375&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27375&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27375&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27375&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27375&r=float
#27375 [Fbk->Opn]: $DOCUMENT_ROOT sometimes empty when register_globals=on
ID: 27375 User updated by: oliver at update dot ch Reported By: oliver at update dot ch -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux PHP Version: 4CVS-2004-02-24 (stable) New Comment: register_globals is always set on. register_globals is set to on in the php.ini file. SERVER_SOFTWARE: Apache/2.0.47 (Unix) mod_perl/1.99_09 Perl/v5.6.1 mod_ssl/2.0.47 OpenSSL/0.9.6c DAV/2 FrontPain/5.0.0.0 Previous Comments: [2004-02-24 12:03:10] [EMAIL PROTECTED] When this happens, is register_globals on or off? Do you override it in some vhost ? How do you do it? In other words: Not enough information.. [2004-02-24 07:30:00] oliver at update dot ch Description: The Global Variable $GLOBALS["DOCUMENT_ROOT"] or $DOCUMENT_ROOT is sometimes empty. After a reload $DOCUMENT_ROOT mostly contains the expected value. see also http://bugs.php.net/bug.php?id=25172 -- Edit this bug report at http://bugs.php.net/?id=27375&edit=1
#19918 [NoF->Csd]: no libphp4.so produced
ID: 19918 User updated by: mad at dactar dot ch Reported By: mad at dactar dot ch -Status: No Feedback +Status: Closed Bug Type: Compile Failure Operating System: HP-UX 11.00 PHP Version: 4.3.1 New Comment: Successfully tested with apache 1.3.27 AND apache 2.0.44 Thanks @++ JC Previous Comments: [2003-02-25 02:04:12] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-18 22:58:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I have added a possible fix for this problem. Now if crypt() is found in libc, then we don't force adding of libcrypt anymore. [2003-02-18 13:57:51] mad at dactar dot ch This workarround (replace -lcrypt by -lc) works. Someone of php's staff can analyse this problem and correct it please ? Thanks @++ JC PS 4 kbrott : thanks very very much :)) [2003-02-18 13:57:18] mad at dactar dot ch This workarround (replace -lcrypt by -lc). Someone of php's staff can analyse this problem and correct it please ? Thanks @++ JC PS 4 kbrott : thanks very very much :)) [2003-02-05 18:15:34] kbrott at eli dot net Reproduced bug on patched-to-current HP-UX 11.00 system trying to build php-4.3.0 against apache httpd 2.0.43 (as well as the php-200301290030.tar.gz snapshot). Have determined cause and offer working solution (well - it worked on my systems anyway). Here's the config.nice that I used for this instance: #! /bin/sh # # Created by configure CFLAGS='-O3' \ LDFLAGS='-L/opt/admin/lib -L/opt/tools/lib' \ CC='gcc' \ './configure' \ '--prefix=/opt/php4' \ '--with-apxs2=/opt/apache/sbin/apxs' \ '--enable-shared' \ '--enable-force-cgi-redirect' \ '--with-openssl=/opt/tools' \ '--with-zlib=/opt/tools' \ '--enable-bcmath' \ '--with-bz2=/opt/tools' \ '--enable-calendar' \ '--enable-dba' \ '--with-gdbm=/opt/tools' \ '--with-db3=/opt/tools' \ '--with-flatfile' \ '--enable-dbase' \ '--enable-dbx' \ '--enable-ftp' \ '--with-gmp=/opt/tools' \ '--with-mysql=/opt/mysql' \ '--enable-mime-magic' \ '--with-ldap=/opt/tools' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-readline=/opt/tools' \ "$@" HP's linker via libtool (apache2 or otherwise) cannot seem to use a lib(anything).a to make a shared library file (at least not in this instance - I gave up on it after a couple of months) - so the trick is to make sure not to call any static libraries. HP moved all of the shared crpyt functions into libc ( as of HP-UX 10.20 see <http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=20062689279> ). So all calls in ./configure for HP-UX 11.00 should use -lc instead of -lcrypt for the crypt_r/ calls (tested - it works). HP has completely deprecated termcap usage ( see <http://devrsrc1.external.hp.com/STK/impacts/i409.html>, <http://devrsrc1.external.hp.com/STK/partner/xcurses.html>, and more specifically <http://h21007.www2.hp.com/hpux-devtools/CXX/hpux-devtools.0012/0052.html> ) so you have to use libcurses instead if you want to access a shared library with those functions. So all calls in ./configure when OS=hpux11 should use -lcurses instead of -ltermcap for the tgetent calls (tested - it works). Making these changes to ./configure, executing ./config.nice, then doing make, make install allowed compilation and installation with no problems (well, once I rebuilt bzip2 with a shared libbz2 that is). Feel free to ping me with questions - I have a working php 4.3.0 install running on HP-UX 11.00 as a shared install under apache 2.0.43 now so I must have done something right. :) 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/19918 -- Edit this bug report at http://bugs.php.net/?id=19918&edit=1
#19452 [NoF->Csd]: Apache2 with php4 freeze on HP-UX 11.00
ID: 19452 User updated by: mad at dactar dot ch Reported By: mad at dactar dot ch -Status: No Feedback +Status: Closed Bug Type: Apache2 related Operating System: HP-UX 11.00 PHP Version: 4CVS-2002-09-17 New Comment: Don't freeze anymore with 99% of the CPU Previous Comments: [2002-12-06 19:13:44] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-11-25 06:30:30] [EMAIL PROTECTED] Maybe you should, since this other dude is able to compile it fine..did you happen to read what the suggestion was? [2002-11-25 06:10:23] mad at dactar dot ch I can't test anymore as long the bug #19918 is not corrected @++ JC [2002-11-23 13:31:33] [EMAIL PROTECTED] Please try what csoto suggested. [2002-11-22 15:58:47] csoto at mail dot utexas dot edu I solved my problem by installing the linker (ld) cumulative patch, available from HP. In my 11.11/s800 environment, I used PHSS_26560. For more information, see http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x32d6cdec06f1d61190050090279cd0f9,00.html You might try this and report back here. Charles 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/19452 -- Edit this bug report at http://bugs.php.net/?id=19452&edit=1
#22620 [NEW]: gmmktime returns bogus STILL in 4.3.1
From: space at arch dot ch Operating system: Windows 2000 PHP version: 4.3.1 PHP Bug Type: Date/time related Bug description: gmmktime returns bogus STILL in 4.3.1 c'mon guys. this is a real pain: on windows systems gmmktime returns bogus. the bug has been known for at least 2 years! it's been reported more than once! will this finally be fixed or not??? there have been other bug reports, but all of them seem to have been ignored so far, although this is NOT some minor issue! at least include a documentation of the bug in the php manual for gmmktime if you do not intend to fix it! [..saying that the function cannot be used on win platforms] :(( as seen in other posts. try: gmmktime(0,0,0,1,1,1970); which should return 0 but does not [unless you are in GMT]!!! -- Edit bug report at http://bugs.php.net/?id=22620&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22620&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22620&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22620&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22620&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22620&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22620&r=support Expected behavior: http://bugs.php.net/fix.php?id=22620&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22620&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22620&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22620&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22620&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22620&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22620&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22620&r=gnused
#22620 [Ana]: gmmktime returns bogus STILL in 4.3.1
ID: 22620 User updated by: space at arch dot ch Reported By: space at arch dot ch Status: Analyzed -Bug Type: Documentation problem +Bug Type: Date/time related Operating System: Windows 2000 PHP Version: 4.3.1 New Comment: please at least read the post! this is a WINDOWS issue. *nix/solaris installations do not have the problem! #22457 seemed to be about win. the reply about unix. [???] again: - gmmktime(0,0,0,1,1,1970); gives: Warning: gmmktime() [function.gmmktime]: Windows does not support negative values for this function - why? #14391 is referred in #22457 and describes the problem thoroghly. but no solution has been presented since 2 years. the question is, if this will be fixed for windows platforms or not. Previous Comments: [2003-03-10 09:45:21] [EMAIL PROTECTED] See bug #22457 [2003-03-10 06:01:07] space at arch dot ch c'mon guys. this is a real pain: on windows systems gmmktime returns bogus. the bug has been known for at least 2 years! it's been reported more than once! will this finally be fixed or not??? there have been other bug reports, but all of them seem to have been ignored so far, although this is NOT some minor issue! at least include a documentation of the bug in the php manual for gmmktime if you do not intend to fix it! [..saying that the function cannot be used on win platforms] :(( as seen in other posts. try: gmmktime(0,0,0,1,1,1970); which should return 0 but does not [unless you are in GMT]!!! -- Edit this bug report at http://bugs.php.net/?id=22620&edit=1
#22351 [Com]: Error in gdttf.c ??
ID: 22351 Comment by: mad at dactar dot ch Reported By: j dot lammerts at chello dot nl Status: No Feedback Bug Type: GD related Operating System: AIX 4.3.3 PHP Version: 4CVS-2003-02-21 (stable) New Comment: I had the same problem but not exactly the same errors. I've added --enable-gd-native-ttf to the configure line and it works :) Version tested : php-4.3.2RC1 @++ JC Previous Comments: [2003-03-09 18:58:08] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-03-04 20:16:04] [EMAIL PROTECTED] Any update on this? [2003-02-28 07:17:55] j dot lammerts at chello dot nl Will try this, but it will be next week... Thanks [2003-02-26 19:15:00] [EMAIL PROTECTED] Could you try adding --enable-gd-native-ttf to you configure line and if that does not help try upgrading to a later version of FreeType 2. [2003-02-24 03:11:30] j dot lammerts at chello dot nl The freetype version is 2.0.1.0, and AFAIK it is the only version installed on our system. 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/22351 -- Edit this bug report at http://bugs.php.net/?id=22351&edit=1
#24043 [NEW]: include()/require() not working properly with absolute URL
From: delmatto at genotec dot ch
Operating system: Debian GNU/Linux 3.0 / stable
PHP version: 4.3.2
PHP Bug Type: URL related
Bug description: include()/require() not working properly with absolute URL
Hi Folks
Whenever using include() / require() with an absolute URL, eg.
include("http://some.site.com/some/file";), I get something like the
following prepended to the included file:
Date: Thu, 05 Jun 2003 13:38:27 GMT Content-Type: text/html Accept-Ranges:
bytes Last-Modified: Thu, 05 Jun 2003 13:00:20 GMT ETag:
"b0d9d6b622bc31:7d6" Content-Length: 12071
This always happens when using 'http://' in the include()/require()
statement. However, when running the same code on the command line, the
file is included without this 'header' beeing prepended, it only happens
when doing so over the web-server.
When using a simple include("/path/to/file") everything seems fine.
I'm running Debian 3.0 stable w/Apache 1.3.26. PHP is 4.3.2 linked against
the current Debian dev packages of Apache.
The problem also exists with PHP 4.3 and 4.3.1. I don't
know wether this is also true for older versions.
Any help on this would be appreciated.
Thank You.
--
phpinfo()
PHP Version => 4.3.2
System => Linux gic-web-lin-01 2.4.18 #16 Thu Feb 6 15:32:27 UTC 2003
i686
Build Date => Jun 5 2003 15:30:33
Configure Command => './configure' '--host=i386-linux'
'--build=i386-linux' '--prefix=/usr' '--mandir=${prefix}/share/man'
'--infodir=${prefix}/share/info' '--with-apxs=/usr/bin/apxs'
'--with-config-file-path=/etc/php4/apache' '--disable-rpath'
'--disable-debug' '--enable-memory-limit' '--with-layout=GNU'
'--with-regex=php' '--enable-track-vars' '--enable-sysvsem'
'--enable-sysvshm' '--enable-trans-sid' '--enable-calendar'
'--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db2'
'--with-pdflib=/usr' '--with-mcrypt' '--with-iconv' '--enable-exif'
'--enable-flatfile' '--with-gettext' '--enable-mbstring'
'--with-pcre-regex=/usr' '--enable-sockets' '--enable-wddx' '--enable-xml'
'--disable-shared' '--enable-static' '--with-expat-dir=/usr' '--with-zlib'
'--with-openssl=/usr' '--with-dom=/usr' '--with-dom-xslt=/usr'
'--with-dom-exslt=/usr' '--with-zlib-dir=/usr' '--with-gd=/usr'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr'
'--with-imap=/usr' '--with-imap-ssl=/usr' '--with-mcal=/usr'
'--with-mhash=/usr' '--with-mm' '--with-mysql=/usr' '--with-recode=/usr'
'--enable-xslt' '--with-xslt-sablot=/usr' '--with-ttf=/usr'
'--with-t1lib=/usr' '--with-ming' '--with-xpm-dir=/usr'
'--with-sybase=/usr/share/freetds0' '--with-pgsql' '--with-pear'
'--enable-ftp'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc/php4/apache/php.ini
PHP API => 20020918
PHP Extension => 20020429
Zend Extension => 20021010
Debug Build => no
Thread Safety => disabled
Registered PHP Streams => php, http, ftp, https, ftps, compress.bzip2,
compress.zlib
This program makes use of the Zend Scripting Language Engine:
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
with Zend Optimizer v2.0.3, Copyright (c) 1998-2002, by Zend
Technologies
___
Configuration
PHP Core
Directive => Local Value => Master Value
allow_call_time_pass_reference => Off => Off
allow_url_fopen => On => On
always_populate_raw_post_data => Off => Off
arg_separator.input => & => &
arg_separator.output => & => &
asp_tags => Off => Off
auto_append_file => no value => no value
auto_prepend_file => no value => no value
browscap => no value => no value
default_charset => no value => no value
default_mimetype => text/html => text/html
define_syslog_variables => Off => Off
disable_classes => no value => no value
disable_functions => system,exec,shell_exec,passthru,phpinfo =>
system,exec,shell_exec,passthru,phpinfo
display_errors => Off => Off
display_startup_errors => Off => Off
doc_root => no value => no value
docref_ext => no value => no value
docref_root => no value => no value
enable_d
#24043 [Fbk->Opn]: include()/require() not working properly with absolute URL
ID: 24043
User updated by: delmatto at genotec dot ch
Reported By: delmatto at genotec dot ch
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Debian GNU/Linux 3.0 / stable
PHP Version: 4.3.2
New Comment:
While another problem not mentioned here has gone,
the one described still remains as of snapshot 4.3.3-200306061130.
Could old dev headers be the source for this problem? I mean, not all
dev-headers are
up to date since I had to stick to some from debian stable...
Just for your reference, I used the following to compile PHP:
apache 1.3.26-dev (debian3/stable)
curl 7.10.2
gd 2.0.9 (not the one shipped with php)
libxml 2.4.30
mind 0.2a
pdflib 4.0.3
sablot 0.96.1
xslt 1.0.23
freetds 0.53
libexpat 1.95.2
openssl 0.96c
libjpeg62 6b
libpng2 1.0.12
freetype6 2.0.9
libmcal 0.6
mhash 0.8.14
pcre3 3.4
recode 3.6
mcrypt 2.5.0
pgsql 7.2.1
I hope I didn't miss one out.
Previous Comments:
[2003-06-06 02:11:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-06-05 10:56:28] delmatto at genotec dot ch
Hi Folks
Whenever using include() / require() with an absolute URL, eg.
include("http://some.site.com/some/file";), I get something like the
following prepended to the included file:
Date: Thu, 05 Jun 2003 13:38:27 GMT Content-Type: text/html
Accept-Ranges: bytes Last-Modified: Thu, 05 Jun 2003 13:00:20 GMT ETag:
"b0d9d6b622bc31:7d6" Content-Length: 12071
This always happens when using 'http://' in the include()/require()
statement. However, when running the same code on the command line, the
file is included without this 'header' beeing prepended, it only
happens when doing so over the web-server.
When using a simple include("/path/to/file") everything seems fine.
I'm running Debian 3.0 stable w/Apache 1.3.26. PHP is 4.3.2 linked
against the current Debian dev packages of Apache.
The problem also exists with PHP 4.3 and 4.3.1. I don't
know wether this is also true for older versions.
Any help on this would be appreciated.
Thank You.
--
phpinfo()
PHP Version => 4.3.2
System => Linux gic-web-lin-01 2.4.18 #16 Thu Feb 6 15:32:27 UTC 2003
i686
Build Date => Jun 5 2003 15:30:33
Configure Command => './configure' '--host=i386-linux'
'--build=i386-linux' '--prefix=/usr' '--mandir=${prefix}/share/man'
'--infodir=${prefix}/share/info' '--with-apxs=/usr/bin/apxs'
'--with-config-file-path=/etc/php4/apache' '--disable-rpath'
'--disable-debug' '--enable-memory-limit' '--with-layout=GNU'
'--with-regex=php' '--enable-track-vars' '--enable-sysvsem'
'--enable-sysvshm' '--enable-trans-sid' '--enable-calendar'
'--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db2'
'--with-pdflib=/usr' '--with-mcrypt' '--with-iconv' '--enable-exif'
'--enable-flatfile' '--with-gettext' '--enable-mbstring'
'--with-pcre-regex=/usr' '--enable-sockets' '--enable-wddx'
'--enable-xml' '--disable-shared' '--enable-static'
'--with-expat-dir=/usr' '--with-zlib' '--with-openssl=/usr'
'--with-dom=/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr'
'--with-zlib-dir=/usr' '--with-gd=/usr' '--with-jpeg-dir=/usr'
'--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-imap=/usr'
'--with-imap-ssl=/usr' '--with-mcal=/usr' '--with-mhash=/usr'
'--with-mm' '--with-mysql=/usr' '--with-recode=/usr' '--enable-xslt'
'--with-xslt-sablot=/usr' '--with-ttf=/usr' '--with-t1lib=/usr'
'--with-ming' '--with-xpm-dir=/usr' '--with-sybase=/usr/share/freetds0'
'--with-pgsql' '--with-pear' '--enable-ftp'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc/php4/apache/php.ini
PHP API => 20020918
PHP Extension => 20020429
Zend Extension => 20021010
Debug Build => no
Thread Safety => disabled
Registered PHP Streams => php, http, ftp, https, ftps, compress.bzip2,
compress.zlib
This program makes use of the Zend Scripting Language Engine:
Zend Engine v1
#24043 [Fbk->Opn]: include()/require() not working properly with absolute URL
ID: 24043
User updated by: delmatto at genotec dot ch
Reported By: delmatto at genotec dot ch
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Debian GNU/Linux 3.0 / stable
PHP Version: 4.3.2
New Comment:
use the following for a server running php 4.3.1 (original config)
http://212.80.185.102/test.php (->
http://212.80.185.102/php/gd/index.php)
http://212.80.185.102/test2.php (->
http://support.genotec.ch/main.asp)
here the error happens, no matter wether I include from
the same server or from an external one as in the later case.
now these for the server running 4.3.3-dev snapshot
http://212.80.185.101/test.php (->
http://212.80.185.101/php/gd/index.php)
http://212.80.185.101/test2.php (->
http://support.genotec.ch/main.asp)
here comes a very strange behaviour as it sometimes works without this
'headers' and sometimes the page even stays blank, then I find the
following in the error log:
[Sat Jun 7 09:34:29 2003] [error] PHP Warning:
main(http://gic-web-lin-01.genotec.ch/php/gd/index.php): failed to open
stream: HTTP request failed! [EMAIL PROTECTED]@P_P ␋[EMAIL PROTECTED]@T
␋┼
/┴▒⎼/␌␌/├␍⎺␌⎽/␍␊°▒┤┌├/├␊⎽├.⎻⎻
⎺┼ ┌␋┼␊ 4
to reproduce just try to reload the page a few times.
I'm not sure wether this header problem is gone now,
though the error shown in the log was only introduced when using the
new snapshot. It seems like it would only happen when including from
the same server, not from an external one, as I couldn't reproduce it
on the second url.
PHP4 ist running as mod_php in Apache. There is no mod_php3. CGI is not
specifically configured in apache,
however I didn't use the '--disable-cgi' switch when building PHP, if
anyone happens to rename a .php file to
.cgi and adds a #!/usr/bin/php to the top of the file, it
would run over cgi/suexec.
Normal .php/php3/phtml files run through mod_php.
Previous Comments:
[2003-06-06 18:40:38] [EMAIL PROTECTED]
Can you give some example script which definately fails for you
everytime? (using some url anybody can access)
Do you happen to have also CGI version of PHP configured
in your Apache? Or PHP 3 as module?
[2003-06-06 12:31:23] delmatto at genotec dot ch
While another problem not mentioned here has gone,
the one described still remains as of snapshot 4.3.3-200306061130.
Could old dev headers be the source for this problem? I mean, not all
dev-headers are
up to date since I had to stick to some from debian stable...
Just for your reference, I used the following to compile PHP:
apache 1.3.26-dev (debian3/stable)
curl 7.10.2
gd 2.0.9 (not the one shipped with php)
libxml 2.4.30
mind 0.2a
pdflib 4.0.3
sablot 0.96.1
xslt 1.0.23
freetds 0.53
libexpat 1.95.2
openssl 0.96c
libjpeg62 6b
libpng2 1.0.12
freetype6 2.0.9
libmcal 0.6
mhash 0.8.14
pcre3 3.4
recode 3.6
mcrypt 2.5.0
pgsql 7.2.1
I hope I didn't miss one out.
[2003-06-06 02:11:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
----
[2003-06-05 10:56:28] delmatto at genotec dot ch
Hi Folks
Whenever using include() / require() with an absolute URL, eg.
include("http://some.site.com/some/file";), I get something like the
following prepended to the included file:
Date: Thu, 05 Jun 2003 13:38:27 GMT Content-Type: text/html
Accept-Ranges: bytes Last-Modified: Thu, 05 Jun 2003 13:00:20 GMT ETag:
"b0d9d6b622bc31:7d6" Content-Length: 12071
This always happens when using 'http://' in the include()/require()
statement. However, when running the same code on the command line, the
file is included without this 'header' beeing prepended, it only
happens when doing so over the web-server.
When using a simple include("/path/to/file") everything seems fine.
I'm running Debian 3.0 stable w/Apache 1.3.26. PHP is 4.3.2 linked
against the current Debian dev packages of Apache.
The problem also exists with PHP 4.3 and 4.3.1. I don't
know wether this is also true for older versions.
Any help on this would be appreciated.
Thank You.
--
phpinfo()
PHP Version => 4.3.2
System => Linux gic-web-lin-01 2.4.18 #16 Thu Feb 6 15:32:27 UTC 2003
i686
Build Date => Jun 5 2003 15:30:33
Configure Command => './configure' '--host=i386-linux'
'--build=i386-linux' '--prefix=/usr' '--mandir=${prefix}/share/man'
'--infodir=${prefix}/share/info' '--with-apxs=/usr/bi
#24043 [Fbk->Opn]: include()/require() not working properly with absolute URL
ID: 24043 User updated by: delmatto at genotec dot ch Reported By: delmatto at genotec dot ch -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Debian GNU/Linux 3.0 / stable PHP Version: 4.3.2 New Comment: I am Sorry, I understood you wantet a working link to see the scripts in action... This is the code of the two test files I use: ---begin test.php--- http://gic-web-lin-01.genotec.ch/php/gd/index.php";); ?> ---end--- ---begin test2.php--- http://support.genotec.ch/main.asp";); ?> ---end--- Previous Comments: [2003-06-07 04:52:43] [EMAIL PROTECTED] I asked for a SOURCE of a script that I can run myself. [2003-06-07 02:54:51] delmatto at genotec dot ch use the following for a server running php 4.3.1 (original config) http://212.80.185.102/test.php (-> http://212.80.185.102/php/gd/index.php) http://212.80.185.102/test2.php (-> http://support.genotec.ch/main.asp) here the error happens, no matter wether I include from the same server or from an external one as in the later case. now these for the server running 4.3.3-dev snapshot http://212.80.185.101/test.php (-> http://212.80.185.101/php/gd/index.php) http://212.80.185.101/test2.php (-> http://support.genotec.ch/main.asp) here comes a very strange behaviour as it sometimes works without this 'headers' and sometimes the page even stays blank, then I find the following in the error log: [Sat Jun 7 09:34:29 2003] [error] PHP Warning: main(http://gic-web-lin-01.genotec.ch/php/gd/index.php): failed to open stream: HTTP request failed! [EMAIL PROTECTED]@P_P ␋[EMAIL PROTECTED]@T ␋┼ /┴▒⎼/␌␌/├␍⎺␌⎽/␍␊°▒┤┌├/├␊⎽├.⎻⎻ ⎺┼ ┌␋┼␊ 4 to reproduce just try to reload the page a few times. I'm not sure wether this header problem is gone now, though the error shown in the log was only introduced when using the new snapshot. It seems like it would only happen when including from the same server, not from an external one, as I couldn't reproduce it on the second url. PHP4 ist running as mod_php in Apache. There is no mod_php3. CGI is not specifically configured in apache, however I didn't use the '--disable-cgi' switch when building PHP, if anyone happens to rename a .php file to .cgi and adds a #!/usr/bin/php to the top of the file, it would run over cgi/suexec. Normal .php/php3/phtml files run through mod_php. [2003-06-06 18:40:38] [EMAIL PROTECTED] Can you give some example script which definately fails for you everytime? (using some url anybody can access) Do you happen to have also CGI version of PHP configured in your Apache? Or PHP 3 as module? ---- [2003-06-06 12:31:23] delmatto at genotec dot ch While another problem not mentioned here has gone, the one described still remains as of snapshot 4.3.3-200306061130. Could old dev headers be the source for this problem? I mean, not all dev-headers are up to date since I had to stick to some from debian stable... Just for your reference, I used the following to compile PHP: apache 1.3.26-dev (debian3/stable) curl 7.10.2 gd 2.0.9 (not the one shipped with php) libxml 2.4.30 mind 0.2a pdflib 4.0.3 sablot 0.96.1 xslt 1.0.23 freetds 0.53 libexpat 1.95.2 openssl 0.96c libjpeg62 6b libpng2 1.0.12 freetype6 2.0.9 libmcal 0.6 mhash 0.8.14 pcre3 3.4 recode 3.6 mcrypt 2.5.0 pgsql 7.2.1 I hope I didn't miss one out. [2003-06-06 02:11:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 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/24043 -- Edit this bug report at http://bugs.php.net/?id=24043&edit=1
#23832 [Bgs->Csd]: ./configure option
ID: 23832 User updated by: 666 at sicap dot ch Reported By: 666 at sicap dot ch -Status: Bogus +Status: Closed Bug Type: *Compile Issues Operating System: Sun Solaris 8 PHP Version: 4.3.1 New Comment: It does not just ignore all unknown options. When I type e. g. ./configure --foo then it returns configure: error: unrecognized option: --foo I guess, that when the name of the option is a long name, and when it is written wrong near the end, then configure just ignoes it. Previous Comments: [2003-05-27 18:25:47] michael-phpbugs at emdee dot net Same everything, except I was entering --with-axps= [2003-05-27 17:47:29] [EMAIL PROTECTED] This is how autoconf works, it just ignores all non-existing options instead of complaining about them. Not PHP issue. [2003-05-27 09:49:41] 666 at sicap dot ch Using ./configure --with-apx2= instead of ./configure --with-apxs2= will not return the error: invalid option. Instead the configure process is running without errors and finally there is no libphp4.so file created. Regards Marcel -- Edit this bug report at http://bugs.php.net/?id=23832&edit=1
#23847 [NEW]: ../libphp4.so: invalid ELF header
From: eddie at rola dot ch Operating system: SuSE Linux Prof. 8.0 PHP version: 4.3.2RC4 PHP Bug Type: *Configuration Issues Bug description: ../libphp4.so: invalid ELF header After installing Apache 2.0.46 on the Webserver (--enable-so --with-layout=SuSE) and PHP 4.3.2RC4 (--with-apxs2=/usr/sbin/apxs) no warnings or failure messages has benn showed. The Configuration file of Apache had a wrong path of the libphp4.so (LoadModule). After I've changed it the failure message came by starting the webserver (Check Summary). Here the whole message: Cannot load /usr/lib/libphp4.so into server: invalid EFL header PS:I had no failure message before (like: cannot find libphp4.so) but the file can't be there [/usr/lib/apache/libphp4.do] because I don't have that file. After all php doesn't work without any failure messages. -- Edit bug report at http://bugs.php.net/?id=23847&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=23847&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=23847&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=23847&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=23847&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=23847&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=23847&r=support Expected behavior: http://bugs.php.net/fix.php?id=23847&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=23847&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=23847&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=23847&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23847&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=23847&r=dst IIS Stability: http://bugs.php.net/fix.php?id=23847&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=23847&r=gnused
#23847 [Fbk->Opn]: ../libphp4.so: invalid ELF header
ID: 23847 User updated by: eddie at rola dot ch Reported By: eddie at rola dot ch -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: SuSE Linux Prof. 8.0 PHP Version: 4.3.2RC4 New Comment: I've never changed any configuration file under php4 path. That isn't necessary! I've change the path of the 'LoadModule' in "httpd.conf". I will try to use the CVS latest version. I hope a developer version can fix it. ;) Previous Comments: [2003-05-28 08:55:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip And don't try fixing anything in any configure file under the php4*/ directory. I'm 100% sure this is not any bug in PHP though, you're just doing something wrong there. (I just compiled the latest CVS snapshot with apache2 and it worked fine.) It's propably SuSE again that is broken here. -------- [2003-05-28 05:48:35] eddie at rola dot ch After installing Apache 2.0.46 on the Webserver (--enable-so --with-layout=SuSE) and PHP 4.3.2RC4 (--with-apxs2=/usr/sbin/apxs) no warnings or failure messages has benn showed. The Configuration file of Apache had a wrong path of the libphp4.so (LoadModule). After I've changed it the failure message came by starting the webserver (Check Summary). Here the whole message: Cannot load /usr/lib/libphp4.so into server: invalid EFL header PS:I had no failure message before (like: cannot find libphp4.so) but the file can't be there [/usr/lib/apache/libphp4.do] because I don't have that file. After all php doesn't work without any failure messages. -- Edit this bug report at http://bugs.php.net/?id=23847&edit=1
#23847 [Fbk->Opn]: ../libphp4.so: invalid ELF header
ID: 23847 User updated by: eddie at rola dot ch Reported By: eddie at rola dot ch -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: SuSE Linux Prof. 8.0 PHP Version: 4.3.2RC4 New Comment: Now failure messages anymore, but PHP still doesn't work. All my php files are showing the source code. Did I forgot something? I thought the configuration settigs would be sufficient: Apache: --with-layout=SuSE --enable-so PHP: --with-apxs2=/usr/sbin/apxs They are, right?? Previous Comments: [2003-05-28 09:03:40] eddie at rola dot ch I've never changed any configuration file under php4 path. That isn't necessary! I've change the path of the 'LoadModule' in "httpd.conf". I will try to use the CVS latest version. I hope a developer version can fix it. ;) [2003-05-28 08:55:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip And don't try fixing anything in any configure file under the php4*/ directory. I'm 100% sure this is not any bug in PHP though, you're just doing something wrong there. (I just compiled the latest CVS snapshot with apache2 and it worked fine.) It's propably SuSE again that is broken here. ---- [2003-05-28 05:48:35] eddie at rola dot ch After installing Apache 2.0.46 on the Webserver (--enable-so --with-layout=SuSE) and PHP 4.3.2RC4 (--with-apxs2=/usr/sbin/apxs) no warnings or failure messages has benn showed. The Configuration file of Apache had a wrong path of the libphp4.so (LoadModule). After I've changed it the failure message came by starting the webserver (Check Summary). Here the whole message: Cannot load /usr/lib/libphp4.so into server: invalid EFL header PS:I had no failure message before (like: cannot find libphp4.so) but the file can't be there [/usr/lib/apache/libphp4.do] because I don't have that file. After all php doesn't work without any failure messages. -- Edit this bug report at http://bugs.php.net/?id=23847&edit=1
#24043 [Bgs]: include()/require() not working properly with absolute URL
ID: 24043 User updated by: delmatto at genotec dot ch Reported By: delmatto at genotec dot ch Status: Bogus Bug Type: Scripting Engine problem Operating System: Debian GNU/Linux 3.0 / stable PHP Version: 4.3.2 New Comment: Well, actually not the answer I expected ;-) Since I really *need* to fix this, I'd appreciate some thoughts on how to find the source of this problem. If you say, it ain't a bug in PHP, then it's propably a local configuration issue (php.ini/apache.conf/etc) or a compiling issue (compiler version/libc/dev headers). what do you think about that? any ideas? Previous Comments: [2003-06-09 08:15:58] [EMAIL PROTECTED] Both scripts work just fine. No bug. [2003-06-07 05:03:32] delmatto at genotec dot ch I am Sorry, I understood you wantet a working link to see the scripts in action... This is the code of the two test files I use: ---begin test.php--- http://gic-web-lin-01.genotec.ch/php/gd/index.php";); ?> ---end--- ---begin test2.php--- http://support.genotec.ch/main.asp";); ?> ---end--- [2003-06-07 04:52:43] [EMAIL PROTECTED] I asked for a SOURCE of a script that I can run myself. [2003-06-07 02:54:51] delmatto at genotec dot ch use the following for a server running php 4.3.1 (original config) http://212.80.185.102/test.php (-> http://212.80.185.102/php/gd/index.php) http://212.80.185.102/test2.php (-> http://support.genotec.ch/main.asp) here the error happens, no matter wether I include from the same server or from an external one as in the later case. now these for the server running 4.3.3-dev snapshot http://212.80.185.101/test.php (-> http://212.80.185.101/php/gd/index.php) http://212.80.185.101/test2.php (-> http://support.genotec.ch/main.asp) here comes a very strange behaviour as it sometimes works without this 'headers' and sometimes the page even stays blank, then I find the following in the error log: [Sat Jun 7 09:34:29 2003] [error] PHP Warning: main(http://gic-web-lin-01.genotec.ch/php/gd/index.php): failed to open stream: HTTP request failed! [EMAIL PROTECTED]@P_P ␋[EMAIL PROTECTED]@T ␋┼ /┴▒⎼/␌␌/├␍⎺␌⎽/␍␊°▒┤┌├/├␊⎽├.⎻⎻ ⎺┼ ┌␋┼␊ 4 to reproduce just try to reload the page a few times. I'm not sure wether this header problem is gone now, though the error shown in the log was only introduced when using the new snapshot. It seems like it would only happen when including from the same server, not from an external one, as I couldn't reproduce it on the second url. PHP4 ist running as mod_php in Apache. There is no mod_php3. CGI is not specifically configured in apache, however I didn't use the '--disable-cgi' switch when building PHP, if anyone happens to rename a .php file to .cgi and adds a #!/usr/bin/php to the top of the file, it would run over cgi/suexec. Normal .php/php3/phtml files run through mod_php. [2003-06-06 18:40:38] [EMAIL PROTECTED] Can you give some example script which definately fails for you everytime? (using some url anybody can access) Do you happen to have also CGI version of PHP configured in your Apache? Or PHP 3 as module? 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/24043 -- Edit this bug report at http://bugs.php.net/?id=24043&edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: phpbugs at virtua dot ch Reported By: josh at zebotech dot com Status: No Feedback Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.3.0-dev New Comment: We are still having the same issue here with php-4.3.3 ... Currently testing latest snapshots. Config : FreeBSD 4.7 UP, Apache 1.3.27, standard /tmp session handling. One of our developers even tried a print_r($_SESSION) and found part of the php source file in it !! There seem to be some leakage somewhere ! Previous Comments: [2003-06-09 08:44:10] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-06-02 17:09:32] [EMAIL PROTECTED] This should be fixed in PHP 4.3.2, so please give it a try. [2003-06-02 14:44:35] radek at pinkbike dot com I also have seen behaviour of missing session data. I have detected this in the custom shopping cart I have written. Every 20 or 30 orders we get a "blank" order. This blank order is a result of the session cart is not picked up on the last stage of the purchase process. I went through my code a million times to try to figure out how I could of caused this but reading this bug report I starting to think it maybe a result of php session/serialization. Like the other person with the shopping cart stated, who knows how many users don't even make it to the last step and their cart disappears. I store associative arrays in the session I run on a dual CPU intel box The site is relatively high load - 3 million hits a day I have not been able to reproduce the problem myself It has been happening regularly since January when i put up the software - it happens on a few versions of php since Jan 2003 What are options here? Any documentation, warnings about what not to store in php sessions? Should I be writting my own handler/serializer? here are the box details Apache/1.3.26 PHP Version 4.3.1 System Linux superlight 2.4.20-xfs #2 SMP Mon Apr 7 21:06:32 CDT 2003 i686 Build Date May 1 2003 00:21:10 Configure Command './configure' '--with-apxs=/usr/bin/apxs' '--with-mysql=/usr/local/mysql' '--with-openssl' '--with-zlib' '--with-mcrypt' '--enable-shmop' '--enable-sysvshm' '--enable-sysvsem' '--enable-mbstring' '--with-gd' '--with-png-dir=/usr' '--with-jpeg-dir=/usr' '--enable-mbstring' '--with-curl=/usr/local' '--enable-exif' Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib/php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety disabled Registered PHP Streams php, http, ftp, https, ftps, compress.zlib [2003-05-24 01:15:44] brian dot diekelman at andrews dot af dot mil I just upgraded from snaps.php.net yesterday and am still experiencing this bug. I am running a very simple authentication script at the beginning of every page to check a generic $_SESSION['user'] to see if there is an active session. If there is not it prompts for login. The session only holds the user name and password. Now I have heard a lot of people in my organization complaining that they'll be browsing the site and it will randomly prompt for login. I have also experienced this myself. I have heard a couple people in this bug thread attribute losing the session to php's handing of arrays, which very well may be true but in my case I am losing sessions on a lot more basic level. System: -- Win2K SP2 Apache 2.0.45 PHP 4.3.x (downloaded from snaps yesterday) [2003-05-21 08:30:40] stefandekonink at xs4all dot nl Currently I have the same session problem. As the page in a frameset get a POST (login user/pass) the page gets the content. The next page presented in this frame is to fill in content, after posting, it goes again thru the login procedure. After the login the SessionID is lost even if a GET var is specified. This behavior occurs on IE6.0.2600 Win2K-SP2, Mozilla Firebird is working without this annoing behavior. 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/20449 -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#32802 [NEW]: General cookie overrides more specific cookie, RFC 2965 incompliant
From: ast at gmx dot ch
Operating system: ANY
PHP version: 4.3.11
PHP Bug Type: HTTP related
Bug description: General cookie overrides more specific cookie, RFC 2965
incompliant
Description:
[EMAIL PROTECTED], you closed the bug prematurely. It is indeed a PHP bug. Let
me explain...
>From RFC 2965, which obsoletes 2109, and is the reference for cookie /
HTTP state management mechanism:
http://www.faqs.org/rfcs/rfc2965
See 4.2 Example 2
Imagine the user agent has received, in response to earlier requests,
the response headers
Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
Path="/acme"
and
Set-Cookie2: Part_Number="Riding_Rocket_0023"; Version="1";
Path="/acme/ammo"
A subsequent request by the user agent to the (same) server for URLs
of the form /acme/ammo/... would include the following request
header:
Cookie: $Version="1";
Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
Part_Number="Rocket_Launcher_0001"; $Path="/acme"
Note that the NAME=VALUE pair for the cookie with the more specific
Path attribute, /acme/ammo, comes before the one with the less
specific Path attribute, /acme. Further note that the same cookie
name appears more than once.
Also from the RFC:
If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific. Ordering with respect to other
attributes (e.g., Domain) is unspecified.
My example is a little specific, but is described in
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=29223.
I tested with ethereal, to look into the packets my browser actually sent
to the webserver. IE and FF behave the same way.
The HTTP header containing the cookies looked the same in both browsers
and conformed to the RFC2965.
The most specific matched cookies (path) are listed first, the least
specific matching cookies last, all NAME=VALUE pairs are delimited by a
semicolon.
There are a number of options to retrieve cookie data in php. $_COOKIE is
indexed by NAME, so you get only a single cookie if mutliple cookies have
the same NAME but a different path. That's not good.
And $_COOKIE['COOKIENAME'] is the least specific cookie. I guess, php just
runs through the Cookie: header and does something like $_COOKIE[$NAME] =
$value, replacing more specific cookies with less specific cookies.
$_GLOBALS['HTTP_SERVER_VARS'] lists all cookies, according to the RFC2965
specification! That's good.
Same for $_GLOBALS['_SERVER']['HTTP_COOKIE'] = $_SERVER['HTTP_COOKIE'].
This is good!
Example showing multiple cookies with NAME = GALLERYSID (they have
different paths), I have this from print_r($_SERVER):
[HTTP_COOKIE] => GALLERYSID=6fb8f64ad5107c62b812f9c4d3cd69b0;
G2_hybrid=1%3B5%3B1%3B1%3B1%3B0%3B; xarayaclassic_textsize=Small
classictext; GALLERYSID=8603809d6b5671bbef5d4b8465d0db89;
xarayaclassic_colscheme=null
So the browsers comply with RFC 2965, but PHP doesn't.
What should be fixed:
The most specific path matched cookie should be in the $_COOKIE array, not
the least specific matched cookie! I.e. when parsing HTTP header Cookie:
from left to right, do this:
if (!isset($_COOKIE[$name])) {
$_COOKIE[$name] = $value;
}
instead of just
$_COOKIE[$name] = $value;
--
Edit bug report at http://bugs.php.net/?id=32802&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32802&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32802&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32802&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32802&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32802&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32802&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32802&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32802&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32802&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32802&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32802&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32802&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32802&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32802&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32802&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32802&r=isapi
Install GNU Sed:
#32802 [Fbk->Opn]: General cookie overrides more specific cookie, RFC 2965 incompliant
ID: 32802
User updated by: ast at gmx dot ch
Reported By: ast at gmx dot ch
-Status: Feedback
+Status: Open
Bug Type: HTTP related
Operating System: ANY
PHP Version: 4.3.11
New Comment:
the bug report that was closed as bogus (sorry, forgot to add the link.
originally, i wanted to add a comment there, but you can't add comments
to bugs that are marked as "bogus".
http://bugs.php.net/bug.php?id=18337
obviously, this isn't "bogus", as php doesn't comply with the RFC 2965
(and all common browsers comply with this RFC concerning the order of
the cookies).
How to reproduce:
See Example 2 of RFC 2965:
2 cookies, with the same NAME, but a different PATH.
It's about the precedence of cookies. Cookies with a more specific path
have precedence over cookies with less specific paths.
See Example 2 of the RFC, it's nicely explained there.
Previous Comments:
[2005-04-23 22:05:01] [EMAIL PROTECTED]
And can you please add a short example script which CLEARLY
demonstrates the problem. (I don't know why but I can't get multiple
cookies set with same name..)
[2005-04-23 20:50:14] [EMAIL PROTECTED]
Exactly what bug did Ilia close? And why are you submitting a new
report if one exists already?
----
[2005-04-23 14:19:22] ast at gmx dot ch
Description:
[EMAIL PROTECTED], you closed the bug prematurely. It is indeed a PHP bug.
Let me explain...
>From RFC 2965, which obsoletes 2109, and is the reference for cookie /
HTTP state management mechanism:
http://www.faqs.org/rfcs/rfc2965
See 4.2 Example 2
Imagine the user agent has received, in response to earlier requests,
the response headers
Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
Path="/acme"
and
Set-Cookie2: Part_Number="Riding_Rocket_0023"; Version="1";
Path="/acme/ammo"
A subsequent request by the user agent to the (same) server for
URLs
of the form /acme/ammo/... would include the following request
header:
Cookie: $Version="1";
Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
Part_Number="Rocket_Launcher_0001"; $Path="/acme"
Note that the NAME=VALUE pair for the cookie with the more specific
Path attribute, /acme/ammo, comes before the one with the less
specific Path attribute, /acme. Further note that the same cookie
name appears more than once.
Also from the RFC:
If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific. Ordering with respect to other
attributes (e.g., Domain) is unspecified.
My example is a little specific, but is described in
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=29223.
I tested with ethereal, to look into the packets my browser actually
sent to the webserver. IE and FF behave the same way.
The HTTP header containing the cookies looked the same in both browsers
and conformed to the RFC2965.
The most specific matched cookies (path) are listed first, the least
specific matching cookies last, all NAME=VALUE pairs are delimited by a
semicolon.
There are a number of options to retrieve cookie data in php. $_COOKIE
is indexed by NAME, so you get only a single cookie if mutliple cookies
have the same NAME but a different path. That's not good.
And $_COOKIE['COOKIENAME'] is the least specific cookie. I guess, php
just runs through the Cookie: header and does something like
$_COOKIE[$NAME] = $value, replacing more specific cookies with less
specific cookies.
$_GLOBALS['HTTP_SERVER_VARS'] lists all cookies, according to the
RFC2965 specification! That's good.
Same for $_GLOBALS['_SERVER']['HTTP_COOKIE'] = $_SERVER['HTTP_COOKIE'].
This is good!
Example showing multiple cookies with NAME = GALLERYSID (they have
different paths), I have this from print_r($_SERVER):
[HTTP_COOKIE] => GALLERYSID=6fb8f64ad5107c62b812f9c4d3cd69b0;
G2_hybrid=1%3B5%3B1%3B1%3B1%3B0%3B; xarayaclassic_textsize=Small
classictext; GALLERYSID=8603809d6b5671bbef5d4b8465d0db89;
xarayaclassic_colscheme=null
So the browsers comply with RFC 2965, but PHP doesn't.
What should be fixed:
The most specific path matched cookie should be in the $_COOKIE array,
not the least specific matched cookie! I.e. when parsing HTTP header
Cookie: from left to right, do this:
if (!isset($_COOKIE[$name])) {
$_COOKIE[$name] = $value;
}
instead of just
$_COOKIE[$name] = $value;
--
Edit this bug report at http://bugs.php.net/?id=32802&edit=1
#32802 [Opn]: General cookie overrides more specific cookie, RFC 2965 incompliant
ID: 32802
User updated by: ast at gmx dot ch
Reported By: ast at gmx dot ch
Status: Open
Bug Type: HTTP related
Operating System: ANY
PHP Version: 4.3.11
New Comment:
Here is a fix for my application.
/**
* Fix the superglobal $_COOKIE to conform with RFC 2965
*
* We don't use $_COOKIE[$cookiename], because it doesn't conform
to RFC 2965 (the
* cookie standard), i.e. in $_COOKIE, we don't get the cookie with
the most specific path for
* a given cookie name, we get the cookie with the least specific
cookie path.
* This function does it exactly the other way around to conform
with the RFC.
*
* This function reevaluates the HTTP Cookie header and populates
$_COOKIE with the correct
* cookies.
*
* @static
*/
function fixCookieVars() {
if (isset($_SERVER['HTTP_COOKIE']) &&
!empty($_SERVER['HTTP_COOKIE'])) {
$allCookies = explode(';', $_SERVER['HTTP_COOKIE']);
/*
* Get rid of less specific cookies if multiple cookies with
the same
NAME
* are present. Do this by going from left/first cookie to
right/last
cookie.
*/
/* Reset the $_COOKIE array */
$_COOKIE = array();
/* Repopulate it, but now correctly */
foreach ($allCookies as $cookie) {
/* Split NAME [=VALUE], value is optional */
$cookie = explode('=', $cookie);
$key = preg_replace('|\s|', '', $cookie[0]);
$value = isset($cookie[1]) ? $cookie[1] : '';
if (!isset($_COOKIE[$key])) {
$_COOKIE[$key] = $value;
}
}
}
}
}
Previous Comments:
----
[2005-04-24 00:43:04] ast at gmx dot ch
the bug report that was closed as bogus (sorry, forgot to add the link.
originally, i wanted to add a comment there, but you can't add comments
to bugs that are marked as "bogus".
http://bugs.php.net/bug.php?id=18337
obviously, this isn't "bogus", as php doesn't comply with the RFC 2965
(and all common browsers comply with this RFC concerning the order of
the cookies).
How to reproduce:
See Example 2 of RFC 2965:
2 cookies, with the same NAME, but a different PATH.
It's about the precedence of cookies. Cookies with a more specific path
have precedence over cookies with less specific paths.
See Example 2 of the RFC, it's nicely explained there.
[2005-04-23 22:05:01] [EMAIL PROTECTED]
And can you please add a short example script which CLEARLY
demonstrates the problem. (I don't know why but I can't get multiple
cookies set with same name..)
[2005-04-23 20:50:14] [EMAIL PROTECTED]
Exactly what bug did Ilia close? And why are you submitting a new
report if one exists already?
[2005-04-23 14:19:22] ast at gmx dot ch
Description:
[EMAIL PROTECTED], you closed the bug prematurely. It is indeed a PHP bug.
Let me explain...
>From RFC 2965, which obsoletes 2109, and is the reference for cookie /
HTTP state management mechanism:
http://www.faqs.org/rfcs/rfc2965
See 4.2 Example 2
Imagine the user agent has received, in response to earlier requests,
the response headers
Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
Path="/acme"
and
Set-Cookie2: Part_Number="Riding_Rocket_0023"; Version="1";
Path="/acme/ammo"
A subsequent request by the user agent to the (same) server for
URLs
of the form /acme/ammo/... would include the following request
header:
Cookie: $Version="1";
Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
Part_Number="Rocket_Launcher_0001"; $Path="/acme"
Note that the NAME=VALUE pair for the cookie with the more specific
Path attribute, /acme/ammo, comes before the one with the less
specific Path attribute, /acme. Further note that the same cookie
name appears more than once.
Also from the RFC:
If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific. Ordering with respect to other
attributes (e.g., Domain) is unspecified.
My example is a little specific, but is described in
http://gallery.menalto.com/index.php?name=PNphpBB2&
#32802 [Opn]: General cookie overrides more specific cookie (path)
ID: 32802
User updated by: ast at gmx dot ch
Reported By: ast at gmx dot ch
Status: Open
Bug Type: HTTP related
Operating System: *
PHP Version: 4.*, 5.*
New Comment:
Your reproduce script does not describe this bug.
Your script describes a Server -> Browser issue.
This bug is about a Browser -> Server issue. The browser sends a Cookie
HTTP header with its request to the server.
The Cookie HTTP request header lists the cookies in the right order.
Cookies with more specific paths precede cookies with less specific
paths in the header string.
PHP populates the superglobal $_COOKIE with the wrong values when
reading/evaluating the Cookie HTTP header.
This The following reproduce script shows the PHP bug.
Please place it into document_root / test.
';
var_dump($_COOKIE);
echo '';
echo '$_SERVER[\'HTTP_COOKIE\'] lists the cookies in the correct order,
Value2 before Value1. It conforms to RFC 2965.';
var_dump($_SERVER['HTTP_COOKIE']);
echo '';
?>
Previous Comments:
[2005-04-24 14:01:21] [EMAIL PROTECTED]
Reproduce script:
';
var_dump($_COOKIE);
var_dump($_SERVER['HTTP_COOKIE']);
echo '';
?>
--------
[2005-04-24 03:21:37] ast at gmx dot ch
Here is a fix for my application.
/**
* Fix the superglobal $_COOKIE to conform with RFC 2965
*
* We don't use $_COOKIE[$cookiename], because it doesn't conform
to RFC 2965 (the
* cookie standard), i.e. in $_COOKIE, we don't get the cookie with
the most specific path for
* a given cookie name, we get the cookie with the least specific
cookie path.
* This function does it exactly the other way around to conform
with the RFC.
*
* This function reevaluates the HTTP Cookie header and populates
$_COOKIE with the correct
* cookies.
*
* @static
*/
function fixCookieVars() {
if (isset($_SERVER['HTTP_COOKIE']) &&
!empty($_SERVER['HTTP_COOKIE'])) {
$allCookies = explode(';', $_SERVER['HTTP_COOKIE']);
/*
* Get rid of less specific cookies if multiple cookies with
the same
NAME
* are present. Do this by going from left/first cookie to
right/last
cookie.
*/
/* Reset the $_COOKIE array */
$_COOKIE = array();
/* Repopulate it, but now correctly */
foreach ($allCookies as $cookie) {
/* Split NAME [=VALUE], value is optional */
$cookie = explode('=', $cookie);
$key = preg_replace('|\s|', '', $cookie[0]);
$value = isset($cookie[1]) ? $cookie[1] : '';
if (!isset($_COOKIE[$key])) {
$_COOKIE[$key] = $value;
}
}
}
}
}
[2005-04-24 00:43:04] ast at gmx dot ch
the bug report that was closed as bogus (sorry, forgot to add the link.
originally, i wanted to add a comment there, but you can't add comments
to bugs that are marked as "bogus".
http://bugs.php.net/bug.php?id=18337
obviously, this isn't "bogus", as php doesn't comply with the RFC 2965
(and all common browsers comply with this RFC concerning the order of
the cookies).
How to reproduce:
See Example 2 of RFC 2965:
2 cookies, with the same NAME, but a different PATH.
It's about the precedence of cookies. Cookies with a more specific path
have precedence over cookies with less specific paths.
See Example 2 of the RFC, it's nicely explained there.
[2005-04-23 22:05:01] [EMAIL PROTECTED]
And can you please add a short example script which CLEARLY
demonstrates the problem. (I don't know why but I can't get multiple
cookies set with same name..)
[2005-04-23 20:50:14] [EMAIL PROTECTED]
Exactly what bug did Ilia close? And why are you submitting a new
report if one exists already?
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/32802
--
Edit this bug report at http://bugs.php.net/?id=32802&edit=1
#32860 [NEW]: quoted-string cookies not handled correctly
From: ast at gmx dot ch
Operating system: *
PHP version: 4.3.11
PHP Bug Type: HTTP related
Bug description: quoted-string cookies not handled correctly
Description:
/*
* Description:
*RFC 2965 describes the HTTP State Management mechanism.
*From section "3.1 Syntax: General":
* av-pairs= av-pair *(";" av-pair)
* av-pair = attr ["=" value] ; optional value
* attr= token
* value = token | quoted-string
*
*PHP 4.3.11 does not handle the case of "quoted-string" values.
*See RFC 2616 section "2.2 Basic Rules" for a definition of
"quoted-string".
*quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
*qdtext = >
*
* The backslash character ("\") MAY be used as a single-character
* quoting mechanism only within quoted-string and comment
constructs.
*
*quoted-pair= "\" CHAR
*
*PHP 4.3.11 urlencodes all cookie name = value pairs. Therefore, it
can handle
*values that contain the separators "," and ";". But the RFC 2965
describes that
*a HTTP Cookie header sent from the user agent to the server may have
av-pairs,
*where the value may be a token or a quoted string.
*
*If one sets a cookie not with PHP's setCookie() method, but directly
with header(),
*then it is sent correctly to the user agent and the user agent
returns it also
*correctly. But when PHP reads the HTTP Cookie header back into
$_COOKIE, it does
*not handle quoted-strings.
*
*Result:
* Wrong cookie values in $_COOKIE.
*
*The bug is in PHP's source in function
* SAPI_API SAPI_TREAT_DATA_FUNC(php_default_treat_data)
*It parses the HTTP Cookie header and directly uses "," and ";" as
separators.
*A slightly more complicated handling of the HTTP Cookie header is
required.
*In addition to the current code, one has to handle:
* - quoted-strings: separators "," and ";" may be in
quoted-strings
* - double-quote marks escaped by "\" don't end a quoted-string
*
*Cookies with values that are not urlencoded may come from:
* - non-PHP applications on the same host
* - RFC 2965 compliant PHP cookies that were set with header()
instead of setcookie().
*
*Example:
* In PHP script:
*header('Set-Cookie: TestCookie = "value with , perfectly ;
allowed 8-Bit characters ' .
*'and escaped \" double-quote marks!"');
* The cookie is successfully sent to the user agent. The user agent
sends it back with a
* perfectly intact value.
* PHP receives the HTTP Cookie header from the webserver (I inserted
the line break):
*Cookie: TestCookie="value with , perfectly ; allowed 8-Bit
characters and escaped \"
*double-quote marks!"\r\n
* Then PHP parses the HTTP Cookie header ignoring the case of
quoted-strings and fills the
* superglobal $_COOKIE with:
* ["TestCookie"]=>
*string(24) ""value with , perfectly "
*
["allowed_8-BIT_characters_and_escaped_\"_double-quote_marks!""]=>
*string(0) ""
* If PHP handled the HTTP Cookie header correctly, one would get:
* ["TestCookie"]=>
*string(86) "value with , perfectly ; allowed 8-BIT
characters and escaped \" double-quote marks!"
*
* I even think, if PHP handled "," and ";" as separators, the
current PHP should have
* created three cookies out of the above name = value pair.
*
* References:
*RFC 2965: http://rfc.net/rfc2965.html
*RFC 2616: http://rfc.net/rfc2616.html
*/
Proposed fix:
In the PHP source, replace the simple strtok() call in SAPI_API
SAPI_TREAT_DATA_FUNC(php_default_treat_data) by the C++ equivalent of the
following PHP code:
/**
* Fix the superglobal $_COOKIE to conform with RFC 2965
*
* This function reevaluates the HTTP Cookie header and populates
$_COOKIE with the correct
* cookies.
*/
function fixCookieVars() {
if (empty($_SERVER['HTTP_COOKIE'])) {
return;
}
$_COOKIE = array();
/* Check if the Cookie header contains quoted-strings */
if (strstr($_SERVER['HTTP_COOKIE'], '"') === false) {
/*
* Use fast method, no quoted-strings in the header.
* Get rid of less specific cookies if multiple cookies with the
same
NAME
* are present. Do this by going from left/first cookie to
right/last
cookie.
*/
$to
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860
User updated by: ast at gmx dot ch
Reported By: ast at gmx dot ch
Status: Open
Bug Type: HTTP related
Operating System: *
PHP Version: 4.3.11
New Comment:
Obviously, the bug report was mangled.
Here's a pretty print of the report / fix:
http://nei.ch/articles/quoted_string_cookie_fix.php
Previous Comments:
[2005-04-27 21:46:18] ast at gmx dot ch
Description:
/*
* Description:
*RFC 2965 describes the HTTP State Management mechanism.
*From section "3.1 Syntax: General":
* av-pairs= av-pair *(";" av-pair)
* av-pair = attr ["=" value] ; optional
value
* attr= token
* value = token | quoted-string
*
*PHP 4.3.11 does not handle the case of "quoted-string" values.
*See RFC 2616 section "2.2 Basic Rules" for a definition of
"quoted-string".
*quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
*qdtext = >
*
* The backslash character ("\") MAY be used as a
single-character
* quoting mechanism only within quoted-string and comment
constructs.
*
*quoted-pair= "\" CHAR
*
*PHP 4.3.11 urlencodes all cookie name = value pairs. Therefore,
it can handle
*values that contain the separators "," and ";". But the RFC 2965
describes that
*a HTTP Cookie header sent from the user agent to the server may
have av-pairs,
*where the value may be a token or a quoted string.
*
*If one sets a cookie not with PHP's setCookie() method, but
directly with header(),
*then it is sent correctly to the user agent and the user agent
returns it also
*correctly. But when PHP reads the HTTP Cookie header back into
$_COOKIE, it does
*not handle quoted-strings.
*
*Result:
* Wrong cookie values in $_COOKIE.
*
*The bug is in PHP's source in function
* SAPI_API SAPI_TREAT_DATA_FUNC(php_default_treat_data)
*It parses the HTTP Cookie header and directly uses "," and ";" as
separators.
*A slightly more complicated handling of the HTTP Cookie header is
required.
*In addition to the current code, one has to handle:
* - quoted-strings: separators "," and ";" may be in
quoted-strings
* - double-quote marks escaped by "\" don't end a quoted-string
*
*Cookies with values that are not urlencoded may come from:
* - non-PHP applications on the same host
* - RFC 2965 compliant PHP cookies that were set with header()
instead of setcookie().
*
*Example:
* In PHP script:
*header('Set-Cookie: TestCookie = "value with , perfectly ;
allowed 8-Bit characters ' .
*'and escaped \" double-quote marks!"');
* The cookie is successfully sent to the user agent. The user
agent sends it back with a
* perfectly intact value.
* PHP receives the HTTP Cookie header from the webserver (I
inserted the line break):
*Cookie: TestCookie="value with , perfectly ; allowed 8-Bit
characters and escaped \"
*double-quote marks!"\r\n
* Then PHP parses the HTTP Cookie header ignoring the case of
quoted-strings and fills the
* superglobal $_COOKIE with:
* ["TestCookie"]=>
*string(24) ""value with , perfectly "
*
["allowed_8-BIT_characters_and_escaped_\"_double-quote_marks!""]=>
*string(0) ""
* If PHP handled the HTTP Cookie header correctly, one would
get:
* ["TestCookie"]=>
*string(86) "value with , perfectly ; allowed 8-BIT
characters and escaped \" double-quote marks!"
*
* I even think, if PHP handled "," and ";" as separators, the
current PHP should have
* created three cookies out of the above name = value pair.
*
* References:
*RFC 2965: http://rfc.net/rfc2965.html
*RFC 2616: http://rfc.net/rfc2616.html
*/
Proposed fix:
In the PHP source, replace the simple strtok() call in SAPI_API
SAPI_TREAT_DATA_FUNC(php_default_treat_data) by the C++ equivalent of
the following PHP code:
/**
* Fix the superglobal $_COOKIE to conform with RFC 2965
*
* This function reevaluates the HTTP Cookie header and populates
$_COOKIE with the correct
* cookies.
*/
function fixCookieVars() {
if (empty($_SERVER['HTTP_COOKIE'])) {
return;
}
$_COOKIE = array();
/* Check if the Cookie header contains quoted-strings */
if (strstr($_SERVER['HTTP_COOKIE']
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860
User updated by: ast at gmx dot ch
Reported By: ast at gmx dot ch
Status: Open
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4.3.11
New Comment:
Feature/Change request?
I don't agree. Handling a HTTP header not according to the RFCs they
are defined in doesn't make sense at all. Therefore, it's a bug.
But it's not that important to me. Do what you consider the right
thing.
Previous Comments:
[2005-04-28 00:00:18] [EMAIL PROTECTED]
Reclassified.
[2005-04-27 23:20:34] ast at gmx dot ch
Obviously, the bug report was mangled.
Here's a pretty print of the report / fix:
http://nei.ch/articles/quoted_string_cookie_fix.php
[2005-04-27 21:46:18] ast at gmx dot ch
Description:
/*
* Description:
*RFC 2965 describes the HTTP State Management mechanism.
*From section "3.1 Syntax: General":
* av-pairs= av-pair *(";" av-pair)
* av-pair = attr ["=" value] ; optional
value
* attr= token
* value = token | quoted-string
*
*PHP 4.3.11 does not handle the case of "quoted-string" values.
*See RFC 2616 section "2.2 Basic Rules" for a definition of
"quoted-string".
*quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
*qdtext = >
*
* The backslash character ("\") MAY be used as a
single-character
* quoting mechanism only within quoted-string and comment
constructs.
*
*quoted-pair= "\" CHAR
*
*PHP 4.3.11 urlencodes all cookie name = value pairs. Therefore,
it can handle
*values that contain the separators "," and ";". But the RFC 2965
describes that
*a HTTP Cookie header sent from the user agent to the server may
have av-pairs,
*where the value may be a token or a quoted string.
*
*If one sets a cookie not with PHP's setCookie() method, but
directly with header(),
*then it is sent correctly to the user agent and the user agent
returns it also
*correctly. But when PHP reads the HTTP Cookie header back into
$_COOKIE, it does
*not handle quoted-strings.
*
*Result:
* Wrong cookie values in $_COOKIE.
*
*The bug is in PHP's source in function
* SAPI_API SAPI_TREAT_DATA_FUNC(php_default_treat_data)
*It parses the HTTP Cookie header and directly uses "," and ";" as
separators.
*A slightly more complicated handling of the HTTP Cookie header is
required.
*In addition to the current code, one has to handle:
* - quoted-strings: separators "," and ";" may be in
quoted-strings
* - double-quote marks escaped by "\" don't end a quoted-string
*
*Cookies with values that are not urlencoded may come from:
* - non-PHP applications on the same host
* - RFC 2965 compliant PHP cookies that were set with header()
instead of setcookie().
*
*Example:
* In PHP script:
*header('Set-Cookie: TestCookie = "value with , perfectly ;
allowed 8-Bit characters ' .
*'and escaped \" double-quote marks!"');
* The cookie is successfully sent to the user agent. The user
agent sends it back with a
* perfectly intact value.
* PHP receives the HTTP Cookie header from the webserver (I
inserted the line break):
*Cookie: TestCookie="value with , perfectly ; allowed 8-Bit
characters and escaped \"
*double-quote marks!"\r\n
* Then PHP parses the HTTP Cookie header ignoring the case of
quoted-strings and fills the
* superglobal $_COOKIE with:
* ["TestCookie"]=>
*string(24) ""value with , perfectly "
*
["allowed_8-BIT_characters_and_escaped_\"_double-quote_marks!""]=>
*string(0) ""
* If PHP handled the HTTP Cookie header correctly, one would
get:
* ["TestCookie"]=>
*string(86) "value with , perfectly ; allowed 8-BIT
characters and escaped \" double-quote marks!"
*
* I even think, if PHP handled "," and ";" as separators, the
current PHP should have
* created three cookies out of the above name = value pair.
*
* References:
*RFC 2965: http://rfc.net/rfc2965.html
*RFC 2616: http://rfc.net/rfc2616.html
*/
Proposed fix:
In the PHP source, replace the simple strtok() call in SAPI_API
SAPI_TREAT_DATA_FUNC(php_default_treat_data) by th
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860
User updated by: ast at gmx dot ch
Reported By: ast at gmx dot ch
Status: Open
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4.3.11
New Comment:
But even the initial cookie RFC, http://rfc.net/rfc2109.html, described
that a value may be either a TOKEN or a quoted-string. The only
difference to the new cookie RFC, RFC 2965, is that <"> are not allowed
in quoted-string values of the old version while they may be in
quoted-string values, just escaped by the escape character "\" in the
new version.
Therefore, the separaters "," and ";" are allowed in quoted-string
values even in the old cookie RFC.
Maybe you could list it as a low-priority bug, but it's a bug and not a
feature or a change request.
Previous Comments:
[2005-04-28 08:16:09] [EMAIL PROTECTED]
When PHP was written, this RFC did not yet exist - that's why we
classify it as a feature request - it's basically "cookie version 1.1".
----
[2005-04-28 00:04:15] ast at gmx dot ch
Feature/Change request?
I don't agree. Handling a HTTP header not according to the RFCs they
are defined in doesn't make sense at all. Therefore, it's a bug.
But it's not that important to me. Do what you consider the right
thing.
[2005-04-28 00:00:18] [EMAIL PROTECTED]
Reclassified.
----
[2005-04-27 23:20:34] ast at gmx dot ch
Obviously, the bug report was mangled.
Here's a pretty print of the report / fix:
http://nei.ch/articles/quoted_string_cookie_fix.php
----
[2005-04-27 21:46:18] ast at gmx dot ch
Description:
/*
* Description:
*RFC 2965 describes the HTTP State Management mechanism.
*From section "3.1 Syntax: General":
* av-pairs= av-pair *(";" av-pair)
* av-pair = attr ["=" value] ; optional
value
* attr= token
* value = token | quoted-string
*
*PHP 4.3.11 does not handle the case of "quoted-string" values.
*See RFC 2616 section "2.2 Basic Rules" for a definition of
"quoted-string".
*quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
*qdtext = >
*
* The backslash character ("\") MAY be used as a
single-character
* quoting mechanism only within quoted-string and comment
constructs.
*
*quoted-pair= "\" CHAR
*
*PHP 4.3.11 urlencodes all cookie name = value pairs. Therefore,
it can handle
*values that contain the separators "," and ";". But the RFC 2965
describes that
*a HTTP Cookie header sent from the user agent to the server may
have av-pairs,
*where the value may be a token or a quoted string.
*
*If one sets a cookie not with PHP's setCookie() method, but
directly with header(),
*then it is sent correctly to the user agent and the user agent
returns it also
*correctly. But when PHP reads the HTTP Cookie header back into
$_COOKIE, it does
*not handle quoted-strings.
*
*Result:
* Wrong cookie values in $_COOKIE.
*
*The bug is in PHP's source in function
* SAPI_API SAPI_TREAT_DATA_FUNC(php_default_treat_data)
*It parses the HTTP Cookie header and directly uses "," and ";" as
separators.
*A slightly more complicated handling of the HTTP Cookie header is
required.
*In addition to the current code, one has to handle:
* - quoted-strings: separators "," and ";" may be in
quoted-strings
* - double-quote marks escaped by "\" don't end a quoted-string
*
*Cookies with values that are not urlencoded may come from:
* - non-PHP applications on the same host
* - RFC 2965 compliant PHP cookies that were set with header()
instead of setcookie().
*
*Example:
* In PHP script:
*header('Set-Cookie: TestCookie = "value with , perfectly ;
allowed 8-Bit characters ' .
*'and escaped \" double-quote marks!"');
* The cookie is successfully sent to the user agent. The user
agent sends it back with a
* perfectly intact value.
* PHP receives the HTTP Cookie header from the webserver (I
inserted the line break):
*Cookie: TestCookie="value with , perfectly ; allowed 8-Bit
characters and escaped \"
*double-quote marks!"\r\n
* Then PHP parses the HTTP Cookie header ignor
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: Fact is that PHP 2 was released after RFC 2109 and the dev cycle of PHP 3, 4, and 5 started completely after RFC 2109 was published. Interpret the issue as you want. I just wanted to help you to be more standards compliant. Previous Comments: [2005-04-28 14:40:05] [EMAIL PROTECTED] You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that <"> are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character "\" in the new version. Therefore, the separaters "," and ";" are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically "cookie version 1.1". ---- [2005-04-28 00:04:15] ast at gmx dot ch Feature/Change request? I don't agree. Handling a HTTP header not according to the RFCs they are defined in doesn't make sense at all. Therefore, it's a bug. But it's not that important to me. Do what you consider the right thing. [2005-04-28 00:00:18] [EMAIL PROTECTED] Reclassified. 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860&edit=1
#32860 [Opn]: quoted-string cookies not handled correctly
ID: 32860 User updated by: ast at gmx dot ch Reported By: ast at gmx dot ch Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.11 New Comment: quoted-string cookies are defined as cookies with a value that is a quoted-string, quoted by double-quote marks. You refer to PHP's mechanism to urlencode all cookie values resulting in TOKEN values. This mechanism is indeed suggested in netscapes standard. I've pointed the difference of these things out in my bug report. So, please don't say what I claim is wrong, because that is simply not true. Handle it as a feature request if you prefer that. It's ok. Thanks for the discussion. After all, we all agree on the state (PHP 4.3.11 implements cookie standard 0 (netscape)) and what it doesn't (RFC 2109 which is as old as PHP 2). Previous Comments: [2005-04-28 16:52:08] [EMAIL PROTECTED] You claimed that PHP handles quoted-strings within cookies incorrectly. This is simply wrong. PHP supports version 0 cookies, like all browsers do by default and there are no quoted-strings in the version 0 standard. It doesn't matter when the Cookie Version 1 RFCs were released. Fact is: the web uses mainly version 0 cookies. So Jani was right when he changed this into a feature request. [2005-04-28 15:41:08] ast at gmx dot ch Fact is that PHP 2 was released after RFC 2109 and the dev cycle of PHP 3, 4, and 5 started completely after RFC 2109 was published. Interpret the issue as you want. I just wanted to help you to be more standards compliant. [2005-04-28 14:40:05] [EMAIL PROTECTED] You are wrong. It is not a bug. PHP implements Cookie version 0 which is based upon the Netscape Cookie standard. Both RFCs 2109/2965 speak of Cookie version 1. [2005-04-28 12:03:44] ast at gmx dot ch But even the initial cookie RFC, http://rfc.net/rfc2109.html, described that a value may be either a TOKEN or a quoted-string. The only difference to the new cookie RFC, RFC 2965, is that <"> are not allowed in quoted-string values of the old version while they may be in quoted-string values, just escaped by the escape character "\" in the new version. Therefore, the separaters "," and ";" are allowed in quoted-string values even in the old cookie RFC. Maybe you could list it as a low-priority bug, but it's a bug and not a feature or a change request. [2005-04-28 08:16:09] [EMAIL PROTECTED] When PHP was written, this RFC did not yet exist - that's why we classify it as a feature request - it's basically "cookie version 1.1". 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/32860 -- Edit this bug report at http://bugs.php.net/?id=32860&edit=1
#33091 [NEW]: no image processing with image magick in typo3 3.7.0
From: rasi at rasi dot ch Operating system: SBS 2003 (iis6) PHP version: 4.3.11 PHP Bug Type: *Graphics related Bug description: no image processing with image magick in typo3 3.7.0 Description: no image processing with image magick 6.2.2.1 or 6.2.2.2 or 6.2.2.4 in typo3 3.7.0 running php in isapi mode on microsoft small business server 2003 with iis6. in fast cgi mode are no problems thanks in advance gerhard rasi http://rasi.ch -- Edit bug report at http://bugs.php.net/?id=33091&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33091&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33091&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33091&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33091&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33091&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33091&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33091&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33091&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33091&r=support Expected behavior: http://bugs.php.net/fix.php?id=33091&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33091&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33091&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33091&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33091&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33091&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33091&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33091&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33091&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33091&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33091&r=mysqlcfg
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876
Comment by: maarten at students dot ch
Reported By: golden at riscom dot com
Status: No Feedback
Bug Type: Session related
Operating System: freebsd 4.8
PHP Version: 4.3.9-4.3.10
Assigned To: sniper
New Comment:
PHP Version 4.3.10, Linux srv1-2 2.4.19 #2 SMP Tue Dec 3 15:16:08 CET
2002 i686, Apache
Same Problem over here. It came out of nowhere and sporadically
appears.
Previous Comments:
[2005-06-08 14:58:58] tech at c64-wiki dot de
I added the following line near the beginning of my PHP code:
ini_set("session.save_handler", "files");
I have not seen the bug again after that, so far (clicked around like
an idiot and everything worked fine). Which does not mean a lot, of
course, due to the extremely random nature of that bug.
Can anybody else confirm that this workaround works (or maybe not)? If
it does "solve" the problem, the root cause may seem to be that PHP
sometimes takes the wrong session handler (not the one which is defined
in PHP.INI, which is "files" as well (while the error message seems to
indicate "user"?)).
Best regards, Klaus
[2005-06-08 14:18:42] tech at c64-wiki dot de
Same problem here as described by "gul_murjani at yahoo dot com". PHP
4.3.10 is the version in use (phpinfo() can be seen at
http://www.c64-wiki.de/test.php). I tried to change session.save_path
to a different path (by adding a php_value line into .htaccess), made
the new directory world-writeable and verified that the session files
do indeed appear there. They do appear there, and there's plenty of
space for that directoty available (about 1GB, should be 'nuff for a
few of these session files with <100 bytes each). And the bug still
appears at extremely random intervals!
Best regards, Klaus
[2005-05-22 12:06:42] dmih at in-solve dot ru
Please someone in PHP team confirm that you are reading from this bug
(it has 'No Feedback' status).
Or may be we are writing for ourselves here?
[2005-05-21 14:30:13] gul_murjani at yahoo dot com
Hi,
I'm experiencing this problem in at least 2 sites.
Since it's a error that appears in random, I wrote a simple script to
try and reproduce the error. This is the script:
All it does is invoke "session_start()" and use one session variable.
It then reloads itself every 10 seconds. On HOSTMANIL.ORG and
HOSTMANIL.NET, the error comes up. But there is no pattern at all.
Sometimes out of 20 refreshes, there's an error, half the time. If the
error comes up, I have to do a manual refresh. I notice that the
session variable is not destroyed at all. It continues counting from
where it stopped.
The problem is at one point in HOSTMANILA.ORG, it kept on coming up
every 2 auto refreshes (and I do an F5). But now, it's was good for 45
straign auto refreshes before the error came up. That's how random the
error is.
I do a lot of programming, mostly in PHP but I'm not "deep" technical.
So I'm not sure if I'm missing something.
I'm running the scripts on 5 sites. These are all on different servers
although all of them are from shared hosting services using cPanel /
WHM.
http://www.hostmanila.org/test.php
http://www.hostmanila.biz/test.php
http://www.hostmanila.net/test.php
http://www.vcdpix.com/test.php
http://www.smokedbangus.com/test.php
So far, it's only happened on HOSTMANILA.ORG and HOSTMANILA.NET.
Here's the rundown on each site:
HOSTMANILA.ORG (error)
Linux 2.4.30-gator_r1
Apache 1.3.33 (Unix)
PERL 5.8.4
PHP 4.3.11
cPanel 9.9.9-STABLE 15
HOSTMANILA.BIZ (fine)
Linux 2.4.30-1-s5
Apache 1.3.33 (Unix)
PERL 5.8.3
PHP 4.3.11
cPanel 10.2.0-RELEASE 82
HOSTMANILA.NET (error)
Linux 2.4.26-grsec
Apache 1.3.33 (Unix)
PERL 5.8.0
PHP 4.3.11
cPanel 10.0.0-RELEASE 7
VCDPIX.COM (fine)
Linux 2.4.20-24.9
Apache 1.3.33 (Unix)
PERL 5.8.1
PHP 4.3.9
cPanel 10.0.0-RELEASE 7
SMOKEDBANGUS.COM (fine)
Linux 2.4.20-20.7smp
Apache 1.3.33 (Unix)
PERL 5.8.4
PHP 4.3.10
cPanel 10.0.0-CURRENT 107
I can't imagine developing anything in PHP without making use of
session_start() so I hope the issue is resolved.
Regards,
Gul
hostmanila.com
[2005-05-21 01:24:55] jspec at bellsouth dot net
I have now experienced this beast with a completely different hosting
company. They are both running 4.3.10 - is this fixed in 4.3.11?
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/25876
--
Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#33525 [NEW]: __autoload() for interfaces and functions
From: sr at brightlight dot ch
Operating system: Irrelevant
PHP version: 5.0.4
PHP Bug Type: Feature/Change Request
Bug description: __autoload() for interfaces and functions
Description:
__autoload() is very nice, but classes are not the only
problem.
Please add a parameter $type to allow functions and interfaces
become autoloaded as well.
Even more convenient if there were not only the types 'class',
'interface' and 'function', but also 'method' to autoload
methods of classes.
Example given.
Reproduce code:
---
function __autoload($name, $type)
{
// $type would be 'class', 'interface', 'function' or 'method'
require_once("$type.$name.inc");
}
--
Edit bug report at http://bugs.php.net/?id=33525&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33525&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33525&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33525&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33525&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33525&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33525&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33525&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33525&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33525&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33525&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33525&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33525&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33525&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33525&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33525&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33525&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33525&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33525&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33525&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33525&r=mysqlcfg
#6932 [Com]: Filesize / File_exists and include_path
ID: 6932 Comment by: sr at brightlight dot ch Reported By: richard dot heyes at heyes-computing dot net Status: Open Bug Type: Feature/Change Request Operating System: Any PHP Version: 4.0.2 New Comment: I second this request. Open since 5 years, since PHP5's autoload even more important and not even yet assigned... :-/ Previous Comments: [2002-06-04 09:13:56] [EMAIL PROTECTED] Any objection not to add this? [2001-08-12 16:32:09] [EMAIL PROTECTED] Maybe I should clarify, it was the filesize and file_exists function I was hoping would be updated to have an optional argument so they would check the include_path. [2001-08-12 16:00:53] [EMAIL PROTECTED] That's nice. Doesn't solve the feature request though. [2001-08-12 15:25:02] [EMAIL PROTECTED] according to the docs: int fopen (string filename, string mode [, int use_include_path]) [2000-09-29 02:08:42] richard dot heyes at heyes-computing dot net Currently filesize and file_exists (possibly other, these are two I know of) don't appear to support an extra argument like fopen does to make use of the include_path. So the following code would fail if the file is in the include_path: $file = fread($fp = fopen($filename, 'r', 1), filesize($filename)); fclose($fp); -- Edit this bug report at http://bugs.php.net/?id=6932&edit=1
#33528 [NEW]: get_include_path returning an array
From: sr at brightlight dot ch Operating system: Irrelevant PHP version: 4.3.11 PHP Bug Type: Feature/Change Request Bug description: get_include_path returning an array Description: get_include_path is basically useless like it is now (get_ini can be used for that as well). It would be more useable if it returned an array of include paths, so that we don't always have to split it up by ourselfs which is time consuming and not elegant. -- Edit bug report at http://bugs.php.net/?id=33528&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33528&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33528&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33528&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33528&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33528&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33528&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33528&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33528&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33528&r=support Expected behavior: http://bugs.php.net/fix.php?id=33528&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33528&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33528&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33528&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33528&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33528&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33528&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33528&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33528&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33528&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33528&r=mysqlcfg
#33525 [Csd]: __autoload() for interfaces and functions
ID: 33525
User updated by: sr at brightlight dot ch
Reported By: sr at brightlight dot ch
Status: Closed
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.*
New Comment:
Yes, it works for interfaces, but you don't know whether you
autoload an interface or a class.
This plays a role when you have a naming scheme which
differs for classes and interfaces. Since interfaces are
many to many it makes sense to place interfaces in separate
files and a naming scheme is never bad idea.
E.g. I have a naming scheme interface.{name}.inc and class.
{name}.inc
Functions: why not? Is it a technical reason? Or you just
don't like the idea?
Previous Comments:
[2005-06-30 20:44:32] [EMAIL PROTECTED]
It already works for Interfaces.
And it will never work for functions.
[2005-06-30 16:49:02] sr at brightlight dot ch
Description:
__autoload() is very nice, but classes are not the only
problem.
Please add a parameter $type to allow functions and interfaces
become autoloaded as well.
Even more convenient if there were not only the types 'class',
'interface' and 'function', but also 'method' to autoload
methods of classes.
Example given.
Reproduce code:
---
function __autoload($name, $type)
{
// $type would be 'class', 'interface', 'function' or 'method'
require_once("$type.$name.inc");
}
--
Edit this bug report at http://bugs.php.net/?id=33525&edit=1
#33707 [NEW]: Errors in select statements not reported
From: mangst at inventec dot ch
Operating system: Windows 2000
PHP version: 5CVS-2005-07-14 (dev)
PHP Bug Type: PDO related
Bug description: Errors in select statements not reported
Description:
When a SQL statement is executed with PDO::query, PDO::errorInfo[0] always
reports "0" even when an error has occurred and PDO::query returned
.
Reproduce code:
---
getMessage());
}
$rs = $db->query('select nvarchar(8) from dual');
echo 'Statement handle: ';
var_dump($rs);
echo "\r\nError info of database handle: ";
var_dump($db->errorInfo());
$db = null;
?>
Expected result:
Somthing like:
Statement handle: bool(false)
Error info of database handle: array(1) { [0]=> string(5) "42000" [1]=>
"" [2]=> string(x) "ORA-00904: "NVARCHAR": invalid identifier"}
Actual result:
--
Statement handle: bool(false)
Error info of database handle: array(1) { [0]=> string(5) "0" }
--
Edit bug report at http://bugs.php.net/?id=33707&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33707&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33707&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33707&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33707&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33707&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33707&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33707&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33707&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33707&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33707&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33707&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33707&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33707&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33707&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33707&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33707&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33707&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33707&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33707&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33707&r=mysqlcfg
#30792 [NEW]: LDAP module could not be found
From: zengerf at post dot ch Operating system: Windows 2000 PHP version: 5.0.2 PHP Bug Type: Reproducible crash Bug description: LDAP module could not be found Description: If PHP is installed as a ISAPI-module, the LDAP-module causes the following error during the start of IIS: PHP Warning: PHP Startup: Unable to load dynamic library 'c:\PHP\ext\php_ldap.dll' - The specified module could not be found. Other modules like for example oci8 work! -- Edit bug report at http://bugs.php.net/?id=30792&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30792&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30792&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30792&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30792&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30792&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30792&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30792&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30792&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30792&r=support Expected behavior: http://bugs.php.net/fix.php?id=30792&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30792&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30792&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30792&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30792&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30792&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30792&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30792&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30792&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30792&r=mysqlcfg
#30792 [Bgs->Opn]: LDAP module could not be found
ID: 30792 User updated by: zengerf at post dot ch Reported By: zengerf at post dot ch -Status: Bogus +Status: Open Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 5.0.2 New Comment: It is not a support question! Previous Comments: [2004-11-15 10:47:13] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . [2004-11-15 10:32:12] zengerf at post dot ch Description: If PHP is installed as a ISAPI-module, the LDAP-module causes the following error during the start of IIS: PHP Warning: PHP Startup: Unable to load dynamic library 'c:\PHP\ext\php_ldap.dll' - The specified module could not be found. Other modules like for example oci8 work! -- Edit this bug report at http://bugs.php.net/?id=30792&edit=1
#30863 [NEW]: imagecolortransparent and imagetruecolortopalette don't mix
From: hp at oeri dot ch Operating system: Windows XP PHP version: 5.0.2 PHP Bug Type: GD related Bug description: imagecolortransparent and imagetruecolortopalette don't mix Description: If I create a truecolor image and a) set a color as transparent b) use imagetruecolortopalette the result is offset by one in "x" direction and a black vertical line at x=0. Leaving out either a or b gives the correct result (no offset). Didn't find this bug anywhere, am however unable to compile on Windows. Reproduce code: --- Expected result: palette image, 750x400 with a rectangle along the borders Actual result: -- palette image, 750x400, with a rectangle open to the right (offset 1) -- Edit bug report at http://bugs.php.net/?id=30863&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30863&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30863&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30863&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30863&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30863&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30863&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30863&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30863&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30863&r=support Expected behavior: http://bugs.php.net/fix.php?id=30863&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30863&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30863&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30863&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30863&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30863&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30863&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30863&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30863&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30863&r=mysqlcfg
#30957 [Com]: filesystem functions bugs in destructor (under gc condition)
ID: 30957
Comment by: iquito at gmx dot ch
Reported By: rueycheng at gmail dot com
Status: Open
Bug Type: Class/Object related
Operating System: Windows XP
PHP Version: 5.0.1
New Comment:
I also encountered this bug, it is very annoying - a class of mine
checks a file with a simple file_exists(), and the file isn't found -
the whole script works if I call the destructor at the very end of it
explicitly (which isn't really the point of having a destructor). it
seems no file functions work at all in the destructor. This bug also
applies to register_shutdown_function, it just seems that as soon as
the "regular" scripts stops, everything that comes after that has
problems with the file system.
Previous Comments:
[2004-12-02 11:25:07] rueycheng at gmail dot com
The garbage collector may clean up the object prior to its __destruct()
invocation. Nothing would go wrong if you explicitly *destroy* the
object.
By the way, I tested the code on Redhat 7.3 with the following
configuration.
$ cat config.nice
#! /bin/sh
#
# Created by configure
'./configure' \
'--with-apxs=/usr/local/apache/bin/apxs' \
'--with-mysql=/usr/local/mysql/' \
'--with-libxml-dir' \
'--enable-dba' \
'--enable-mbstring' \
"$@"
$ diff php.ini ../src/php-5.0.1/php.ini-recommended
353c353
< display_errors = On
---
> display_errors = Off
407c407
< ;error_log = /var/log/php.log
---
> ;error_log = filename
491c491
< include_path = ".:/usr/local/lib/php"
---
> ;include_path = ".:/php/includes"
As a result, two warnings are generated.
[
Warning: file_put_contents(./.bugtest) [function.file-put-contents]:
failed to open stream: Permission denied in
/home/httpd/html/testbed/bugtest.php on line 12
Warning: file_get_contents(./.bugtest) [function.file-get-contents]:
failed to open stream: No such file or directory in
/home/httpd/html/testbed/bugtest.php on line 13
]
Actually I've already enabled the write-permission for the directory.
The execution of these filesystem functions outside of __destruct() is
OK.
[2004-12-02 11:01:33] rueycheng at gmail dot com
Description:
Some filesystem functions, like file_put_contents() or fwrite(), don't
work properly in the destructor __destruct(). The following scenario
may looks a bit weird: it appeared that the file is not overwritten or
even created, but PHP does 'read' the content of the imaginary file!
If you uncomment the last line of the code, everything would works
fine.
Thanks.
$ diff php.ini php.ini-dist
288c288
< error_reporting = E_ALL
---
> error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
436c436
< include_path = ".;c:\php-5.0.1\PEAR"
---
> ;include_path = ".;c:\php\includes"
450c450
< extension_dir = "c:\php-5.0.1\ext"
---
> extension_dir = "./"
571,573c571,573
< extension=php_mbstring.dll
< extension=php_mcrypt.dll
< extension=php_mhash.dll
---
> ;extension=php_mbstring.dll
> ;extension=php_mcrypt.dll
> ;extension=php_mhash.dll
578c578
< extension=php_mysql.dll
---
> ;extension=php_mysql.dll
Reproduce code:
---
filename = $filename;
}
public function __destruct() {
echo "[";
file_put_contents($this->filename, 'Gotcha!');
echo file_get_contents($this->filename);
echo "]";
}
}
$bug = new Bug('.bugtest');
//unset($bug);
?>
Expected result:
[Gotcha!]
(And the file .bugtest under working directory should be created.)
$ cat .bugtest
Gotcha!
Actual result:
--
[Gotcha!]
$ cat .bugtest
cat: .bugtest: No such file or directory
--
Edit this bug report at http://bugs.php.net/?id=30957&edit=1
#31141 [Fbk->Opn]: wrong type of variable reference with DOMDocument Class
ID: 31141
User updated by: saschal at saschal dot ch
Reported By: saschal at saschal dot ch
-Status: Feedback
+Status: Open
Bug Type: DOM XML related
-Operating System:
+Operating System: Win 32 / Linux
PHP Version: 5.0.3
New Comment:
I use win32 XAMPP 1.4.10 (
http://www.apachefriends.org/en/xampp-windows.html )
and
Linux PHP 5.0.3RC2 (cli) (built: Dec 15 2004 14:43:51)
Previous Comments:
[2004-12-17 04:17:10] [EMAIL PROTECTED]
I can verify this on Win32, but please fill in your OS. Are you using
Win32 as well?
[2004-12-17 01:31:00] saschal at saschal dot ch
Description:
If my test class is extended with the DOMDocument class, the alias
variable becomes a wrong type (NULL).
Reproduce code:
---
class Test extends DOMDocument
{
public $array = array();
function __construct()
{
parent::__construct();
if(!$ar_test) {
$ar_test = array();
}
$this->array = &$ar_test;
echo gettype($this->array);
}
}
$newtest = new Test;
// $this->array is NULL
Expected result:
type should be array
Actual result:
--
type is NULL
--
Edit this bug report at http://bugs.php.net/?id=31141&edit=1
#31141 [Opn]: wrong type of variable reference with DOMDocument Class
ID: 31141
User updated by: saschal at saschal dot ch
Reported By: saschal at saschal dot ch
Status: Open
Bug Type: DOM XML related
Operating System: Win 32 / Linux
PHP Version: 5.0.3
New Comment:
I installed a testsystem (Linux / Apache 2 / PHP 5.03) on my
public-server. There you can see the problem:
http://knowhow.ethz.ch:81/php/testclass.php
Previous Comments:
[2004-12-17 09:07:55] saschal at saschal dot ch
I use win32 XAMPP 1.4.10 (
http://www.apachefriends.org/en/xampp-windows.html )
and
Linux PHP 5.0.3RC2 (cli) (built: Dec 15 2004 14:43:51)
[2004-12-17 04:17:10] [EMAIL PROTECTED]
I can verify this on Win32, but please fill in your OS. Are you using
Win32 as well?
[2004-12-17 01:31:00] saschal at saschal dot ch
Description:
If my test class is extended with the DOMDocument class, the alias
variable becomes a wrong type (NULL).
Reproduce code:
---
class Test extends DOMDocument
{
public $array = array();
function __construct()
{
parent::__construct();
if(!$ar_test) {
$ar_test = array();
}
$this->array = &$ar_test;
echo gettype($this->array);
}
}
$newtest = new Test;
// $this->array is NULL
Expected result:
type should be array
Actual result:
--
type is NULL
--
Edit this bug report at http://bugs.php.net/?id=31141&edit=1
#31141 [NEW]: wrong type of variable reference with DOMDocument Class
From: saschal at saschal dot ch
Operating system:
PHP version: 5.0.3
PHP Bug Type: DOM XML related
Bug description: wrong type of variable reference with DOMDocument Class
Description:
If my test class is extended with the DOMDocument class, the alias
variable becomes a wrong type (NULL).
Reproduce code:
---
class Test extends DOMDocument
{
public $array = array();
function __construct()
{
parent::__construct();
if(!$ar_test) {
$ar_test = array();
}
$this->array = &$ar_test;
echo gettype($this->array);
}
}
$newtest = new Test;
// $this->array is NULL
Expected result:
type should be array
Actual result:
--
type is NULL
--
Edit bug report at http://bugs.php.net/?id=31141&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31141&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31141&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31141&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31141&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31141&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31141&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31141&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31141&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31141&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31141&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31141&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31141&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31141&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31141&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31141&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31141&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31141&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31141&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31141&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31141&r=mysqlcfg
#31243 [NEW]: mssql_query returns false despite query succeeded (with 0 results)
From: php at pilif dot ch Operating system: Gentoo Linux PHP version: 5.0.3 PHP Bug Type: MSSQL related Bug description: mssql_query returns false despite query succeeded (with 0 results) Description: mssql_query() returns false despite a query being successfully executed if it's a query returning empty (or none) result sets (queries like INSERT or BEGIN TRANSACTION) Concerning my exmaple blelow: In the second two queries (where mssql_query falsly returned false), mssql_get_last_message() is empty. Looking at the MS-SQL-Server I could confirm that the queries where executed correctly (the ones in the example do nothing, but even when INSERTing something, I'm getting the same results). I'm quite positive that this working in PHP 5.0.2 and below. As this is quite a simple testcase and always reproducible, I'm pretty confident to have actually hit a bug here. Versions: php-5.3.0 (--with-mssql) freetds-0.62.3 (mssql support compiled in) Looking more thorugh the bug tracker, I came across #31195 which is the same thing for PHP 4.3. I can definitely confirm this happening with PHP5. Thanks for listening... Philip Reproduce code: --- Expected result: 1st query succeeded 2nd query succeeded 3rd query succeeded Actual result: -- 1st query succeeded 2nd query failed 3rd query failed -- Edit bug report at http://bugs.php.net/?id=31243&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31243&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31243&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31243&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31243&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31243&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31243&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31243&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31243&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31243&r=support Expected behavior: http://bugs.php.net/fix.php?id=31243&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31243&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31243&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31243&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31243&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31243&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31243&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31243&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31243&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31243&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31243&r=mysqlcfg
#31820 [NEW]: configuration file not read
From: info at netzpilot dot ch
Operating system: darwin
PHP version: 5.0.3
PHP Bug Type: PHP options/info functions
Bug description: configuration file not read
Description:
The configuration file is not read.
I compiled PHP --with-config-file-path=/etc/httpd and without it.
I have put a php.ini at /etc/httpd and /usr/local/lib and many more
places.
Always did a restart of apache.
I also gave all rights to php.ini.
Reproduce code:
---
echo "get_cfg_var('cfg_file_path') = " . get_cfg_var('cfg_file_path');
/* and this to check little changes in php.ini */
phpinfo();
Expected result:
the path to php.ini
Actual result:
--
compiled without '--with-config-file-path=/etc/httpd' my phpinfo says
Configuration File (php.ini) Path: /usr/local/lib
But changes in php.ini there have no effect.
--
Edit bug report at http://bugs.php.net/?id=31820&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31820&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31820&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31820&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31820&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31820&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31820&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31820&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31820&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31820&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31820&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31820&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31820&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31820&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31820&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31820&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31820&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31820&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31820&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31820&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31820&r=mysqlcfg
#22894 [Com]: set_error_handler fails to pick up method reference
ID: 22894
Comment by: patr0ck at hispeed dot ch
Reported By: david dot grant at wiredmedia dot co dot uk
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 2000
PHP Version: 4.3.1
New Comment:
i've got the same problem, but it's not depending on the number of
lines. sometimes the handler does work, sometimes it doesn't. Page
refreshing does switch between the original and my handler, but not
every time, most time it takes the original handler...
Setup:
- PHP4.3.RC4 / PHP 4.3.1
- Win 2k (shame on my workstation)
- Apache 2.0.45 / Apache 1.3.28
--
Constructor:
function handlerDebug($errno, $errmsg, $errfile, $errline, $context) {
$this->addError($errno, $errmsg, $errfile, $errline);
// redefine user error constants
define ("ERROR",E_USER_ERROR);
define ("WARNING", E_USER_WARNING);
define ("NOTICE", E_USER_NOTICE);
// set error reporting
error_reporting(E_ALL);
// set error handler
if(!$debug)
$this->old_error_handler =
set_error_handler(array(&$this,
"handlerProductive"));
else
$this->old_error_handler =
set_error_handler(array(&$this,
"handlerDebug"));
--
Method:
function handlerDebug($errno, $errmsg, $errfile, $errline, $context) {
$this->addError($errno, $errmsg, $errfile, $errline);
switch($errno)
{
case ERROR:
echo "Error: $errmsg\n";
echo " Line: $errline
\n";
echo " File:
$errfile\n";
exit(1);
break;
case WARNING:
... and so on
---
software modifications doesn't help...
btw: i hope it works on linux ;o)
Previous Comments:
[2003-04-09 16:45:04] [EMAIL PROTECTED]
Can not reproduce -> bogus.
[2003-04-09 09:32:28] david dot grant at wiredmedia dot co dot uk
I have installed 4.3.2RC as directed, but the problem remains .
[2003-04-09 06:54:36] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-04-09 06:54:14] [EMAIL PROTECTED]
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".
Thank you for your interest in PHP.
[2003-04-09 06:50:16] david dot grant at wiredmedia dot co dot uk
I've just retested this bug with the same setup (4.3.1, IIS 5), and got
some strange results.
In the constructor, I have a single instruction:
set_error_handler(array(&$this, 'ReportError'));
Then, in the ReportError() method, I have the following:
echo ("ERROR CAUGHT");
In order to test the error handler, I instantiate the object in a
seperate script, and attempt to increment variable i , which doesn't
exist. This *should* be handled by the error handling class, but is
not. It is instead handled by the built-in PHP error handler.
Now for the strange part.
I added a HTML comment (echo("")) to both the constructor and
the ReportError method, and PHP started to use my error reporting class
to report the error.
With further investigation, the reporting seems to change depending on
the number of lines in the file.
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/22894
--
Edit this bug report at http://bugs.php.net/?id=22894&edit=1
#22894 [Com]: set_error_handler fails to pick up method reference
ID: 22894
Comment by: patr0ck at hispeed dot ch
Reported By: david dot grant at wiredmedia dot co dot uk
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 2000
PHP Version: 4.3.1
New Comment:
oh, sorry it's wrong:
function JacketError($debug=false) {
$this->class_version = "0.1";
// redefine user error constants
define ("ERROR",E_USER_ERROR);
define ("WARNING", E_USER_WARNING);
define ("NOTICE", E_USER_NOTICE);
// set error reporting
error_reporting(E_ALL);
// set error handler
if(!$debug)
$this->old_error_handler =
set_error_handler(array(&$this,
"handlerProductive"));
else
$this->old_error_handler =
set_error_handler(array(&$this,
"handlerDebug"));
that's the constructor... copy paste is difficult ;)
Previous Comments:
----
[2003-08-20 08:55:38] patr0ck at hispeed dot ch
i've got the same problem, but it's not depending on the number of
lines. sometimes the handler does work, sometimes it doesn't. Page
refreshing does switch between the original and my handler, but not
every time, most time it takes the original handler...
Setup:
- PHP4.3.RC4 / PHP 4.3.1
- Win 2k (shame on my workstation)
- Apache 2.0.45 / Apache 1.3.28
--
Constructor:
function handlerDebug($errno, $errmsg, $errfile, $errline, $context) {
$this->addError($errno, $errmsg, $errfile, $errline);
// redefine user error constants
define ("ERROR",E_USER_ERROR);
define ("WARNING", E_USER_WARNING);
define ("NOTICE", E_USER_NOTICE);
// set error reporting
error_reporting(E_ALL);
// set error handler
if(!$debug)
$this->old_error_handler =
set_error_handler(array(&$this,
"handlerProductive"));
else
$this->old_error_handler =
set_error_handler(array(&$this,
"handlerDebug"));
--
Method:
function handlerDebug($errno, $errmsg, $errfile, $errline, $context) {
$this->addError($errno, $errmsg, $errfile, $errline);
switch($errno)
{
case ERROR:
echo "Error: $errmsg\n";
echo " Line: $errline
\n";
echo " File:
$errfile\n";
exit(1);
break;
case WARNING:
... and so on
---
software modifications doesn't help...
btw: i hope it works on linux ;o)
[2003-04-09 16:45:04] [EMAIL PROTECTED]
Can not reproduce -> bogus.
[2003-04-09 09:32:28] david dot grant at wiredmedia dot co dot uk
I have installed 4.3.2RC as directed, but the problem remains .
[2003-04-09 06:54:36] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-04-09 06:54:14] [EMAIL PROTECTED]
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".
Thank you for your interest in PHP.
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/22894
--
Edit this bug report at http://bugs.php.net/?id=22894&edit=1
#25198 [NEW]: error_reporting() seems to affect whole server
From: red at raven dot ch Operating system: linux (redhat 9) apache 2.0.47 PHP version: 4.3.2 PHP Bug Type: PHP options/info functions Bug description: error_reporting() seems to affect whole server Description: The global configuration shows the following: error_reporting 20392039 when 2 scripts in 2 differents virtualhosts run at the same time and the first one sets error_reporting(E_ALL) and the second one starts before the first ended (and doesn't set error_reporting) it shows the notices as well. ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-xml --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-mysql=/usr --with-zlib-dir=/usr --enable-sysvshm --enable-sysvsem --with-xslt --with-ttf --with-freetype-dir=/usr/local --enable-gd-native-ttf --disable-cgi --with-dom --with-dom-xslt --with-iconv -- Edit bug report at http://bugs.php.net/?id=25198&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25198&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25198&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25198&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25198&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25198&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25198&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25198&r=support Expected behavior: http://bugs.php.net/fix.php?id=25198&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25198&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25198&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25198&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25198&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25198&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25198&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25198&r=gnused
#25198 [Fbk->Opn]: error_reporting() seems to affect whole server
ID: 25198 User updated by: red at raven dot ch Reported By: red at raven dot ch -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: linux (redhat 9) apache 2.0.47 PHP Version: 4.3.2 New Comment: hm, this is a server with about 40 domains running on it. so I don't really like the idea of running a cvs-snapshot (or release-candidate). well, I will try to recreate this one on my development-server. apache2 configuration: ./configure --enable-so --enable-rewrite --enable-proxy Previous Comments: [2003-08-21 18:52:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Also, what was the configure line you used for Apache2? [2003-08-21 12:40:48] red at raven dot ch Description: The global configuration shows the following: error_reporting 20392039 when 2 scripts in 2 differents virtualhosts run at the same time and the first one sets error_reporting(E_ALL) and the second one starts before the first ended (and doesn't set error_reporting) it shows the notices as well. ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-xml --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-mysql=/usr --with-zlib-dir=/usr --enable-sysvshm --enable-sysvsem --with-xslt --with-ttf --with-freetype-dir=/usr/local --enable-gd-native-ttf --disable-cgi --with-dom --with-dom-xslt --with-iconv -- Edit this bug report at http://bugs.php.net/?id=25198&edit=1
#25207 [NEW]: multiple auto_prepend_file, auto_append_file
From: zeug at delirium dot ch Operating system: Irrelevant PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: multiple auto_prepend_file, auto_append_file Description: Hi Devs I'm referring to bug #3293. Yes, allowing multiple auto_prepend_file/auto_append/file does make sense. Picture this: You have your global configs in a file that's auto prepended. And you want to use a package using auto_prepend_file as well (like my db_auth, see https://www.bitcetera.com/en/project/pear/). You can't include() dbauth to your global config as you don't want to protect all pages. And you don't want to include() your global config in dbauth as this means you have to alter the code of dbauth and trouble arises when new dbauth versions are released. I suggest allowing the following: auto_prepend_file /path/to/inc1.php:/path/to/inc2.php Allowing several auto_prepend_file directires is not a good idea as things would get very messy when using it with .htaccess. Love PHP! -sven -- Edit bug report at http://bugs.php.net/?id=25207&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25207&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25207&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25207&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25207&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25207&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25207&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25207&r=support Expected behavior: http://bugs.php.net/fix.php?id=25207&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25207&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25207&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25207&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25207&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25207&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25207&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25207&r=gnused
#25198 [Opn]: error_reporting() seems to affect whole server
ID: 25198 User updated by: red at raven dot ch Reported By: red at raven dot ch Status: Open Bug Type: PHP options/info functions Operating System: linux (redhat 9) apache 2.0.47 PHP Version: 4.3.2 New Comment: just installed php-4.3.3; still the same problem... Previous Comments: [2003-08-22 00:21:22] red at raven dot ch hm, this is a server with about 40 domains running on it. so I don't really like the idea of running a cvs-snapshot (or release-candidate). well, I will try to recreate this one on my development-server. apache2 configuration: ./configure --enable-so --enable-rewrite --enable-proxy [2003-08-21 18:52:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Also, what was the configure line you used for Apache2? [2003-08-21 12:40:48] red at raven dot ch Description: The global configuration shows the following: error_reporting 20392039 when 2 scripts in 2 differents virtualhosts run at the same time and the first one sets error_reporting(E_ALL) and the second one starts before the first ended (and doesn't set error_reporting) it shows the notices as well. ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-xml --with-gd --with-png-dir=/usr --with-jpeg-dir=/usr --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-mysql=/usr --with-zlib-dir=/usr --enable-sysvshm --enable-sysvsem --with-xslt --with-ttf --with-freetype-dir=/usr/local --enable-gd-native-ttf --disable-cgi --with-dom --with-dom-xslt --with-iconv -- Edit this bug report at http://bugs.php.net/?id=25198&edit=1
#24282 [Com]: Strange Open Base Dir Restriction Errors
ID: 24282 Comment by: red at raven dot ch Reported By: matzrek at shw-networks dot de Status: Open Bug Type: Apache related Operating System: Suse Linux 8.2 / Apache 1.3.27 PHP Version: 4.3.2 New Comment: seems to be the same or similar thing: bug #25198 I realised the same issue as dprado at floripa dot com dot br mentioned... Previous Comments: [2003-08-25 23:57:05] celticlegend at dublin dot com Am working with my hosting co. on what appears to be this same problem. php v.4.3.1, on Apache. The problem is very intermittent, and is triggered by the main site's index.php, the phpBB forum's .php files (various), and a blogger app (php). The hosting techs have not been able to trigger it yet, and say that we are their only customer reporting this problem. Strangely enough, all the errors indicate the offending page is trying to reach another users' directory (/home/bone and others). Sample errors follow: # Example #1 of 3: Warning: Unknown(): open_basedir restriction in effect. File(/home/clegend/public_html/index.php) is not within the allowed path(s): (/home/bone) in Unknown on line 0 Warning: Unknown(/home/clegend/public_html/index.php): failed to create stream: Operation not permitted in Unknown on line 0 Warning: Unknown(): Failed opening '/home/clegend/public_html/index.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php:/tmp') in Unknown on line 0 (note: I have scoured the code and there is no reference to /home/bone anywhere.) # Example #2 of 3: Warning: Unknown(): open_basedir restriction in effect. File(/home/clegend/public_html/forum/viewtopic.php) is not within the allowed path(s): (/home/bone) in Unknown on line 0 Warning: Unknown(/home/clegend/public_html/forum/viewtopic.php): failed to create stream: Operation not permitted in Unknown on line 0 Warning: Unknown(): Failed opening '/home/clegend/public_html/forum/viewtopic.php' for inclusion (include_path='') in Unknown on line 0 # Example #3 of 3: Warning: Unknown(): open_basedir restriction in effect. File(/home/clegend/public_html/forum/posting.php) is not within the allowed path(s): (/home/bone) in Unknown on line 0 Warning: Unknown(/home/clegend/public_html/forum/posting.php): failed to create stream: Operation not permitted in Unknown on line 0 Warning: Unknown(): Failed opening '/home/clegend/public_html/forum/posting.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in Unknown on line 0 # Apparently my host tech just replied to my ticket on this, just as I was about to hit "Submit": they found this ticket and are trying to apply what dprado suggested. Thanks in advance. [2003-08-21 12:38:31] matzrek at shw-networks dot de Will send my config this evening. Daniel [2003-08-21 11:40:14] fs at nessus dot at ok, i just sent you my configuration files. the php file is nonsense because it happens everywhere, phpinfo() for example. i hope we can fix it as soon as possible. greetings, Florian Schicker [2003-08-15 11:07:33] [EMAIL PROTECTED] I say again: We need to get the httpd.conf, etc. with which you HAVE been experiencing this problem. Read my previous comment. [2003-08-15 10:48:00] matzrek at shw-networks dot de Hi sniper, This error cannot be reproduces exactly at the moment. It happens sometimes. The only thin i realized : it does not appear directly after restarting apache. I have to wait several hours until it happens the first time. Daniel 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/24282 -- Edit this bug report at http://bugs.php.net/?id=24282&edit=1
#23682 [NoF->Opn]: sybase_query and multiple result sets: not returning first row set
ID: 23682
User updated by: uk at dataway dot ch
Reported By: uk at dataway dot ch
-Status: No Feedback
+Status: Open
Bug Type: Sybase-ct (ctlib) related
-Operating System: Linux 2.4.20
+Operating System: Linux 2.4.21
-PHP Version: 4.3.2RC4
+PHP Version: 4.3.3
New Comment:
The issue is still present in version 4.3.3. This is unsurprising,
since the code in question was not changed.
Why don't you want to apply the patch I supplied?
Previous Comments:
[2003-08-26 00:58:29] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-08-19 19:20:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
And possibly update your patch for it.
Is bug #25161 possibly caused by this..?
[2003-05-27 03:38:15] uk at dataway dot ch
This issue is still present in 4.3.2RC4
[2003-05-18 11:55:56] uk at dataway dot ch
Here (with a slight correction, CS_STATUS_RESULT
doesn't return a result set)
--- ext/sybase_ct/php_sybase_ct.c.orig Sun May 18 17:49:26 2003
+++ ext/sybase_ct/php_sybase_ct.c Sun May 18 18:37:11 2003
@@ -1386,8 +1386,22 @@
case CS_CURSOR_RESULT:
case CS_PARAM_RESULT:
case CS_ROW_RESULT:
- /* Unexpected results, cancel them. */
+ if (status != Q_RESULT) {
+ result = php_sybase_fetch_result_set(sybase_ptr, buffered,
store);
+ if (result == NULL) {
+ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_ALL);
+sybase_ptr->dead = 1;
+RETURN_FALSE;
+ }
+ status = Q_RESULT;
+ }
+ else {
+ /* Unexpected results, cancel them. */
+ ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_CURRENT);
+ }
+ break;
case CS_STATUS_RESULT:
+ /* Unexpected results, cancel them. */
ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_CURRENT);
break;
[2003-05-18 11:44:29] [EMAIL PROTECTED]
Provide that patch in unified form (diff -u).
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/23682
--
Edit this bug report at http://bugs.php.net/?id=23682&edit=1
#25667 [NEW]: Strange switch-case behaviour
From: zeug at delirium dot ch Operating system: Linux 2.4.20-3-386 PHP version: 4.3.3 PHP Bug Type: Scripting Engine problem Bug description: Strange switch-case behaviour Description: Hi there This is a very minor bug concerning the structure of a source code rather than its functionality. It's been dealt with in Bug #13387, yet the case was closed back then when it seems to have been fixed in 4.2.0-dev. It's back in 4.3.3. Here are some examples: Example 1, okay: Example 2, okay: Example 3, syntax error: The parser doesn't seem to like whitespace in HTML between switch and case. When mixing PHP and HTML code, the syntax in example 3 can improve readablility. Reproduce code: --- Expected result: 1 Actual result: -- Parse error: parse error, expecting `T_ENDSWITCH' or `T_CASE' or `T_DEFAULT' in .../test.php on line 4 -- Edit bug report at http://bugs.php.net/?id=25667&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25667&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25667&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25667&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25667&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25667&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25667&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25667&r=support Expected behavior: http://bugs.php.net/fix.php?id=25667&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25667&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25667&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25667&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25667&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25667&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25667&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25667&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25667&r=float
#24131 [Com]: session_start() warns about failed read
ID: 24131
Comment by: leo at alternative dot ch
Reported By: meat at reed dot edu
Status: Bogus
Bug Type: Session related
Operating System: Linux 2.2.16-22 SMP
PHP Version: 4.3.2
New Comment:
I get this bug too with 4.3.3 on a YellowDog Champion
Server release 1.2
-leo
Previous Comments:
[2003-07-02 03:45:12] dont at spam dot me "manfred at yumyum dot at"
ok, i also had this bug with 4.3.2 on a RH 6.2 system and could
reproduce it.
the php source code for this shows in 4.2.2:
-
if (n != sbuf.st_size) {
efree(*val);
return FAILURE;
}
-
while in 4.3.2:
-
if (n != sbuf.st_size) {
if (n == -1)
php_error_docref(NULL TSRMLS_CC, E_WARNING, "read failed:
%s (%d)", strerror(errno), errno);
else
php_error_docref(NULL TSRMLS_CC, E_WARNING, "read returned
less bytes than requested");
efree(*val);
return FAILURE;
}
-
so basically its the same code as in 4.2.2 just with
some warning-messages added.
so i assume the reason for the warnings was also there in 4.2.2. but
with 4.2.2 the whole stuff worked, so maybe that
warning should be safe to ignore.
i just commented the 2 warnings out in the source code, works for me
now (altough not a clean solution;)
i think the whole stuff might be caused by some 32/64 bit troubles in
the system. this is what i found somewhere else:
At a glance I'd say an lstat limit. There's an lstat64() call whose
returned structure has wider size fields. That's the core reason for
this ugly open64/lseek64/... fiasco - binary compatability :-(
Given that system calls are a binary API you're pretty much stuck with
this.
---
[2003-06-12 05:39:31] [EMAIL PROTECTED]
Since even you can't reproduce it on another box, we should
assume it's just problem with the system, not PHP.
[2003-06-11 23:13:23] meat at reed dot edu
I certainly hope that I can't reproduce this bug, since
all it takes is a call to session_start()--all configs
are out-of-the-box defaults. No, I am not sure it's
not a kernel bug, but the same scripts work flawlessly
on my FreeBSD box. I guess I will keep it as
@session_start() and see if the admin will upgrade the
kernel (and the Apache installation).
[2003-06-11 18:42:38] [EMAIL PROTECTED]
Can you reproduce this within some other machine?
And are you sure it's not just some bug in that kernel?
(latest is 2.2.25 already.. :)
[2003-06-11 17:41:59] meat at reed dot edu
This occurs both when session.save_path is the default
(/tmp) and when I set it to something else. The
session files are created successfully. Like I said in
the original submissions, the sessions appear to work
just fine, and the warning only happens when starting a
fresh session. It's totally possible that something is
broken on the system, but that would seem to be at odds
with the apparent functionality despite the warning.
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/24131
--
Edit this bug report at http://bugs.php.net/?id=24131&edit=1
#26011 [NEW]: filemtime-problem
From: final at solnet dot ch Operating system: SuSE Linux 8.2 PHP version: 4.3.3 PHP Bug Type: Filesystem function related Bug description: filemtime-problem Description: ok, i've written a "watcher-tool" for my /var/log/mail, which is a syslog-file (for pop-before-smtp with sendmail, but this doesn't matter). i have a never ending do-while with a sleep of 4 seconds, and i use filemtime to see if something changed in /var/log/mail. well, the problem was, the script never went through even if the file got changed (i've checked that with ls -l many times...). only if you get filemtime of another file between two filemtimes of /var/log/mail, php noticed that the file modification time changed. well, but if you edit the file by an editor, php does notice it. first i thought, its a matter of syslog-daemon, but since i tried to use filemtime on another file between two checks of /var/log/mail, im not sure anymore... Reproduce code: --- #!/usr/local/php/bin/php Expected result: Get out of do ... while as soon as sendmail/postfix/qpopper/ipopd/whatever writes something to your /var/log/mail Actual result: -- you won't get out :p -- Edit bug report at http://bugs.php.net/?id=26011&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26011&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26011&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26011&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26011&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26011&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26011&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26011&r=support Expected behavior: http://bugs.php.net/fix.php?id=26011&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26011&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26011&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26011&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26011&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26011&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26011&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26011&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26011&r=float
#26064 [NEW]: Warning: mime_magic: invalid type 0 in mconvert(). in ...
From: e05 at freemails dot ch Operating system: Linux 2.4.20 (Debian) PHP version: 4.3.3 PHP Bug Type: Unknown/Other Function Bug description: Warning: mime_magic: invalid type 0 in mconvert(). in ... Description: Well, there isn´t much to tell. The error message is: Warning: mime_magic: invalid type 0 in mconvert(). in /foo/bar.php on line 2 mconvert doesn´t seems to be a public funktion as http://www.php.net/mconvert didn´t work. Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=26064&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26064&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26064&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26064&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26064&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26064&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26064&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26064&r=support Expected behavior: http://bugs.php.net/fix.php?id=26064&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26064&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26064&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26064&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26064&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26064&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26064&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26064&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26064&r=float
#26064 [Fbk->Opn]: Warning: mime_magic: invalid type 0 in mconvert(). in ...
ID: 26064
User updated by: e05 at freemails dot ch
Reported By: e05 at freemails dot ch
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux 2.4.20 (Debian)
PHP Version: 4.3.3
New Comment:
m
1st this seems to happen to all files
2nd the avi is too large (190 MB)
but I tried to write a test script:
\n";
var_dump(mime_content_type('/home/e05/file2.mov'));
print "\n";
var_dump(mime_content_type('/home/e05/file3.zip'));
print "\n";
var_dump(mime_content_type('/home/e05/file4.rm'));
print "";
?>
The intresting point seems to be the output.
Warning: mime_magic: invalid type 0 in mconvert(). in
/home/ck/lamp/public_html/filemanager/bugtest1.php on line 2
(repeats about more than hundred times each line with a
mime_content_type call! while ignoring print "\n";)
the end is that the last mime_content_type returns a value after a lot
warnings:
string(19) "application/x-troff"
The only print "\n"; that seems to be executed works there.
Previous Comments:
[2003-10-31 16:43:39] [EMAIL PROTECTED]
Would it be possible for you to make the avi file in question
avaliable?
--------
[2003-10-31 16:02:16] e05 at freemails dot ch
Description:
Well, there isn´t much to tell. The error message is:
Warning: mime_magic: invalid type 0 in mconvert(). in /foo/bar.php on
line 2
mconvert doesn´t seems to be a public funktion as
http://www.php.net/mconvert didn´t work.
Reproduce code:
---
--
Edit this bug report at http://bugs.php.net/?id=26064&edit=1
#26064 [Bgs]: error msg without sense: Warning: mime_magic: invalid type 0 in mconvert(). in
ID: 26064
User updated by: e05 at freemails dot ch
-Summary: Warning: mime_magic: invalid type 0 in mconvert(). in
...
Reported By: e05 at freemails dot ch
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux 2.4.20 (Debian)
PHP Version: 4.3.3
New Comment:
well, it sounds like the mistake is mine but the error message is not
really usefull :(
I would preffer an error message that says "Hey, you´ve got a problem
magic file" (well, something like that; And I have to check that)
But the error messages is really useless!
Previous Comments:
[2003-11-02 15:59:04] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Sounds like a problem with your magic file used by the mime_magic
extension.
[2003-11-01 04:09:05] e05 at freemails dot ch
m
1st this seems to happen to all files
2nd the avi is too large (190 MB)
but I tried to write a test script:
\n";
var_dump(mime_content_type('/home/e05/file2.mov'));
print "\n";
var_dump(mime_content_type('/home/e05/file3.zip'));
print "\n";
var_dump(mime_content_type('/home/e05/file4.rm'));
print "";
?>
The intresting point seems to be the output.
Warning: mime_magic: invalid type 0 in mconvert(). in
/home/ck/lamp/public_html/filemanager/bugtest1.php on line 2
(repeats about more than hundred times each line with a
mime_content_type call! while ignoring print "\n";)
the end is that the last mime_content_type returns a value after a lot
warnings:
string(19) "application/x-troff"
The only print "\n"; that seems to be executed works there.
[2003-10-31 16:43:39] [EMAIL PROTECTED]
Would it be possible for you to make the avi file in question
avaliable?
----
[2003-10-31 16:02:16] e05 at freemails dot ch
Description:
Well, there isn´t much to tell. The error message is:
Warning: mime_magic: invalid type 0 in mconvert(). in /foo/bar.php on
line 2
mconvert doesn´t seems to be a public funktion as
http://www.php.net/mconvert didn´t work.
Reproduce code:
---
--
Edit this bug report at http://bugs.php.net/?id=26064&edit=1
#26105 [Com]: argument format specified for non-function
ID: 26105 Comment by: php at dactar dot ch Reported By: simon dot boulet at divahost dot net Status: Open Bug Type: Compile Failure Operating System: Linux/gcc 3.0.4 PHP Version: 4.3.4 New Comment: I've the same problem on HP-UX 11.00 and gcc version 3.0.1 @++ JC Previous Comments: [2003-11-03 21:39:45] simon dot boulet at divahost dot net Description: The new version on PHP fails to compile. I was previously using version 4.3.3 and it was compiling fine. Configure flags: --with-mysql --with-apxs --with-gd -with-zlib --with-jpeg-dir=/usr --with-apxs=/usr/local/apache/bin/apxs `make` fails straight at the beginning with: /bin/sh /root/php-4.3.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/zlib/ -I/root/php-4.3.4/ext/zlib/ -DPHP_ATOM_INC -I/root/php-4.3.4/include -I/root/php-4.3.4/main -I/root/php-4.3.4 -I/root/php-4.3.4/Zend -I/root/php-4.3.4/ext/xml/expat -I/root/php-4.3.4/TSRM -g -O2 -prefer-pic -c /root/php-4.3.4/ext/zlib/zlib.c -o ext/zlib/zlib.lo In file included from /root/php-4.3.4/main/php.h:34, from /root/php-4.3.4/ext/zlib/zlib.c:28: /root/php-4.3.4/Zend/zend.h:311: argument format specified for non-function `error_function' /root/php-4.3.4/Zend/zend.h:312: argument format specified for non-function `printf_function' /root/php-4.3.4/Zend/zend.h:444: argument format specified for non-function `zend_printf' /root/php-4.3.4/Zend/zend.h:451: argument format specified for non-function `zend_error_cb' make: *** [ext/zlib/zlib.lo] Error 1 I am far from being a C expert, but I think it as something to do with GCC version checking in Zend/zend.h near line 155. I was able to compile just fine with: #define ZEND_ATTRIBUTE_PTR_FORMAT(type, idx, first) instead of: # define ZEND_ATTRIBUTE_PTR_FORMAT(type, idx, first) __attribute__ ((format(type, idx, first))) that would be defined with ZEND_GCC_VERSION >= 3000. -- Edit this bug report at http://bugs.php.net/?id=26105&edit=1
#27375 [Fbk->Opn]: $DOCUMENT_ROOT sometimes empty when register_globals=on
ID: 27375
User updated by: oliver at update dot ch
Reported By: oliver at update dot ch
-Status: Feedback
+Status: Open
Bug Type: Apache2 related
Operating System: Linux
-PHP Version: 4CVS-2004-02-24 (stable)
+PHP Version: 4.3.3.
New Comment:
Sorry about that. I'm not the pro on stuff like this.
But I try again:
Configuration:
--
'./configure' '--with-apxs2=/opt/httpd-2.0.47/bin/apxs'
'--with-config-file-path=/etc/httpd2' '--prefix=/opt/
php-4.x' '--enable-versioning' '--with-gd' '--with-jpeg-
dir=/usr' '--with-xpm-dir=/usr' '--with-bz2' '--with-
freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-
debug=no' '--with-exec-dir=/opt/php-4.x/run' '--enable-
track-vars=yes' '--disable-cgi' '--enable-calendar' '--
with-ttf' '--with-imap' '--with-ft' '--with-xml' '--
with-mhash' '--with-mcrypt' '--with-bcmath' '--with-
snmp' '--enable-ucd-snmp-hack' '--enable-ucd-snmp-
compatibility' '--with-pdflib=/opt/pdflib-4.0' '--with-
zlib' '--enable-trans-sid' '--with-openssl' '--with-
wddx' '--with-crack' '--with-kerberos' '--with-gettext'
Reproduce code:
---
register_globals: ""
$GLOBALS["DOCUMENT_ROOT"] = "
$DOCUMENT_ROOT: ""
$_SERVER["DOCUMENT_ROOT"]: ""
Expected result:
register_globals: "1"
$GLOBALS["DOCUMENT_ROOT"] = "/home/www/
$DOCUMENT_ROOT: "/home/www/"
$_SERVER["DOCUMENT_ROOT"]: "/home/www/"
Result (tested on 02/24/04):
--
register_globals: "1"
$GLOBALS["DOCUMENT_ROOT"] = ""
$DOCUMENT_ROOT: ""
$_SERVER["DOCUMENT_ROOT"]: "/home/www/"
PHP-Version is 4.3.3.
The thing is, that I couldn't reproduce the result today
(02/25). So I guess, you can really let vanish this
report. Thanks for the help anyway.
Previous Comments:
[2004-02-24 16:57:50] [EMAIL PROTECTED]
Second try. (If I have to ask these same things for the 3rd time, this
bug report will vanish mysteriously..)
1. How did you configure Apache? (configure line used)
2. What MPM are you using with Apache?
3. What is register_globals set to WHEN this happens?
(put var_dump(ini_get("register_globals")); in the beginning of your
script, see bug #24253 what a nice short test script looks like)
4. Are you sure there aren't any .htaccess files or vhosts setting
register_globals to something else? Or setting any other php.ini
options? (using php_value, php_admin_value, php_flag or php_admin_flag
directives)
5. How was PHP configured into Apache? (as module or CGI binary??)
[2004-02-24 12:59:58] oliver at update dot ch
register_globals is always set on. register_globals is
set to on in the php.ini file.
SERVER_SOFTWARE:
Apache/2.0.47 (Unix) mod_perl/1.99_09 Perl/v5.6.1
mod_ssl/2.0.47 OpenSSL/0.9.6c DAV/2 FrontPain/5.0.0.0
[2004-02-24 12:03:10] [EMAIL PROTECTED]
When this happens, is register_globals on or off?
Do you override it in some vhost ?
How do you do it?
In other words: Not enough information..
[2004-02-24 07:30:00] oliver at update dot ch
Description:
The Global Variable $GLOBALS["DOCUMENT_ROOT"] or $DOCUMENT_ROOT is
sometimes empty.
After a reload $DOCUMENT_ROOT mostly contains the expected value.
see also http://bugs.php.net/bug.php?id=25172
--
Edit this bug report at http://bugs.php.net/?id=27375&edit=1
#27456 [NEW]: file upload with arrays loses $_POST vars
From: php at humbapa dot ch
Operating system: apache 2.0.48 @ Linux 2.6.2
PHP version: 4.3.5RC3
PHP Bug Type: Unknown/Other Function
Bug description: file upload with arrays loses $_POST vars
Description:
when I use a form with all input-fields named e.g. "foo[]" the fields
after an input-file-field will be lost in the $_POST var.
Reproduce code:
---
0) {
print_r($_POST);
print_r($_FILES);
}
?>
Expected result:
Array
(
[foo] => Array
(
[0] => bar1
[1] => bar2
)
)
Array
(
[foo] => Array
(
[name] => Array
(
[0] => file1
[1] => file2
)
...SKIP...
Actual result:
--
Array
(
[foo] => Array
(
[0] => bar1
)
)
Array
(
[foo] => Array
(
[name] => Array
(
[0] => file1
[1] => file2
)
...SKIP...
--
Edit bug report at http://bugs.php.net/?id=27456&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27456&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27456&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27456&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27456&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27456&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27456&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27456&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27456&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27456&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27456&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27456&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27456&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27456&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27456&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27456&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27456&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27456&r=float
#18251 [Com]: Lost variables from post action
ID: 18251
Comment by: dbucher at horus dot ch
Reported By: jazar at zacks dot com
Status: Bogus
Bug Type: Variables related
Operating System: WindowsXP, Linux
PHP Version: 4.1.2
New Comment:
I have exactely the same problem.
For some people they have the problem 9 out of 10 times,
they can't use the script at all.
Personnally, some days I have the problem 1/4 times, some
other days almost never.
I'm using $_POST['xxx']
And PHP Version 4.1.2
Under Linux (none) 2.4.20-6um #1 SMP Fri Jun 6 10:15:19 EDT 2003 i686
unknown
safe_mode
Previous Comments:
[2003-01-11 02:54:14] tagg_maiwald at yahoo dot com
Ack.
1. First form name = foo
2. Second (last) print_r: print_r ($_GET)
[2003-01-11 02:49:04] tagg_maiwald at yahoo dot com
I did encounter a similar coding error: queried the $_POST array
multiple times, came up empty subsequent times.
CODE FIX: reset($_POST)
HTTP SERVER/PHP TEST SCRIPT:
posttest.php
Foo A
Foo B
Foo C
Foo D
Bar 1
Bar 2
Bar 3
Bar 4
method = post";
while (list ($cgi_foo, $cgi_on) = each ($_POST))
{ if (is_array($cgi_on))
{ while (list ($cgi_bar, $cgi_val) = each ($cgi_on))
{ $sz_ret .=
"\n".''.$cgi_foo.'--'.$cgi_bar.'';
}
} elseif (('on'==$cgi_on)&&('foo_'==substr($cgi_foo,0,4)))
{ $sz_ret .= "\n".''.$cgi_foo.'';
} else
{ $sz_ret .= "\ngot: '$cgi_foo', '$cgi_on'";
}
$i_counter++;
}
if (1>$i_counter)
{ echo "\n\n";
print_r ($_POST);
echo "\n\n";
}
} elseif (isset($_GET)&&(0'.$cgi_foo.'--'.$cgi_bar.'';
}
} elseif (('on'==$cgi_on)&&('foo_'==substr($cgi_foo,0,4)))
{ $sz_ret .= "\n".''.$cgi_foo.'';
} else
{ $sz_ret .= "\ngot: '$cgi_foo', '$cgi_on'";
}
$i_counter++;
}
if (1>$i_counter)
{ echo "\n\n";
print_r ($_POST);
echo "\n\n";
}
} else
{ $sz_ret .= " no data extracted";
}
$sz_ret .= "i_counter = $i_counter";
return $sz_ret;
}
print get_foos();
?>
[2002-12-15 06:44:10] roberto_orenstein at yahoo dot com dot br
Running php 4.2.3 on apache 1.3.27 on Win2k.
In some pages my POST variables make it to the next page missing the
first 4 character's. If I send "test_data", I'll get only "_data" on
the other side. The funny thing is that it only happens in one machine.
I have two other machines with the same configuration and nothing wrong
happens. And it appears that this bug happens only with array from form
variables.
Any thoughts???
[2002-11-29 14:20:38] jazar at zacks dot com
The answer will be "We are not support previous PHP versions" ;-)
[2002-11-28 14:00:39] sk at pilonet dot de
My problem might be affected by this bug.
I'm using PHP 4.2.3 (sapi) on Windows 2000 Server running Apache 1.3.27
as Webserver.
My form:
Then I'm dumping $_POST, where the following happens:
When input was an integer from 1-999 it is displayed correctly. From
1000 on the corresponding post value is "false". Inserting "abcdefgh"
in the form results in "efgh"...
Any Ideas?
Copying that example to my debian system, running PHP 4.2.3 on an
apache 1.3.26, the result is fine and works as expected.
Hope that helps finding another bug,
Stefan
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/18251
--
Edit this bug report at http://bugs.php.net/?id=18251&edit=1
#27554 [NEW]: GTK installation failed
From: timon at digitalforce dot ch Operating system: Suse Linux 9.0 PHP version: Irrelevant PHP Bug Type: Unknown/Other Function Bug description: GTK installation failed Description: Hello my dearest i am trying to install PHP-GTK (Version 0.5 and/or 1.0) on my machine (SUSE-Linux 9.0) in both cases when i call the #./buildconf shellscript i get the following error. make: phpize: Kommando nicht gefunden make: *** [buildmk.stamp] Fehler 127 the above is in german an will mean make: phpize: command not found make: *** [buildmk.stamp] error 127 so whats the problem? -- Edit bug report at http://bugs.php.net/?id=27554&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27554&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27554&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27554&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27554&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27554&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27554&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27554&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27554&r=support Expected behavior: http://bugs.php.net/fix.php?id=27554&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27554&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27554&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27554&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27554&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27554&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27554&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27554&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27554&r=float
#27642 [Com]: mysqli_prop.c: In function `stmt_affected_rows_read'
ID: 27642 Comment by: spam at 8304 dot ch Reported By: josh at trutwins dot homeip dot net Status: Bogus Bug Type: Compile Failure Operating System: Linux SuSE 8.1 PHP Version: 5.0.0RC1 New Comment: same problem under suse 9.0. 5.0.0b4 compiled perfectely, but with the same config.nice build of 5.0.0rc1 fails: #! /bin/sh # # Created by configure './configure' \ '--prefix=/usr/local/php5' \ '--with-apxs2=/usr/local/apache2/bin/apxs' \ '--with-iconv' \ '--enable-mbstring' \ '--enable-track-vars' \ '--enable-safe-mode' \ '--with-gd' \ '--with-curl' \ '--with-ttf' \ '--with-mysql=/usr/local/mysql500' \ '--with-mysqli=/usr/local/mysql500/bin/mysql_config' \ '--with-xml' \ '--enable-memory-limit' \ '--with-png-dir=/usr/lib' \ '--with-jpeg-dir=/usr/lib' \ '--with-freetype-dir=/usr/lib' \ '--with-zlib' \ '--enable-ftp' \ '--with-openssl' \ '--with-ldap' \ '--enable-mbstring' \ '--with-mssql=/usr/local/freetds' \ "$@" /usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c: In function `stmt_affected_rows_read': /usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: error: structure has no member named `affected_rows' /usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: error: structure has no member named `affected_rows' /usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: error: structure has no member named `affected_rows' make: *** [ext/mysqli/mysqli_prop.lo] Error 1 Previous Comments: [2004-03-19 01:16:37] [EMAIL PROTECTED] MySQL 5.0 is a preview version for SP's. Fixes and changes in 4.1 are currently not merged in 5.0 tree, this will probably happen when 4.1.3-beta will come out. [2004-03-18 19:23:43] josh at trutwins dot homeip dot net Oops, bad subject. [2004-03-18 19:15:26] josh at trutwins dot homeip dot net Description: Attempting to compile PHP-5.0.0RC1 with MySQL 5.0.0 alpha built from source using --with-mysqli Here is the error: cc1: warning: changing search order for system directory "/usr/local/include" cc1: warning: as it has already been specified as a non-system directory /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c: In function `stmt_affected_rows_read': /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' /usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: structure has no member named `affected_rows' make: *** [ext/mysqli/mysqli_prop.lo] Error 1 Here is the configure script: ./configure \ --with-config-file-path=/etc/httpd \ --enable-libgcc \ --enable-sigchild \ --enable-track-vars \ --disable-ipv6 \ \ --with-apxs2=/usr/local/apache/bin/apxs \ \ --enable-exif \ --enable-ftp \ --enable-sockets \ --with-mcrypt \ --with-mhash \ --with-openssl \ --with-iconv \ --with-ncurses \ --with-readline \ --with-curl \ \ --with-bz2 \ --with-zip \ --with-zlib \ \ --with-mysqli=/usr/local/mysql/bin/mysql_config \ --with-mysql-sock=/usr/local/mysql/mysql.sock \ \ --with-pgsql=/usr/local/pgsql \ \ --with-oci8 \ \ --with-sqlite \ \ --with-gd \ --with-ttf \ --with-freetype \ --with-freetype-dir=/usr/X11/lib \ --with-png-dir=/usr \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --with-xpm-dir=/usr \ \ --enable-xml \ --enable-wddx \ --with-xsl \ --with-expat-dir=/usr \ --with-libxml-dir=/usr/local \ --with-xmlrpc \ --with-dom \ --with-qtdom \ \ --with-java=/usr/local/java/ \ | tee config.out System is SuSE 8.1 with gcc 3.2 -- Edit this bug report at http://bugs.php.net/?id=27642&edit=1
#27712 [NEW]: unserialize / Array access
From: hannes at phpug dot ch
Operating system: Debian GNU/Linux
PHP version: 5.0.0RC1
PHP Bug Type: Zend Engine 2 problem
Bug description: unserialize / Array access
Description:
Unserialize works perfectly and produces an array with like
array("0" => "foo"). The same serialized string gets unserialized
differently in PHP4, there it's array(0 => "foo").
I cannot access the content of the PHP5 result, because it seems that my
lookup for "1"(string) gets converted to one for 1 (int). Which fails.
Tested with:
-PHP 4.3.5RC2-dev (cli) (built: Jan 15 2004 16:58:31)
-PHP 5.0.0RC2-dev (cli) (built: Mar 21 2004 17:58:48)
I'm not sure if this is really something that needs to be fixed,
unserialize works correctly, but not as expected.
Reproduce code:
---
'hubert',
php4:
array (
0 => 'hubert',
..
print($names["1"]); // php5: doesn't work. php4: works;
print($names[1]); // php5: doesn't work php4: works;
?>
Expected result:
array (
0 => 'hubert',
1 => 'waldo',
)waldowaldo
Actual result:
--
array (
'0' => 'hubert',
'1' => 'waldo',
)
PHP Notice: Undefined index: 1 in
--
Edit bug report at http://bugs.php.net/?id=27712&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27712&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27712&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27712&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27712&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27712&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27712&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27712&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27712&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27712&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27712&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27712&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27712&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27712&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27712&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27712&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27712&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27712&r=float
#27733 [Com]: inaccurate arithmetic calculations
ID: 27733 Comment by: j at bitron dot ch Reported By: admin at rubas dot net Status: Open Bug Type: Math related Operating System: Linux 2.4.xx and 2.6.xx PHP Version: 4.3.4 New Comment: Other programming languages as for example C don't have such inaccuracies in results of that simple calculations. According to the IEEE standard for floating point arithmetic, the different programming languages must not return different results on the same machine. Previous Comments: [2004-03-27 11:12:58] admin at rubas dot net Description: Sample Code: Output: Result A: 0 Result B: -7.105427357601E-15 Reproduced with: PHP 4.3.4 PHP 4.3.3 PHP 4.3.2 Reproduce code: --- Sample Code: Expected result: Result A: 0 Result B: 0 Actual result: -- Result A: 0 Result B: -7.105427357601E-15 -- Edit this bug report at http://bugs.php.net/?id=27733&edit=1
#27800 [NEW]: gd extension fails with gd 1.2 lib
From: php at tyra dot ch Operating system: Linux PHP version: 4.3.5 PHP Bug Type: Compile Failure Bug description: gd extension fails with gd 1.2 lib Description: I installed gd v1.2 (gif support) in /usr/local I compiled php 4.3.4 without problems (working) php 4.3.5 fails to compile with the error: undefined reference to gdImageWBMP I think wbmp support is only available since gd v1.5 -- Edit bug report at http://bugs.php.net/?id=27800&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27800&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27800&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27800&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27800&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27800&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27800&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27800&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27800&r=support Expected behavior: http://bugs.php.net/fix.php?id=27800&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27800&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27800&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27800&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27800&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27800&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27800&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27800&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27800&r=float
#27844 [NEW]: $_POST and $_FILES empty when upload_max_size exceeded
From: marco at opus dot ch Operating system: Windows 2000 PHP version: 4.3.6RC1 PHP Bug Type: Unknown/Other Function Bug description: $_POST and $_FILES empty when upload_max_size exceeded Description: I've got a form which uploads a file along with other information (including and ID that identifies location in the site). When I upload a file that exceeds the size limits, I get no $_FILES and no $_POST information. That means if the user chooses a large file, they are redirected to a 'not allowed to do that here' page instead of a form error, because the ID is missing and their request can't be validated. This bug has been documented in the user comments in the documentation, but is still in the latest release: http://php.planetmirror.com/manual/en/features.file-upload.common-pitfalls.php Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=27844&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27844&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27844&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27844&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27844&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27844&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27844&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27844&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27844&r=support Expected behavior: http://bugs.php.net/fix.php?id=27844&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27844&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27844&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27844&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27844&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27844&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27844&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27844&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27844&r=float
#27712 [Bgs]: unserialize / Array access
ID: 27712
User updated by: hannes at phpug dot ch
Reported By: hannes at phpug dot ch
Status: Bogus
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2004-04-07
New Comment:
Yous see, the example string above does not come from PHP. Other tools
that interact with PHP have adopted the format. The string above can be
unserialized in PHP4 and in PHP5, the result can not be accessed using
the indices.
If you feel this is not PHP's fault, just close this bug. :)
Previous Comments:
[2004-04-07 07:49:09] [EMAIL PROTECTED]
"hubert", "1" => "waldo");
$ser = serialize ($nam);
echo $ser, "\n";
$unser = unserialize ($ser);
var_export($unser);
?>
Using that script, I can NOT get such serialized string as you did.
Note: There was some bug in this earlier but nowadays serialize() works
fine..
----
[2004-03-26 05:38:54] hannes at phpug dot ch
Description:
Unserialize works perfectly and produces an array with like
array("0" => "foo"). The same serialized string gets unserialized
differently in PHP4, there it's array(0 => "foo").
I cannot access the content of the PHP5 result, because it seems that
my lookup for "1"(string) gets converted to one for 1 (int). Which
fails.
Tested with:
-PHP 4.3.5RC2-dev (cli) (built: Jan 15 2004 16:58:31)
-PHP 5.0.0RC2-dev (cli) (built: Mar 21 2004 17:58:48)
I'm not sure if this is really something that needs to be fixed,
unserialize works correctly, but not as expected.
Reproduce code:
---
'hubert',
php4:
array (
0 => 'hubert',
..
print($names["1"]); // php5: doesn't work. php4: works;
print($names[1]); // php5: doesn't work php4: works;
?>
Expected result:
array (
0 => 'hubert',
1 => 'waldo',
)waldowaldo
Actual result:
--
array (
'0' => 'hubert',
'1' => 'waldo',
)
PHP Notice: Undefined index: 1 in
--
Edit this bug report at http://bugs.php.net/?id=27712&edit=1
#26286 [Com]: Parent: child process exited with status 3221225477 -- Restarting
ID: 26286 Comment by: hagen at xiag dot ch Reported By: igg10 at alu dot ua dot es Status: No Feedback Bug Type: Apache2 related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: The same on WindowsXP SP1, PHP 5RC1 as a module on Apache 2.0.48. Previous Comments: [2004-04-08 20:44:45] colstrom at dxlab dot com I am running into the same problem, with the following configuration: Windows XP SP1 Apache 2.0.47 PHP 4.3.4 In an attempt to correct this, I upgraded to the following: Apache 2.0.49 PHP 4.3.5 And yet the problem persists. As for scripts, I am running a very heavily hacked phpBB-v2.0.6, and dotProject-v1.0.2. I have tried the aforementioned fix of turning register_globals ON, and still the error persists. What am I doing wrong? [2004-03-23 17:01:19] MSunbeam at gmx dot net I had that same bug. Using apache 2.0.49 php5.0.0rc1 on Win2k Using SSL Listen 443 LoadFile "/server/php/ssleay32.dll" LoadModule ssl_module modules/mod_ssl.so The error eccord when user was request http://localhost:443 (he called normal server on SSL-port) error.log [Tue Mar 23 23:03:46 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Tue Mar 23 23:03:49 2004] [notice] Parent: Created child process 592 [Tue Mar 23 23:03:54 2004] [notice] Child 592: Child process is running [Tue Mar 23 23:03:54 2004] [notice] Child 592: Acquired the start mutex. [Tue Mar 23 23:03:54 2004] [notice] Child 592: Starting 250 worker threads. drwtsn32 error report Anwendungsausnahme aufgetreten: Anwendung: (pid=1080) Wann: 23.03.2004 @ 23:03:45.902 Ausnahmenummer: c005 (Zugriffsverletzung) *> Systeminformationen <* Computername: msunbeam.net Benutzername: MSun Prozessoranzahl: 1 Prozessortyp: x86 Family 6 Model 3 Stepping 3 Windows 2000-Version: 5.0 Aktuelles Build: 2195 Service Pack: None Aktueller Typ: Uniprocessor Free Firma: Besitzer: MSun *> Taskliste <* 0 Idle.exe 8 System.exe 144 smss.exe 172 csrss.exe 192 winlogon.exe 220 services.exe 232 lsass.exe 388 svchost.exe 416 SPOOLSV.exe 444 blackd.exe 460 svchost.exe 488 nvsvc32.exe 508 RapApp.exe 540 regsvc.exe 572 winmgmt.exe 768 explorer.exe 876 4DMAIN.exe 896 blackice.exe 1076 Apache.exe 1004 IEXPLORE.exe 1080 Apache.exe 2100 IEXPLORE.exe 2120 drwtsn32.exe 0 _Total.exe (0040 - 00405000) .\Apache.pdb (77F8 - 77FFF000) (6EEC - 6EEE) .\libapr.pdb (77E7 - 77F33000) (77DA - 77DFA000) (77D3 - 77D9F000) (74FA - 74FB4000) (7800 - 78046000) (74F9 - 74F98000) (74F6 - 74F73000) (77E0 - 77E65000) (77F4 - 77F7C000) (7797 - 77994000) (74FC - 74FC9000) (6EE6 - 6EE89000) .\libaprutil.pdb (6EE5 - 6EE59000) .\libapriconv.pdb (6FF0 - 6FF42000) .\libhttpd.pdb (6C92 - 6C928000) (664B - 66504000) (7758 - 777C6000) (70BD - 70C35000) (7171 - 71794000) (77A4 - 77B35000) (74F4 - 74F51000) (74F8 - 74F87000) (7CA0 - 7CA22000) (77C0 - 77C5E000) (7741 - 77488000) (7740 - 7741) (6FCF - 6FCF6000) (6FCD - 6FCD6000) (6FCC - 6FCC6000) (6FCB - 6FCB6000) (6FCA - 6FCA8000) (6FC8 - 6FC86000) (6FE2 - 6FE26000) (6FEA - 6FEA6000) (6FE9 - 6FE96000) (6FC4 - 6FC48000) (6FC3 - 6FC37000) (6FC2 - 6FC27000) (6FC1 - 6FC19000) (6FC0 - 6FC06000) (6FE5 - 6FE57000) (1000 - 10027000) (0084 - 00919000) (6FD0 - 6FD1F000) (0092 - 00C74000) (779A - 77A35000) (1F7D - 1F804000) (76B0 - 76B3F000) (1F8C - 1F8D9000) (0119 - 01199000) (013A - 013A8000) (013B - 013C) (013C - 013E7000) (7754 - 77571000) (0147 - 01477000) (0148 - 0148C000) (0149 - 01564000) (0157 - 01577000) (0158 - 0158B000) (0159 - 01665000) (0167 - 01701000) (77BD - 77BDF000) (0171 - 0172F000) (0173 - 01736000) (0174 - 018C3000) (018D - 018DA000) (018E - 0191F000) (0194 - 01949000) (0195 - 01956000) (0196 - 0198A000) (0199 - 019C2000) (019D - 019DC000) (019E - 01A23000) (01A4 - 01A53000) (01A6 - 01B4A000) (01B6 - 01B67000) (750E - 7512F000) (7513 - 75136000) (750C - 750CF000) (7794 - 7796A000) (01B8 - 01B8F000) (01B9 - 01C16000) (01C2 - 01C28000) (01C3 - 01C37000) (01C4 - 01C4B000) (777F - 7780D000) (01C5 - 01C5A000) (01C6 -
#27844 [Bgs]: $_POST and $_FILES empty when upload_max_size exceeded
ID: 27844 User updated by: marco at opus dot ch Reported By: marco at opus dot ch Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 PHP Version: 4.3.6RC1 New Comment: Yeah, it looks to be bogus ... the code I posted wasn't exactly the sample I was using. As mentioned, it wasn't just the request that was entirely empty, but also the post and files variables. I am no longer able to replicate it though ... seems to be working as advertised. Sorry to trouble you. Previous Comments: [2004-04-04 13:57:20] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The _REQEUST super-global does not include the data from $_FILES. If you print the $_FILES array you will see it contains the file entry with an error indicator. The $_POST and $_REQUEST both have the regular post fields filled in. [2004-04-02 13:32:45] marco at opus dot ch Description: I've got a form which uploads a file along with other information (including and ID that identifies location in the site). When I upload a file that exceeds the size limits, I get no $_FILES and no $_POST information. That means if the user chooses a large file, they are redirected to a 'not allowed to do that here' page instead of a form error, because the ID is missing and their request can't be validated. This bug has been documented in the user comments in the documentation, but is still in the latest release: http://php.planetmirror.com/manual/en/features.file-upload.common-pitfalls.php Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=27844&edit=1
