Re: [PHP-DEV] size of session vars

2003-01-08 Thread Rick Widmer
At 10:52 AM 1/8/03 +0100, Hannes Smit wrote:

Does anyone know how much space can be stored in a session?



How much free space do you have on the drive that holds the session 
data?  I don't think there is an arbitrary limit on session size.  Just the 
limitations of the resources of your machine.


This thread probably belongs on php-general.  This list is for the 
development _of_ php, not _with_ php.

Rick


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: [PHP] PHP 4.3.0 released

2002-12-28 Thread Rick Widmer
At 11:29 AM 12/28/02 -0700, The Doctor wrote:

On Sat, Dec 28, 2002 at 04:04:14AM -0700, Rick Widmer wrote:
> At 08:40 PM 12/27/02 -0700, The Doctor wrote:
> ./configure --with-apache=../apache --with-mysql --with-pgsql=/usr
> --enable-cli --enable-calendar --enable-debug=no
> --with-config-file=/web/conf --with-PEAR --with-jpeg-dir=/usr/local
> --with-phg-dir=/usr/local --with-zlib-dir=/usr/local --with-gd=/usr
> --enable-gd-native-ttf --with-freetype=/usr/include/freetype2
> --with-pdflib=/usr/local --with-ming --enable-magic-quotes --with-mm=../mm
> --with-pspell


vs.



> >configure --prefix=/usr/contrib --localstatedir=/var
> >--infodir=/usr/share/info --mandir=/usr/share/man --with-low-memory
> >--with-elf --with-x   --with-mysql --with-zlib --enable-track-vars
> >--enable-debug  --enable-versioning 
--with-config-file-path=/usr/local/lib
> >--with-iconv=/usr --with-openssl=/usr/contrib  --enable-ftp 
--with-gd=/usr
> >--enable-imap --with-bz2
> >--with-apache=/usr/source/apache_1.3.27_nonSSL/
> >--with-pgsql=/usr/contrib/pgsql --enable-gd-native-ttf
> >--with-jpeg-dir=/usr --with-png-dir=/usr
> >--with-freetype-dir=/usr  --with-xpm-dir=/usr/X11/lib


What I have that you do not:
   cli - create command line interface executable program.
   calendar - fancy tricks with dates.
   pear - a library of handy functions
   gd-native-ttf
   pdflib - create pdf files
   ming - create swf files
   magic-quotes - eliminates a lot of addslashes()
   mm - I'm not sure
   pspell - spelling checker

I don't think anything I added would make any difference.

Things that look wrong to me:

--with-low-memory, --with-elf and --with-x are not listed as valid options 
in ./configure --help, and look scary to me.  Get rid of them.


You used enable-zlib, but the correct statement is with-zlib or with-zlib-dir.


--enable-track-vars - is enabled by default and ignored for a couple of php 
versions now.

--enable-versioning - is only needed when you want to run more than one PHP 
module version at the same time.



The next thing to try...

xpm-dir, bz2, imap, iconv  are the modules you are using that I am 
not.  Try compiling without them and see what happens.



I don't see where any of these _should_ affect things, but I've gotten in 
trouble before using options I did not need...

--prefix - --with-apache specifies where the resulting files are placed, so 
prefix is not relevant to static install.

localstatedir, infodir, mandir - not relevant to a static install because a 
php module does not use any of the directories specified by these.



Rick


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: [PHP] PHP 4.3.0 released

2002-12-28 Thread Rick Widmer
At 08:40 PM 12/27/02 -0700, The Doctor wrote:



Is it just my or are there problems with static Aapche 1.3.27 compiles?


I don't know if it is _just_ you, but my static install compiled and is 
running just fine.

SuSE 8.0

php 4.3.0

Apache 1.3.27

Mod_SSL 2.8.12-1.3.27

OpenSSL 0.9.6h

ming 0.2a

pdflib 4.0.3

./configure --with-apache=../apache --with-mysql --with-pgsql=/usr 
--enable-cli --enable-calendar --enable-debug=no 
--with-config-file=/web/conf --with-PEAR --with-jpeg-dir=/usr/local 
--with-phg-dir=/usr/local --with-zlib-dir=/usr/local --with-gd=/usr 
--enable-gd-native-ttf --with-freetype=/usr/include/freetype2 
--with-pdflib=/usr/local --with-ming --enable-magic-quotes --with-mm=../mm 
--with-pspell




