Req #44118 [Com]: [PATCH] MySQL: Set connection charset via php.ini option

2013-02-05 Thread shane dot bester at oracle dot com 
Edit report at https://bugs.php.net/bug.php?id=44118edit=1

 ID: 44118
 Comment by: shane dot bester at oracle dot com
 Reported by:slava_reg at nsys dot by
 Summary:[PATCH] MySQL: Set connection charset via php.ini
 option
 Status: Wont fix
 Type:   Feature/Change Request
 Package:MySQL related
 Operating System:   any
 PHP Version:5.2.5
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

I compiled my server with default charset of utf32.  Now I cannot connect at 
all, 
therefore cannot execute any SET NAMES command.  So, this needs fixing.

PHP Warning:  mysqli_connect(): (HY000/1231): Variable 'character_set_client' 
can't be set to the value of 'utf32' in X line Y


Previous Comments:

[2011-10-18 12:58:41] and...@php.net

mysqli has this. You can create a connection with mysqli_init() or just new 
mysql() and then call mysqli_options() or $link-options and set the charset to 
be used. It will be negotiated during the client-server handshake and there 
will be no additional query like SET NAMES. mysqli_options() works before 
connections is established, later it has no effect.


[2011-02-24 14:15:45] cavo at ynet dot sk

This is not about making application utf8 compatible. You can do this by set 
names query. But it may be redundant. For example: All my database is in utf8 
encoding. All my pages have content-type utf8. All form posts from clients are 
in utf8. All strings I process in application are utf8. But what do I need to 
do right after I connect to database? - set names utf8; Why? Because if I 
don't, db will re-encode all strings to latin1. And PHP don't care. If I have 
100 new connections to db per second, I need to 100 times run that query. Why 
if client and server could negotiate encoding in those 2 obliged packets? ( 
http://bugs.php.net/bug.php?id=54086 ). It's ok to set latin1 as default 
character set used by client to not affect existing applications (I believe 
mostly for those, who actualy don't know, what are they doing..). But I think 
it's very useful to have option to set encoding manualy via configuration 
option or in connect functions like: mysql_connect('localhost', 'user', 'pwd', 
true, MYSQL_CLIENT_ENCODING_UTF8);

Or am I somwhere wrong?

http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol#Client_Authentication_Packet
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_default-character-set
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_character-set-client-handshake
http://bugs.php.net/bug.php?id=54086


[2011-01-31 11:52:36] johan...@php.net

The application has to know the encoding being used, else some strange things 
might happen. We have seen the trouble in having this globally configurable 
when Gentoo decided to use Utf-8 for their MySQL installations by default 
instead of MySQL's default. I doubt you can make an application Utf-8 
comaptible by just setting such a low-level switch (it won't affect the HTTP 
Content-type header or HTML forms, thus receiving data in a wrong encoding from 
the user, not re-encode it etc.)


[2011-01-06 16:19:52] u...@php.net

Not sure if this is really needed. It can be done in user land. Its a bit of a 
convenience feature. Not many votes for it... Andrey, Johannes...?


[2008-02-14 13:00:54] slava_reg at nsys dot by

Description:

Hi,

As I'm tired of patching various user-installed php-engines to work correctly 
with newer MySQL versions (4.1.x +) that require connection character set to be 
specified, I decided to solve the problem at the php level.
So, I patched both mysql and mysqli extensions (based on an idea found 
somewhere in internet).
Result is available at:

http://bubble.nsys.by/projects/patches/php/php-5.2.5-mysql-client-charset.patch

The patch introduces two more php.ini directives:
mysql.client_charset and
mysqli.client_charset

As those directives are optional, the patch shouldn't break any existing 
functionality, but it could *really* help users who's native language is not 
latin and who want to use some php-scripted engine with mysql 'out-of-the-box'.

Best,
Vladislav Bogdanov








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=44118edit=1

Req #44118 [Com]: [PATCH] MySQL: Set connection charset via php.ini option

2013-02-05 Thread shane dot bester at oracle dot com 
Edit report at https://bugs.php.net/bug.php?id=44118edit=1

 ID: 44118
 Comment by: shane dot bester at oracle dot com
 Reported by:slava_reg at nsys dot by
 Summary:[PATCH] MySQL: Set connection charset via php.ini
 option
 Status: Wont fix
 Type:   Feature/Change Request
 Package:MySQL related
 Operating System:   any
 PHP Version:5.2.5
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

in my above case, i can connect only if i start server with 
--skip-character-set-
client-handshake option


Previous Comments:

[2013-02-06 03:09:05] shane dot bester at oracle dot com

I compiled my server with default charset of utf32.  Now I cannot connect at 
all, 
therefore cannot execute any SET NAMES command.  So, this needs fixing.

PHP Warning:  mysqli_connect(): (HY000/1231): Variable 'character_set_client' 
can't be set to the value of 'utf32' in X line Y


[2011-10-18 12:58:41] and...@php.net

mysqli has this. You can create a connection with mysqli_init() or just new 
mysql() and then call mysqli_options() or $link-options and set the charset to 
be used. It will be negotiated during the client-server handshake and there 
will be no additional query like SET NAMES. mysqli_options() works before 
connections is established, later it has no effect.


[2011-02-24 14:15:45] cavo at ynet dot sk

This is not about making application utf8 compatible. You can do this by set 
names query. But it may be redundant. For example: All my database is in utf8 
encoding. All my pages have content-type utf8. All form posts from clients are 
in utf8. All strings I process in application are utf8. But what do I need to 
do right after I connect to database? - set names utf8; Why? Because if I 
don't, db will re-encode all strings to latin1. And PHP don't care. If I have 
100 new connections to db per second, I need to 100 times run that query. Why 
if client and server could negotiate encoding in those 2 obliged packets? ( 
http://bugs.php.net/bug.php?id=54086 ). It's ok to set latin1 as default 
character set used by client to not affect existing applications (I believe 
mostly for those, who actualy don't know, what are they doing..). But I think 
it's very useful to have option to set encoding manualy via configuration 
option or in connect functions like: mysql_connect('localhost', 'user', 'pwd', 
true, MYSQL_CLIENT_ENCODING_UTF8);

Or am I somwhere wrong?

http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol#Client_Authentication_Packet
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_default-character-set
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_character-set-client-handshake
http://bugs.php.net/bug.php?id=54086


[2011-01-31 11:52:36] johan...@php.net

The application has to know the encoding being used, else some strange things 
might happen. We have seen the trouble in having this globally configurable 
when Gentoo decided to use Utf-8 for their MySQL installations by default 
instead of MySQL's default. I doubt you can make an application Utf-8 
comaptible by just setting such a low-level switch (it won't affect the HTTP 
Content-type header or HTML forms, thus receiving data in a wrong encoding from 
the user, not re-encode it etc.)


[2011-01-06 16:19:52] u...@php.net

Not sure if this is really needed. It can be done in user land. Its a bit of a 
convenience feature. Not many votes for it... Andrey, Johannes...?




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=44118


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=44118edit=1

#41552 [Fbk-Csd]: Bus Error - core dumped - Solaris - make: [test] Error 138

2007-06-01 Thread shane dot kinsch at netracorp dot com 
 ID:   41552
 User updated by:  shane dot kinsch at netracorp dot com
 Reported By:  shane dot kinsch at netracorp dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: *Compile Issues
 Operating System: Solaris 10 (SunOS 5.10)
 PHP Version:  4.4.7
 New Comment:

I downloaded the Sun Studio 11 compiler from:
http://opensolaris.org/os/community/tools/sun_studio_tools/sun_studio_11_tools/

Then recompiled PHP using these options:

arch=`isainfo -k | sed s/sparc//` \
CC=/opt/SUNWspro/bin/cc -fast -xarch=${arch} \
CXX=/opt/SUNWspro/bin/CC -fast -xarch=${arch} \
CPPFLAGS=-I/usr/local/ssl/include \
LDFLAGS=-L/usr/local/ssl/lib -R/usr/local/ssl/lib
--L/usr/local/mysql/lib -L/usr/local/etc/apache/lib \

 ./configure \
  --with-apxs2=/usr/local/etc/apache/bin/apxs \
  --enable-track-vars \
  --enable-sockets \
  --enable-wddx \
  --enable-xslt \
--with-xslt-sablot=/usr/local \
--with-expat-dir=/usr/local \
--with-iconv=/usr/local \
--with-libxml-dir=/usr/local/lib \
  --with-curl \
  --with-mysql=/mysql-client \
  --with-zlib-dir=/usr/local \
  --with-jpeg-dir=/usr/local \
  --with-png-dir=/usr/local \
  --with-freetype-dir=/usr/local \
  --with-gd \
  --with-xpm-dir=/usr/local \
  --with-openssl=/usr/local/ssl \
  --disable-debug \
  --enable-safe-mode \
  --enable-inline-optimization \
  --enable-memory-limit \
  --enable-bcmath \
  --enable-calendar

It compiled fine.  Thanks for the assistance.

Shane Kinsch


Previous Comments:


[2007-05-31 16:33:20] [EMAIL PROTECTED]

Try updating GCC to the latest available version.



[2007-05-31 16:25:28] shane dot kinsch at netracorp dot com

Description:

Running the make test for PHP 4.4.7 caused a core dump under Solaris

Using GCC 3.4.6 under Solaris 10 (SunOS 5.10) and receive the same Bus
Error / core dump on an elaborate configure or a basic configure.  In
the example below, I'm using a simple configure in order to isolate
where the issue may live, but unfortunately I'm still stumped.

Reproduce code:
---
I received a simple warning about libiconv, so I've downgraded libiconv
from 1.11 to 1.9.2 with no different results.  I've since removed 1.9.2
and re-applied libiconv 1.11.

I get the same bus error / core dump when I configure PHP with only
these options:

# make clean
# CC=gcc \
 ./configure --disable-xml --without-pear

It configures what appears to be fine:
http://my.gi.net/shane.kinsch/php-configure-log.txt

It compiles what appears to be fine as well:
http://my.gi.net/shane.kinsch/php-make-log.txt

OS and Package Versions:
SunOS web1 5.10 s10_72 sun4u sparc SUNW,UltraSPARC-IIi-cEngine

- openssl-0.9.8e- autoconf 2.60
- automake 1.10 - bison 2.3
- expat 1.95.5  - flex 2.5.33
- fontconfig 2.4.2  - freetype 2.3.1
- gcc 3.4.6 - gd 2.0.33
- jpeg 6b   - libiconv 1.9.2
- libpng 1.2.16 - libtool 1.5
- libxml2 2.6.26- libxslt 1.1.17
- m4 1.4.7  - make 3.81
- perl 5.8.8- texinfo 4.8
- xpm 3.4k  - zlib 1.2.3

Expected result:

make test to complete successfully, or even execute.

Actual result:
--
# make test
Bus Error - core dumped
make: [test] Error 138 (ignored)
core dump





-- 
Edit this bug report at http://bugs.php.net/?id=41552edit=1

#41552 [NEW]: Bus Error - core dumped - Solaris - make: [test] Error 138

2007-05-31 Thread shane dot kinsch at netracorp dot com 
From: shane dot kinsch at netracorp dot com
Operating system: Solaris 10 (SunOS 5.10)
PHP version:  4.4.7
PHP Bug Type: *Compile Issues
Bug description:  Bus Error - core dumped - Solaris - make: [test] Error 138

Description:

Running the make test for PHP 4.4.7 caused a core dump under Solaris

Using GCC 3.4.6 under Solaris 10 (SunOS 5.10) and receive the same Bus
Error / core dump on an elaborate configure or a basic configure.  In the
example below, I'm using a simple configure in order to isolate where the
issue may live, but unfortunately I'm still stumped.

Reproduce code:
---
I received a simple warning about libiconv, so I've downgraded libiconv
from 1.11 to 1.9.2 with no different results.  I've since removed 1.9.2 and
re-applied libiconv 1.11.

I get the same bus error / core dump when I configure PHP with only these
options:

# make clean
# CC=gcc \
 ./configure --disable-xml --without-pear

It configures what appears to be fine:
http://my.gi.net/shane.kinsch/php-configure-log.txt

It compiles what appears to be fine as well:
http://my.gi.net/shane.kinsch/php-make-log.txt

OS and Package Versions:
SunOS web1 5.10 s10_72 sun4u sparc SUNW,UltraSPARC-IIi-cEngine

- openssl-0.9.8e- autoconf 2.60
- automake 1.10 - bison 2.3
- expat 1.95.5  - flex 2.5.33
- fontconfig 2.4.2  - freetype 2.3.1
- gcc 3.4.6 - gd 2.0.33
- jpeg 6b   - libiconv 1.9.2
- libpng 1.2.16 - libtool 1.5
- libxml2 2.6.26- libxslt 1.1.17
- m4 1.4.7  - make 3.81
- perl 5.8.8- texinfo 4.8
- xpm 3.4k  - zlib 1.2.3

Expected result:

make test to complete successfully, or even execute.

Actual result:
--
# make test
Bus Error - core dumped
make: [test] Error 138 (ignored)
core dump

-- 
Edit bug report at http://bugs.php.net/?id=41552edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41552r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41552r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41552r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41552r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41552r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41552r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41552r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41552r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41552r=support
Expected behavior:http://bugs.php.net/fix.php?id=41552r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41552r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41552r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41552r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41552r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41552r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41552r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41552r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41552r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41552r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41552r=mysqlcfg

#40335 [Com]: Compile fails when using GCC 4.1.1/binutils 2.17

2007-02-05 Thread shane at hemc dot coop 
 ID:   40335
 Comment by:   shane at hemc dot coop
 Reported By:  earlej at hotmail dot copm
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: RHEL4
 PHP Version:  4.4.4
 New Comment:

Is there a fix for the 4.4.4 version? I cannot upgrade to v5 quite
yet...please help.


Previous Comments:


[2007-02-02 22:41:40] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2007-02-02 22:35:25] earlej at hotmail dot copm

Description:

# export CFLAGS=-m64 -fPIC
# gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1.1/configure --prefix=/usr/local/gcc411
--quiet --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit
--enable-languages=c,c++ --disable-multilib
--disable-libunwind-exceptions
Thread model: posix
gcc version 4.1.1

# ./configure (about as simple as it gets)
# make
...
ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':
my_tempnam.c:(.text+0x69): warning: the use of `tempnam' is dangerous,
better use `mkstemp'
main/output.o: In function `php_output_init_globals':
output.c:(.text+0x12): undefined reference to
`php_default_output_func'
output.c:(.text+0x23): undefined reference to
`php_default_output_func'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php] Error 1

If I try and build a DSO for Apache 1.3.37, using:

./configure \
--prefix=~/tools/php \
--with-xsl=~/tools/libxslt \ 
--with-openssl=~/tools/openssl \ 
--with-libxml-dir=~/tools/libxml2 \ 
--with-zlib=~/tools/zlib \ 
--without-xmlrpc \ 
--without-bz2 \ 
--with-mysql \ 
--without-sqlite \ 
--enable-force-cgi-redirect \ 
--enable-memory-limit \ 
--disable-pear \ 
--disable-ipv6 \
--with-pgsql=/home/jonathan/sw/build/pgclient \
--with-apxs=~/tools/apache/bin/apxs

Then I receive:

/usr/local/gcc411/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../x86
_64-unknown-linux-gnu/bin/ld: main/output.lo: relocation R_X86_64_PC32
against `php_default_output_func' can not be used when making a shared
object; recompile with -fPIC
/usr/local/gcc411/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../x86
_64-unknown-linux-gnu/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

Compile output shows main/output.c _is_built using -fPIC:

/bin/sh /home/jonathan/sw/build/php-4.4.4/libtool --silent
--preserve-dup-deps --mode=compile gcc  -Imain/
-I/home/jonathan/sw/vbuild/php-4.4.4/main/ -DPHP_ATOM_INC
-I/home/jonathan/sw/build/php-4.4.4/include
-I/home/jonathan/sw/build/php-4.4.4/main
-I/home/jonathan/sw/build/php-4.4.4
-I~/tools/openssl/include 
-I~/tools/zlib/include
-I/home/jonathan/sw/build/pgclient/
-I/home/jonathan/sw/build/php-4.4.4/ext/xml/expat
-I/home/jonathan/sw/build/php-4.4.4/TSRM
-I/home/jonathan/sw/build/php-4.4.4/Zend-m64 -fPIC   -c
/home/jonathan/sw/build/php-4.4.4/main/output.c -o
main/output.lo

Expected result:

I would expect a properly built PHP instance.

Actual result:
--
Unless I use GCC 3.4.6 (the default on this system), I cannot build
PHP.



[2007-02-02 22:32:28] earlej at hotmail dot copm

Description:

# export CFLAGS=-m64 -fPIC
# gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1.1/configure --prefix=/usr/local/gcc411
--quiet --enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++ --disable-multilib
--disable-libunwind-exceptions
Thread model: posix
gcc version 4.1.1

# ./configure (about as simple as it gets)
# make
...
ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':
my_tempnam.c:(.text+0x69): warning: the use of `tempnam' is dangerous,
better use `mkstemp'
main/output.o: In function `php_output_init_globals':
output.c:(.text+0x12): undefined reference to
`php_default_output_func'
output.c:(.text+0x23): undefined reference to
`php_default_output_func'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php] Error 1

If I try and build a DSO for Apache 1.3.37, using:

./configure \
--prefix=~/tools/php \
--with-xsl=~/tools/libxslt \ 
--with-openssl=~/tools/openssl \ 
--with-libxml-dir=~/tools/libxml2 \ 
--with-zlib=~/tools/zlib \ 
--without-xmlrpc \ 
--without-bz2 \ 
--with-mysql \ 
--without-sqlite \ 
--enable-force-cgi-redirect \ 
--enable-memory-limit \ 
--disable-pear \ 
--disable-ipv6 \
--with-pgsql=/home/jonathan/sw/build

#36177 [NEW]: The specified CGI application misbehaved by not returning a complete set of HTT

2006-01-26 Thread shane dot luffman at filton dot ac dot uk 
From: shane dot luffman at filton dot ac dot uk
Operating system: win2k3 server
PHP version:  5.1.2
PHP Bug Type: IIS related
Bug description:  The specified CGI application misbehaved by not returning a 
complete set of HTT

Description:

i installed lastest php windows installed on win2k3 server with iis6 and
works fine in command line when i run php -i from shell, however i get
this error when i try and render php file through a web browser The
specified CGI application misbehaved by not returning a complete set of
HTTP headers

i have checked

php.ini
extentions
file permiision
environment path

all seem fine and as it should be.  i also tried the php zip version and
got the same results with the same The specified CGI application
misbehaved by not returning a complete set of HTTP headers error

please can you shen some light on why it might working on command line and
not in iis6? thanks shane


-- 
Edit bug report at http://bugs.php.net/?id=36177edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=36177r=trysnapshot44
Try a CVS snapshot (PHP 5.1): 
http://bugs.php.net/fix.php?id=36177r=trysnapshot51
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=36177r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36177r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=36177r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=36177r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36177r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36177r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=36177r=support
Expected behavior:http://bugs.php.net/fix.php?id=36177r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=36177r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=36177r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36177r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=36177r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36177r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36177r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=36177r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=36177r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=36177r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36177r=mysqlcfg

#34812 [Opn]: socket_write will not write a string ending in 0 Zero

2005-10-20 Thread shane at 71software dot com 
 ID:   34812
 User updated by:  shane at 71software dot com
 Reported By:  shane at 71software dot com
 Status:   Open
 Bug Type: Sockets related
 Operating System: Windows XP
 PHP Version:  5.1.0RC1
 New Comment:

I have mostly ruled the Cisco IOS bug out because there are several
Perl scripts that issue the 'terminal length 0' command. I will sniff
the traffic though because that sounds like a great way to get some
definitive answers. Thank you. I will post once I have it.


Previous Comments:


[2005-10-19 13:36:24] franz dot hofbauer at gmail dot com

Perhaps it's a Cisco-IOS-Bug?

Have you already checked the network-traffic with a sniffer (e.g.
Ethereal), which bytes are exactly sent to the router by your
PHP-Script?



[2005-10-17 15:58:57] shane at 71software dot com

The bug is not bogus.



[2005-10-17 15:58:02] shane at 71software dot com

If I give you access to the script and a router to run the script on
will that suffice?



[2005-10-17 15:35:30] [EMAIL PROTECTED]

We can't reproduce it either.
Please reopen the report when you have a short but complete reproduce
script or just more info about it.



[2005-10-17 15:19:43] shane at 71software dot com

I am not sure that I can reproduce the intended result without a router
in 20 lines or less. What should I do?



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/34812

-- 
Edit this bug report at http://bugs.php.net/?id=34812edit=1

#34812 [Fbk-Opn]: socket_write will not write a string ending in 0 Zero

2005-10-17 Thread shane at 71software dot com 
 ID:   34812
 User updated by:  shane at 71software dot com
 Reported By:  shane at 71software dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Sockets related
 Operating System: Windows XP
 PHP Version:  5.1.0RC1
 New Comment:

I am not sure that I can reproduce the intended result without a router
in 20 lines or less. What should I do?


Previous Comments:


[2005-10-11 21:03:18] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2005-10-10 15:55:39] shane at 71software dot com

Description:

I am using sockets to log in to a Cisco router. I need to issues the
command terminal length 0. The 0 must return a FALSE or NULL status
to socket_write or maybe socket_read is what is actually returning
false I am not sure. But it will not work in Binary, ASCII, OCTAL, HEX
anything.

 

Reproduce code:
---
$IosCmdExec = 'terminal length 0' . \n;
socket_write($socket, $IosCmdExec, strlen($IosCmdExec)); 

$makeCaptureFile = 'C:\rtrconfig\config.txt';
$captureFile = fopen($makeCaptureFile,'a');
$out = '';

while ($out = socket_read($socket, 1024)){ 
ereg_replace(\r, ' ', $out);
fwrite($captureFile, $out);
}

$sep =
'***';
  
fwrite($captureFile, $sep); 

socket_shutdown($socket, 2);
socket_close($socket); 

Expected result:

I expect the writing of 'terminal length 0' to the Cisco CLI. It works
fine as long as the digit is not 0. 1-512 etc.

xx#terminal length 512
Building configuration...

Current configuration : 26921 bytes
!
! Last configuration change at 07:00:37 CDT Tue Jun 28 2005 by
amschultz
! NVRAM config last updated at 06:38:49 CDT Mon Jun 20 
!
version 12.2
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service compress-config
!
hostname xx
!
logging buffered 512000 debugging
aaa new-model
aaa authentication login default group tacacs+ local

etc..

Actual result:
--
xxx#terminal length
***

NOTE: 'xxx#' being the router prompt





-- 
Edit this bug report at http://bugs.php.net/?id=34812edit=1

#34812 [Bgs]: socket_write will not write a string ending in 0 Zero

2005-10-17 Thread shane at 71software dot com 
 ID:   34812
 User updated by:  shane at 71software dot com
 Reported By:  shane at 71software dot com
 Status:   Bogus
 Bug Type: Sockets related
 Operating System: Windows XP
 PHP Version:  5.1.0RC1
 New Comment:

If I give you access to the script and a router to run the script on
will that suffice?


Previous Comments:


[2005-10-17 15:35:30] [EMAIL PROTECTED]

We can't reproduce it either.
Please reopen the report when you have a short but complete reproduce
script or just more info about it.



[2005-10-17 15:19:43] shane at 71software dot com

I am not sure that I can reproduce the intended result without a router
in 20 lines or less. What should I do?



[2005-10-11 21:03:18] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2005-10-10 15:55:39] shane at 71software dot com

Description:

I am using sockets to log in to a Cisco router. I need to issues the
command terminal length 0. The 0 must return a FALSE or NULL status
to socket_write or maybe socket_read is what is actually returning
false I am not sure. But it will not work in Binary, ASCII, OCTAL, HEX
anything.

 

Reproduce code:
---
$IosCmdExec = 'terminal length 0' . \n;
socket_write($socket, $IosCmdExec, strlen($IosCmdExec)); 

$makeCaptureFile = 'C:\rtrconfig\config.txt';
$captureFile = fopen($makeCaptureFile,'a');
$out = '';

while ($out = socket_read($socket, 1024)){ 
ereg_replace(\r, ' ', $out);
fwrite($captureFile, $out);
}

$sep =
'***';
  
fwrite($captureFile, $sep); 

socket_shutdown($socket, 2);
socket_close($socket); 

Expected result:

I expect the writing of 'terminal length 0' to the Cisco CLI. It works
fine as long as the digit is not 0. 1-512 etc.

xx#terminal length 512
Building configuration...

Current configuration : 26921 bytes
!
! Last configuration change at 07:00:37 CDT Tue Jun 28 2005 by
amschultz
! NVRAM config last updated at 06:38:49 CDT Mon Jun 20 
!
version 12.2
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service compress-config
!
hostname xx
!
logging buffered 512000 debugging
aaa new-model
aaa authentication login default group tacacs+ local

etc..

Actual result:
--
xxx#terminal length
***

NOTE: 'xxx#' being the router prompt





-- 
Edit this bug report at http://bugs.php.net/?id=34812edit=1

#34812 [Bgs-Opn]: socket_write will not write a string ending in 0 Zero

2005-10-17 Thread shane at 71software dot com 
 ID:   34812
 User updated by:  shane at 71software dot com
 Reported By:  shane at 71software dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Sockets related
 Operating System: Windows XP
 PHP Version:  5.1.0RC1
 New Comment:

The bug is not bogus.


Previous Comments:


[2005-10-17 15:58:02] shane at 71software dot com

If I give you access to the script and a router to run the script on
will that suffice?



[2005-10-17 15:35:30] [EMAIL PROTECTED]

We can't reproduce it either.
Please reopen the report when you have a short but complete reproduce
script or just more info about it.



[2005-10-17 15:19:43] shane at 71software dot com

I am not sure that I can reproduce the intended result without a router
in 20 lines or less. What should I do?



[2005-10-11 21:03:18] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2005-10-10 15:55:39] shane at 71software dot com

Description:

I am using sockets to log in to a Cisco router. I need to issues the
command terminal length 0. The 0 must return a FALSE or NULL status
to socket_write or maybe socket_read is what is actually returning
false I am not sure. But it will not work in Binary, ASCII, OCTAL, HEX
anything.

 

Reproduce code:
---
$IosCmdExec = 'terminal length 0' . \n;
socket_write($socket, $IosCmdExec, strlen($IosCmdExec)); 

$makeCaptureFile = 'C:\rtrconfig\config.txt';
$captureFile = fopen($makeCaptureFile,'a');
$out = '';

while ($out = socket_read($socket, 1024)){ 
ereg_replace(\r, ' ', $out);
fwrite($captureFile, $out);
}

$sep =
'***';
  
fwrite($captureFile, $sep); 

socket_shutdown($socket, 2);
socket_close($socket); 

Expected result:

I expect the writing of 'terminal length 0' to the Cisco CLI. It works
fine as long as the digit is not 0. 1-512 etc.

xx#terminal length 512
Building configuration...

Current configuration : 26921 bytes
!
! Last configuration change at 07:00:37 CDT Tue Jun 28 2005 by
amschultz
! NVRAM config last updated at 06:38:49 CDT Mon Jun 20 
!
version 12.2
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service compress-config
!
hostname xx
!
logging buffered 512000 debugging
aaa new-model
aaa authentication login default group tacacs+ local

etc..

Actual result:
--
xxx#terminal length
***

NOTE: 'xxx#' being the router prompt





-- 
Edit this bug report at http://bugs.php.net/?id=34812edit=1

#34812 [NEW]: socket_write will not write a string ending in 0 Zero

2005-10-10 Thread shane at 71software dot com 
From: shane at 71software dot com
Operating system: Windows XP
PHP version:  5.1.0RC1
PHP Bug Type: Sockets related
Bug description:  socket_write will not write a string ending in 0 Zero 

Description:

I am using sockets to log in to a Cisco router. I need to issues the
command terminal length 0. The 0 must return a FALSE or NULL status to
socket_write or maybe socket_read is what is actually returning false I am
not sure. But it will not work in Binary, ASCII, OCTAL, HEX anything.

 

Reproduce code:
---
$IosCmdExec = 'terminal length 0' . \n;
socket_write($socket, $IosCmdExec, strlen($IosCmdExec)); 

$makeCaptureFile = 'C:\rtrconfig\config.txt';
$captureFile = fopen($makeCaptureFile,'a');
$out = '';

while ($out = socket_read($socket, 1024)){ 
ereg_replace(\r, ' ', $out);
fwrite($captureFile, $out);
}

$sep =
'***';
  
fwrite($captureFile, $sep); 

socket_shutdown($socket, 2);
socket_close($socket); 

Expected result:

I expect the writing of 'terminal length 0' to the Cisco CLI. It works
fine as long as the digit is not 0. 1-512 etc.

xx#terminal length 512
Building configuration...

Current configuration : 26921 bytes
!
! Last configuration change at 07:00:37 CDT Tue Jun 28 2005 by amschultz
! NVRAM config last updated at 06:38:49 CDT Mon Jun 20 
!
version 12.2
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service compress-config
!
hostname xx
!
logging buffered 512000 debugging
aaa new-model
aaa authentication login default group tacacs+ local

etc..

Actual result:
--
xxx#terminal length
***

NOTE: 'xxx#' being the router prompt

-- 
Edit bug report at http://bugs.php.net/?id=34812edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=34812r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=34812r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=34812r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34812r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34812r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=34812r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=34812r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=34812r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34812r=support
Expected behavior:   http://bugs.php.net/fix.php?id=34812r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=34812r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=34812r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34812r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=34812r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34812r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=34812r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34812r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=34812r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=34812r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=34812r=mysqlcfg

#28227 [Com]: PHP CGI depends upon non-standard SCRIPT_FILENAME

2004-05-03 Thread shane at caraveo dot com 
 ID:   28227
 Comment by:   shane at caraveo dot com
 Reported By:  lukem at NetBSD dot org
 Status:   Assigned
 Bug Type: CGI related
 Operating System: NetBSD 2.0C
 PHP Version:  4.3.6
 Assigned To:  shane
 New Comment:

The current code does not rely on script_filename, script_filename is
only used as a shortcut if it is available.  Otherwise, the init
function tries to determine the real script path, IF the fix_pathinfo
ini setting is on.  The current code was only tested under apache and
iis.

That said, the patch looks ok, and very likely improves the situation,
but needs some good testing on apache/mod_php, apache/cgi, iis/isapi
and iis/cgi, with various changes of configuration in php.ini (discard
path, fix pathinfo, etc.).  Unfortunately I have zero time.

-Shane


Previous Comments:


[2004-05-03 11:59:41] [EMAIL PROTECTED]

Shane, can you please take a look when you have a moment?



[2004-05-03 04:25:48] lukem at NetBSD dot org

Here's the patch:
 
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/www/php4/patches/patch-aa?rev=1.10content-type=text/plain



[2004-04-30 02:11:47] lukem at NetBSD dot org

Description:

I upgraded PHP from 4.2.3 to 4.3.6 and I started getting the error No
input file specified. from the php-as-cgi whilst running under a
(fairly minimal and small) web server called bozohttpd.

Further investigation reveals that
sapi/cgi/cgi_main.c::init_request_info() is using the existance of
SCRIPT_FILENAME to determine if php is running as a CGI.

However, the defacto standard for CGI/1.1:
   http://cgi-spec.golux.com/
makes no mention of SCRIPT_FILENAME, only SCRIPT_NAME.
Thus, when a web server that is used to run php as a CGI doesn't
support SCRIPT_FILENAME (which is reasonable - see the specs above),
php refuses to function and fails with the error above.

Some research into other web servers indicates that none of them
support SCRIPT_FILENAME.  These servers include:
   thttpd, mini_httpd, w3c-httpd, OmniHTTPd - (PHP PR 25833), Xitami
(PHP PR 25305)

This issue is also alluded to in the command line documentation on
your web site:
  http://www.php.net/features.commandline
(search for no input file).

In summary, PHP 4.3.6 should not be relying solely upon SCRIPT_FILENAME
to determine if it's running as a CGI.
I have a patch to fix this issue - rev 1.10 of NetBSD's
pkgsrc/www/php4/patches/patch-aa - which I can provide if necessary.

Cheers,
Luke Mewburn.








-- 
Edit this bug report at http://bugs.php.net/?id=28227edit=1

#25373 [NEW]: inconsistency in manual and src, possible nonstandard EOL character?

2003-09-02 Thread shane at sell dot com 
From: shane at sell dot com
Operating system: linux
PHP version:  4.3.3
PHP Bug Type: *Mail Related
Bug description:  inconsistency in manual and src, possible nonstandard EOL character?

Description:

From the PHP source (ext/standard/mail.c:215):

fprintf(sendmail, To: %s\n, to);
fprintf(sendmail, Subject: %s\n, subject);
if (headers != NULL) {
  fprintf(sendmail, %s\n, headers);
}
fprintf(sendmail, \n%s\n, message);

From the manual (http://us4.php.net/manual/en/function.mail.php):

Note:  You must use \r\n to separate headers, although some Unix mail
transfer agents may work with just a single newline (\n).

The source and the manual seem to differ in their treatment of newlines.

We were alerted to this problem by a customer's mail server, which is
having trouble parsing \r\n (which is the RFC standard, right?).

Expected result:

550 error on remote SMTP server


-- 
Edit bug report at http://bugs.php.net/?id=25373edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25373r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25373r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25373r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25373r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25373r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25373r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25373r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25373r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25373r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25373r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25373r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25373r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25373r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25373r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25373r=gnused

#23694 [Com]: Hidden input for session is invalid XHTML

2003-08-14 Thread shane at aptest dot com 
 ID:   23694
 Comment by:   shane at aptest dot com
 Reported By:  max at taupe dot breezeland dot com
 Status:   Wont fix
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  4.3.2RC3
 New Comment:

Just a short followup note.  As editor if the XHTML Recommendations, I
can confirm that the content models of XHTML 1.0 Strict and XHTML 1.1
both require that input elements be within a block element.  This has
nothing to do with presentation - it has to do with document content
structure and ready manipulation via the DOM.  Anyway, it would make
sense to ensure that any form content elements emitted by php are
wrapped within block elements to maintain the validity of the generated
content.


Previous Comments:


[2003-07-22 11:51:22] bruno at ubik-fr dot net

Is that so difficult, writing divinput type=//div instead of
input type=hidden / ?
Or is there any other reason why you don't want to fix it ?
Setting session.trans_sid to 0 is a way (not always possible) to solve
this problem but I just can't be sure that the user accept cookies.


Thanks.



[2003-05-19 09:29:00] max at taupe dot breezeland dot com

I'm not asking for support, I'm submiting a bug.
PHP adds an input tag, not framed by a block element.
So it's a bug.

(I know that it can be configured in php.ini, but fisrtly it isn't a
good correction (because it merge 2 types of request, GET and POST),
secondly because often we havn't any acces to php.ini, and finally, if
you think taht it can be corrected, why does the default choise is the
bug one ?)



[2003-05-19 07:14:09] [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.

Can be configured in php.ini



[2003-05-19 06:57:48] max at taupe dot breezeland dot com

When using session.use_trans_sid, a hidden input field containing the
session name and ID is placed right after the form tag. But this
makes the HTML invalid if you're using XHTML 1.1, or strict XHTML 1.0,
because it needs to be in a div or a fieldset for example.






-- 
Edit this bug report at http://bugs.php.net/?id=23694edit=1

#24711 [Bgs]: phpinfo() returns Apache/1.3.24 on 1.3.28

2003-07-19 Thread shane dot mcwhorter at designpsychology dot com 
 ID:   24711
 User updated by:  shane dot mcwhorter at designpsychology dot com
 Reported By:  shane dot mcwhorter at designpsychology dot com
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Win 2000 P SP4
 PHP Version:  4.3.2
 New Comment:

Likely a bug in php text. *Link*ing to 1.3.24
not specified in PHP info text. Possibility of future bug submissions.
phpinfo using version similarly as Apache uses version. Suggests
phpinfo change to read: linked to Apache Version to be diagnostic.


Previous Comments:


[2003-07-19 03:26:35] [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 binary version is just linked to apache 1.3.24 headers, no big
deal here.



[2003-07-18 18:38:42] shane dot mcwhorter at designpsychology dot com

Description:

phpinfo () returns 
Apache Version  Apache/1.3.24  
Apache Release  10324100  

apache -v returns
Server version: Apache/1.3.28 (Win32)
Server built:   Jul 18 2003 13:04:10

Expected result:

phpinfo () returns 
Apache Version  Apache/1.3.28






-- 
Edit this bug report at http://bugs.php.net/?id=24711edit=1

#24711 [NEW]: phpinfo() returns Apache/1.3.24 on 1.3.28

2003-07-18 Thread shane dot mcwhorter at designpsychology dot com 
From: shane dot mcwhorter at designpsychology dot com
Operating system: Win 2000 P SP4
PHP version:  4.3.2
PHP Bug Type: PHP options/info functions
Bug description:  phpinfo() returns Apache/1.3.24 on 1.3.28

Description:

phpinfo () returns 
Apache Version  Apache/1.3.24  
Apache Release  10324100  

apache -v returns
Server version: Apache/1.3.28 (Win32)
Server built:   Jul 18 2003 13:04:10

Expected result:

phpinfo () returns 
Apache Version  Apache/1.3.28


-- 
Edit bug report at http://bugs.php.net/?id=24711edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=24711r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=24711r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=24711r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=24711r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24711r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=24711r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24711r=support
Expected behavior:  http://bugs.php.net/fix.php?id=24711r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24711r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24711r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=24711r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24711r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=24711r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=24711r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24711r=gnused

#24167 [Asn-Dup]: [PATCH] FastCGI server processes dying when script not found

2003-06-29 Thread shane 
 ID:   24167
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mweilguni at sime dot com
-Status:   Assigned
+Status:   Duplicate
 Bug Type: CGI related
 Operating System: Redhat Linux 7.2
 PHP Version:  4.3.2
 Assigned To:  shane
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.

this is a dup of 24009, patch being submitted shortly


Previous Comments:


[2003-06-18 10:29:45] [EMAIL PROTECTED]

Try this patch http://bb.prohost.org/fcgi.txt and let me know if it
fixes the problem.



[2003-06-13 07:46:40] [EMAIL PROTECTED]

Shane should know? :)




[2003-06-13 03:14:07] mweilguni at sime dot com

Description:

We use PHP 4.3.2 + FastCGI + Apache/mod_fcgi. The PHP fastcgi server is
started in our setup with 8 preforked php-servers,
so after a restart the process tree will look like:
\_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2

so far it's ok. when I request for a non-existant script, I get the
error No input file specified.. That's ok too. But after that, one
server process died:
\_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2

After requesting a non-existant script 8 times all servers are gone,
only the master server process remains:
\_ /usr/bin/php-fcgi-4.3.2

I checked the file sapi/cgi/cgi_main.c and it seems the error is in
line 1473:
if (retval == FAILURE  file_handle.handle.fp == NULL) {
SG(sapi_headers).http_response_code = 404;
PUTS(No input file specified.\n);
php_request_shutdown((void *) 0);
php_module_shutdown(TSRMLS_C);
return FAILURE;
}

IMO this should be:
if (retval == FAILURE  file_handle.handle.fp == NULL) {
SG(sapi_headers).http_response_code = 404;
PUTS(No input file specified.\n);
#if PHP_FASTCGI
continue; 
#endif
php_request_shutdown((void *) 0);
php_module_shutdown(TSRMLS_C);
return FAILURE;
}

It seems to work fine, but I'm not really sure if this is right.






-- 
Edit this bug report at http://bugs.php.net/?id=24167edit=1

#24009 [Asn-Csd]: FCGX_Finish_r() isn't called if no SCRIPT_FILENAME is provided

2003-06-29 Thread shane 
 ID:   24009
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jan at kneschke dot de
-Status:   Assigned
+Status:   Closed
 Bug Type: CGI related
 Operating System: Linux
 PHP Version:  4CVS-2003-06-04 (stable)
 Assigned To:  shane
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2003-06-06 07:20:56] [EMAIL PROTECTED]

Shane, you should know this? :)




[2003-06-04 02:30:10] jan at kneschke dot de

I'm using a php with the fastcgi-SAPI for my own webserver 
lighttpd. While testing various cases I've found a bug in the 
FastCGI-SAPI in PHP: 
 
If no usefull script-filename is sent to the PHP it would send a 
default error-page with No input file specified. and status 
404. After sending this messsage the module is shutdown 
without finishing the FastCGI request. This results in a missing 
FCGI_REQUEST_END packet and is against the FastCGI 
spec. 
 
I don't know if the FCGX_Finished_r() should be called before 
or after module_shutdown(). Before actually works fine. 
 
Index: cgi_main.c 
=== 
RCS file: /repository/php4/sapi/cgi/cgi_main.c,v 
retrieving revision 1.190.2.37 
diff -u -r1.190.2.37 cgi_main.c 
--- cgi_main.c  31 May 2003 17:02:01 -  1.190.2.37 
+++ cgi_main.c  4 Jun 2003 07:19:12 - 
@@ -1487,6 +1487,9 @@ 
SG(sapi_headers).http_response_code = 404; 
PUTS(No input file specified.\n); 
php_request_shutdown((void *) 0); 
+#ifdef PHP_FASTCGI 
+   if (fastcgi) FCGX_Finish_r(request); 
+#endif 
php_module_shutdown(TSRMLS_C); 
return FAILURE; 
} 




-- 
Edit this bug report at http://bugs.php.net/?id=24009edit=1

#23664 [Asn-Csd]: FastCGI -b: !FCGX_IsCGI()

2003-06-29 Thread shane 
 ID:   23664
 Updated by:   [EMAIL PROTECTED]
 Reported By:  krip at OpenIsis dot org
-Status:   Assigned
+Status:   Closed
 Bug Type: CGI related
 Operating System: any *nix
 PHP Version:  4.3.2RC3
 Assigned To:  shane
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

now closes stdin if using socket server


Previous Comments:


[2003-05-18 09:52:26] [EMAIL PROTECTED]

Assigning to the responsible party. :)




[2003-05-17 12:04:17] krip at OpenIsis dot org

workaround: having the shell close stdin works using
PHP_FCGI_CHILDREN=3 php -b 1234 -
running from fcgi devkit's cgi-fcgi works, too



[2003-05-16 16:14:48] krip at OpenIsis dot org

hey derick, didn't you read?
just like sniper declared the initial submission #21303
of #21367 as bogus (not a php error)?

This one's a completely different topic!
The old bug is closed and was a different one:
there was no b in OPTSTRING.
This one's about file descriptors.

If you still think this should be appended to #21367,
then do you want change it's status back to open!?
Although it IS resolved?



[2003-05-16 16:04:32] [EMAIL PROTECTED]

Add your comments to the old bugreport, no need to open a new one.



[2003-05-16 15:56:16] krip at OpenIsis dot org

nice to see that
#21367  FastCGI -b option error
is closed, however, it's still not working:
the fastcgi is not detected in FCGX_IsCGI,
because FCGI_LISTENSOCK_FILENO (#defined to 0)
is no listening socket; it's just plain stdin :)

a close(0); in cgi_main.c, if (bindpath) { ...

of course fixes this.

just one question: did you test this even once
before declaring #21367 closed,
and how come it worked ?




-- 
Edit this bug report at http://bugs.php.net/?id=23664edit=1

#23908 [Asn-Bgs]: problem with PATH_INFO urls

2003-06-03 Thread shane 
 ID:   23908
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pagameba at magma dot ca
-Status:   Assigned
+Status:   Bogus
 Bug Type: CGI related
 Operating System: winxp
 PHP Version:  4.3.2
 Assigned To:  shane
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

cgi.fix_pathinfo=1 in php.ini fixes this.  4.3.2 was changed to default
to cgi.fix_pathinfo=0 as that fixes BC for the majority of apps that
were written prior.


Previous Comments:


[2003-06-02 13:16:55] [EMAIL PROTECTED]

Does not work, seems like some late bugfix broke this then..





[2003-06-02 12:28:39] pagameba at magma dot ca

create a script called pathinfo.php at your web root with the following
contents:

? echo $_SERVER[PATH_INFO]; ?

and open this with

http://localhost/pathinfo.php/my/path

in PHP 4.3.2 RC1 (up to RC4 I think) this would result in a page
containing:

my/path

with the release version of PHP 4.3.2, this returns:

No input file specified.

winxp, apache 1.3.26.  No changes to httpd.conf or php.ini between the
RC and final.

I noticed also on the main php website,

http://www.php.net/in_array

this should search the documentation for in_array and redirect to the
in_array page, but it returns an error.  I think this is caused by the
same error.



[2003-06-01 20:40:38] [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-05-30 14:16:57] pagameba at magma dot ca

Not sure of the classification of this one, or even the summary at this
point.  Pres2 uses PATH_INFO to calculate what presentation/slide to
show with a URL something like:

http://myserver/pres2/show.php/mypresentation/1

This worked with PHP 4.3.2 RC1 but I just installed PHP 4.3.2 final and
now I get No input file specified..

I've hacked pres2 to use query strings instead, which works fine.  Is
this a configuration issue?  I changed nothing in my php.ini between
rc1 and the final version.

Oh, and register_globals in On because pres2 needs it.




-- 
Edit this bug report at http://bugs.php.net/?id=23908edit=1

#23902 [Asn]: header(HTTP/1.0 401 Authorization Required); failed

2003-06-03 Thread shane 
 ID:   23902
 Updated by:   [EMAIL PROTECTED]
 Reported By:  noxter at web dot de
 Status:   Assigned
 Bug Type: CGI related
 Operating System: Windows 2000
 PHP Version:  4.3.2
 Assigned To:  shane
 New Comment:

Yeah, I started on a fix for it yesterday and will look at it again
tonight.  Not sure who wrote the header stuff, but not checking for
NULL is the problem here.


Previous Comments:


[2003-06-02 12:42:46] [EMAIL PROTECTED]

This works:

?php
 
header(WWW-Authenticate: Basic realm=\example\);
header(HTTP/1.0 401 Authorization Required);  

?

For Shane:
Seems that when line sapi/cgi/cgi_main.c:307 is reached,
the SG(sapi_headers).http_status_line is reset to NULL in line
main/SAPI.c:591 (matters only when cgi.rfc2616_headers = 1).

Not sure if this is bug in SAPI.c (or not even a bug) but
CGI SAPI should handle this a bit better, at least by not setting that
(null)\r\n header line.




[2003-06-02 11:43:14] noxter at web dot de

No difference. HTTP/1.0 or 1.1, the result is alike.



[2003-06-01 21:01:55] [EMAIL PROTECTED]

What if you sent it as HTTP/1.1:

header(HTTP/1.1 401 Authorization Required);

Does it make any difference?




[2003-05-30 12:16:33] noxter at web dot de

The follow example failed by php as common gateway interface
application. This problem is common and not specified of a server.
Testing with apache, iis, devwex ... .  The option cgi.rfc2616_headers
= 1 is setting in the php.ini.

?
header(HTTP/1.0 401 Authorization Required);
header(WWW-Authenticate: Basic realm=\example\);
?

the response of Server :

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Fri, 30 May 2003 17:04:01 GMT
(null)
Content-type: text/html
X-Powered-By: PHP/4.3.2
WWW-Authenticate: Basic realm=example

the respone of CGI:

(null)
Content-type: text/html
X-Powered-By: PHP/4.3.2
WWW-Authenticate: Basic realm=example
...

the respone correct is:

HTTP/1.0 401 Authorization Required
Content-type: text/html
X-Powered-By: PHP/4.3.2
WWW-Authenticate: Basic realm=example
...






-- 
Edit this bug report at http://bugs.php.net/?id=23902edit=1

#23902 [Asn]: header(HTTP/1.0 401 Authorization Required); failed

2003-06-03 Thread shane 
 ID:   23902
 Updated by:   [EMAIL PROTECTED]
 Reported By:  noxter at web dot de
 Status:   Assigned
 Bug Type: CGI related
 Operating System: Windows 2000
 PHP Version:  4.3.2
-Assigned To:  shane
+Assigned To:  edink
 New Comment:

Since my testing appears to show that rfc2616_headers *DOES NOT* work
with IIS/5.0, I'm reasigning this to the author of that code.  However,
the patch below 'fixes' the (null) problem, and properly allows full
status lines to be used with the authenticate header.  This bug is
related to bug 19207.

With rfc2616_headers=1 on IIS/5.0, the following occurs (IIS/5.0 likes
rfc2616_headers=0, oposite of comments in php.ini):

C:\usr\src\php43wget -S http://localhost/auth.php43d
--23:54:42--  http://localhost/auth.php43d
   = `auth.php43d.4'
Resolving localhost... done.
Connecting to localhost[127.0.0.1]:80... connected.
HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Server: Microsoft-IIS/5.0
 3 Date: Tue, 03 Jun 2003 06:54:42 GMT
 4 HTTP/1.0 401 Authorization Required
 5 Content-type: text/html
 6 X-Powered-By: PHP/4.3.3-dev
 7 WWW-Authenticate: Basic realm=example

[ = ] 4  3.91K/s



Index: main/SAPI.c
===
RCS file: /repository/php4/main/SAPI.c,v
retrieving revision 1.155.2.9
diff -u -d -u -r1.155.2.9 SAPI.c
--- main/SAPI.c 11 Feb 2003 23:30:13 -  1.155.2.9
+++ main/SAPI.c 3 Jun 2003 06:48:47 -
@@ -456,6 +456,12 @@
 
 static void sapi_update_response_code(int ncode TSRMLS_DC)
 {
+   /* if the status code did not change, we do not want
+  to change the status line, and no need to change the code */
+   if (SG(sapi_headers).http_response_code == ncode) {
+   return;
+   }
+
if (SG(sapi_headers).http_status_line) {
efree(SG(sapi_headers).http_status_line);
SG(sapi_headers).http_status_line = NULL;
Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php4/sapi/cgi/cgi_main.c,v
retrieving revision 1.190.2.37
diff -u -d -u -r1.190.2.37 cgi_main.c
--- sapi/cgi/cgi_main.c 31 May 2003 17:02:01 -  1.190.2.37
+++ sapi/cgi/cgi_main.c 3 Jun 2003 06:48:47 -
@@ -303,7 +303,7 @@
if (SG(sapi_headers).http_response_code != 200) {
int len;

-   if (rfc2616_headers) {
+   if (rfc2616_headers  SG(sapi_headers).http_status_line) {
len = snprintf(buf, SAPI_CGI_MAX_HEADER_LENGTH, 
   %s\r\n, 
SG(sapi_headers).http_status_line);
 



Previous Comments:


[2003-06-02 14:12:40] [EMAIL PROTECTED]

Yeah, I started on a fix for it yesterday and will look at it again
tonight.  Not sure who wrote the header stuff, but not checking for
NULL is the problem here.



[2003-06-02 12:42:46] [EMAIL PROTECTED]

This works:

?php
 
header(WWW-Authenticate: Basic realm=\example\);
header(HTTP/1.0 401 Authorization Required);  

?

For Shane:
Seems that when line sapi/cgi/cgi_main.c:307 is reached,
the SG(sapi_headers).http_status_line is reset to NULL in line
main/SAPI.c:591 (matters only when cgi.rfc2616_headers = 1).

Not sure if this is bug in SAPI.c (or not even a bug) but
CGI SAPI should handle this a bit better, at least by not setting that
(null)\r\n header line.




[2003-06-02 11:43:14] noxter at web dot de

No difference. HTTP/1.0 or 1.1, the result is alike.



[2003-06-01 21:01:55] [EMAIL PROTECTED]

What if you sent it as HTTP/1.1:

header(HTTP/1.1 401 Authorization Required);

Does it make any difference?




[2003-05-30 12:16:33] noxter at web dot de

The follow example failed by php as common gateway interface
application. This problem is common and not specified of a server.
Testing with apache, iis, devwex ... .  The option cgi.rfc2616_headers
= 1 is setting in the php.ini.

?
header(HTTP/1.0 401 Authorization Required);
header(WWW-Authenticate: Basic realm=\example\);
?

the response of Server :

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Fri, 30 May 2003 17:04:01 GMT
(null)
Content-type: text/html
X-Powered-By: PHP/4.3.2
WWW-Authenticate: Basic realm=example

the respone of CGI:

(null)
Content-type: text/html
X-Powered-By: PHP/4.3.2
WWW-Authenticate: Basic realm=example
...

the respone correct is:

HTTP/1.0 401 Authorization Required
Content-type: text/html
X-Powered-By: PHP/4.3.2

#23893 [Opn-Fbk]: setcookie fails if $_GET value is empty

2003-06-03 Thread shane 
 ID:   23893
 Updated by:   [EMAIL PROTECTED]
 Reported By:  info at splendense dot nl
-Status:   Open
+Status:   Feedback
 Bug Type: CGI related
 Operating System: sunOS
 PHP Version:  4.3.2
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to Open.

Thank you for your interest in PHP.


unable to repro on apache/cgi/win32 with 4.2.3, 4.3.2 or CVS.

Perhaps you should consider (warnings were breaking setting the cookie
for me):

?php

if (isset($_GET[something]))
$something = $_GET[something];

$value = this is a value;
if (!setcookie (TestCookie, $value)) {
print (cookie NOT set!);
} else {
print (cookie set!);
}

?

Otherwise, you need to provide more details on configuration of your
system.




Previous Comments:


[2003-05-30 05:05:27] info at splendense dot nl

I'm running php as CGI API and register globals and i'm trying the
following script:

?php

$something = $_GET[something];

$value = this is a value;
if (!setcookie (TestCookie, $value)) {
print (cookie NOT set!);
} else {
print (cookie set!);
}

?

with the following outputs:

1. www.server.com/script.php?something=
outputs: 'cookie set!'

2. www.server.com/script.php
outputs: 'cookie NOT set!'

3. www.server.com/script.php?somehting=value
outputs: 'cookie set!'

4. www.server.com/script.php?something_else=
outputs: 'cookie NOT set!'

so if I try to read a variable (can be GET/COOKIE/POST/...) and it is
not explicitly specified, even if it's empty, cookies can't be set
anymore.

I think it has to do with being a CGI API, because on another server
where it's installed as apache API I don't have this problem.

can anyone verify this?




-- 
Edit this bug report at http://bugs.php.net/?id=23893edit=1

#18371 [Opn-Fbk]: --enable-discard-path breaks php-cgi

2003-06-03 Thread shane 
 ID:   18371
 Updated by:   [EMAIL PROTECTED]
 Reported By:  janus at area319 dot de
-Status:   Open
+Status:   Feedback
 Bug Type: CGI related
 Operating System: ALL
 PHP Version:  4.3.2
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to Open.

Thank you for your interest in PHP.


I do beleive you should not have any configuration for PHP in
httpd.conf when you use --enable-discard-path?  See
http://www.php.net/manual/en/security.cgi-bin.php Case 4.  If properly
configured in this situation, you should not see the self parsing bug. 
If --enable-discard-path is not what you really want, use
--enable-force-cgi-redirect with the configuration you provided a long
time ago.


Previous Comments:


[2003-06-01 16:28:20] janus at area319 dot de

Wow! Incredible, it's back again.
Powered by 4.3.2-RELEASE this time.



[2002-12-03 01:09:41] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

don't use discard path.

but really, fixed in cvs.



[2002-11-29 10:06:07] janus at area319 dot de

But the problem also exists with apache1...



[2002-11-15 01:28:05] [EMAIL PROTECTED]

Nobody here runs Apache2.  Feel free to pitch in and provide a patch.



[2002-11-15 01:26:00] janus at area319 dot de

Wow... incredible... now i'm getting the same error with SSL too.
That's really boring! The people need a safe way to run php... but
there isn't any up-to-date solution that really works (especially
apache2/cgi). It's hard to believe that php will run at any ISP, when
there are so great problems with it.
Apache2 is much better in managing resources and has more speed... so
it will be the next step in webhosting-environments, please fix it
soon.



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/18371

-- 
Edit this bug report at http://bugs.php.net/?id=18371edit=1

#22292 [Opn-Dup]: PHP.EXE never ends

2003-02-23 Thread shane 
 ID:   22292
 Updated by:   [EMAIL PROTECTED]
 Reported By:  francois dot kaufmann at swisscom dot com
-Status:   Open
+Status:   Duplicate
 Bug Type: CGI related
 Operating System: WIN NT 4 SP6
 PHP Version:  4.3.1
 New Comment:

Ok, this is a duplicate of bug 22291, the bug is in iisfunc.dll.  I'm
closing this bug, refer to 22291 for this issue.


Previous Comments:


[2003-02-21 02:06:43] francois dot kaufmann at swisscom dot com

Hi,

Since we could'nt come back on the first server, we use it, I did the
test on another server wich has 'little' different config (Win2000 SP2,
IIS 5) and there is the same symptom.
So I comment iisfunc.dll out and Yes, it works! PHP.EXE stops after
serving the page

kaf



[2003-02-19 12:59:09] [EMAIL PROTECTED]

kaf,
Are you using the iisfunc.dll extension?  If so, please comment it out,
and see if you still have the problem with php not ending.  If not, let
us know. 




[2003-02-19 07:15:07] francois dot kaufmann at swisscom dot com

Excusez-moi!

I'm sorry, I rode the reply below wich says it is not a bug!
But the fellow tryied it with 4.2.3 and we are talking from 4.3.1

It's open again
kaf



[2003-02-19 07:10:51] v dot robert at ouestfrance-multimedia dot com

Why have you closed the subject ? The bug is still here. We can't use
the command line and the CGI !!

We need some explanations !



[2003-02-19 06:52:55] cg at gordimer dot net

IMHO this should not be closed as the bug still exists (verified here
too with IIS4/NT4).

Christoph



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/22292

-- 
Edit this bug report at http://bugs.php.net/?id=22292edit=1

#22292 [Opn]: PHP.EXE never ends

2003-02-19 Thread shane 
 ID:   22292
 Updated by:   [EMAIL PROTECTED]
 Reported By:  francois dot kaufmann at swisscom dot com
 Status:   Open
 Bug Type: CGI related
 Operating System: WIN NT 4 SP6
 PHP Version:  4.3.1
 New Comment:

kaf,
Are you using the iisfunc.dll extension?  If so, please comment it out,
and see if you still have the problem with php not ending.  If not, let
us know. 



Previous Comments:


[2003-02-19 07:15:07] francois dot kaufmann at swisscom dot com

Excusez-moi!

I'm sorry, I rode the reply below wich says it is not a bug!
But the fellow tryied it with 4.2.3 and we are talking from 4.3.1

It's open again
kaf



[2003-02-19 07:10:51] v dot robert at ouestfrance-multimedia dot com

Why have you closed the subject ? The bug is still here. We can't use
the command line and the CGI !!

We need some explanations !



[2003-02-19 06:52:55] cg at gordimer dot net

IMHO this should not be closed as the bug still exists (verified here
too with IIS4/NT4).

Christoph



[2003-02-19 04:56:46] francois dot kaufmann at swisscom dot com

I had the exactly same sympton as described below while starting the
script on command line (Dr. Watson)

Now as suggested I change the config to use ISAPI inteed of CGI and it
works :-)

The only concern is that IASPI is not yet considered as to be
production quality!

Anyway, thanks the the help
kaf



[2003-02-19 04:54:04] v dot robert at ouestfrance-multimedia dot com

When using command line, if extension=php_iisfunc.dll is on, i've an
error, but when it's off (in comment), i've NO error.



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/22292

-- 
Edit this bug report at http://bugs.php.net/?id=22292edit=1

#22291 [Opn]: iisfunc extension crashes on shutdown

2003-02-19 Thread shane 
 ID:   22291
 Updated by:   [EMAIL PROTECTED]
-Summary:  CGI do not function !
 Reported By:  v dot robert at ouestfrance-multimedia dot com
 Status:   Open
 Bug Type: CGI related
 Operating System: NT4 SP6a  XP Pro SP1
 PHP Version:  4.3.1
-Assigned To:  
+Assigned To:  [EMAIL PROTECTED]
 New Comment:

Lets make this bug clear, it's not a CGI problem, it's a iisfunc
problem on shutdown.  The problem does not occure with ISAPI because it
does not shutdown on every request like CGI.  I have reproduced it with
4.3.1.  Assigning this to Frank, author of iisfunc.

It is not clear if #22292 is in fact a dup of this bug, until we find
out if kaf is using iisfunc or not.




Previous Comments:


[2003-02-19 07:15:04] v dot robert at ouestfrance-multimedia dot com

the second subject is closed !! ??? Why ???

I can't use the command line and CGI ! 

Help, please !



[2003-02-19 04:31:42] [EMAIL PROTECTED]

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.


Fine, add comments to the other report.




[2003-02-19 04:30:39] v dot robert at ouestfrance-multimedia dot com

It's a bug !!!

I'm not the only one,

please look at : http://bugs.php.net/bug.php?id=22292thanks=6



[2003-02-19 03:47:20] [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.


Ask support questions elsewhere.




[2003-02-19 03:45:44] v dot robert at ouestfrance-multimedia dot com

My config for extensions is:
extension=php_iisfunc.dll
extension=php_mssql.dll
extension=php_sockets.dll

others are off.

When I put in comment extension=php_iisfunc.dll, all work fine in CGI.

NB: We use php in order to use phpbb forum.



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/22291

-- 
Edit this bug report at http://bugs.php.net/?id=22291edit=1

#22270 [Asn]: cgi binary parses itself when called directly

2003-02-18 Thread shane 
 ID:   22270
 Updated by:   [EMAIL PROTECTED]
 Reported By:  zlo at canada dot com
 Status:   Assigned
 Bug Type: Apache related
 Operating System: RedHat 7.2
 PHP Version:  4CVS-2003-02-18 (stable)
 Assigned To:  shane
 New Comment:

This has happened for some time, it's a big part of what prompted my
starting on rewriting cgi stuff.  It shouldn't happen with 4.3 if
cgi.fix_pathinfo=1, or if you don't compile with discard-path.


Previous Comments:


[2003-02-18 07:29:10] zlo at canada dot com

when PHP cgi binary is called from cgi-bin without cgi-redirect, it
parses itself (argv[0] of the binary, whatever that happens to be)! i
don't think it represents much of a security problem (it still does to
some extent, because it reveals path to php and default settings), and
no sane person will run the cgi binary without cgi-redirect, but i
don't think its the way its supposed to be either..

here is a simple example; this also works with the php binary itself in
place of this binary. 
this results in some binary output and the typical phpinfo() page in
the middle:
# cat php.c

#include stdio.h
#include string.h
#include stdlib.h

const char *PHP_BINARY=/path/to/php/bin/php;
const char * dummy=?php phpinfo(); ?;

int main(int argc, char *argv[]){
  execl(PHP_BINARY,argv[0],0);
  return 1;
};

p.s. btw this simple wrapper (without the phpinfo() part, or course)
can be used as a workaround for the vulnerability with cgi-redirect
that resulted in the release of 4.3.1 since it removes parameters
before exec'ing php itself..

p.p.s. where can i post feedback? i can't seem to find it..




-- 
Edit this bug report at http://bugs.php.net/?id=22270edit=1

#22233 [Ver]: mod_gzip_on yes makes force-cgi-redirect disabled and incorrect PHP_SELF

2003-02-16 Thread shane 
 ID:   22233
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: Apache related
 Operating System: RedHat 7.1, 7.2
 PHP Version:  4.3.1-dev
 New Comment:

reproducable with 4.2.3 and 4.0.6 on windows.


Previous Comments:


[2003-02-15 18:52:59] [EMAIL PROTECTED]

Reproduced with PHP 4.3.1-dev..




[2003-02-15 18:18:36] [EMAIL PROTECTED]

tried that, apparently it's not fixed.
just compiled php4-STABLE-200302152230, problem is still there.
when i turn on mod_gzip, its works like magic!



[2003-02-15 17:23:37] [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


This should be fixed already.




[2003-02-15 13:06:48] [EMAIL PROTECTED]

when mod_gzip_on yes, PHP's force-cgi-redirect security mechanizm
becomes disabled (urls like /cgi-bin/php/test.php start working) and
PHP_SELF takes on a wrong value (/cgi-bin/php/test.php).
when mod_gzip_on no, both aspects of the problem disappear.
problem has been observed on 2 different systems.
apache version: 1.3.26, 1.3.27
php version: latest snapshot
mod_gzip version: latest
php.ini does not exist.
php's configure:
./configure \
--with-config-file-path=/path/to/php \
--prefix=/path/to/php \
--enable-force-cgi-redirect \
--disable-cli \
--enable-bcmath \
--enable-trans-sid \
--with-zlib-dir=/build/zlib-1.1.4 \
--with-gd=/build/gd-1.8.4 \
--with-png-dir=/build/png-1.2.4 \
--with-jpeg-dir=/build/jpeg-6b \
--with-freetype \

apache's configure:
./configure \
--prefix=/path/to/apache \
--enable-module=so \
--enable-suexec \
--suexec-caller=www \
--suexec-docroot=/www \
no other modules loaded other than mod_gzip.
i thought this could well be PHP's problem. sorry if i'm wrong, then
please direct me to other possible sources of the problem.




-- 
Edit this bug report at http://bugs.php.net/?id=22233edit=1

#21261 [Opn-Csd]: $_SERVER['PHP_SELF'] gives wrong info

2003-01-25 Thread shane 
 ID:   21261
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: linux 2.4.18 - slack 8.1
 PHP Version:  4.3.0
 Assigned To:  shane
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

This is now fixed in cvs:
4.3: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.190.2.12
5.0: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.208


Previous Comments:


[2003-01-17 06:36:29] [EMAIL PROTECTED]

Sorry, my PHP-Based Workaround seems to be buggy in some cases, too...
Here is a quick  dirty bugfix for the quick  dirty workaround :-)

Btw, it would be nice if the bug is fixed in PHP 4.3.1...

-snip
// Small Workaround for a bug in PHP 4.3.0/cgi
// See http://bugs.php.net/bug.php?id=21261 for details

$_SERVER['SCRIPT_NAME'] = substr($_SERVER['PATH_TRANSLATED'],
 strlen($_SERVER['DOCUMENT_ROOT']));
if (substr($_SERVER['SCRIPT_NAME'], 0, 2) == '//') {
$_SERVER['SCRIPT_NAME'] = substr($_SERVER['SCRIPT_NAME'], 1);
}

$PHP_SELF =
$SCRIPT_NAME =
$_SERVER['PHP_SELF'] =
$_SERVER['SCRIPT_NAME'];
-snip



[2003-01-13 11:41:12] [EMAIL PROTECTED]

That (or similar) urgent problem occurs here too. PHP versions before
mid december were not affected IMO.

At first today I've checked out the php4 and php5 modules from CVS,
configured, and build them. After installation of the CGI binaries I
detected a problem with $_SERVER['PHP_SELF']:

a) the PHP4 version shows no value
b) the PHP5 version shows illegal characters, cut off strings with low
ASCII values etc. Depending on the namebased vhost name the value of
PHP_SELF looks like ind## instead of index.php (# should
represent low ASCII chars, which are shown as boxes here) of just 5
which is definitely the last char of index.php5. Short: looks like a
pointer on a string array is bent somewhere.

The problem insist with and without '--enable-force-cgi-redirect' in
both versions. As an example you may want to take a look at

  http://daniel-gorski.de/index.php4  (PHP4 CGI)
  http://daniel-gorski.de/index.php5  (PHP5 CGI)

and compare the values of $_SERVER['PHP_SELF']. Additionally the PHP5
version has a strange Zend Extension date: 90021012. OTOH this value
seems to be correct in the PHP4 version.

The operating system is Linux (RedHat 6.2).

I would appreciate to see this bug solved as soon as possible, because
this is a dramatic show stopper for a few ZE2 applications I am
developing  running.

What required information can I provide to help to solve this problem?

regards dtg



[2003-01-09 14:57:05] [EMAIL PROTECTED]

Quick  Dirty PHP-Based workaround:

Put this code in a file and add it to auto_prepend_file-directive in
php.ini:
-snip
// Small Workaround for a bug in PHP 4.3.0/cgi
// See http://bugs.php.net/bug.php?id=21261 for details

$_SERVER['SCRIPT_NAME'] = substr($_SERVER['PATH_TRANSLATED'],
 strlen($_SERVER['DOCUMENT_ROOT']));

$PHP_SELF =
$SCRIPT_NAME =
$_SERVER['PHP_SELF'] =
$_SERVER['SCRIPT_NAME'];
-snip

Works fine for me... If PHP is used as CLI it may be neccessary to
check current mode before running this code.



[2003-01-07 13:30:23] [EMAIL PROTECTED]

There is no space in SCRIPT_NAME on my localhost, this was an
copypaste-error. But the I at the end exists.



[2003-01-07 13:27:55] [EMAIL PROTECTED]

Same for me, your patch seems to have no affect.

I checked the debugging output from cgiwrap which says:
[...]
Fixing Environment Variables.

Environment Variables:
 QUERY_STRING: ''
  SCRIPT_NAME: '/phpinfo.php'
  SCRIPT_FILENAME: 'DOCUMENT_ROOT/phpinfo.php'
 REDIRECT_URL: 'NULL'
PATH_INFO: '/phpinfo.php'
  PATH_TRANSLATED: 'DOCUMENT_ROOT/phpinfo.php'
  REMOTE_USER: 'NULL'
  REMOTE_HOST: 'NULL'
  REMOTE_ADDR: '217.4.137.70'
[...]

Seems to be ok?! But PHP_SELF

#21367 [Asn-Csd]: FastCGI -b option error

2003-01-25 Thread shane 
 ID:   21367
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: Other web server
 Operating System: WinXP
 PHP Version:  4.3.0
 Assigned To:  shane
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

This is now fixed in cvs:
4.3: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.190.2.12
5.0: http://cvs.php.net/co.php/php4/s


Previous Comments:


[2003-01-13 20:44:17] [EMAIL PROTECTED]

My php -v and php -h are exactly equal as the above one.

I don't have any of those envvars set and it still doesn't work.



[2003-01-13 17:51:18] [EMAIL PROTECTED]

-b is ONLY available was what I wanted to say. :)
Anyway, if you have any of these set in your environment:

SERVER_SOFTWARE
SERVER_NAME
GATEWAY_INTERFACE
REQUEST_METHOD

then it won't be available.





[2003-01-13 17:47:08] [EMAIL PROTECTED]

Verified:

C:\php4php -v
PHP 4.3.0 (cgi-fcgi), Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies

C:\php4php -h
[snip]
  -b address:port|port Bind Path for external FASTCGI Server mode
[snip]

C:\php4php -b 127.0.0.1:12345
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b



[2003-01-13 17:41:33] [EMAIL PROTECTED]

-b is not available for fastcgi binary..iirc, the binary
provided in the release package is compiled with the fastcgi support
turned on. You can check that with 'php -v'



[2003-01-02 19:54:26] [EMAIL PROTECTED]

I've downloaded the full Win32 PHP binary and the -b argument that
should Bind Path for external FASTCGI server mode doesn't work.

What happens is:
c:\phpphp -b 5000
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b
Error in argument 1, char 2: option not found b

I read on php.dev newsgroup that this is the right way to start FastCGI
support since SAPI/FastCGI was discontinued.
But it doesn't work.




-- 
Edit this bug report at http://bugs.php.net/?id=21367edit=1

#21675 [Opn-Fbk]: Relative includes and Apache Alias problem

2003-01-25 Thread shane 
 ID:   21675
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Apache related
 Operating System: BSDI 4.1
 PHP Version:  4.3.0
 New Comment:

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

Try the following patched file and see if your problem is fixed

http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.190.2.12



Previous Comments:


[2003-01-15 22:37:23] [EMAIL PROTECTED]

Here's a post that pretty much sums-up the problem.

http://groups.google.com.au/groups?q=php+4.3.0+%22failed+to+create+stream%22hl=enlr=ie=UTF-8oe=UTF-8selm=501021782.1042219035023.JavaMail.luser%40dubb11h05-0.dplanet.chrnum=10


This is not my post, but it is exactly the same issue we are having.
Here's my PHP entries in httpd.conf:

AddType application/x-httpd-php4 .php .php4
AddType application/x-httpd-php4-source .phps .php4s
AddHandler php4-script .phtml .p4html

Action application/x-httpd-php4 /cgi-bin/php4
Action application/x-httpd-php4-source /cgi-bin/php4
Action php4-script /cgi-bin/php4

Please note we were previously using 4.1.2 and
did not have this problem.

I appologize if my report is not extremly detailed.
if you need more info, please let me know.

Thank you,
Chris





-- 
Edit this bug report at http://bugs.php.net/?id=21675edit=1

#14409 [Opn-Csd]: request for nonexistent file does not return 404 error

2003-01-25 Thread shane 
 ID:   14409
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Apache related
 Operating System: IRIX64 vega 6.5 04191225 IP27
 PHP Version:  4.2.2
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

This is fixed for CGI in both the 4.3 tree and HEAD.

4.3: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.190.2.12
5.0: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.208




Previous Comments:


[2003-01-21 15:31:33] [EMAIL PROTECTED]

I've duplicated this on Linux/Apache w/ PHP 4.3.0 running PHP via CGI.
Documents that don't return No input file specified. and the apache
logs show a 200 (succesful page retrieval). Nothing is sent to the
error log.

The problem is that there's no way to track or log bad page requests.
This is very very bad.



[2002-10-22 02:05:57] [EMAIL PROTECTED]

Small addendum.  PHP does exit 255 if its target does not exist, but
since it has already sent a complete CGI/1.1 HTTP header back to Apache
(Content-type: text/html\n\n), including the blank line that
indicates end of headers,
Apache has already parsed and sent a complete 200 OK set
of HTTP headers back to the client.  No, this is not an
Apache bug.

Running PHP 4.2.2 as a CGI via an Action directive under Apache 1.3.23
(RedHat patched).  From httpd.conf:

## PHP run as a CGI without everyone needing ExecCGI privs
AddType application/x-httpd-php .php .php4 .php3 .phtml
AddHandler php-script .php .php4 .php3 .phtml
Action php-script /lcgi/php



[2002-10-21 20:40:02] [EMAIL PROTECTED]

By default, the PHP executable runs in CGI mode and produces
an HTTP header Content-type: text/html

Since PHP runs in CGI mode, it should follow the CGI/1.1 specification,
which has not changed in so long that it might even pre-date PHP!  I
refer you to:
  http://hoohoo.ncsa.uiuc.edu/cgi/out.html

If PHP is going to leave something like the following in my Apache
error log:
  PHP Fatal error:  Unable to open /pub/a/b/acb.com/index3.html in
Unknown on line 0
when it is unable to find a target file, then I would expect it to
either return an error page 404 Not Found, or exit non-zero, at which
point Apache will return 500 Server Error.  Under NO circumstance
should a PHP Fatal error return a 200 OK to the client, which is
implicitly done by Apache as per the CGI/1.1 spec when Apache receives
pieces of a valid HTTP header without Status: xxx specified.

Incorrect PHP behavior confirmed on PHP 4.2.2 on Linux 2.4.18, RedHat
7.2.  PHP custom compiled with:
 './configure' '--prefix=/usr/local/php' '--enable-memory-limit'
'--enable-force-cgi-redirect' '--enable-safe-mode' '--disable-rpath'
'--with-mysql' '--with-db3'

-Glenn



[2002-09-23 14:59:17] [EMAIL PROTECTED]

Re-opening bug report.



[2002-09-23 13:46:12] [EMAIL PROTECTED]

Dear Kalowsky,

I've just reproduced it on php4-20020920 on Apache.
It said php-4.3.0 in phpinfo(), and it is more recent than 
your post.

You should understand that it is Apache-related bug, so IIS 
testing does not apply here, and it is stated in original 
bug report.
Probably you also used php module in your testing on 
FreeBSD, while original bug report says that PHP was 
installed as CGI.

The trouble looks to me as follows: if php CGI meets 
nonexistent php file, it does not output anything, 
while it should output error page, and I would really 
appreciate if I'd be able to tune that page via php.ini 
or whatever.

Unfortunately, I can't reopen this bug, so someone please 
reopen it.

Thank you.



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/14409

-- 
Edit this bug report at http://bugs.php.net/?id=14409edit=1

#21575 [Opn-Csd]: 4.2x to 4.3 Compatibility issue

2003-01-25 Thread shane 
 ID:   21575
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: IIS related
 Operating System: Windows 2000
 PHP Version:  4.3.0
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

PATH_INFO and PATH_TRANSLATED conform to the CGI spec in PHP 4.3.  For
linux (and possibly other platforms) a fix was requried which is now in
CVS (fixes PHP_SELF also).  The fix in CVS also creates ORIG_PATH_INFO
and ORIG_PATH_TRANSLATED so you can easily fix scripts dependent on the
previous incorrect variables.

ISAPI has always had broken PATH_INFO/PATH_TRANSLATED, and this was not
changed in 4.3, but will be fixed for 5.0.



Previous Comments:


[2003-01-20 21:32:31] [EMAIL PROTECTED]

Well, cgi.fix_pathinfo does not completely solve this 
problem. By adding this line to php.ini, $PATH_INFO is 
presented only in CGI mode. However, it is still missing in 
ISAPI mode.

It is indeed a bug, or else they should put a warning 
message in 4.30 press release or installation document.



[2003-01-20 18:55:05] [EMAIL PROTECTED]

See bug http://bugs.php.net/bug.php?id=21716
Thanks to Milky!
Use cgi.fix_pathinfo=0 in 4.3.0 php.ini to solve this problem.



[2003-01-18 07:02:44] [EMAIL PROTECTED]

Compare these PhpInfo() outputs:

http://php430.eserv.ru/php_info.php/path/info?query
http://php423.eserv.ru/php_info.php/path/info?query

Same web-server, same php.ini, very different environment variables!
(of course, web-server pass the same variables, but 4.3.0 damages them!
;) PATH_INFO disappears in 4.3.0 :(



[2003-01-18 06:35:03] [EMAIL PROTECTED]

[EMAIL PROTECTED] wrote:
For 4.3, cgi variables were changed to correctly conform to 
cgi specs.  This means that
PATH_INFO is now in fact PATH_INFO as per:
http://hostname/script_name.php/path/info?query_string

You may try this URL url on Win32 web-server with PHP 4.3.0 as CGI and
YOU WILL SEE - for this URL PHP will not show PATH_INFO variable,
passed to it by web-server! Web-server pass PATH_INFO=/path/info (for
this URL), but PhpInfo() in PHP 4.3.0 will NOT show PATH_INFO in the
list! All old 4.2.x versions works OK with this case, and previous
4.3.0-dev too, but in 4.3.0 just drop PATH_INFO in any case. This is
definitely 4.3.0 BUG.



[2003-01-13 11:26:28] [EMAIL PROTECTED]

register globals has nothing to do with this.  For 4.3, cgi variables
were changed to correctly conform to cgi specs.  This means that
PATH_INFO is now in fact PATH_INFO as per:
http://hostname/script_name.php/path/info?query_string

Use SCRIPT_NAME or PHP_SELF if you need to refer to /script_name.php,
and use SCRIPT_FILENAME if you need to get the full path to
script_name.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/21575

-- 
Edit this bug report at http://bugs.php.net/?id=21575edit=1

#21575 [Com]: 4.2x to 4.3 Compatibility issue

2003-01-13 Thread shane 
 ID:   21575
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: IIS related
 Operating System: Any
 PHP Version:  4.3.0
 New Comment:

register globals has nothing to do with this.  For 4.3, cgi variables
were changed to correctly conform to cgi specs.  This means that
PATH_INFO is now in fact PATH_INFO as per:
http://hostname/script_name.php/path/info?query_string

Use SCRIPT_NAME or PHP_SELF if you need to refer to /script_name.php,
and use SCRIPT_FILENAME if you need to get the full path to
script_name.php


Previous Comments:


[2003-01-13 06:15:51] [EMAIL PROTECTED]

In PHP 4.2.0, the 'register_globals' setting default changed to
'off'. See http://www.php.net/release_4_2_0.php for more info.
We are sorry about the inconvenience, but this change was a necessary
part of our efforts to make PHP scripting more secure and portable.





[2003-01-13 05:30:53] [EMAIL PROTECTED]

How can a PHP variable which existed when running 4.2.3 then
disappears, without a mention that it was going to, when running 4.3.0
not be considered a bug?

I have the same problem here. Yes, PHP has to rely on the server
environment for the values to the PHP Variables, but if one version of
PHP can see it and a newer one cannot, then surely the code has been
modified incorrectly in the newer version. Nothing else has changed on
my server - I can easily test this by having PHP in two different
directories, PHP.4.2.3 and PHP.4.3.0. Naming each to PHP in turn and
running the phpinfo() command produces a version with PHP_INFO, i.e.
for 4.2.3 and one without, for 4.3.0

Regards,
Taomyn



[2003-01-11 12:15:55] [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.

php.ini settings do not have any impact on the enviroment variables.
PHP will automatically gather all avaliable enviroment variables and
make then avaliable to you, if an enviroment variable does not exist it
simply means it is not set. In which case PHP cannot make it avaliable
to you.



[2003-01-11 06:37:21] [EMAIL PROTECTED]

I'm using Windows 2000 with IIS 5, and I've tried both CGI 
and ISAPI mode. I updated my server to PHP4.30 on 2 Jan, as 
you may notice in another bug-report I submitted ( http://
bugs.php.net/bug.php?id=20426 ). I did not run Windows 
Update this week, and I disabled auto-update service since 
I don't trust Microsoft. :-)

Anyway, it should not be called as 'bug', and I have not 
trouble to modify my codes (just find/replace PATH_INFO 
with PHP_SELF.) I'm just curious about what is going on. 
Does PHP.INI would affect environment variables ? I'm using 
all default settings but enabling register_globals.



[2003-01-10 21:54:37] [EMAIL PROTECTED]

Environment variables are supplied by the environment under which PHP
is running.  In most cases this means the webserver.  Did you
change/upgrade your webserver at the same time?  Moreover, what
webserver are you running and on what OS?



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/21575

-- 
Edit this bug report at http://bugs.php.net/?id=21575edit=1

#21261 [Opn]: $_SERVER['PHP_SELF'] gives wrong info

2003-01-06 Thread shane 
 ID:   21261
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: linux 2.4.18 - slack 8.1
 PHP Version:  4.3.0
 Assigned To:  shane
 New Comment:

[EMAIL PROTECTED]: email me your httpd.conf, php.ini and the test
script you use.  You can remove anything from the files that are
private.  Also, as per spec PATH_TRANSLATED will be empty unless you
have PATH_INFO, which is path data *after* the script in a url:
http://host/script.php/path/info?query-string
The only thing I'm concerned about is the garbled PHP_SELF.  PHP_SELF
is the same as SCRIPT_NAME, is SCRIPT_NAME also garbled?


Previous Comments:


[2003-01-06 11:06:47] [EMAIL PROTECTED]

Negative. Patch not only did not work (I applied it to 
current 4.3.0) but I now no longer have a 
$_SERVER['PATH_TRANSLATED'] variable . 
So $_SERVER['PHP_SELF'] remains corrupted and 
$_SERVER['PATH_TRANSLATED'] gives some kind of udefined 
error. 
Joshua



[2003-01-05 21:58:19] [EMAIL PROTECTED]

The patch at
http://www.caraveo.com/php/cgi.patch

Should fix this problem.  Please try this and let me know.  It's
against cvs HEAD from today.




[2003-01-02 10:54:32] [EMAIL PROTECTED]

I'm using php with cgiwrap. 
http://cgiwrap.unixtools.org/

I added two small patches as described in Bug #21301 but i don't know
if they work with current cvs version.

In httpd.conf:

AddHandler php-cgiwrap .php
Action php-cgiwrap /cgiwrapper/php-cgiwrap/USER
ScriptAlias /cgiwrapper/ /usr/local/cgiwrap/



[2003-01-01 11:21:36] [EMAIL PROTECTED]

Are you talking about this? 
 
ScriptAlias /cgi/ /var/www/htdcos/cgi/ 
Action application/x-httpd-php  /cgi/php 
AddType application/x-httpd-php .php 
 
I can also post my ini and my configure script though you 
can probably get that info from the env.html I posted 
earlier.



[2002-12-31 01:21:50] [EMAIL PROTECTED]

Send me the pertinent lines out of httpd.conf that you have used to
configure php so I can test with the same settings.



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/21261

-- 
Edit this bug report at http://bugs.php.net/?id=21261edit=1

#21261 [Opn]: $_SERVER['PHP_SELF'] gives wrong info

2003-01-05 Thread shane 
 ID:   21261
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: linux 2.4.18 - slack 8.1
 PHP Version:  4.3.0
 New Comment:

The patch at
http://www.caraveo.com/php/cgi.patch

Should fix this problem.  Please try this and let me know.  It's
against cvs HEAD from today.



Previous Comments:


[2003-01-02 10:54:32] [EMAIL PROTECTED]

I'm using php with cgiwrap. 
http://cgiwrap.unixtools.org/

I added two small patches as described in Bug #21301 but i don't know
if they work with current cvs version.

In httpd.conf:

AddHandler php-cgiwrap .php
Action php-cgiwrap /cgiwrapper/php-cgiwrap/USER
ScriptAlias /cgiwrapper/ /usr/local/cgiwrap/



[2003-01-01 11:21:36] [EMAIL PROTECTED]

Are you talking about this? 
 
ScriptAlias /cgi/ /var/www/htdcos/cgi/ 
Action application/x-httpd-php  /cgi/php 
AddType application/x-httpd-php .php 
 
I can also post my ini and my configure script though you 
can probably get that info from the env.html I posted 
earlier.



[2002-12-31 01:21:50] [EMAIL PROTECTED]

Send me the pertinent lines out of httpd.conf that you have used to
configure php so I can test with the same settings.



[2002-12-30 20:21:48] [EMAIL PROTECTED]

Probable cause found Checking with submitter of prior patch.



[2002-12-30 20:21:02] [EMAIL PROTECTED]

I have a similar problem. It is discribed in
http://bugs.php.net/bug.php?id=21301

The result of set cat be viewed on
http://www.engter.de/shenv.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/21261

-- 
Edit this bug report at http://bugs.php.net/?id=21261edit=1

#21301 [Dup]: PHP_SELF is empty

2003-01-05 Thread shane 
 ID:   21301
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Duplicate
 Bug Type: Scripting Engine problem
 Operating System: Linux (SuSE)
 PHP Version:  4.3.0
-Assigned To:  
+Assigned To:  shane
 New Comment:

I do beleive this is caused by the same problem that caused the bug
21261, please try the patch linked to on that bug.


Previous Comments:


[2002-12-31 02:15:14] [EMAIL PROTECTED]

When we ask for feedback, we set the status to Feedback :)



[2002-12-30 20:38:06] [EMAIL PROTECTED]

While the comments in that bug report get a little confusing, this
*does* seem to be the same bug and indeed a problem in PHP and not the
webserver as I thought at one point.



[2002-12-30 20:23:57] [EMAIL PROTECTED]

I'm not very sure if it is the same bug. In #21261 PATH_INFO is empty
but as you can see on http://www.engter.de/shenv.php this is not the
case in my installation.



[2002-12-30 19:53:40] [EMAIL PROTECTED]

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.

Please feel free to add your comments to Bug #21261.

In fact, please describe your operating environment as thoroughly as
possible so that this bug can be reliably reproduced.

A dump of /usr/local/apache/bin/httpd -l and a list of all
LoadModule lines would also be helpful.



[2002-12-30 19:48:43] [EMAIL PROTECTED]

Did anyone change the way php get it's PHP_SELF-Variable?

On my server php-files are wrapped through a slightly patched version
of
cgiwrap. I changed a few lines so that PHP_SELF is not broken and
cgiwrap is not visible to the user. For details have a look at:
http://www.engter.de/phpinfo.php
http://roland.engter.de/stuff/cgiwrap-PATH_INFO.patch
http://roland.engter.de/stuff/cgiwrap-SCRIPT_NAME.patch

With PHP 4.2.3 everything worked fine. But after updating to PHP 4.3.0
(with --disable-cli) PHP_SELF was empty. At first i thought that my
patch on cgiwrap was the reason for this, but finally i installed PHP
4.2.3 again and everything was fine.

Any ideas?




-- 
Edit this bug report at http://bugs.php.net/?id=21301edit=1

#19378 [Opn-Csd]: Parse error in PHP executable as Apache CGI

2002-12-02 Thread shane 
 ID:   19378
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Apache related
 Operating System: FreeBSD 4.5-STABLE
 PHP Version:  4.2.3
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

fixed in CVS as of today.


Previous Comments:


[2002-11-10 19:07:33] [EMAIL PROTECTED]

I think the message No feedback was provided for this bug for over 2
weeks,... is absurd and may represent a bug in bug-track.  I provided
the feedback as requested.



[2002-11-09 01:00:08] [EMAIL PROTECTED]

No feedback was provided for this bug for over 2 weeks, 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-10-24 19:27:09] [EMAIL PROTECTED]

Recompiled using the same script and now get the following when the
page is shown in Apache.

Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator, [EMAIL PROTECTED] and inform
them of the time the error occurred, and anything you might have done
that may have caused the error.

More information about this error may be available in the server error
log.

apache_error_log shows:

[Thu Oct 24 20:20:45 2002] [error] [client 192.168.1.140] Premature end
of script headers: /www/kyler.com/cgi/php

nothing else was changed.

Ken



[2002-10-24 15:35:28] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-09-17 01:10:04] [EMAIL PROTECTED]

As usual, it seems that nobody is interessted in these problems with
PHP as CGI, its the same like this:
http://bugs.php.net/bug.php?id=18371 , its a general issue.



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/19378

-- 
Edit this bug report at http://bugs.php.net/?id=19378edit=1

#20053 [Opn]: apachesuexecphp-cgiignore_user_abort - problem with cancelled connections

2002-12-02 Thread shane 
 ID:   20053
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Apache related
 Operating System: linux 2.4.18
 PHP Version:  4.3.0-dev
 New Comment:

Please try the latest cvs as of today.  Several significant cgi fixes
have been commited.


Previous Comments:


[2002-10-24 12:26:56] [EMAIL PROTECTED]

updated version.




[2002-10-24 04:27:26] [EMAIL PROTECTED]

Exactly the same behaviour as in 4.2.3 :(



[2002-10-24 02:42:11] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip



[2002-10-23 19:40:25] [EMAIL PROTECTED]

Under very specific circumstances, php goes in tight infinite loop
eating all cpu after request is cancelled.

Configuration:
php 4.2.3 as cgi
apache 1.3.27
php configured with Action directive, (important) using suexec.

Conditions for problem to occur in script:
1.ignore_user_abort(true)
2.sending any http header
3.sending any body content AFTER http header
4. connection is aborted before all data are sent to client.

Script to reproduce problem:
 CUT 
?
ignore_user_abort(true);
header(X-Whatever: whatever);
?
whatever
 CUT 

Problem doesn't exist with mod_php or php-cgi without suexec.
It appears that after apache has closed connection php is still trying
to write output and loops for unknown reason.
I'm not sure if this is fault of php, apache or suexec, but I think it
could be fixed in php.




-- 
Edit this bug report at http://bugs.php.net/?id=20053edit=1

#17314 [NoF]: CGI error with doc_root as in php.ini_dist

2002-12-02 Thread shane 
 ID:   17314
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: IIS related
 Operating System: Win XP Pro
 PHP Version:  4.3.0 dev
 New Comment:

Please try a snapshot dated after today.


Previous Comments:


[2002-11-16 01:00:01] [EMAIL PROTECTED]

No feedback was provided for this bug for over 2 weeks, 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-10-31 11:55:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-07-01 16:08:43] [EMAIL PROTECTED]

Veryfied with 4.3.0 snapshot of yesterday. Still the same phenomen.



[2002-06-03 14:26:47] [EMAIL PROTECTED]

No, I'm sure it's not cgi.force-redirect.

The behaviour is changing when commenting out doc_root.

Have verified it again. However, I didn't have the problem on a NT 4.0
Server SP6a with IIS 4.

Christoph



[2002-06-03 12:32:58] [EMAIL PROTECTED]

Can't reproduce.

Are you sure this is not actually the problem with having
cgi.force_redirect set to 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/17314

-- 
Edit this bug report at http://bugs.php.net/?id=17314edit=1

#18942 [WFx-Csd]: $PHP_SELF is set to HTTP_SERVER_VARS[PATH_INFO] if available

2002-12-02 Thread shane 
 ID:   18942
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Won't fix
+Status:   Closed
 Bug Type: Other web server
 Operating System: Debian
 PHP Version:  4.2.2
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

It's fixed in cvs as of today.


Previous Comments:


[2002-08-17 10:01:52] [EMAIL PROTECTED]

The manual states why this shouldn't used, and the fact that it's
populated at all is interesting.  



[2002-08-17 09:41:56] [EMAIL PROTECTED]

I believe it should be fixed ... Or at least the apache SAPI should be
modified too.

With the current code, PATH_INFO has different meanings (and values) in
the Apache and CGI SAPIs, not good at all for applications portability
IMHO.



[2002-08-17 00:58:09] [EMAIL PROTECTED]

I believe this is a documented issue, and won't be fixed.



[2002-08-16 15:56:02] [EMAIL PROTECTED]

There is a very fast way of testing, create a script called phpinfo.php
with juste ?phpinfo()? in it.

Then call it like http://yourserver.com/phpinfo.php/this/is/a/test

if the two images (zend and php logos) are broken, then $PHP_SELF is
not set as it should be.

again, this problem only happens with the CGI sapi



[2002-08-16 15:44:07] [EMAIL PROTECTED]

Okay can we have a sample script just to ensure that we may or may not
have fixed your issue?



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/18942

-- 
Edit this bug report at http://bugs.php.net/?id=18942edit=1

#12264 [Bgs-Csd]: PATH_INFO and PATH_TRANSLATED not being correctly set

2002-12-02 Thread shane 
 ID:   12264
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Closed
 Bug Type: IIS related
 Operating System: Win2K Server
 PHP Version:  4.0.6
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2002-06-03 12:12:36] [EMAIL PROTECTED]

