headers sent issue

[Platero]

Hi,
I've a stupid question but...

The code is the following:

if(($role!='tut or')&&(array_ke y_exists('tutor _id',$_GET)))
{
$possible_ids = array(2,6,7,8,9 ,10);
$t_id = $_GET['tutor_id'];

if(in_array($t_ id, $possible_ids)) {

$query="SELECT id_class FROM class WHERE
id_user='".$_GE T['tutor_id']."'";

$id_class=$db->get_field($que ry,id_class);

include("print_ data.php");

$formButtonLabe l = "Modifica";

}

--->else

{

//$my_echo = "hello";
//echo $my_echo;

//header('Locatio n: http://www.google.com' );
//exit();
}

}


What happens:

if in the array there's what you have in $_GET, anything works.

It's the else block that matters: :-)
- if I ONLY print $my_echo, no problems;
- if I comment $my_echo and I leave the header() uncommented, this
command doesn't work (that is, the page does not redirect);

What is happening?
How can I solve this?

I tried (in the else block) the headers_sent function too:

if (headers_sent() ) {
$my_echo = "sent";
echo $mioeco;
}

and it seems headers are sent, but maybe before I try to redirect.
Is there a way to "clean" the headers already sent??

Thanks very much,
Platero

[Mladen Gogala]

On Sun, 13 Aug 2006 15:45:51 -0400, Jerry Stuckle wrote:

Sooner
or later it will come back to bite you.

Nope. Sooner or later they'll fix PHP to start doing output buffering by
default. I've had pages working without a hitch on Linux or Solaris and
reporting "headers already sent" on Windows 2000. Making every programmer
aware of intricacies of a convoluted and unnecessarily restrictive
protocol is not a solution. Things must be doable through normal
programming, without counting bytes. Your "solution" is like dieting by
maniacally counting calories - it seldomly works and usually creates more
problems then it solves. Calling header() is not an unusual request, it's
like calling a subroutine to jump to another page. I couldn't care less if
headers are already sent, I just want another page, period.
I'm a DBA, programming is not my primary business. I need to get things
done, lots of them and quickly. Things must work, but nobody will come
back complaining to me because of few KB of address space more consumed by
the httpd processes. I use PHP because Perl CGI module is very complex
and the very nature of Perl executing things like `ls /tmp` before the
variable substitution is made. I'm still using Perl for the CLI stuff, but
PHP is my primary web interface. In other words, I started using PHP
because Perl was too complex and it took me too long to develop and
bulletproof my scripts. Following headers religiously and studying trifle
details like that would defeat the purpose. The purpose, may I remind you,
is to develop web applications quickly and not to practice programming
religion. Programming religion is, just as is the case with any other
religion, a guidance and a moral compass when consumed in small doses, but
can also be debilitating, if followed fanatically and to the letter.

--
http://www.mgogala.com

[Mladen Gogala]

On Fri, 11 Aug 2006 23:41:46 -0700, dawnerd wrote:

IMO it's bad practice to
use PHP in the middle of html, unless it's used to output text.

It was written to be used that way. I don't see any reasons for such
puritanic attitude.

--
http://www.mgogala.com

[Jerry Stuckle]

Mladen Gogala wrote:

On Sun, 13 Aug 2006 15:45:51 -0400, Jerry Stuckle wrote:

>>Sooner
or later it will come back to bite you.

Nope. Sooner or later they'll fix PHP to start doing output buffering by
default.

PHP isn't broken. It shouldn't have output buffering by default - no
other language does, for instance. And doing so would break other
applications which depend on immediate output.

And BTW - it doesn't even have to be PHP which causes the output to be
sent. A space or new line character before the first "<?php" is enough
to do it. And PHP isn't even involved.

I've had pages working without a hitch on Linux or Solaris and
reporting "headers already sent" on Windows 2000.

I rest my case. If they were coded properly you wouldn't have that problem.

Making every programmer
aware of intricacies of a convoluted and unnecessarily restrictive
protocol is not a solution.

