PHP Programming - php.ini is output_buffering effected after Global Variables change?

Author

php.ini is output_buffering effected after Global Variables change?

Al Kolff

2005-07-29, 10:00 pm

I am putting together a site based on iSchoolAd a apache/php/mysql script

It is being developed locally using PHPDEV.

After completing modifications the script worked fine.

Till I changed global_variables to on in php.ini (to make a old script
run).

When I went back to my project I received a message when trying to login:
Warning: unable to add to header already.........

So I changed global_variables back to off. Rebooted and guess what
Same message when I tried to run my script

After much searching I found a reference to changing output_buffering to on
as a fix for the warning. And it cured the problem.

My question is why did it work before I changed the global variables to on
(I understand, I think, how that caused a problem) And not work after I
changed it back to Off, until I changed output_buffering to on? I never
touched that in the first place.

--
God Bless you,
Al Kolff

Jerry Stuckle

2005-07-30, 3:59 am

Al Kolff wrote:
> I am putting together a site based on iSchoolAd a apache/php/mysql script
>
> It is being developed locally using PHPDEV.
>
> After completing modifications the script worked fine.
>
> Till I changed global_variables to on in php.ini (to make a old script
> run).
>
> When I went back to my project I received a message when trying to login:
> Warning: unable to add to header already.........
>
> So I changed global_variables back to off. Rebooted and guess what
> Same message when I tried to run my script
>
> After much searching I found a reference to changing output_buffering to on
> as a fix for the warning. And it cured the problem.
>
> My question is why did it work before I changed the global variables to on
> (I understand, I think, how that caused a problem) And not work after I
> changed it back to Off, until I changed output_buffering to on? I never
> touched that in the first place.
>

I don't know why it worked before - but one thing I do know. Turning on output
buffering didn't "fix" the problem. It only hid the problem.

It could be anything - a blank line in an included file, for instance. Anything
which caused output to be sent. Maybe while looking for the problem you
accidentally added a blank line.

You'd be much better to fix the problem than hide it. Then fix the major
security problem cause by register_globals being on.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Geoff Berrow

2005-07-30, 8:59 am

I noticed that Message-ID: <XMadnSh0Gsh7ZXffRVn-qg@comcast.com> from
Jerry Stuckle contained the following:

>
>You'd be much better to fix the problem than hide it. Then fix the major
>security problem cause by register_globals being on.

You know, I've been coming at this the wrong way for ages. Until now
I've been coding to allow for the fact that register_globals might be
off. While this is correct, I now realise that the most important thing
is to code on the assumption that they /might be on/ which they often
will be on production servers.

Simply turning register_globals off on your development server won't
make your scripts secure. In fact, I think too much is made of this.
register globals has been made out to be the bad guy for so long that
people are forgetting why.

If all variables are defined within the script what is so wrong with it?
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Al Kolff

2005-07-30, 4:59 pm

"Geoff Berrow" <blthecat@ckdog.co.uk> wrote in message
news:t0nme195d62jj9h5ida2ghadg32olrapbd@
4ax.com...
> I noticed that Message-ID: <XMadnSh0Gsh7ZXffRVn-qg@comcast.com> from
> Jerry Stuckle contained the following:
>
>
>
> You know, I've been coming at this the wrong way for ages. Until now
> I've been coding to allow for the fact that register_globals might be
> off. While this is correct, I now realise that the most important thing
> is to code on the assumption that they /might be on/ which they often
> will be on production servers.
>
> Simply turning register_globals off on your development server won't
> make your scripts secure. In fact, I think too much is made of this.
> register globals has been made out to be the bad guy for so long that
> people are forgetting why.
>
> If all variables are defined within the script what is so wrong with it?
> --
> Geoff Berrow (put thecat out to email)
> It's only Usenet, no one dies.
> My opinions, not the committee's, mine.
> Simple RFDs http://www.ckdog.co.uk/rfdmaker/

It flat out broke when I turned globals on, but still refused to start
working again when globals were turned back off. (Yes I did reboot between
each). But, the blank line in an include is highly possible. There have been
no problems on my production server.

All the variables are defined within the script or read from mysql except:
(Your absolutely right about that solving many problems)

$MySqlHostname = "localhost";
$MySqlUsername = "xxxxxx";
$MySqlPassword = "xxxxxx";
$MySqlDatabase = "xxxxxxx";

which are defined in config.php which then is included in the various php
pages. I store the rest in the xxxxxxx msql database and read them as
needed.

Thanks for the suggestions
God Bless,
al

Sponsored Links