Thank you for taking the time to report a problem with PHP.
Unfortunately your version of PHP is too old -- the problem
might already be fixed. Please download a new PHP
version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to Open.
Again, thank you for your continued support of PHP.





[2001-07-20 03:20:19] [EMAIL PROTECTED]

Hmm, looks like my patch thing didn't quite work [for one, PATH_INFO
isn't being set right, then I think there are also some memory leaks])
... I had an old very hacky patch around here that I ended up reverting
to for now.

A proper fix for this problem would be great :)



[2001-07-19 14:29:07] [EMAIL PROTECTED]

Hello,

The scripts that we are running use PATH_INFO to determine where a user
is trying to access, and this became a problem when we switched over
from using Apache to using IIS. Once we made the switch from Apache to
IIS we were getting continual CGI Errors (like virtually every single
hit was a CGI Error) [ and this was not because of permissions ]

As it turns out, the only pages where we would not get a CGI error was
the root page, which had an empty PATH_INFO. Here's an example:

Our root script is /test.php. If I requested /test.php everything would
work fine; However if I requested /test.php/hello/world I
would get a CGI Error (under IIS). Under Apache I would get the proper
results -- it would run /test.php and PATH_INFO would be 
/hello/world.

But anyways - after spending some time poking around the PHP source I
found that PHP was trying to execute the wrong file! In the above
example, it was attempting to run /test.php/hello/world instead of
/test.php (SCRIPT_NAME was being to /test.php). To me it looked like
IIS was setting PATH_INFO and PATH_TRANSLATED differently than PHP was
expecting, so I made a change the the source so that it would modify
those two until they were in working order. I'm not sure if my change
is correct - but it did fix the problem).

