date:20030204

#22057 [Bgs->Fbk]: fgets function failure

2003-02-04 Thread wez

 ID:  22057
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
-Status:  Bogus
+Status:  Feedback
 Bug Type:Filesystem function related
 PHP Version: 4.3.0
 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.


"response:"fbc" or something similar."

How about a real error report?
If you can't be bothered to spend the time to give us
precise details, why should we sit here guessing what
your problem is?

Are you sure that your web server isn't sending back data using the
chunked transfer encoding? (read the specs for HTTP 1.1!).

If your code doesn't handle chunked encoding, use HTTP 1.0 instead.

If you are *absolutely* 100% sure that your script isn't broken as far
as HTTP is concerned, how about giving us more details on the remote
server?  Is it something we can access so that we can see the same
problem?

Don't start complaining to us about how nicely you have been treated;
so far you have wasted 2 peoples time with insufficient data.  Please
don't waste mine as well.



Previous Comments:


[2003-02-05 01:25:00] [EMAIL PROTECTED]

I am well aware of what manual states and how the function works. You
are
saying you get same results from both versions. Which configuration of
server settings you use? Did you try all, so you can be so sure?

I use Apache 1.3.27 on Windows and upgraded from PHP 4.2.3 to 4.3.0
recently
by keeping all settings same and this problem occurred.  How would you
explain same function code returns two different responses in
different
versions?



Server: Apache/1.3.27 (Win32) PHP/4.3.0

PHP 4.3.0

response:"fbc" or something similar.

PHP 4.2.3

response:"HTTP/1.1 200 OK"



And also this doesn't happen for all websites I tried. It seems the
function
is having some serious problem with certain server configurations.
This
wasn't the case for 4.2.3.

I hope you are not approaching all bug reports as you did to mine.
Maybe I
should have mentioned my server but still you are approaching with a
prejudice of dealing with a dummy user rather than trying to make sure
the
function works with all platform and distribution versions. You could
have
asked more details rather than putting it into a "dummy user wandering
in
bug pages" case from the first reply.



