Just to add, with the patch one can set PHP_FCGI_MAX_REQUESTS quite high,
which will give a big reqs/sec performance boost, eg:
PHP_FCGI_CHILDREN=10
PHP_FCGI_MAX_RAM_INCREASE=25
PHP_FCGI_MAX_REQUESTS=2
ap.
On Fri, June 24, 2005 13:15, Andrew Prendergast said:
> Resend. List serv problems.
>
Resend. List serv problems.
ap.
Original Message
Subject: Re: PHP memory fragmentation
From:"Andrew Prendergast" <[EMAIL PROTECTED]>
Date:Sun, June 12, 2005 21:09
To: internals@lists.php.net
--
I've been trying to compile PHP4 with IMAP support however it fails
claiming it can't find the rfc822.h file and I've searched my drive
for it and couldn't locate it.
I searched the cyrus-imap source files (2.2.12 is installed) and the
closest thing it has is rfc822date.h and this has only
Why not simply disable allow_url_fopen on your server or servers? With
it set off, you get these errors:
Warning: main() [function.main]: URL file-access is disabled in the
server configuration in .../test.php on line 3
Warning: main(http://www.google.com/) [function.main]: failed to open
s
Has anyone encountered this? I cant get any of the attributes in
/etc/php.ini to be read, even when built with:
make clean && ./configure --with-config-file-path=/etc/ --with-unixODBC
--with-mod_charset --enable-discard-path --with-zlib --enable-bcmath
--with-curl --with-inifile --enable-exif -
E_STRICT would be a nice place to leave a warning, but of course, the naive
programmers don't use E_STRICT, so what's the point in that? Personally, I
think include is just fine the way it is. What I could imagine though, is
that the include() function would be enhanced with parameters to
allow/dis
This has been discussed very much long ago. I use variables in include
clauses and always take a very special attention at it. Adding a
warning in E_STRICT does not make any sense either. In no way PHP can
judge if the instruction is needed or not. I, for myself, code in
E_STRICT and don't deserve
Hmm.. If anything, E_STRICT could leave a warning about variables being used
with include/require.. This is the PHP programmers fault clearly.. And the
documentation is exactly the right place.. Your suggestion is pretty much as
stupid as suggesting to forbid ../ in fopen().. There's nothing wro
I believe that the 'include' operator is intrinsically harmful. As
evidence I introduce three exhibits: Google for "php security flaw".
The very first page you find will explain how a very common use of
'include' is insecure. As the second bit of evidence, I introduce the
fact both of the naive p
Yep, that's what I remember too. Would make more sense IMO.
At 11:05 AM 6/24/2005 +0100, Nuno Lopes wrote:
You can find the patches for httpOnly session cookies against the PHP5
CVS HEAD in the attachment.
Now also included is support for httpOnly cookies for PHP functions
setcookie() and setraw
Thanks!
At 09:36 AM 6/24/2005 +0200, Derick Rethans wrote:
On Thu, 23 Jun 2005, Jani Taskinen wrote:
> On Thu, 23 Jun 2005, Derick Rethans wrote:
>
> > On Thu, 23 Jun 2005, Andi Gutmans wrote:
> >
> > > > I can do that if we agree on doing it. You do know that most of
the ones
> > > > in the
You can find the patches for httpOnly session cookies against the PHP5
CVS HEAD in the attachment.
Now also included is support for httpOnly cookies for PHP functions
setcookie() and setrawcookie().
bool setcookie ( string name [, string value [, int expire [, string path
[, string domain [, boo
On Thu, 23 Jun 2005, Jani Taskinen wrote:
> On Thu, 23 Jun 2005, Derick Rethans wrote:
>
> > On Thu, 23 Jun 2005, Andi Gutmans wrote:
> >
> > > > I can do that if we agree on doing it. You do know that most of the ones
> > > > in the "scripting engine" one are ZE1 bugs?
> > >
> > > It seems the m
13 matches
Mail list logo