Script started on Fri Dec 27 20:34:45 2002
nl2k.ca//usr/source/php-4.3.0$ cat configphp

configure --prefix=/usr/contrib --localstatedir=/var 
--infodir=/usr/share/info --mandir=/usr/share/man --with-low-memory 
--with-elf --with-x   --with-mysql --with-zlib --enable-track-vars 
--enable-debug  --enable-versioning --with-config-file-path=/usr/local/lib 
--with-iconv=/usr --with-openssl=/usr/contrib  --enable-ftp --with-gd=/usr 
--enable-imap --with-bz2 
--with-apache=/usr/source/apache_1.3.27_nonSSL/ 
--with-pgsql=/usr/contrib/pgsql --enable-gd-native-ttf 
--with-jpeg-dir=/usr --with-png-dir=/usr 
--with-freetype-dir=/usr  --with-xpm-dir=/usr/X11/lib


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] session only for who needs it

2002-12-25 Thread Rick Widmer
At 03:59 AM 12/26/02 +0100, Mattia wrote:

First, this list is for the development _of_ PHP, not development _with_ 
PHP, so further discussion of this and similar subjects should appear on 
the php-general list.

I have a site in wich user can register, but everyone can navigate as
Guest, even if he/she is nt registered.
The problem is that I need session for registered user, but I don't
need them for unregistered ones!
So I tried to check if they already have an opened session (they are
registered), but to check it I have to do a session_start(), and this
will OPEN a session if it's not opened! So I'll have an opened session
for every guest I have in the site. This is difficult for me because I
would like session to last very long, and many empty session waste a
lot of space!


Try something like:

if( isset( $REQUEST[ 'PHPSESSID' ] )) { #  User is registered/logged in
   session_start();
   }

This is based on looking for the cookie or get value for PHPSESSID, the 
default session name.  If it is set, then either a cookie with the session 
ID is set, or the session is being passed in the URL.

Rick


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] is_callable documentation

2002-12-14 Thread Rick Widmer

I just submitted documentation for the is_callable function.  I _think_ is 
correct, but someone who knows more about it than I might want to look it 
over.  It should appear soon in the user notes at:

   http://www.php.net/manual/en/function.is-callable.php


Rick

Thanks to Andrei Zmievski and leon  leonatkinson.com for the 
information I found in the archives on the function.


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false

2002-12-05 Thread Rick Widmer
At 03:02 PM 12/5/02 +0100, Tit \"Black\" Petric wrote:

> >  From my point of view accessing a file should result in an
> > error if the file cannot be opened or in case of
> > GetImageSize() a file operation cannot be executed. For
> > example i would expect GetImageSize() to show an error if the
> > information cannot be retrieved due to file corruptions.
>
> I agree. Absolutely. Masking bona fide file operation errors would
> be a huge mistake, IMHO.

I personally dissagree here - an error is a bit harsh if it doesn't hinder
execution - I dont see anything in getimagesize() which should return
E_ERROR - only E_NOTICE if the file is corrupt, unless I'm missing
something.


If you don't want to see the filesystem error use @ to hide them.  Having 
filesystem errors available makes troubleshooting easier.  If GetImageSize 
never returns them, how do you figure out what is wrong when you it returns 
false?

Rick



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] $_get['variable']

2002-11-30 Thread Rick Widmer
At 12:27 PM 11/30/02 +, Benjamin Paul wrote:

Anyone know how to allow pre 4.0.3 code which was written when you could
call get parsed variables as $variable etc tyo work on the new version of
php which doesnt allow this ???


This really belongs on  the php-general list, this list is for the 
development OF php, not develpment with php.

In php.ini change the setting for REGISTER_GLOBALS to on.


Rick




--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Default Return-Path with mail() and qmail

2002-11-28 Thread Rick Widmer
At 06:28 PM 11/28/02 -0800, Sara "Pollita" Golemon wrote:

I'm a big -1 on this.  The patch will not actually solve the root problem.

On Unix systems, the MTA needs to know that the webserver user is
'trusted' to masquerade as another user.  In exim this would be the
'trusted-users' directive, sendmail, qmail, and postfix have similar
directives.

