[PHP-DOC] #27583 [Com]: Not enough info on Apache 2 issues
ID: 27583 Comment by: rick at alpinenetworking dot com Reported By: stewart dot james at vu dot edu dot au Status: Open Bug Type: Documentation problem Operating System: Any PHP Version: Irrelevant New Comment: I for one would much prefer to use php on apache 2. One of the main reasons for this is that just about every linux distro known to man won't install apache 1.3 for me anymore. I have to manually install it and manually do all of the updates or look to a 3rd party to get package files for whatever distro I happen to be installing on. It would be much nicer if I could just use the version of apache that came with the distro and use the standard update tools to do security/version updates. It seems like there is no really good reason not to except "well it's no better and nobody really wants it." I'll bet that a lot more people would start running php on apache2 once it became stable. Is there anyway to make it so that php will only run on the prefork MPM so that you can at least say that php is stable under those conditions? It seems like that would satisfy the people who want to use php on apache 2 but not force you to deal with the thread safety issues for now. Previous Comments: [2004-03-14 18:27:52] stewart dot james at vu dot edu dot au Reading the first comment your probably right the chicken itself is fine just some of the feathers need fixing (e.g. some extentions abnd their libs being the issue not core PHP) - at least thats just info from reading the first reponse to this bug report. Thanks for the tip on subversion. Will look into that this week. [2004-03-14 12:33:07] [EMAIL PROTECTED] I suppose it is a bit of a chicken and egg situation with the one exception that we have a nicely working chicken already. Also note that you do not need Apache2 for SubVersion. You can use the standalone svnserve instead. See http://lxnt.info:/book/book.html#svn-ch-5-sect-4.2 [2004-03-14 02:19:46] stewart dot james at vu dot edu dot au Ahhh enlightenment :) That gives me alot of info as to the issues with apache2 and php and why php is considered bad. Added to that the PHP group seem to be facing a chicken and the egg scenario. Alot of sites probably will not shift to PHP (I know my servers won't be) until php is considered safe for apache2. So I guess in large respects apache2 could stay fringe for php deployments. My...recent eagerness...to see apache2 and php in production started with subversion being released..among other things. Seems to be a real chicken and egg scenario the php group is faced with. apache2 is fringe. Once apache2 has a higher market share, then more people will probably code and get php to work well with apache2. But considering the popularit of apache2+php, apache2 probably won;t increase market share significantly until either php and apache2 are considered safe for a production environment or apache1.3 is dropped by the apache group. Anyway back to this bug report. Much of what was said in the previous post gave me sufficient information to give me enlightenment. I am sure it would for others as well. Perhaps that could be included in the docs? Cheers - and thanks for the enlightening, Stewart [2004-03-13 18:26:12] [EMAIL PROTECTED] We are not talking about just Apache2 here. We are talking about Apache2+an MPM+PHP+3rd Party Libs. The folks at apache.org are only concerned with Apache2 itself, and for serving up static files it is better than Apache1 in many respects. However we have to worry about a lot more stuff here. In fact, we couldn't care less about serving up static files. The main issues as I see them are: 1. Thread safety issues. - It is very difficult to track down threading problems and we don't have decent tools to help us. - The thread safety of many 3rd party libraries are unknown quantities and can depend on the OS, libc and even compile flags. - Many distributions seem to ship with the Worker MPM as the default and that is the MPM that gets the most attention. This is a hybrid multi-process, multi-threaded MPM. 2. You can eliminate the threading problem by running the prefork MPM which effectively makes Apache2 behave just like Apache1 in the way it forks processes and serves one request at a time per process. Issues here: - Apache2 itself is rather fringe still. It has approximately a 5% marketshare vs. 65% for Apache1 at the time of this and out of that I would guess the majority are running the Worker MPM. So we are talking about a fringe MPM in a fringe server. This means it has not had anywhere near the attention from people
Re: [PHP-DOC] Greek fonts don't display correctly
On Thu, 18 Mar 2004, Gabor Hojtsy wrote: > > Congratulations for this work, in Greek > > > > A small problem. As you see on the left pane / index tab, the greek > > fonts don't display correctly > > (while on the right pane is OK). > > This is also a common problem we experienced with Chinese text. We don't > know how to fix it yet... Just want to say that the Left "Contents" plane looks fine to me, it's *just* the Index tab that is broken. If anybody know how to fix it... please let me know. regards, Derick
[PHP-DOC] Re: Details [#166654]
Dear Napster member: We have received your support request and are currently reviewing it. We strive to reply to all help requests within 24 to 48 hours. A Napster Customer Support representative will be in contact with you shortly regarding your issue. For immediate assistance, please visit our FAQ's and User Guide located within the "Help" section of Napster 2.0. We appreciate your business and thank you for making Napster your choice for quality digital music. Best regards, Napster Customer Support - [EMAIL PROTECTED] Wrote - Please read the attached file.
Re: [PHP-DOC] Greek fonts don't display correctly
Hi! Congratulations for this work, in Greek A small problem. As you see on the left pane / index tab, the greek fonts don't display correctly (while on the right pane is OK). Any suggestions? P.S. Some of my friends have also similar problem) This is also a common problem we experienced with Chinese text. We don't know how to fix it yet... Goba
[PHP-DOC] #27635 [Opn->Csd]: Bad german translation concerning $_SERVER['REMOTE_ADDR']
ID: 27635
Updated by: [EMAIL PROTECTED]
Reported By: pubtom at bigfoot dot com
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: N/A
PHP Version: Irrelevant
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2004-03-18 11:35:32] pubtom at bigfoot dot com
Description:
This is about the german translation of the description of the
predefined variable $_SERVER['REMOTE_ADDR']
Documentation: English original:
http://www.php.net/manual/en/reserved.variables.php
'REMOTE_ADDR'
The IP address from which the user is viewing the current page.
This is partly correct. If there is no proxy, it is the IP address of
the user's computer. If there is a proxy, it is the IP address of the
proxy.
German translation:
http://www.php.net/manual/de/reserved.variables.php
'REMOTE_ADDR'
Die IP-Adresse des Servers, von dem die aktuelle Seite geladen
wurde.
The word "Server" seems wrong and confusing to me.
To me, the words "server" and "client" have the following meaning: On
one side of the internet, there is the user ("client"), on the other
side, there is the webserver with PHP ("server").
Thus, $_SERVER['REMOTE_ADDR'] contains the IP address of the "client".
I suggest the following translation, which also is technically more
precise/correct:
"Die IP-Adresse des Rechners, der die aktuelle Seite angefordert hat."
("The IP address of the computer that requested the current page.")
--
Edit this bug report at http://bugs.php.net/?id=27635&edit=1
[PHP-DOC] #27635 [NEW]: Bad german translation concerning $_SERVER['REMOTE_ADDR']
From: pubtom at bigfoot dot com
Operating system: N/A
PHP version: Irrelevant
PHP Bug Type: Documentation problem
Bug description: Bad german translation concerning $_SERVER['REMOTE_ADDR']
Description:
This is about the german translation of the description of the predefined
variable $_SERVER['REMOTE_ADDR']
Documentation: English original:
http://www.php.net/manual/en/reserved.variables.php
'REMOTE_ADDR'
The IP address from which the user is viewing the current page.
This is partly correct. If there is no proxy, it is the IP address of the
user's computer. If there is a proxy, it is the IP address of the proxy.
German translation:
http://www.php.net/manual/de/reserved.variables.php
'REMOTE_ADDR'
Die IP-Adresse des Servers, von dem die aktuelle Seite geladen wurde.
The word "Server" seems wrong and confusing to me.
To me, the words "server" and "client" have the following meaning: On one
side of the internet, there is the user ("client"), on the other side,
there is the webserver with PHP ("server").
Thus, $_SERVER['REMOTE_ADDR'] contains the IP address of the "client".
I suggest the following translation, which also is technically more
precise/correct:
"Die IP-Adresse des Rechners, der die aktuelle Seite angefordert hat."
("The IP address of the computer that requested the current page.")
--
Edit bug report at http://bugs.php.net/?id=27635&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27635&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27635&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27635&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27635&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27635&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27635&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27635&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27635&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27635&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27635&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27635&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27635&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27635&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27635&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27635&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27635&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27635&r=float
[PHP-DOC] cvs: phpdoc /en/security errors.xml
tony2001Thu Mar 18 10:40:04 2004 EDT Modified files: /phpdoc/en/security errors.xml Log: change roles to "html" http://cvs.php.net/diff.php/phpdoc/en/security/errors.xml?r1=1.3&r2=1.4&ty=u Index: phpdoc/en/security/errors.xml diff -u phpdoc/en/security/errors.xml:1.3 phpdoc/en/security/errors.xml:1.4 --- phpdoc/en/security/errors.xml:1.3 Thu Mar 18 10:12:49 2004 +++ phpdoc/en/security/errors.xml Thu Mar 18 10:40:04 2004 @@ -1,5 +1,5 @@ - + Error Reporting @@ -17,7 +17,7 @@ variables, or modify them: Attacking Variables with a custom HTML page - +
Re: [PHP-DOC] cvs: phpdoc /en/security errors.xml
> Example previous to this in the same file uses &: > > Should I change them both? Yes, please. And I believe their roles should be html. Jakub Vrana
Re: [PHP-DOC] cvs: phpdoc /en/security errors.xml
On Thu, 18 Mar 2004 16:07:43 +0100 (CET) Derick Rethans <[EMAIL PROTECTED]> wrote: > On Thu, 18 Mar 2004, Antony Dovgal wrote: > > > On Thu, 18 Mar 2004 15:53:08 +0100 > > Jakub Vrana <[EMAIL PROTECTED]> wrote: > > > > > Antony Dovgal wrote: > > > > change & to & in example form > > > > - > > > action="attacktarget?errors=Y&showerrors=1&debug=1"> > > > > + > > > > > > Please revert this change. > > > > > > You can use entities inside values of HTML attributes (to e.g. write > > > quote inside it), so & has to be written as &. It's common error > > > ignored by most browsers, but correct is &. > > > > Example previous to this in the same file uses &: > > > > > > Should I change them both? > > Yes please. Done. Thanks & sorry =) --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] || [EMAIL PROTECTED]
[PHP-DOC] cvs: phpdoc /en/security errors.xml
tony2001Thu Mar 18 10:12:52 2004 EDT Modified files: /phpdoc/en/security errors.xml Log: revert previous change and fix 1st example http://cvs.php.net/diff.php/phpdoc/en/security/errors.xml?r1=1.2&r2=1.3&ty=u Index: phpdoc/en/security/errors.xml diff -u phpdoc/en/security/errors.xml:1.2 phpdoc/en/security/errors.xml:1.3 --- phpdoc/en/security/errors.xml:1.2 Thu Mar 18 09:35:12 2004 +++ phpdoc/en/security/errors.xml Thu Mar 18 10:12:49 2004 @@ -1,5 +1,5 @@ - + Error Reporting @@ -19,7 +19,7 @@ Attacking Variables with a custom HTML page
Re: [PHP-DOC] cvs: phpdoc /en/security errors.xml
On Thu, 18 Mar 2004, Antony Dovgal wrote: > On Thu, 18 Mar 2004 15:53:08 +0100 > Jakub Vrana <[EMAIL PROTECTED]> wrote: > > > Antony Dovgal wrote: > > > change & to & in example form > > > - > > > + > > > > Please revert this change. > > > > You can use entities inside values of HTML attributes (to e.g. write > > quote inside it), so & has to be written as &. It's common error > > ignored by most browsers, but correct is &. > > Example previous to this in the same file uses &: > > > Should I change them both? Yes please. Derick
Re: [PHP-DOC] cvs: phpdoc /en/security errors.xml
> Jakub Vrana wrote: > Antony Dovgal wrote: > > change & to & in example form > > - > > + > > Please revert this change. > > You can use entities inside values of HTML attributes (to e.g. write > quote inside it), so & has to be written as &. It's common error > ignored by most browsers, but correct is &. Yes, and if we want to be xhtml compliant someday this is required.
Re: [PHP-DOC] cvs: phpdoc /en/security errors.xml
On Thu, 18 Mar 2004 15:53:08 +0100 Jakub Vrana <[EMAIL PROTECTED]> wrote: > Antony Dovgal wrote: > > change & to & in example form > > - > > + > > Please revert this change. > > You can use entities inside values of HTML attributes (to e.g. write > quote inside it), so & has to be written as &. It's common error > ignored by most browsers, but correct is &. Example previous to this in the same file uses &: Should I change them both? --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] || [EMAIL PROTECTED]
Re: [PHP-DOC] cvs: phpdoc /en/security errors.xml
Antony Dovgal wrote: > change & to & in example form > - > + Please revert this change. You can use entities inside values of HTML attributes (to e.g. write quote inside it), so & has to be written as &. It's common error ignored by most browsers, but correct is &. Jakub Vrana
[PHP-DOC] some_correction _on_PHP_manual
Dear sir/mam,
hello!
This is Pradeep Kumar from India. I felt the PHP manual provided by you,
highly helpful for development. Being a regular user of manual I feel it my
duty
to inform you about any bug I encounter in the manual.
In date() function reference page the first function under the heading
User contributed notes: the first function datecalc($rdate, $j=7) returns
date
with subtracted $j days from $rdate gives wrong output for any $j one less
then
day of the date $rdate (eg. dateecalc('17-04-2004',16 )) or any no of days
more than this.
This is because of a wrong condition check in the code.
The right code with enhanced leap year check is :
//
function datecalc ($rdate, $j=7)
{
$rdate = explode("-",$rdate);
$y = $rdate[0]; $m = $rdate[1]; $d = $rdate[2];
// CHECK LEAP YEAR
if($y%4==0 && ($y%100!=0 || $y%400==0)) { $leap='Y'; }
// MONTH SWITCH: Determines days in previous month $dm
switch ($m) {
case 2: $dm = '31'; break;
case 3: if($leap == 'Y') { $dm = '29'; break; }
else { $dm = '28'; break; }
case 4: $dm = '31'; break;
case 5: $dm = '30'; break;
case 6: $dm = '31'; break;
case 7: $dm = '30'; break;
case 8: $dm = '31'; break;
case 9: $dm = '31'; break;
case 10: $dm = '30'; break;
case 11: $dm = '31'; break;
case 12: $dm = '30'; break;
case 1: $dm = '31'; break;
} // END SWITCH
// SUBTRACT DAYS AND ROLL BACK MONTHS
$rd = $d; $rm = $m; $ry = $y; $rj = $j;
while($rj >= 1) {
if($rd == '1') //Check for first day of month
{
$rm = $rm - 1; //Back one month
$rd = $dm;
//Set day equal to days of previous month
}
else $rd = $rd - 1; //Subtract 1 day
if($rm < 1) //Sets up previous year
{
$ry = $ry - 1; //Subtracts year
$rm = '12';//We know this must be December
$rd = '31';//December has 31 days
}
$rj = $rj - 1; //Subtract 1 iteration
}
// CREATE THE NEW DATE $rdate
$rdate = $ry;
$rdate .= '-';
$rdate .= $rm;
$rdate .= '-';
$rdate .= $rd;
return $rdate;
} // END datecalc()
//
Hope this right code could be helpful for some other programmers like me.
_
Join BharatMatrimony.com.
http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?72 Unmarried? Join
Free.
[PHP-DOC] cvs: phpdoc /en/security errors.xml
tony2001Thu Mar 18 09:35:12 2004 EDT Modified files: /phpdoc/en/security errors.xml Log: change & to & in example form http://cvs.php.net/diff.php/phpdoc/en/security/errors.xml?r1=1.1&r2=1.2&ty=u Index: phpdoc/en/security/errors.xml diff -u phpdoc/en/security/errors.xml:1.1 phpdoc/en/security/errors.xml:1.2 --- phpdoc/en/security/errors.xml:1.1 Mon Jan 26 08:22:25 2004 +++ phpdoc/en/security/errors.xml Thu Mar 18 09:35:12 2004 @@ -1,5 +1,5 @@ - + Error Reporting @@ -46,7 +46,7 @@ Exploiting common debugging variables
[PHP-DOC] cvs: phpdoc /en/chapters install.iplanet.xml
thetaphiThu Mar 18 08:48:21 2004 EDT Modified files: /phpdoc/en/chapters install.iplanet.xml Log: hint to raise stacksize (bug #27231) http://cvs.php.net/diff.php/phpdoc/en/chapters/install.iplanet.xml?r1=1.14&r2=1.15&ty=u Index: phpdoc/en/chapters/install.iplanet.xml diff -u phpdoc/en/chapters/install.iplanet.xml:1.14 phpdoc/en/chapters/install.iplanet.xml:1.15 --- phpdoc/en/chapters/install.iplanet.xml:1.14 Wed Feb 18 12:15:18 2004 +++ phpdoc/en/chapters/install.iplanet.xml Thu Mar 18 08:48:20 2004 @@ -1,5 +1,5 @@ - + Servers-Netscape, iPlanet and SunONE @@ -216,6 +216,13 @@ + + + The stacksize that PHP uses depends on the configuration of the webserver. If you get + crashes with very large PHP scripts, it is recommended to raise it with the Admin Server + (in the section "MAGNUS EDITOR"). + + Installing PHP with NES/iPlanet/SunONE on Windows @@ -361,11 +368,20 @@ - - More details about setting up - PHP as an NSAPI filter can be found here: - &url.netscape.nsapi; - + + + More details about setting up + PHP as an NSAPI filter can be found here: + &url.netscape.nsapi; + + + + + The stacksize that PHP uses depends on the configuration of the webserver. If you get + crashes with very large PHP scripts, it is recommended to raise it with the Admin Server + (in the section "MAGNUS EDITOR"). + + CGI environment and recommended modifications in php.ini
[PHP-DOC] #20447 [Com]: Register_shutdown_function - connection still open while registered shutdown...
ID: 20447
Comment by: php at mcking dot nl
Reported By: richardz at omniture dot com
Status: Analyzed
Bug Type: Documentation problem
Operating System: RedHat 7.2
PHP Version: 4.2.3
New Comment:
I tested this on a system with:
OS: Fedora Linux Core 1
Apache version: 2.0.48-1.2
PHP version: 4.3.4-1.1
And the connection to the browser was still open. So the bug isn't
solved yet!
Previous Comments:
[2003-11-20 17:09:52] gabe at websaviour dot com
Could you elaborate on that please? I am experiencing
the bug in PHP 4.3.0 and Apache 1.3.27 on OS X, 10.2.8,
as well as PHP 4.1.2 on Apache 1.3.22 on Red Hat Linux.
Under what conditions will it work? I need this
function to work as advertised to perform some time-
consuming tasks in the background and let the user move
on. Since this is pretty much the only way to achieve
anything approaching asynchronous processing in the
Apache PHP environment it seems fairly important.
[2003-08-10 21:24:16] [EMAIL PROTECTED]
This is a documtation problem.
Under certain condition you may infact be able to output data to the
browser from inside the register_shutdown_function handler.
[2003-05-04 02:31:26] [EMAIL PROTECTED]
Is this a documentation problem or a php-bug?
According to some users the documented behaviour worked under PHP <
4.1.0, but now the function behaves differently.
Could someone please check this?
[2003-01-16 12:14:43] firewire at itsyourdomain dot com
I to have run across this problem. I was hoping to use a registered
shutdown function to do some final fairly slow socket processing that
the client didn't need to see. My test case is as follows:
register_shutdown_function('sd');
function sd()
{
echo "I shouldn't be seen";
sleep(5);
}
Causes the browser to echo text then sleep for 5 seconds before
completing the page. I also agree that the manual is incorrect. Is
there another way to force php to close the output stream so slower non
user related functions can be executed?
[2002-11-15 10:32:35] richardz at omniture dot com
My problem is that the connection to the browser is still open while
the registered shutdown functions are executing. The documentation
says that from the registered shutdown functions you WON'T be able to
echo or print or modify the contents of the buffer. I can...
Example:
using apache 1.3.27
php version 4.2.3
//
Test Page.
I was hoping to register shutdown functions to do some cleanup -
without affecting the load time of the site. Apparently these
functions don't work that way?
--
Edit this bug report at http://bugs.php.net/?id=20447&edit=1