A good programmer's job includes an understanding of the environment
under which he's working.

Things must be doable through normal
programming, without counting bytes.

Yep. Zero bytes output, no headers sent. 1 byte output, headers sent.

Your "solution" is like dieting by
maniacally counting calories - it seldomly works and usually creates more
problems then it solves.

Nope. It solves ALL the problems. And it doesn't artificially hide the
problems cause by poor coding practices.

Calling header() is not an unusual request, it's
like calling a subroutine to jump to another page.

Agreed.

I couldn't care less if
headers are already sent. I just want another page, period.

If you were a real programmer, you WOULD care about whether the headers
have been sent or not.

I'm a DBA, programming is not my primary business.

That explains a lot. Might I suggest you stick with DBA work and let
programmers do the programming?

I need to get things
done, lots of them and quickly. Things must work, but nobody will come
back complaining to me because of few KB of address space more consumed by
the httpd processes.

Fine. I get things done quickly, also. And they work - correctly.

I use PHP because Perl CGI module is very complex
and the very nature of Perl executing things like `ls /tmp` before the
variable substitution is made.

And Perl has the same "problem" as you call it, as PHP. Any output, and
headers have been sent.

I'm still using Perl for the CLI stuff, but
PHP is my primary web interface. In other words, I started using PHP
because Perl was too complex and it took me too long to develop and
bulletproof my scripts.

OK, PHP is easier. But that doesn't mean sloppy programming is good.

Following headers religiously and studying trifle
details like that would defeat the purpose. The purpose, may I remind you,
is to develop web applications quickly and not to practice programming
religion.

Not at all a programming religion. It's an understanding of the
environment under which you're working, and the actions and limitations
of that environment.

Programming religion is, just as is the case with any other
religion, a guidance and a moral compass when consumed in small doses, but
can also be debilitating, if followed fanatically and to the letter.

And so can stupid and asinine programming practices.

I hope you don't have such a cavalier attitude towards your DBA work as
you do programming. If so, I pity your employer.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Mladen Gogala]

On Sun, 13 Aug 2006 20:38:11 -0400, Jerry Stuckle wrote:

>
PHP isn't broken. It shouldn't have output buffering by default - no
other language does, for instance. And doing so would break other
applications which depend on immediate output.

Actually, all Unix and Unix-like systems have both input and output
buffering turned on by default. That's what system buffers are all about.
If you want to bypass them, you have to do something called "direct I/O".
Buffering on Unix-like systems is a fact of life and it isn't language
dependent.

>
And BTW - it doesn't even have to be PHP which causes the output to be
sent. A space or new line character before the first "<?php" is enough
to do it. And PHP isn't even involved.

>I've had pages working without a hitch on Linux or Solaris and
reporting "headers already sent" on Windows 2000.

I rest my case. If they were coded properly you wouldn't have that problem.

Call to ob_start() resolved the issue extremely quickly. This also breaks
your argument, for if it was a protocol problem, it would be a protocol
problem on both systems. Network protocols are, by definition, independent
of the operating system.

>

>Your "solution" is like dieting by
maniacally counting calories - it seldomly works and usually creates more
problems then it solves.

Nope. It solves ALL the problems. And it doesn't artificially hide the
problems cause by poor coding practices.

With the exception of the ease of programming and the speed of getting
things done. In addition to that, if you call something "poor coding
practices", you should explain why do you think that and what evil can
come out of following those "poor programming practices".

>

>Calling header() is not an unusual request, it's
like calling a subroutine to jump to another page.

Agreed.

>I couldn't care less if
headers are already sent. I just want another page, period.

If you were a real programmer, you WOULD care about whether the headers
have been sent or not.

And why exactly would I care about that? You didn't come up with any
arguments so far, only with unprovoked personal insults.

>

>I'm a DBA, programming is not my primary business.

That explains a lot. Might I suggest you stick with DBA work and let
programmers do the programming?