(Note: The problem is independent of the actual script - any script
where you put stuff on the URL in this manner will have this problem)

=

What follows now is the output that I had PHP give on what it was
trying to run. The first is the original version that didn't work,
followed by the version with the changes that I made, and the proper
results:

In both of the cases, the requested URL was:

http://192.168.1.2/test.php/hello/world


Original (non-working) version
--
PHP Output follows

SG(request_info).path_translated: (null)
PATH_INFO  : /test.php/hello/world
SCRIPT_NAME: /test.php
SG(request_info).request_uri = /test.php/hello/world
php_fopen_primary_script(): filename  =
C:\web\fcsweb\test.php\hello\world
php_fopen_primary_script(): path_info = /test.php/hello/world

=

So you can see that in the original request it is trying to run the
wrong script. With the changes I made, I now get the following:

New (working) version
-
PHP Output follows

SG(request_info).path_translated: C:\web\fcsweb\test.php
PATH_INFO  : /hello/world
SCRIPT_NAME: /test.php
SG(request_info).request_uri = /hello/world
php_fopen_primary_script(): filename  = C:\web\fcsweb\test.php
php_fopen_primary_script(): path_info = /hello/world

=

Some more information on our system:

OS: Win2k Server SP1
Webserver: IIS4
PHP: 4.0.6 CGI mode