I agree that the documentation could use some updating in this regard and
would be happy to make that modification after I collect up some examples
of the correct directives to use on common systems.


Qmail seems to trust everyone on the system by default.  I did nothing 
special to allow 'nobody' rights to use sendmail -f to set the From: 
address.  (Running Qmail's sendmail wrapper.)


You might consider recommending a configuration setting like the following 
in each  block on a multi-domain Apache server.  This sends 
bounces and replies to the webmaster of the domain if no attempt is made to 
set the From: and Reply-to: headers when mail() is used.


pph_admin_value sendmail_path "/usr/sbin/sendmail -t [EMAIL PROTECTED]"



I think sendmail requires the user to be a member of the 'trusted' group, 
but I yield to anyone who knows more about it.

Rick


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DEV] RE: Bug #2965

2002-11-28 Thread Rick Widmer
At 07:09 PM 11/28/02 -0500, John Coggeshall wrote:


That's not the issue... In C, the behavior is to actually print the
alphabet A-Z... It looks like our implementation is messed up, but the
bug report is a bit misleading as to if I should fix the documentation
to say you CAN'T do this, or fix the code so you can :)


May I suggest the best choice is to fix the code.  The current action is 
bizarre!

A to Z followed by AA - AZ, BA - BZ ... up to YA-YZ, then if finally 
stops.  A lower case range acts the same way with lower case characters.

If that isn't bad enough for you, try the range from A to z.  After 30 
seconds it got up to AUHXT.

Rick


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Memory persistence with apache question

2002-11-18 Thread Rick Widmer
At 10:33 PM 11/18/02 -0500, Mike Leddy wrote:

Hello,

In what situations will memory allocated to a script remain with the
apache process after the script has terminated ?

I always thought that memory allocated would be released on script
termination - Am I wrong in this assumption ?

Could it be that the heap in the apache process stays at the maximally
used level ?


My understanding is that once an Apache process increases its stack space, 
that stack space stays allocated until the process dies.  For a short term 
fix lower the MaxRequestsPerChild so the big stack processes die off 
sooner.  Long term fix is to upgrade the script causing the problem, 
assuming it has actually been fixed per Marcus' message.

If there are only a few, kill them off by hand.  Apache will start a new one.

Rick



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] I hope this is the last email about this :)

2002-10-28 Thread Rick Widmer
At 07:38 PM 10/28/02 +0900, Yasuo Ohgaki wrote:


BTW, we should better to have a little different ini
selection for CLI.

For instance,

/etc/phprc or php.ini
~/.phprc or php.ini

which are standard locations of rc files under UNIX
like systems.


This I can agree with.  I would prefer /etc/php.ini  which I am already using.


Rick


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] I hope this is the last email about this :)

2002-10-27 Thread Rick Widmer
At 06:05 PM 10/27/02 -0800, Zeev Suraski wrote:

Thank you for the detailed explanation, I'm sure everybody understands it now.

I vote we keep PHP-CLI with implicit_flush on by default.



+1


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] short_open_tag

2002-10-15 Thread Rick Widmer


>
>I fail to see how using plan on distributing your code to the masses or mixing XML/XHTML without
>trivially escaping it, I see absolutely no point in using 
>In reality, very few people intermix PHP and XML.  It just doesn't make a
>whole lot of sense to do so.  People tend to keep the two separate and
>parse the XML from PHP.
>
>In the XHTML case, a lot of people mistakenly believe that they must start
>their documents with an  tag, which if you read the
>XHTML spec, is actually not necessary. The only use for the XML encoding
>tag is for XML parsers to get the right character encoding. Browsers,
>which are typically the target of PHP generated pages, get their character
>encoding from the Content-type header, or optionally from a similar meta
>tag. But even if you choose to put in the XML encoding tag, I find it a
>hell of a lot easier to just put '?> at
>the top instead of changing hundreds of 
>PHP became popular because it eliminated most of the tediousness of
>writing CGI scripts or low-level Apache modules.  If we slowly but surely
>eliminate all the convenience aspects of PHP we are going to turn the
>experience back into one of tedium again.
>
>PHP is not a pure language.  It never will be.  The problem it solves is
>ugly.  Ugly problems often require ugly solutions.  Solving an ugly
>problem in a pure manner is bloody hard.  PHP's aim is to make solving the
>web problem easy.  Ergo, therefore, Q.E.D, removing all the "ugly"
>features of PHP is going to make it harder and harder to use PHP to solve
>the web problem.