Might I suggest you to refrain from unsolicited career advices? The
difference among us is that you think that there is something to be gained
by catching that fateful space or newline before "<?php" and I don't. I am
not at all opposed to alleviating the pain by inserting <?php ob_start()?>
as the very first line of my php scripts and forget about headers. I
haven't had the case of that biting me later and you haven't explained how
will that byte me later. You did get quite personal which discourages me from
continuing the debate. My scripts and programs do work, are written quite
clearly and are quite easy to maintain. I'm maintaining them for years.
This is the point at which I will shrug my shoulders, direct you to some
"real programmers" jokes at:
http://www.jestsandjokes.com/show.php3?joke=171

and terminate it gracefully with EOD. You may believe that Allah told you
how to program but I subscribe to the other gods. May the farce be with
you, my friend.
.....

>And so can stupid and asinine programming practices.
I hope you don't have such a cavalier attitude towards your DBA work as
you do programming. If so, I pity your employer."

You must be a joy to work with. Your employer probably fully deserves you,
just for giving you "your team".

--
http://www.mgogala.com

[Jerry Stuckle]

Mladen Gogala wrote:

On Sun, 13 Aug 2006 20:38:11 -0400, Jerry Stuckle wrote:

>>PHP isn't broken. It shouldn't have output buffering by default - no
other language does, for instance. And doing so would break other
application s which depend on immediate output.

Actually, all Unix and Unix-like systems have both input and output
buffering turned on by default. That's what system buffers are all about.
If you want to bypass them, you have to do something called "direct I/O".
Buffering on Unix-like systems is a fact of life and it isn't language
dependent.

But PHp is not a system. It's a programming language. Apache still
buffers the output. And as soon as ANY output is sent - whether from
PHP, PERL, HTML or whatever - Apache sends the headers.

>

>>And BTW - it doesn't even have to be PHP which causes the output to be
sent. A space or new line character before the first "<?php" is enough
to do it. And PHP isn't even involved.

>>>I've had pages working without a hitch on Linux or Solaris and
reporting "headers already sent" on Windows 2000.

I rest my case. If they were coded properly you wouldn't have that problem.

Call to ob_start() resolved the issue extremely quickly. This also breaks
your argument, for if it was a protocol problem, it would be a protocol
problem on both systems. Network protocols are, by definition, independent
of the operating system.

Sure, You're getting around the real problem.

And it doesn't break my argument at all. ob_start() just tells PHP to
do some buffering. It doesn't fix your problem at all. Just bypasses
it - for now.

>

>>>Your "solution" is like dieting by
maniacally counting calories - it seldomly works and usually creates more
problems then it solves.

Nope. It solves ALL the problems. And it doesn't artificially hide the
problems cause by poor coding practices.

With the exception of the ease of programming and the speed of getting
things done. In addition to that, if you call something "poor coding
practices", you should explain why do you think that and what evil can
come out of following those "poor programming practices".

And if you don't have the time (or inclination) to do it right - when
will you have the time (or inclination) to do it over?

And I tried to explain to you. But you're obviously not willing to
understand.

>

>>>Calling header() is not an unusual request, it's
like calling a subroutine to jump to another page.

Agreed.

>>>I couldn't care less if
headers are already sent. I just want another page, period.

If you were a real programmer, you WOULD care about whether the headers
have been sent or not.

And why exactly would I care about that? You didn't come up with any
arguments so far, only with unprovoked personal insults.

I've already tried explaining it to you. You're not fixing the problem.
You're bypassing it. Sooner or later you're going to run into
problems - like when you're on a different OS, maybe a different version
of PHP which buffers differently, or even expect the headers to have
already been sent when you're doing something in your code.

All kinds of things can happen. And it's not at all difficult to fix
the real problem.

>

>>>I'm a DBA, programming is not my primary business.

That explains a lot. Might I suggest you stick with DBA work and let
programmers do the programming?

