NYCPHP Meetup

NYPHP.org

Subject: Re: [nycphp-talk] PHP 4.3.3 and session_start

Dan Cech dcech at phpwerx.net
Fri Feb 27 09:02:29 EST 2004


Emmanuel Décarie wrote:
> From: Chris Shiflett <shiflett at php.net>
>>--- Emmanuel DÈcarie <emm at scriptdigital.com> wrote:
>>
>>>I'd like to know why in the world, starting with PHP 4.3.3, PHP need
>>>to throw an error (E_NOTICE) when it encounter a second session_start
 >>
>>This seems like the right thing for PHP to do, in my opinion.

This is absolutely correct, errors of level E_NOTICE are:

Run-time notices. Indicate that the script encountered something that 
could indicate an error, but could also happen in the normal course of 
running a script.

From: <http://us2.php.net/manual/en/ref.errorfunc.php#e-notice>

Trying to open a second session when one already exists falls squarely 
into this category.

>>>But really, I don't understand the logic behind this change. If the
>>>second session_start is to be ignored, why then throw an error?
>>
>>I hate to sound unsympathetic, but a warning seems appropriate. PHP will
>>still do what you're wanting, but there's no reason to have multiple
>>session_start() calls, so it's just letting you know.

Exactly, now if it was throwing an E_WARNING or E_ERROR there might be a 
case for arguing against it, but a notice is just there to let you know 
that you have some code which may be sloppy.

>>It seems like you have your error reporting set very strict, but you want
>>your code to be sloppy. You have to pick one or the other. If you don't
>>care whether your code is sloppy, set your error reporting differently.

I am surprised myself, I have never heard of anyone running a production 
server with error_reporting set to E_ALL, and definitely not without 
some form of custom error handling routine.

> Here's my scenario. I work for a learning institution that produce on-line
> courses. They asked me to plug on the already existing courses an access control
> framework. The control access framework is easy to plug on top of these courses,
> it’s just two includes in the pages to be protected.
> 
> Some of these courses are starting a session and some not. Since the access
> framework need to start a session and is called first, PHP will throw an error
> when it will encounter a session_start in the courses that need a session.
> 
> Because these courses where produced by different programmers working for
> different shops, I need to ask them to modify their code and check first if a
> session already exists before calling session_start. This is not fun.
> 
> I can understand the point that for now on, I should  always in my code check
> first if a session exists. But what about existing code base like in my
> scenario?

Working around existing code can be tough, but it is also not a problem 
you are alone in facing.  There are many ways to avoid the problem, some 
of which are:

- Modify your error reporting level to something like:
   error_reporting(E_ALL ^ E_NOTICE);

- Write a custom error handler.

> Maybe my line of reasoning is wrong but I never heard that there was a penalty
> when PHP encountered a second session_start (). What I know is that PHP will
> disregard the second session_start, doing something similar I guess to
> include_once when it encounter a file that was already included.
> 
> If there is no penalty calling multiple times session_start, why PHP should
> throw an error when this behavior might break compatibilities with existing
> code?

Just to be clear, the error is there as a notice to let you know you 
might be doing something silly, which is absolutely correct because in 
the vast majority of cases having multiple session_start calls is an 
indication of bad programming.

On a side note, if you are already editing these files to add include() 
calls for your password protection scheme, why not remove the 
session_start calls at the same time?

I hope this has helped to clear up the situation,

Dan




More information about the talk mailing list