[2003-02-04 16:17:54] [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.

The manual clearly states that no more then 1 line will be read by
fgets() function. This is not something new, the old code worked in the
exact same manner.
In my tests the outputs of PHP 4.2.3 & 4.3.0 are identical:
PHP 4.2.3
string(17) "HTTP/1.1 200 OK
"

PHP 4.3.0
string(17) "HTTP/1.1 200 OK
"




[2003-02-04 16:13:43] [EMAIL PROTECTED]

What error? And please give us a complete (but short!) example
script..




[2003-02-04 15:59:22] [EMAIL PROTECTED]

PHP manual doesn't tell why this function start to give an error in
version 4.3 while working fine with 4.2.x.

I also tried less efficient ways of getting http headers just for test
purposes and such 3-character long string never appears. That
inefficient method returns same string fgets in 4.2.3 used to return.
PHP manual says the function was modified regarding a fix about
binaries. does that affect the result?

As I say it is not about HTTP or server settings. Same code is not
working with 4.3 although it worked fine with 4.2.3. 

Sorry but your answer doesn't help to explain why this error happened
after upgrading to 4.3 while keeping all server and configuration
settings same.



[2003-02-04 15:39:24] [EMAIL PROTECTED]

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

fgets() will only return a single line of data or the requested number
of bytes, which ever one is smallest will be returned. In case of HTTP,
the 1st line that will be sent to you by the webserver will be the
response code, which in many cases is just a number 3 by

#22057 [Bgs]: fgets function failure

2003-02-04 Thread elazizli

 ID:  22057
 User updated by: [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
 Status:  Bogus
 Bug Type:Filesystem function related
 PHP Version: 4.3.0
 New Comment:

I am well aware of what manual states and how the function works. You
are
saying you get same results from both versions. Which configuration of
server settings you use? Did you try all, so you can be so sure?

I use Apache 1.3.27 on Windows and upgraded from PHP 4.2.3 to 4.3.0
recently
by keeping all settings same and this problem occurred.  How would you
explain same function code returns two different responses in
different
versions?



Server: Apache/1.3.27 (Win32) PHP/4.3.0

PHP 4.3.0

response:"fbc" or something similar.

PHP 4.2.3

response:"HTTP/1.1 200 OK"



And also this doesn't happen for all websites I tried. It seems the
function
is having some serious problem with certain server configurations.
This
wasn't the case for 4.2.3.

I hope you are not approaching all bug reports as you did to mine.
Maybe I
should have mentioned my server but still you are approaching with a
prejudice of dealing with a dummy user rather than trying to make sure
the
function works with all platform and distribution versions. You could
have
asked more details rather than putting it into a "dummy user wandering
in
bug pages" case from the first reply.


Previous Comments:


[2003-02-04 16:17:54] [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.

The manual clearly states that no more then 1 line will be read by
fgets() function. This is not something new, the old code worked in the
exact same manner.
In my tests the outputs of PHP 4.2.3 & 4.3.0 are identical:
PHP 4.2.3
string(17) "HTTP/1.1 200 OK
"

PHP 4.3.0
string(17) "HTTP/1.1 200 OK
"




[2003-02-04 16:13:43] [EMAIL PROTECTED]

What error? And please give us a complete (but short!) example
script..




[2003-02-04 15:59:22] [EMAIL PROTECTED]

PHP manual doesn't tell why this function start to give an error in
version 4.3 while working fine with 4.2.x.

I also tried less efficient ways of getting http headers just for test
purposes and such 3-character long string never appears. That
inefficient method returns same string fgets in 4.2.3 used to return.
PHP manual says the function was modified regarding a fix about
binaries. does that affect the result?

As I say it is not about HTTP or server settings. Same code is not
working with 4.3 although it worked fine with 4.2.3. 

Sorry but your answer doesn't help to explain why this error happened
after upgrading to 4.3 while keeping all server and configuration
settings same.



[2003-02-04 15:39:24] [EMAIL PROTECTED]

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

fgets() will only return a single line of data or the requested number
of bytes, which ever one is smallest will be returned. In case of HTTP,
the 1st line that will be sent to you by the webserver will be the
response code, which in many cases is just a number 3 bytes long.



[2003-02-04 15:29:19] [EMAIL PROTECTED]

The following code used to return correct  headers for the requested
page whit PHP 4.2.3.. $host, $port and $path variables are dynamically
assigned by the script.
Now it doesn't work without any configuration change other than PHP
upgrade. It returns a three-character string instead of the requested
information. Is this because of the change applied to fgets function in
PHP 4.3? Same code stopped working when migrated to 4.3 from 4.2.3, no
module or configuration change happened during upgrade, same settings
were kept.



$fp = fsockopen($host,$port);

$request =
"GET $path HTTP/1.1
Host: $host$port
Accept: */*
Accept-Charset: iso-8859-1
Accept-Encoding: identity

";
fputs($fp,$request);
$answer = fgets($fp,4096);





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

#20014 [Opn]: SSL w/ fsockopen not working

2003-02-04 Thread k . schroeder

 ID:   20014
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Sockets related
 Operating System: windows 2000
-PHP Version:  4CVS-2002-10-21
+PHP Version:  4CVS-2003-02-05
 New Comment:

This is reproducable with latest php4-win32 snap, latest php4 source
snap works on Linux:

Relevant parts from phpinfo():
Registered PHP Streams => php, http, ftp, compress.zlib
OpenSSL support => enabled
OpenSSL Version => OpenSSL 0.9.6g 9 Aug 2002

test:
--TEST--
Bug #20014 SSL w/ fsockopen not working
--SKIPIF--

--FILE--

--EXPECT--
resource(4) of type (stream)


 EXPECTED OUTPUT
resource(4) of type (stream)
 ACTUAL OUTPUT
Warning: fsockopen() [/phpmanual/function.fsockopen.html]: no SSL
support in this build in D:\work\php4\ext\openssl\tests\bug20014.php on
line 2

Warning: fsockopen() [/phpmanual/function.fsockopen.html]: unable to
connect to www.openssl.org:443 in
D:\work\php4\ext\openssl\tests\bug20014.php on line 2
bool(false)
 FAILED


Previous Comments:


[2002-10-21 15:24:24] [EMAIL PROTECTED]

Looks like main/config.w32.h.in needs to
#define HAVE_OPENSSL_EXT 1

I'm unable to test this ATM, so I'm hoping that some other kind win32
developer can look into it.



[2002-10-21 15:17:27] [EMAIL PROTECTED]

Environment: W2K/IIS5/php 4.3.0-dev (win32 snapshot 10/21, 7:25), CGI

Reproduce w/:

$fp = fsockopen('ssl://secure.hostname.here',$port);

Error:

"Warning: fsockopen() [function.fsockopen]: no SSL support in this
build in E:\test\fsockopen_ssl.php"

phpinfo() shows OpenSSL is available. I tested the openssl funcs to
confirm availability. All DLLs are copied to system32 dir.




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

#22064 [NEW]: mb_send_mail hard-coded to send text/plain

2003-02-04 Thread jc

From: [EMAIL PROTECTED]
Operating system: Red Hat Linux 7.2
PHP version:  4.3.0
PHP Bug Type: mbstring related
Bug description:  mb_send_mail hard-coded to send text/plain

Feature request:

Currently mb_send_mail() is hard-coded to send a Content-type of
text/plain. Would it be possible to add a way to change this (being able
to set it to text/html would be very useful).

Either a parameter to mb_send_email or a function such as
mb_send_mail_set_content_type(string)?

Thanks!

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

#22047 [Com]: PHP pollutes the namespace w/ (what looks like) its grammar tokens

2003-02-04 Thread chrala

 ID:   22047
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Wont fix
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

> A notice is fine,

redefinition of a constant being only a NOTICE?  
you can't be serious!


Previous Comments:


[2003-02-05 00:49:18] [EMAIL PROTECTED]

How's changing a NOTICE into a WARNING going to break
anything, anyway?

diff -ur a/Zend/zend_constants.c b/Zend/zend_constants.c
--- a/Zend/zend_constants.c 2002-10-09 16:17:53.0 +0200
+++ b/Zend/zend_constants.c 2003-02-05 07:46:35.0 +0100
@@ -265,7 +265,7 @@
if (!(c->flags & CONST_PERSISTENT)) {
zval_dtor(&c->value);
}
-   zend_error(E_NOTICE,"Constant %s already defined",
lowercase_name);
+   zend_error(E_WARNING, "Constant %s already defined",
lowercase_name);
ret = FAILURE;
}
free_alloca(lowercase_name);



[2003-02-04 12:46:48] [EMAIL PROTECTED]

Guys, if this is how you deal with backwards
compatibility issues, then I'm scared.

I've been maintaining a big PHP project that's about
1MB of very clean code and I need to keep it alive.
This particular bug gave me quite a bit of a headache.
I've provided valid arguments on why a (trivial) change
should be made, and you seem to not really care.  That's
not giving me nice prospects into the future, is it?

Come on, we're talking about constants here!
If a constant is redefined by a program, then
that program is broken by definition and needs
to be told on an appropriate level.



[2003-02-04 12:31:13] [EMAIL PROTECTED]

It's fine as it is -> wont fix.



[2003-02-04 11:48:17] [EMAIL PROTECTED]

A NOTICE definitely is NOT sufficient.

Remember many setups running older PHP software set
"error_reporting = E_ALL & ~E_NOTICE", because the
amount of notices on undefined array indices and
undefined variables can be quite overwhelming --
and it is precisely these setups that are likely
to be bitten by this problem.

Redefinition of a constant should be a WARNING,
I must insist.



[2003-02-04 10:27:54] [EMAIL PROTECTED]

A notice is fine, we're not going to change this as it might break
scripts out there.



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

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

#20302 [Fbk->NoF]: Leaked Descriptors

2003-02-04 Thread php-bugs

 ID:   20302
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.4.18
 PHP Version:  4.2.2
 New Comment:

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".


Previous Comments:


[2003-01-20 21:54:41] [EMAIL PROTECTED]

Could you please check this with using PHP 4.3.0 and Apache 1.3.27 if
it's any better? Also, PHP 4.3.0 builds a CLI binary always, it would
be nice to know also if that has
the same leaks..(you don't have to _install_ php to do that? :)




[2002-12-08 11:11:59] [EMAIL PROTECTED]

>It would be nice if you could give an exact 
>description of what descriptors are open for you. 

The main problem is with apache 2.x. The listing is huge. There are 2
descriptors per website on the machine + main error log + main access
log just being leaked by mod_cgi. When testing mod_php, I found 3
additional descriptors being leaked. I guess I incorrectly assumed that
this was a php problem. If php does not police or cleanup the
environment that php applications run under, then I guess this bug
report can be closed. I will also make the apache team aware of this
issue, too. My feelings are that apache 2.x really has some problems.

If you are curious about the leaked descriptors, visit :
http://www.web-insights.net/env_audit  The env_audit program has full
description and ready to use php script for testing this. There is also
a 50 page report that can be downloaded from that page that gives more
detail than I can list here.

>BTW: The opened script fd can be leaked without 
>any security impact.

Maybe and maybe not. If a hole is found in php, people could use this
to overwrite a page making a temporary security problem more permanent.
To do this requires first finding another exploit, then you might be
able to use this for more mischief. Unless there's a compelling reason
not to do so, I would close the fd or set the FD_CLOEXEC flag. My
testing calls a program external to PHP using the passthru() function.
This external program should not have access to PHP files.

So, I leave it to your team. I won't object to closing this bug report
if you feel the issue truly lies with apache 2.x. Thanks for looking at
it.



[2002-12-05 13:09:27] [EMAIL PROTECTED]

It would be nice if you could give an exact description of what
descriptors are open for you. Like a directory listing
...
ls -la /proc/pidofapache/fd

BTW: The opened script fd can be leaked without any security impact.

And it is an apache bug that the fds are leaked. PHP does no
accept (its the apache child that accepts). And mysql etc... sockets
are opened by the mysqlclient libs... these are responsible for setting
the close on exec flag, not PHP.





[2002-12-05 07:27:02] [EMAIL PROTECTED]

I got the e-mail stating to try the latest tarball. I downloaded it and
grep'ed around. I am not sure how to build a rpm of php that is 100%
compatible with RedHat 8.0. The e-mail back was terse and didn't say
the problem was replicated or fixed. The tarball has no CHANGELOG.
Grep'ing did not show FD_CLOEXEC. 

Since I am not sure about building a rpm and I cannot find what the fix
was, how am I to provide feedback? Was the problem replicated? Did your
testing show its now fixed? What files were changed? Are there diffs of
the affected code?



[2002-12-04 18:16:22] [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.





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

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

#22047 [Com]: PHP pollutes the namespace w/ (what looks like) its grammar tokens

2003-02-04 Thread szepe

 ID:   22047
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Wont fix
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

How's changing a NOTICE into a WARNING going to break
anything, anyway?

diff -ur a/Zend/zend_constants.c b/Zend/zend_constants.c
--- a/Zend/zend_constants.c 2002-10-09 16:17:53.0 +0200
+++ b/Zend/zend_constants.c 2003-02-05 07:46:35.0 +0100
@@ -265,7 +265,7 @@
if (!(c->flags & CONST_PERSISTENT)) {
zval_dtor(&c->value);
}
-   zend_error(E_NOTICE,"Constant %s already defined",
lowercase_name);
+   zend_error(E_WARNING, "Constant %s already defined",
lowercase_name);
ret = FAILURE;
}
free_alloca(lowercase_name);


Previous Comments:


[2003-02-04 12:46:48] [EMAIL PROTECTED]

Guys, if this is how you deal with backwards
compatibility issues, then I'm scared.

I've been maintaining a big PHP project that's about
1MB of very clean code and I need to keep it alive.
This particular bug gave me quite a bit of a headache.
I've provided valid arguments on why a (trivial) change
should be made, and you seem to not really care.  That's
not giving me nice prospects into the future, is it?

Come on, we're talking about constants here!
If a constant is redefined by a program, then
that program is broken by definition and needs
to be told on an appropriate level.



[2003-02-04 12:31:13] [EMAIL PROTECTED]

It's fine as it is -> wont fix.



[2003-02-04 11:48:17] [EMAIL PROTECTED]

A NOTICE definitely is NOT sufficient.

Remember many setups running older PHP software set
"error_reporting = E_ALL & ~E_NOTICE", because the
amount of notices on undefined array indices and
undefined variables can be quite overwhelming --
and it is precisely these setups that are likely
to be bitten by this problem.

Redefinition of a constant should be a WARNING,
I must insist.



[2003-02-04 10:27:54] [EMAIL PROTECTED]

A notice is fine, we're not going to change this as it might break
scripts out there.



[2003-02-04 10:20:52] [EMAIL PROTECTED]

Good, thanks.

Let me clarify -

PHP does log a NOTICE such as

[04-Feb-2003 17:18:22] PHP Notice:
  Constant T_LIST already defined
  in x.php on line 3

but this definitely needs to be a WARNING
or even an ERROR.

-Tomas



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

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

#22041 [Fbk->Opn]: mb_substr produces "mojibake" on certain strings ...

2003-02-04 Thread jc

ID: 22041
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: mbstring related
Operating System: Red Hat Linux 7.2
PHP Version: 4.3.0
New Comment:

Glad you could see the funny side of this bug report :) I did try very
hard to find a better example ... but couldn't get mb_substr to break
on anything else.

Why set internal encoding to eucJP-win? The data is from a database and
is in EUC-JP ...

When I entered the data into the DB if the were any illegal EUC-JP
characters it should have complained ...

And as you can see I can display the whole string as EUC-JP perfectly.
It's only *after* I use mb_substr() that the string becomes mojibake
...

Thanks!

Previous Comments:

[2003-02-04 07:36:19] [EMAIL PROTECTED]

LOL! It's indeed so OFFENSIVE I have no idea how to translate those
words to English. But perhaps you know what that means?

Ehm, first try setting the internal encoding to "eucJP-win".

[2003-02-04 05:28:48] [EMAIL PROTECTED]

First, sorry for any offensive japanese words. I can't read/write
japanese very well, and the error in mb_substr occurs on data from a
list of video titles ... I tried to find another less offensive example
but couldn't. I'm just posting this bug report in order to help ...

I am trying to use mb_substr on data I get from a postgreSQL DB and in
some cases mb_substr seems to cut the string in the middle of a
multibyte char .. which turns the "cut" char into mojibake ...

The DB is in EUC-JP and my internal encoding is set to EUC-JP in my
php.ini file ...

As you can see the last character of the string has been improperly cut
...

Here is my test program and output:

CODE:

substr;

echo "String: ";
echo $c ."";

$c = mb_substr($c, 0, 80);

echo " After cutting it ... ";
echo $c ."";
?>

OUPUT:

AFTER cutting it ...
¥¢¥ó¥°¥ë¤Î¡ÖÄ¶-¸Ô´Ö¤Î¥¢¥ó¥°¥ë¡×¥·¥ê¡¼¥º£Ä£Ø¡¢Â³¡¹ÅÐ¾ì¡ª¤¿¤À¤ÎºÆÊÔ¤â¤Î¤Ç¤Ï¤¢¤ê¤Þ�

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

#22038 [Fbk->Ctl]: array() doesn't work right

2003-02-04 Thread k . schroeder

 ID:   22038
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Critical
 Bug Type: Zend Engine 2 problem
 Operating System: Windows 2000 Server
 PHP Version:  5CVS-2003-02-03 (dev)


Previous Comments:


[2003-02-04 01:42:27] [EMAIL PROTECTED]

I've tested with latestet php4-win32 snap and latestest source snaps of
PHP4 and PHP5 on Linux. All these tests works, it's only a problem with
PHP5 + Win. Critical in my eyes because /run-tests.php doesn't work and
array's are important.



[2003-02-04 00:33:23] [EMAIL PROTECTED]

s/intentionally/intensively/



[2003-02-04 00:31:24] [EMAIL PROTECTED]

Did you try one of the branch version (ZE1)?
And I suppose we have to look into the problem more intentionally
before marking this as critical.




[2003-02-03 18:04:07] [EMAIL PROTECTED]

Looks like an windows only problem. It works on Linux with latest
source snap. Please verify on other operating systems.



[2003-02-03 17:53:18] [EMAIL PROTECTED]

/run-tests.php doesn't work with latest php5-win32 snap on W2kserver.
Every second array value get an array key.

declaration (line 141):
$ini_overwrites = array(
'output_handler=',
'zlib.output_compression=Off',
'open_basedir=',
'safe_mode=0',
'disable_functions=',
'output_buffering=Off',
'error_reporting=2047',
'display_errors=1',
'log_errors=0',
'html_errors=0',
'track_errors=1',
'report_memleaks=1',
'report_zend_debug=0',
'docref_root=/phpmanual/',
'docref_ext=.html',
'error_prepend_string=',
'error_append_string=',
'auto_prepend_file=',
'auto_append_file=',
'magic_quotes_runtime=0',
);

var_dump($settings); (added on line 794):
array(11) {
  [""]=>
  string(15) "output_handler="
  ["zlib.output_compression=Off"]=>
  string(13) "open_basedir="
  ["safe_mode=0"]=>
  string(18) "disable_functions="
  ["output_buffering=Off"]=>
  string(20) "error_reporting=2047"
  ["display_errors=1"]=>
  string(12) "log_errors=0"
  ["html_errors=0"]=>
  string(14) "track_errors=1"
  ["report_memleaks=1"]=>
  string(19) "report_zend_debug=0"
  ["docref_root=/phpmanual/"]=>
  string(16) "docref_ext=.html"
  ["error_prepend_string="]=>
  string(20) "error_append_string="
  ["auto_prepend_file="]=>
  string(17) "auto_append_file="
  ["magic_quotes_runtime=0"]=>
  &array(1) {
["magic_quotes_runtime=0"]=>
&array(1) {
  ["magic_quotes_runtime=0"]=>
  *RECURSION*
}
  }
}




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

#18648 [Com]: Single entry form POST gives incorrect variable content

2003-02-04 Thread laday

 ID:   18648
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache2 related
 Operating System: All
 PHP Version:  5CVS-2003-01-29 (dev) / 4CVS-20020121 (stable)
 New Comment:

Thanks... It works ok.


Previous Comments:


[2003-02-04 15:05:45] [EMAIL PROTECTED]

[To anyone who experiences this trouble]

Are you sure that your httpd.conf has just A SINGLE KIND OF PHP RELATED
DIRECTIVE?

Then try grep "\(OutputFilter\|InputFilter\|AddType\)" < httpd.conf or
whatsoever.

# bad example (a)
AddInputFilter PHP php
AddOutputFilter PHP php

...

AddType x-httpd-php .php

# bad example (b)
SetInputFilter PHP
SetOutputFilter PHP

...

AddType x-httpd-php .php

# not bad (c)
AddInputFilter PHP php
AddOutputFilter PHP php

# good (d)
AddType x-httpd-php .php




[2003-02-04 09:16:42] [EMAIL PROTECTED]

Tested in RH8.0 + PHP 4.2.2 + Apache 2.

- Is ok when you add the 'enctype="multipart/form-data"' propety to the
form tag.
- Is ok when you send using GET method instead POST.
- Is ok when you send more than one field: if you have a text and a
button, if you send it pressing enter only the text send and the
problem occurs. When you press the button, text and button are send and
the problem not occur.
ciao.



[2003-02-03 12:36:09] [EMAIL PROTECTED]

I can _NOT_ reproduce this with Apache 2.0.44 and PHP 4.3.1-dev..




[2003-02-03 11:55:47] [EMAIL PROTECTED]

array(4) {
  [0]=>
  string(1) "1"
  [1]=>
  string(1) "2"
  [2]=>
  string(1) "1"
  [3]=>
  string(1) "2"
}

>From the latest snap's (php4-STABLE, php5). cvs commit (?) :)



[2003-01-31 19:52:37] [EMAIL PROTECTED]

Have Apache/2.0.44 (RedHat8.0 (LastUpdates) mod_ssl/2.0.44
OpenSSL/0.9.6b PHP/4.3.0

Starting Apache answers - 
[root@delta bin]# httpd -DSSL
httpd: module "/usr/src/php-4.3.0/sapi/apache2filter/sapi_apache2.c" is
not comp
atible with this version of Apache.
Please contact the vendor for the correct version.

Where troubles ?



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

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

#21262 [Fbk->Csd]: crash or fail when outputting large amounts of text quickly

2003-02-04 Thread spagmoid

 ID:   21262
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: Performance problem
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

We have heard of unrelated issues with SP1, and with M$ there's no
going back.  We will upgrade eventually, but I will accept this as
resolved since others have reported this fix.  Thanks to gmeakin!


Previous Comments:


[2003-02-04 05:19:20] [EMAIL PROTECTED]

Why can't you install that SP1??
Others reported it fixes this issue, so..




[2003-02-03 22:45:20] [EMAIL PROTECTED]

I can't install SP1 here, but I wouldn't be surprised.

This does counter iliaa's "by design" theory.



[2003-02-03 11:32:57] [EMAIL PROTECTED]

[Update]
Just to confirm further after many more hours of use that installing
Micrsoft's WinXP Service Pack-1 has fixed this bug for me.



[2003-01-29 00:06:12] [EMAIL PROTECTED]

Does the solution provided by [EMAIL PROTECTED] 
fix the problem for you..?





[2003-01-28 13:27:42] [EMAIL PROTECTED]

I have managed to solve my problem with outputting large amounts of
data under WinXP Home Edition, PHP 4.3.0 and Apache 2.0.44. 

I experienced this problem consistently with a php page that I had
written. I installed Windows XP Service Pack-1 from Microsoft and it
fixed the problem straight away. To convince myself further I tried the
php script listed at the beginning of this bug thread which I
previously experienced the same problem. This also works with the
service pack installed.

It looks like a bug on Microsoft's side of the fence. Try installing
the service pack for yourself and email this thread with your results
as it worked for me.

Good luck.
Regards



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

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

1 2 >

1 - 100 of 124 matches

Mail list logo