And finally, the patch for the changes I made to cgi_main.c are at:

http://div.dyndns.org/jah/php/iis_cgi_path_fix.patch

I've never submitted a patch before, so I don't know if it's done in
the right manner...

Hopefully I've analyzed this whole issue somewhat correctly... :)

Thanks!

-Jah

#19592 [Opn-Csd]: PHP_SELF is not correct with --enable-discard-path

2002-12-02 Thread shane 
 ID:   19592
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: URL related
 Operating System: GNU/Linux
 PHP Version:  4.2.3
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2002-10-03 07:36:20] [EMAIL PROTECTED]

You can find my patch proposition for this PHP Bug at:
http://groups.google.com/groups?selm=amelb7%24297k%241%40FreeBSD.csie.NCTU.edu.tw
(I have sent this to php-dev list, but there was
no response from php core developers)...

Maybe updating this bug report would make any change.



[2002-09-25 12:38:24] [EMAIL PROTECTED]

In absence of a PATH_INFO PHP_SELF is correct
( it is set to the value of SCRIPT_NAME )
But when a PATH_INFO is given PHP_SELF is set to
its value. For example:

  URI: /php4info.cgi   --- PHP_SELF: /php4info.cgi
  URI: /php4info.cgi/test  --- PHP_SELF: /test