Rick


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Patches and Extensions and Such

2002-09-18 Thread Rick Widmer

At 01:08 PM 9/18/02 +0100, Dan Hardiker wrote:
>Hi All,


>  1. Does adding the ?HIGHLIGHT_FORMAT switch to the .phps file format
>reduce or degregate current / existing functionality in any way? {if yes,
>please expand)

No,  but since no one has given any reason why line numbers should not
be on all the time, why bother with it?  Just turn them on all the time.


 > 2. Would the PHP community benifit from this extended functionality? (as
>a whole - Im not looking for a "well I wouldnt use it so -1")

Yes.


>  3. Are we looking to encourage or discourage active PHP development - or
>are we trying to slash down up-and-coming developers because of biest
>opinions and (perhaps) closed minded views?

A little of both.  There seem to be some here who thing their style of 
programming
is the only valid one and have no tolerance for the choices of 
others.  Most people
here are great, and PHP is a fantastic language because of it.


 > 4. Is there any *good* reason why this patch should not be included? That
>is to ask, what negative effects does this script have.

I haven't seen any reason not to include it, other than a suggestion that .phps
should never be used, so it does not need to be improved.  Anyone is free to
disable .phps on their system and ignore it.  The rest of us seem to like the
idea.  Please get it over with.  Install the patch.



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Patches and Extensions and Such

2002-09-18 Thread Rick Widmer

At 10:12 PM 9/18/02 +0300, Jani Taskinen wrote:

> I was just thinking that .phps support is there to
> just show source of some php file. I don't think it's
> really any BC problem to always have line numbering on
> for them. And have an optional parameter to the PHP function
> to show those numbers if wanted.

I agree!  Has ANYONE given a good reason why .phps should not ALWAYS have
line numbers turned on.  ?HIGHLIGHT_FORMAT  is a hassle and likeley to be
forgotten when you need it most.  People who don't use .phps have no business
in making this decision.  You are free to disable it on your system and 
ignore it.


 I don't understand what's the big deal about this thing anyway?
> It's nice new feature.
It sure is!

Rick


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] highlight_file modification

2002-09-11 Thread Rick Widmer


May I suggest that for .phps you just turn line numbers on all the time,
unless someone can come up with a reason not to enable them better
than "that's the way its always been."   Backwards compatibility is good
when it affects how a program runs, but in this case I just don't see a
reason not to enable line numbers.

My guess is the most common, if not the _only_ use for .phps is
displaying php source code for humans to read.  Maybe if you can find
more than one person who is pulling .phps output into a program and
parsing it then _maybe_ that might be a reason not  to turn on line
numbers all the time.

Considering the number of people the line numbers will help, I'm not sure
finding just one or two people who expect no line numbers is reason
enough not to turn it on all the time.  Like it is _so_ hard to just ignore
(or remove) them if you don't need them.

Rick


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] trans-sid warning?

2002-08-20 Thread Rick Widmer

At 05:31 PM 8/20/02 +0200, Tit \"Black\" Petric wrote:
>the ip match should be implemented too, but trough a php.ini switch, since i
>see how that behaviour might not be desired from your comment above, i would
>default it to off thou, let the user/admin/whatnot change it if they desire
>to do that.

What part of "YOU  CAN'T RELY ON IP ADDRESSES FOR AUTHENTICATION!!!"
don't you understand?  IT DOES NOT WORK!  PERIOD... EVER, at least on the
real Internet world!

I've seen a page request, and the images on that page come from different IP
addresses in the AOL block of addresses.  I know they came from the same
browser, yet they show different IP addresses. AOL is not the only place that
proxies/caches traffic from their users.  You can't trust IP addresses to match
with the browser they came from, not even within one single page load.

Rick



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] How can I search in the dev list?

2002-07-18 Thread Rick Widmer

At 11:15 AM 7/18/02 -0600, Braulio José Solano Rojas wrote:
>Hi!
>
>Is there an interface to search through the dev list?

Try:

http://marc.theaimsgroup.com/?l=php-dev&r=1&w=2


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php