Might I suggest you to refrain from unsolicited career advices? The
difference among us is that you think that there is something to be gained
by catching that fateful space or newline before "<?php" and I don't. I am
not at all opposed to alleviating the pain by inserting <?php ob_start()?>
as the very first line of my php scripts and forget about headers. I
haven't had the case of that biting me later and you haven't explained how
will that byte me later. You did get quite personal which discourages me from
continuing the debate. My scripts and programs do work, are written quite
clearly and are quite easy to maintain. I'm maintaining them for years.
This is the point at which I will shrug my shoulders, direct you to some
"real programmers" jokes at:
http://www.jestsandjokes.com/show.php3?joke=171

Nope, you post in this forum and you might get some advice - whether you
want it or not.

And you're the real joke here. I'm glad real programmers find the
problem - instead of making a "quick fix". The quick fix never is - in
the long run.

and terminate it gracefully with EOD. You may believe that Allah told you
how to program but I subscribe to the other gods. May the farce be with
you, my friend.
....

>>And so can stupid and asinine programming practices.
I hope you don't have such a cavalier attitude towards your DBA work as
you do programming. If so, I pity your employer."

You must be a joy to work with. Your employer probably fully deserves you,
just for giving you "your team".

Actually, I'm a consultant. I have my own business. And quite in
demand, also. Enough that I regularly turn down work.

But that's because my customers know their projects are done on time,
within budget - and right.
--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Rik]

Jerry Stuckle wrote:

Mladen Gogala wrote:

>On Sun, 13 Aug 2006 20:38:11 -0400, Jerry Stuckle wrote:

>>And BTW - it doesn't even have to be PHP which causes the output to
be
sent. A space or new line character before the first "<?php" is
enough
to do it. And PHP isn't even involved.

I've had pages working without a hitch on Linux or Solaris and
reporting "headers already sent" on Windows 2000.

I rest my case. If they were coded properly you wouldn't have that
problem.

Call to ob_start() resolved the issue extremely quickly. This also
breaks your argument, for if it was a protocol problem, it would be
a protocol problem on both systems. Network protocols are, by
definition, independent of the operating system.

Sure, You're getting around the real problem.

And it doesn't break my argument at all. ob_start() just tells PHP to
do some buffering. It doesn't fix your problem at all. Just bypasses
it - for now.

The fact of the matter is: there is no real reason NOT to use ob_start().
Hell, it can be very usefull. If you're using it to be able to send headers
without regard to output, it shouldn't be necessary however. The script
doesn't break, there isn't a real security issue. It's just a sign of you
coding practices: sloppy. When using this kind of 'hack' to use sessions,
possibilities are you use a lot more bad coding practices. It may be your
only vice, or one of many, but if I see your code and this is one of the
first things I see, my trust in the coder diminishes quickly. I'd suspect
(either correct or incorrect) you don't give a shit about notices like
constants having to be turned into strings and the like.

I don't have the time to check up on entire scripts of coders which are
working on a project, I'll have to trust them. And I'll have to be able to
trust particular code to work elsewhere, undependant of hacks at the
beginning of a script (allthough one can make _some_ requirements, but only
the strictly necessary).

When discovering this sloppy work the trust will be gone, and so will the
assignments to the particular coder be. They will go to someone who DOES
know how to code with care and correctly.

Grtz,
--
Rik Wasmus

[Mladen Gogala]

On Mon, 14 Aug 2006 06:29:08 -0400, Jerry Stuckle wrote:

Nope, you post in this forum and you might get some advice - whether you
want it or not.

There is a very simple solution for that: plonk!

--
http://www.mgogala.com

[Mladen Gogala]

On Mon, 14 Aug 2006 13:42:58 +0200, Rik wrote:

The fact of the matter is: there is no real reason NOT to use ob_start().
Hell, it can be very usefull. If you're using it to be able to send headers
without regard to output, it shouldn't be necessary however. The script
doesn't break, there isn't a real security issue. It's just a sign of you
coding practices: sloppy.

Actually, not necessarily. I use ob_start() in scripts like this one:

<?php ob_start(); session_start() ;?>
<html>
<head>
<title>Kill Session</title>
</head>
<body bgcolor="#EFECC 7">
<center>
<h2>
Warning: kill session <?=$_REQUEST['sid'] ?>, <?=$_REQUEST['serial'] ?>?
</h2>
<hr>
<?php
require_once ('config.php');
require_once ('HTML/Form.php');
$DSN = $_SESSION['DSN'];
$invoker = $_SESSION['invoker'];
$db = NewADOConnectio n("oci8");
if (!empty($_GET['sid'])) {
$sid = $_GET['sid'];
$serial = $_GET['serial'];
} else {
$sid = $_POST['sid'];
$serial = $_POST['serial'];
}
if (empty($sid)) die("Kill session: sid cannot be empty!");
$kill = @$_POST['kill'];
if (empty($kill)) {
$form = new HTML_Form($_SER VER['PHP_SELF'], "POST");
$form->addSubmit("kil l", "Yes");
$form->addSubmit("kil l", "No");
$form->addHidden('sid ', $sid);
$form->addHidden('ser ial', $serial);
$form->display();
exit;
}
if (strtolower($ki ll) != 'yes') {
header("Locatio n: $invoker");
exit;
}
$SQL = "alter system disconnect session '$sid,$serial' immediate";
try {
$db->Connect($DSN['database'], $DSN['username'], $DSN['password']);
$rs = $db->Execute($SQL );
$db->close();
header("Locatio n: $invoker");
}
catch(Exception $e) {
die($e->getMessage() );
}
?>
</center>
</body>
</html>
Here I deliberately and explicitly send HTML headers in such a way that I
can set the background color and write a line of text in HTML. I don't see
why would I program those things in PHP when HTML is made for presenting
static information in an easy way. PHP was designed to mix freely with
HTML. All I want to do in this script is to print a warning and, if
answered with "yes", kill the session, then go back to the invoker.
Without "ob_start() " in the beginning, I am unable to use header()
function on Win2k/Apache 2.0.54/PHP 5.1.4. How will ob_start() byte me
later?

--
http://www.mgogala.com

[Rik]

Mladen Gogala wrote:

On Mon, 14 Aug 2006 13:42:58 +0200, Rik wrote:

>The fact of the matter is: there is no real reason NOT to use
ob_start(). Hell, it can be very usefull. If you're using it to be
able to send headers without regard to output, it shouldn't be
necessary however. The script doesn't break, there isn't a real
security issue. It's just a sign of you coding practices: sloppy.

Actually, not necessarily. I use ob_start() in scripts like this one:

<snip code>

Here I deliberately and explicitly send HTML headers in such a way
that I can set the background color and write a line of text in HTML.
I don't see why would I program those things in PHP when HTML is made
for presenting static information in an easy way. PHP was designed to
mix freely with
HTML. All I want to do in this script is to print a warning and, if
answered with "yes", kill the session, then go back to the invoker.
Without "ob_start() " in the beginning, I am unable to use header()
function on Win2k/Apache 2.0.54/PHP 5.1.4. How will ob_start() byte me
later?

Well, on a server you generating and trashing content that didn't need to
be build in the first place. Not necessarily an issue, but a huge waste of
resources, cpu & memory.

What's the problem with the following flow?

1. start session
2. if form is submitted and answer is yes, destroy session and redirect
3. else show form

It will produce a lot less overhead.
--
Rik Wasmus

[Mladen Gogala]

On Mon, 14 Aug 2006 16:29:56 +0200, Rik wrote:

Well, on a server you generating and trashing content that didn't need to
be build in the first place. Not necessarily an issue, but a huge waste of
resources, cpu & memory.

What is a waste of resources? Which part?

>
What's the problem with the following flow?

1. start session
2. if form is submitted and answer is yes, destroy session and redirect
3. else show form

It will produce a lot less overhead.

The largest single wait is for an Oracle connection to be established. I
want to postpone that for as long as I can and create a connection only
if necessary. This script is invoked from a link, and I don't want to kill
session or establish connection if someone has accidentally clicked on the
link. The full complement of the scripts is available on my page. I'd be
grateful if you decide to take a look.

--
http://www.mgogala.com