Of course the scripts themself start with #!/path/to/php4
And the interpreter was compiled with --enable-discard-path



[2002-09-25 10:42:57] [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.






[2002-09-25 08:57:43] [EMAIL PROTECTED]

When compiled with --enable-discrd-path
PHP does not provide a valid PHP_SELF.

It seems to me as simple as concatenating
SCRIPT_NAME with PATH_INFO, do I miss something ?




-- 
Edit this bug report at http://bugs.php.net/?id=19592edit=1

#20490 [NEW]: enable versioning not supported on OSX

2002-11-18 Thread shane 
From: [EMAIL PROTECTED]
Operating system: OSX 10.2.2
PHP version:  4CVS-2002-11-18 (dev)
PHP Bug Type: *Configuration Issues
Bug description:  enable versioning not supported on OSX

./configure --enable-versioning uses -export-sybmols in the ld command,
this is not supported under osx and should be disabled in the configure
script.
-- 
Edit bug report at http://bugs.php.net/?id=20490edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20490r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20490r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20490r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20490r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20490r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20490r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20490r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20490r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20490r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20490r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20490r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20490r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20490r=isapi

#19730 [NoF-Opn]: PHP --with-mysql reports the wrong client API version

2002-10-28 Thread shane 
 ID:   19730
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: MySQL related
 Operating System: debian linux potato
 PHP Version:  4.2.3
 New Comment:

Apologies for the delay; the previous message got lost in my inbox and
I forgot to check up on it.

I am unable to build from the snapshot. I grabbed the latest snapshot,
and ran buildconf in the root of the source tree. then I ran my
configure line (pasted earlier). Error follows:

[root@aqua php4-200210280900]# make
gcc  -Iext/sockets/ -I/usr/local/src/php4-200210280900/ext/sockets/
-DPHP_ATOM_INC -I/usr/local/src/php4-200210280900/include
-I/usr/local/src/php4-200210280900/main
-I/usr/local/src/php4-200210280900
-I/usr/local/src/php4-200210280900/Zend -I/usr/local/ssl/include
-I/usr/local/include/mysql -I/usr/local/include/ucd-snmp
-I/usr/local/src/php4-200210280900/ext/xml/expat -I/usr/local/include 
-I/usr/local/src/php4-200210280900/TSRM  -g -O2  -c
/usr/local/src/php4-200210280900/ext/sockets/sockets.c -o
ext/sockets/sockets.o   echo  ext/sockets/sockets.lo
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/src/php4-200210280900/ext/sockets/sockets.c:276: conflicting
types for `php_read'
/usr/local/src/php4-200210280900/ext/sockets/php_sockets.h:105:
previous declaration of `php_read'
make: *** [ext/sockets/sockets.lo] Error 1
[root@aqua php4-200210280900]#


Previous Comments:


[2002-10-27 19:12:20] [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-10-12 10:23:45] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


Even as I'm pretty sure this is some problem in your system or an user
error..




[2002-10-04 19:21:39] [EMAIL PROTECTED]

yes, it does. Both the binary build and the apache module were built on
October 2, 2002, and they both show the correct build date.



[2002-10-04 18:29:07] [EMAIL PROTECTED]

Can you check what the build-date is in the phpinfo output where the
incorrect mysql version is shown?
(2nd line, iirc)

Does it match the date you build it?




[2002-10-04 13:08:36] [EMAIL PROTECTED]

Additionally, as I stated earlier, the PHP binary and the PHP Apache
modules are being compiled on the same server, with the same configure
options (except --with-apache).

Nothing on the server was changed between building the binary and the
module. They both used clean source trees (freshly untarred, even). The
binary reports the correct version, the module does not. The module
also does not report the version of the included MySQL libs, instead it
reports a version of MySQL that has never been installed on the server.



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/19730

-- 
Edit this bug report at http://bugs.php.net/?id=19730edit=1

#20126 [Opn-Csd]: fwrite to stdin causes exception in streams

2002-10-27 Thread shane 
 ID:   20126
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: win2k
 PHP Version:  4CVS-2002-10-27
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

fixed in cvs, streams.c revision: 1.118



Previous Comments:


[2002-10-27 16:41:44] [EMAIL PROTECTED]

running run-tests.php with current cvs build causes exception.  Minimal
code to repro:

$fp = fopen(php://stdin, r+);
fwrite($fp, Some tests have failed, would you like to send the\nreport
to PHP's QA team? [Yn]: );
fflush($fp);
$user_input = fgets($fp, 10);






-- 
Edit this bug report at http://bugs.php.net/?id=20126edit=1

#20127 [NEW]: writing to stdin produces no output

2002-10-27 Thread shane 
From: [EMAIL PROTECTED]
Operating system: win2k
PHP version:  4CVS-2002-10-27
PHP Bug Type: Output Control
Bug description:  writing to stdin produces no output

the following produces no output in windows.

$fp = fopen(php://stdin, r+);
fwrite($fp, Some tests have failed, would you like to send the\nreport to
PHP's QA team? [Yn]: );
fflush($fp);
$user_input = fgets($fp, 10);


-- 
Edit bug report at http://bugs.php.net/?id=20127edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20127r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20127r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20127r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20127r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20127r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20127r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20127r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20127r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20127r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20127r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20127r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20127r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20127r=isapi

#19730 [Fbk-Opn]: PHP --with-mysql reports the wrong client API version

2002-10-04 Thread shane 

 ID:   19730
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Apache related
 Operating System: debian linux potato
 PHP Version:  4.2.3
 New Comment:

yes, it does. Both the binary build and the apache module were built on
October 2, 2002, and they both show the correct build date.


Previous Comments:


[2002-10-04 18:29:07] [EMAIL PROTECTED]

Can you check what the build-date is in the phpinfo output where the
incorrect mysql version is shown?
(2nd line, iirc)

Does it match the date you build it?




[2002-10-04 13:08:36] [EMAIL PROTECTED]

Additionally, as I stated earlier, the PHP binary and the PHP Apache
modules are being compiled on the same server, with the same configure
options (except --with-apache).

Nothing on the server was changed between building the binary and the
module. They both used clean source trees (freshly untarred, even). The
binary reports the correct version, the module does not. The module
also does not report the version of the included MySQL libs, instead it
reports a version of MySQL that has never been installed on the server.



[2002-10-03 20:01:10] [EMAIL PROTECTED]

with regards to the beta string, I have known about the development
life cycle, and the alpha, beta, gamma, and release phases of
development for many years. MySQL 4 is doing wonderfully in production,
and we put each release through rigorous testing in house before
implementing it. You should try it out sometime.

With regards to the version string, there are no files on the
filesystem that match 3.23.35.

Have you tried to build it yet using the build method I sent? If so,
what were the results?



[2002-10-03 19:27:21] [EMAIL PROTECTED]

I hope you're aware that the 'beta' text in that version for mysql
really means that it's not ready for production..

Anyway, the api version shown in phpinfo() output comes from
mysql function called 'mysql_get_client_info()' and that is provided by
the mysql client libs and in the bundled mysql lib sources it's like
this:

mysql_get_client_info(void)
{
  return (char*) MYSQL_SERVER_VERSION;
}

Try grepping your whole system for that incorrect version and you'll
find where it's defined..




[2002-10-03 09:26:40] [EMAIL PROTECTED]

Apologies, I copy and pasted the wrong build script. As you can see
from my first post to this bug, I did use a prefix of /usr/local when
configuring php.

Since the shipped version of the mysql libs are 3.23.39 (not 3.23.35),
it is obvious that the binary is built against other libs.
Additionally, the box has never had a version of MySQL installed on it
lower than 3.23.37, so the 3.23.35 version string has to be in error.

Additionally, there are no other copies of the mysql libs and includes
other than the 4.0.4 set. I verified this over lunch one day when I
left one of our boxen doing a recursive grep of /usr looking for old
versions.

Have you attempted to reproduce this? It should be exceedingly easy for
anyone to prove.



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/19730

-- 
Edit this bug report at http://bugs.php.net/?id=19730edit=1

#19730 [Fbk-Opn]: PHP --with-mysql reports the wrong client API version

2002-10-03 Thread shane 

 ID:   19730
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Apache related
 Operating System: debian linux potato
 PHP Version:  4.2.3
 New Comment:

Apologies, I copy and pasted the wrong build script. As you can see
from my first post to this bug, I did use a prefix of /usr/local when
configuring php.

Since the shipped version of the mysql libs are 3.23.39 (not 3.23.35),
it is obvious that the binary is built against other libs.
Additionally, the box has never had a version of MySQL installed on it
lower than 3.23.37, so the 3.23.35 version string has to be in error.

Additionally, there are no other copies of the mysql libs and includes
other than the 4.0.4 set. I verified this over lunch one day when I
left one of our boxen doing a recursive grep of /usr looking for old
versions.

Have you attempted to reproduce this? It should be exceedingly easy for
anyone to prove.


Previous Comments:


[2002-10-03 07:17:18] [EMAIL PROTECTED]

If you use '--with-mysql' with php configure, it will use the bundled
mysql client libs which are of version 3.23.39
in 4.2.3. 

You must use the prefix with which you installed the mysql
to get the correct libs and headers.

Also, make sure you don't have some older mysql libs in your system's
default libpath..




[2002-10-03 00:10:52] [EMAIL PROTECTED]

I am using the latest sources for apache 1.3.26, mod_ssl 2.8.10, and
php-4.2.3. Additionally, I am doing a build from source of MySQL
4.0.4.

*Every* time I build a new binary, I rm -rf each of the source
directories, tar -zxvf each tarball, and rebuild from scratch. Below
are the directives I am using to build apache, in order:

cd mod_ssl-2.8.10-1.3.26
./configure --with-apache=../apache_1.3.26

cd ../apache_1.3.26
./configure --prefix=/usr/local/apache

cd ../php-4.2.3
./configure --with-apache=/usr/local/src/apache_1.3.26 \
--disable-magic-quotes \
--disable-short-tags \
--disable-debug \
--without-gd \
--enable-url-fopen-wrapper \
--enable-track-vars \
--enable-memory-limit \
--enable-inline-optimization \
--with-config-file-path=/usr/local/php/ini \
--with-mysql \
--enable-ftp \
--enable-sockets \
--enable-xml \
--enable-wddx \
--enable-bcmath \
--with-zlib=/usr \
--with-snmp \
--enable-ucd-snmp-hack \
--with-openssl \
--with-xmlrpc

make -j15
make install

cd ../apache_1.3.26

./configure --prefix=/usr/local/apache \
--enable-module=ssl \
--activate-module=src/modules/php4/libphp4.a \
--enable-module=rewrite \
--enable-module=proxy \
--enable-module=so

make
make install



[2002-10-02 20:59:12] [EMAIL PROTECTED]

Please do a clean build of Apache next time.
You should do 'make clean' in the apache sources at least,
better yet, get fresh sources and do the build from scratch.




[2002-10-02 20:09:41] [EMAIL PROTECTED]

I have MySQL 4.0.4-beta installed. I configured php as follows:

 './configure' '--with-apache=/usr/local/src/apache_1.3.26'
'--disable-magic-quotes' '--disable-short-tags' '--disable-debug'
'--without-gd' '--enable-url-fopen-wrapper' '--enable-track-vars'
'--enable-memory-limit' '--enable-inline-optimization'
'--with-config-file-path=/usr/local/php/ini' '--with-mysql=/usr/local'
'--enable-ftp' '--enable-sockets' '--enable-xml' '--enable-wddx'
'--enable-bcmath' '--with-zlib=/usr' '--with-snmp'
'--enable-ucd-snmp-hack' '--with-openssl' '--with-xmlrpc'

the php binary reports:

mysql
MySQL Support enabled
Active Persistent Links 0
Active Links 0
Client API version 4.0.4-beta

apache (mod_php installed) reports:

mysql
MySQL Support enabled
Active Persistent Links 0
Active Links 0
Client API version 3.23.35




-- 
Edit this bug report at http://bugs.php.net/?id=19730edit=1

#19730 [Fbk-Opn]: PHP --with-mysql reports the wrong client API version

2002-10-03 Thread shane 

 ID:   19730
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Apache related
 Operating System: debian linux potato
 PHP Version:  4.2.3
 New Comment:

with regards to the beta string, I have known about the development
life cycle, and the alpha, beta, gamma, and release phases of
development for many years. MySQL 4 is doing wonderfully in production,
and we put each release through rigorous testing in house before
implementing it. You should try it out sometime.

With regards to the version string, there are no files on the
filesystem that match 3.23.35.

Have you tried to build it yet using the build method I sent? If so,
what were the results?


Previous Comments:


[2002-10-03 19:27:21] [EMAIL PROTECTED]

I hope you're aware that the 'beta' text in that version for mysql
really means that it's not ready for production..

Anyway, the api version shown in phpinfo() output comes from
mysql function called 'mysql_get_client_info()' and that is provided by
the mysql client libs and in the bundled mysql lib sources it's like
this:

mysql_get_client_info(void)
{
  return (char*) MYSQL_SERVER_VERSION;
}

Try grepping your whole system for that incorrect version and you'll
find where it's defined..




[2002-10-03 09:26:40] [EMAIL PROTECTED]

Apologies, I copy and pasted the wrong build script. As you can see
from my first post to this bug, I did use a prefix of /usr/local when
configuring php.

Since the shipped version of the mysql libs are 3.23.39 (not 3.23.35),
it is obvious that the binary is built against other libs.
Additionally, the box has never had a version of MySQL installed on it
lower than 3.23.37, so the 3.23.35 version string has to be in error.

Additionally, there are no other copies of the mysql libs and includes
other than the 4.0.4 set. I verified this over lunch one day when I
left one of our boxen doing a recursive grep of /usr looking for old
versions.

Have you attempted to reproduce this? It should be exceedingly easy for
anyone to prove.



[2002-10-03 07:17:18] [EMAIL PROTECTED]

If you use '--with-mysql' with php configure, it will use the bundled
mysql client libs which are of version 3.23.39
in 4.2.3. 

You must use the prefix with which you installed the mysql
to get the correct libs and headers.

Also, make sure you don't have some older mysql libs in your system's
default libpath..




[2002-10-03 00:10:52] [EMAIL PROTECTED]

I am using the latest sources for apache 1.3.26, mod_ssl 2.8.10, and
php-4.2.3. Additionally, I am doing a build from source of MySQL
4.0.4.

*Every* time I build a new binary, I rm -rf each of the source
directories, tar -zxvf each tarball, and rebuild from scratch. Below
are the directives I am using to build apache, in order:

cd mod_ssl-2.8.10-1.3.26
./configure --with-apache=../apache_1.3.26

cd ../apache_1.3.26
./configure --prefix=/usr/local/apache

cd ../php-4.2.3
./configure --with-apache=/usr/local/src/apache_1.3.26 \
--disable-magic-quotes \
--disable-short-tags \
--disable-debug \
--without-gd \
--enable-url-fopen-wrapper \
--enable-track-vars \
--enable-memory-limit \
--enable-inline-optimization \
--with-config-file-path=/usr/local/php/ini \
--with-mysql \
--enable-ftp \
--enable-sockets \
--enable-xml \
--enable-wddx \
--enable-bcmath \
--with-zlib=/usr \
--with-snmp \
--enable-ucd-snmp-hack \
--with-openssl \
--with-xmlrpc

make -j15
make install

cd ../apache_1.3.26

./configure --prefix=/usr/local/apache \
--enable-module=ssl \
--activate-module=src/modules/php4/libphp4.a \
--enable-module=rewrite \
--enable-module=proxy \
--enable-module=so

make
make install



[2002-10-02 20:59:12] [EMAIL PROTECTED]

Please do a clean build of Apache next time.
You should do 'make clean' in the apache sources at least,
better yet, get fresh sources and do the build from scratch.




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/19730

-- 
Edit this bug report at http://bugs.php.net/?id=19730edit=1

#19730 [NEW]: PHP --with-mysql reports the wrong client API version

2002-10-02 Thread shane 

From: [EMAIL PROTECTED]
Operating system: debian linux potato
PHP version:  4.2.3
PHP Bug Type: Apache related
Bug description:  PHP --with-mysql reports the wrong client API version

I have MySQL 4.0.4-beta installed. I configured php as follows:

 './configure' '--with-apache=/usr/local/src/apache_1.3.26'
'--disable-magic-quotes' '--disable-short-tags' '--disable-debug'
'--without-gd' '--enable-url-fopen-wrapper' '--enable-track-vars'
'--enable-memory-limit' '--enable-inline-optimization'
'--with-config-file-path=/usr/local/php/ini' '--with-mysql=/usr/local'
'--enable-ftp' '--enable-sockets' '--enable-xml' '--enable-wddx'
'--enable-bcmath' '--with-zlib=/usr' '--with-snmp'
'--enable-ucd-snmp-hack' '--with-openssl' '--with-xmlrpc'

the php binary reports:

mysql
MySQL Support enabled
Active Persistent Links 0
Active Links 0
Client API version 4.0.4-beta

apache (mod_php installed) reports:

mysql
MySQL Support enabled
Active Persistent Links 0
Active Links 0
Client API version 3.23.35
-- 
Edit bug report at http://bugs.php.net/?id=19730edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19730r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19730r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19730r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19730r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19730r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19730r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19730r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19730r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19730r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19730r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19730r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19730r=dst

#19730 [Bgs-Opn]: PHP --with-mysql reports the wrong client API version

2002-10-02 Thread shane 

 ID:   19730
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Apache related
 Operating System: debian linux potato
 PHP Version:  4.2.3
 New Comment:

I am using the latest sources for apache 1.3.26, mod_ssl 2.8.10, and
php-4.2.3. Additionally, I am doing a build from source of MySQL
4.0.4.

*Every* time I build a new binary, I rm -rf each of the source
directories, tar -zxvf each tarball, and rebuild from scratch. Below
are the directives I am using to build apache, in order:

cd mod_ssl-2.8.10-1.3.26
./configure --with-apache=../apache_1.3.26

cd ../apache_1.3.26
./configure --prefix=/usr/local/apache

cd ../php-4.2.3
./configure --with-apache=/usr/local/src/apache_1.3.26 \
--disable-magic-quotes \
--disable-short-tags \
--disable-debug \
--without-gd \
--enable-url-fopen-wrapper \
--enable-track-vars \
--enable-memory-limit \
--enable-inline-optimization \
--with-config-file-path=/usr/local/php/ini \
--with-mysql \
--enable-ftp \
--enable-sockets \
--enable-xml \
--enable-wddx \
--enable-bcmath \
--with-zlib=/usr \
--with-snmp \
--enable-ucd-snmp-hack \
--with-openssl \
--with-xmlrpc

make -j15
make install

cd ../apache_1.3.26

./configure --prefix=/usr/local/apache \
--enable-module=ssl \
--activate-module=src/modules/php4/libphp4.a \
--enable-module=rewrite \
--enable-module=proxy \
--enable-module=so

make
make install


Previous Comments:


[2002-10-02 20:59:12] [EMAIL PROTECTED]

Please do a clean build of Apache next time.
You should do 'make clean' in the apache sources at least,
better yet, get fresh sources and do the build from scratch.




[2002-10-02 20:09:41] [EMAIL PROTECTED]

I have MySQL 4.0.4-beta installed. I configured php as follows:

 './configure' '--with-apache=/usr/local/src/apache_1.3.26'
'--disable-magic-quotes' '--disable-short-tags' '--disable-debug'
'--without-gd' '--enable-url-fopen-wrapper' '--enable-track-vars'
'--enable-memory-limit' '--enable-inline-optimization'
'--with-config-file-path=/usr/local/php/ini' '--with-mysql=/usr/local'
'--enable-ftp' '--enable-sockets' '--enable-xml' '--enable-wddx'
'--enable-bcmath' '--with-zlib=/usr' '--with-snmp'
'--enable-ucd-snmp-hack' '--with-openssl' '--with-xmlrpc'

the php binary reports:

mysql
MySQL Support enabled
Active Persistent Links 0
Active Links 0
Client API version 4.0.4-beta

apache (mod_php installed) reports:

mysql
MySQL Support enabled
Active Persistent Links 0
Active Links 0
Client API version 3.23.35




-- 
Edit this bug report at http://bugs.php.net/?id=19730edit=1

Bug #15828 Updated: Trim() leaving 1 begining/ending whitespace

2002-03-02 Thread shane . hcohstetler 

 ID:   15828
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Output Control
 Operating System: WindowsXP Pro
 PHP Version:  4.1.1
 New Comment:

This is using php4isapi.dll

$var = '   content   ';
$var = trim($var);  // fixed TYPO..
echo -.$var.-;
echo -$var-;

Output:
 - content -
 - content -

leaves 1 whitespace at the beginning and at the end.


and I have RTFM!!!


Previous Comments:


[2002-03-02 05:27:59] [EMAIL PROTECTED]

RTFM! trim() returns the trimmed string.
$foo = trim($foo) and not trim($foo)



[2002-03-02 03:09:45] [EMAIL PROTECTED]

This is using php4isapi.dll

$var = '   content   ';
trim($var);
echo -.$var.-;
echo -$var-;

Output:
 - content -
 - content -

leaves 1 whitespace at the beginning and at the end.






-- 
Edit this bug report at http://bugs.php.net/?id=15828edit=1

Bug #15828: Trim() leaving 1 begining/ending whitespace

2002-03-01 Thread shane . hochstetler 

From: [EMAIL PROTECTED]
Operating system: WindowsXP Pro 
PHP version:  4.1.1
PHP Bug Type: Output Control
Bug description:  Trim() leaving 1 begining/ending whitespace

This is using php4isapi.dll

$var = '   content   ';
trim($var);
echo -.$var.-;
echo -$var-;

Output:
 - content -
 - content -

leaves 1 whitespace at the beginning and at the end.


-- 
Edit bug report at http://bugs.php.net/?id=15828edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=15828r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15828r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=15828r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15828r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15828r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15828r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15828r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15828r=submittedtwice

Bug #14883 Updated: Remote vulnerability allows access to ALL files on webserver

2002-02-28 Thread shane 

 ID:   14883
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Other web server
 Operating System: Windows NT (all Win32)
 PHP Version:  4.1.1
 New Comment:

It's still not a full solution.  PHP is going out by default with a big
hole, and most users will not read that part of the docs to figure out
that PHP CGI has that hole.  The patch I've now submitted turns on
FORCE_REDIRECT by default, but it can be turned off (IIS for example
needs it off) in the php.ini file.


Previous Comments:


[2002-02-28 20:53:54] [EMAIL PROTECTED]

Shane has already commited the fix to CVS :)



[2002-02-28 20:32:12] [EMAIL PROTECTED]

I just would like to make sure if document in source is ok also.
Could anyone check it?

And I would like to open this report since [EMAIL PROTECTED] is
willing
to write patch for this :)

Could you change Category to Apache problem after checking doc in
source?



[2002-02-28 20:04:08] [EMAIL PROTECTED]

Not a doc prob...RTFM

http://www.php.net/manual/en/security.cgi-bin.php




[2002-02-28 19:59:34] [EMAIL PROTECTED]

The problem can be avoided by setting doc_root in php.ini.  Meanwhile,
I've submitted a quick patch to cvs.  Working right now on a full
patch.
Shane



[2002-02-28 19:54:24] [EMAIL PROTECTED]

I think document is updated so that users can set up Apache corretly,
right?
(Not yet?)



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/14883

-- 
Edit this bug report at http://bugs.php.net/?id=14883edit=1