By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,454 Members | 1,804 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,454 IT Pros & Developers. It's quick & easy.

headers sent issue

P: n/a
Hi,
I've a stupid question but...

The code is the following:

if(($role!='tutor')&&(array_key_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='".$_GET['tutor_id']."'";

$id_class=$db->get_field($query,id_class);

include("print_data.php");

$formButtonLabel = "Modifica";

}

--->else

{

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

//header('Location: 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

Aug 11 '06 #1
Share this Question
Share on Google+
22 Replies


P: n/a
Rik
Platero wrote:
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??
No, once the headers are sent you're stuck with it. Remember: even a space
before <?php will result in headers being sent.

Headers must be sent before any output, whatever it is, wether it's
generated from php or fram a static file.

Grtz,
--
Rik Wasmus
Aug 11 '06 #2

P: n/a

Platero wrote:
Hi,
I've a stupid question but...

The code is the following:

if(($role!='tutor')&&(array_key_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='".$_GET['tutor_id']."'";

$id_class=$db->get_field($query,id_class);

include("print_data.php");

$formButtonLabel = "Modifica";

}

--->else

{

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

//header('Location: 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
Use output buffering, should fix your problem.

Aug 12 '06 #3

P: n/a
dawnerd wrote:
Platero wrote:
>>Hi,
I've a stupid question but...

The code is the following:

if(($role!='tutor')&&(array_key_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='".$_GET['tutor_id']."'";

$id_class=$db->get_field($query,id_class);

include("print_data.php");

$formButtonLabel = "Modifica";

}

--->else

{

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

//header('Location: 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


Use output buffering, should fix your problem.
Better to find and fix the problem than unnecessarily add overhead by
buffering the output.

Output buffering has its uses. But to use it to get around a problem in
the code is not a good idea, IMHO.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Aug 12 '06 #4

P: n/a

Jerry Stuckle wrote:
dawnerd wrote:
Platero wrote:
>Hi,
I've a stupid question but...

The code is the following:

if(($role!='tutor')&&(array_key_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='".$_GET['tutor_id']."'";

$id_class=$db->get_field($query,id_class);

include("print_data.php");

$formButtonLabel = "Modifica";

}

--->else

{

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

//header('Location: 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

Use output buffering, should fix your problem.

Better to find and fix the problem than unnecessarily add overhead by
buffering the output.

Output buffering has its uses. But to use it to get around a problem in
the code is not a good idea, IMHO.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
I couldn't agree with you more. I find it always better to do all of
the dirty work before anything is outputted. IMO it's bad practice to
use PHP in the middle of html, unless it's used to output text.

Instead of say checking variables for errors and redirecting to a new
page in the middle of a page, do it before any html will even be
outputted, that way you are safe to set headers and the work.

Aug 12 '06 #5

P: n/a

Thanks very much.
I red all the thread and I solved :-)

Platero
Aug 12 '06 #6

P: n/a
On Fri, 11 Aug 2006 23:26:44 -0400, Jerry Stuckle wrote:
Output buffering has its uses. But to use it to get around a problem in
the code is not a good idea, IMHO.
The whole business with headers is unnecessarily restrictive and real pain
in the neck or lower. Newer versions of Apache are more and more tolerant,
as they should be. If ob_start will solve my problem, I'll use it in a
heartbeat. It is a solution in 99% of the cases. For the remaining 1%,
it's still a pain.

--
http://www.mgogala.com

Aug 12 '06 #7

P: n/a
Mladen Gogala wrote:
On Fri, 11 Aug 2006 23:26:44 -0400, Jerry Stuckle wrote:

>>Output buffering has its uses. But to use it to get around a problem in
the code is not a good idea, IMHO.


The whole business with headers is unnecessarily restrictive and real pain
in the neck or lower. Newer versions of Apache are more and more tolerant,
as they should be. If ob_start will solve my problem, I'll use it in a
heartbeat. It is a solution in 99% of the cases. For the remaining 1%,
it's still a pain.
This not not an Apache restriction. It's one of the HTTP protocol, and
there isn't anything Apache can do to "fix" it.

And I understand. You're rather go for a "quick fix" than find and fix
the real problem.

Glad you're not on my team.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Aug 12 '06 #8

P: n/a
On Sat, 12 Aug 2006 09:34:36 -0400, Jerry Stuckle wrote:
This not not an Apache restriction. It's one of the HTTP protocol, and
there isn't anything Apache can do to "fix" it.
I don't know, but I do see less problems with Apache 2.0.54 then with
Apache 1.0.3x. I haven't quantified anything
And I understand. You're rather go for a "quick fix" than find and fix
the real problem.
That does fix the real problem: unnecessary painful issue with "headers
already sent". If all that I want to do is to issue header() function and
redirect browser onto another page, then I don't really care about the
"real problem".
>
Glad you're not on my team.
No need to get personal here, but since you've put it that way, I too am
glad that I am not on your team.
--
http://www.mgogala.com

Aug 12 '06 #9

P: n/a
Mladen Gogala wrote:
On Sat, 12 Aug 2006 09:34:36 -0400, Jerry Stuckle wrote:

>>This not not an Apache restriction. It's one of the HTTP protocol, and
there isn't anything Apache can do to "fix" it.

I don't know, but I do see less problems with Apache 2.0.54 then with
Apache 1.0.3x. I haven't quantified anything

>>And I understand. You're rather go for a "quick fix" than find and fix
the real problem.


That does fix the real problem: unnecessary painful issue with "headers
already sent". If all that I want to do is to issue header() function and
redirect browser onto another page, then I don't really care about the
"real problem".
Nope. The real problem is why you're sending data in the first place.
There may be a valid reason. However, just using ob_start() just hides
the real problem.
>
>>Glad you're not on my team.


No need to get personal here, but since you've put it that way, I too am
glad that I am not on your team.

Yep, you wouldn't get away with that on my team. Like anything else -
you should have a reason for using ob_start(). And just using it to
hide the fact you've sent out something ahead of time - but have no idea
what you've sent - is not a valid reason.

Another case of a quick fix instead of finding the real problem. Sooner
or later it will come back to bite you.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Aug 13 '06 #10

P: n/a
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

Aug 13 '06 #11

P: n/a
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

Aug 13 '06 #12

P: n/a
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*******@attglobal.net
==================
Aug 14 '06 #13

P: n/a
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

Aug 14 '06 #14

P: n/a
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
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.
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*******@attglobal.net
==================
Aug 14 '06 #15

P: n/a
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
Aug 14 '06 #16

P: n/a
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

Aug 14 '06 #17

P: n/a
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="#EFECC7">
<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 = NewADOConnection("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($_SERVER['PHP_SELF'], "POST");
$form->addSubmit("kill", "Yes");
$form->addSubmit("kill", "No");
$form->addHidden('sid', $sid);
$form->addHidden('serial', $serial);
$form->display();
exit;
}
if (strtolower($kill) != 'yes') {
header("Location: $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("Location: $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

Aug 14 '06 #18

P: n/a
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
Aug 14 '06 #19

P: n/a
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

Aug 14 '06 #20

P: n/a
Rik
Mladen Gogala wrote:
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?
You are using memory for buffering that hypothetically could be needed
elsewhere. True, it's a very low usage, but hey, if there are thousands on
your site at once, and your server resources are limited, it might shave of
something.

As long as the code stays readable, why not choose the order & checks that
will keep the use of memory & CPU to a minimum. Don't overdo it, but if
either option is OK, why not choose the easiest on the server?
>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.
That has absolutely NOTHING to do with where it is in the script. Surrounded
by a conditional, it could be anywhere, and never be called when it's not
necessary.

As I've yet to set up a testserver here to start to check the
oracle-database, I'll refrain from commenting on the way you use it, but I
doubt wether this construction is safe (could be wrong though):

$sid = $_POST['sid'];
$serial = $_POST['serial'];
$SQL = "alter system disconnect session '$sid,$serial' immediate";
$rs = $db->Execute($SQL);

Is oracle that well build this isn't wide open to attack?
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.
Well, I haven't looked at your page yet, but let's just say this rewrite of
your posted code works perfectly. (which demonstrated further bad coding
practices like <?=$var ?>, exiting without letting your HTML tags close on
form completion....). It's made with simple reasoning: if you have to check
with code what the actual intent of the visitor is, check for the
fastest/easiest things first.

<?php
session_start();
$invoker = $_SESSION['invoker'];

/* I'm not sure what's in here, so I'll put it here:*/
require_once ('config.php');

/* First check: if $sid is not set, all the rest is useless */
if(!isset($_REQUEST['sid'])) die("Kill session: sid cannot be empty!");

/* On a cancel the user will also be directed back asap */
if(isset($_POST['kill'] && strtolower($_POST['kill'])!='yes'){
header("Location: $invoker");
exit;
}
$sid = $_REQUEST['sid'];
$serial = $_REQUEST['serial'];

/* a simple check wether we should delete or display the form: */
if(strtolower($_POST['kill'])=='yes'){
$DSN = $_SESSION['DSN'];
/* If you're that worried about your db-connection, let's make a nice
shutdown: */
function closedb(){
global $db;
$db->close();
}
register_shutdown_function('closedb');

$db = NewADOConnection("oci8");
$SQL = "alter system disconnect session '$sid,$serial' immediate";
try {
$db->Connect($DSN['database'], $DSN['username'], $DSN['password']);
$rs = $db->Execute($SQL);
$db->close();
header("Location: $invoker");
exit;
}
catch(Exception $e) {
die($e->getMessage());
}
/* If the user get's here we need to display HTML */
?>
<html>
<head>
<title>Kill Session</title>
</head>
<body bgcolor="#EFECC7" style="text-align:center">
<h2>Warning: kill session <?php
echo $_REQUEST['sid'].', '.$_REQUEST['serial']; ?>?</h2>
<hr>
<?php
/* only now do we need a form, so we require it */
require_once ('HTML/Form.php');
$form = new HTML_Form($_SERVER['PHP_SELF'], "POST");
$form->addSubmit("kill", "Yes");
$form->addSubmit("kill", "No");
$form->addHidden('sid', $sid);
$form->addHidden('serial', $serial);
$form->display();
/* we had an exit here, let's not begin to tell you why that's bullshit, and
even very bad */
}
?>
</body>
</html>

This took me about 4 minutes with the code you made (no, I haven't checked
for typo's/copy paste errors). Hell, if you take out the comments and empty
lines, it's even shorter.

Also, seeing your code my statement:" When using this kind of 'hack' to use
sessions, possibilities are you use a lot more bad coding practices." has
proven right. Note this is not a personal attack, it's still only an attack
on using ob_start() to use sessions/headers, and will now also go one about
<?= ?syntax, and a warning to let you HTML tags close if you exit;, unless
on fatal errors.

If this was alt.html, I'd add that <centerhas been deprecated for a very
long time now, since HTML4.0.....

Grtz,
--
Rik Wasmus
Aug 14 '06 #21

P: n/a
Rik wrote:
Mladen Gogala wrote:
>>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?


You are using memory for buffering that hypothetically could be needed
elsewhere. True, it's a very low usage, but hey, if there are thousands on
your site at once, and your server resources are limited, it might shave of
something.

As long as the code stays readable, why not choose the order & checks that
will keep the use of memory & CPU to a minimum. Don't overdo it, but if
either option is OK, why not choose the easiest on the server?

>>>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.


That has absolutely NOTHING to do with where it is in the script. Surrounded
by a conditional, it could be anywhere, and never be called when it's not
necessary.

As I've yet to set up a testserver here to start to check the
oracle-database, I'll refrain from commenting on the way you use it, but I
doubt wether this construction is safe (could be wrong though):

$sid = $_POST['sid'];
$serial = $_POST['serial'];
$SQL = "alter system disconnect session '$sid,$serial' immediate";
$rs = $db->Execute($SQL);

Is oracle that well build this isn't wide open to attack?

>>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.


Well, I haven't looked at your page yet, but let's just say this rewrite of
your posted code works perfectly. (which demonstrated further bad coding
practices like <?=$var ?>, exiting without letting your HTML tags close on
form completion....). It's made with simple reasoning: if you have to check
with code what the actual intent of the visitor is, check for the
fastest/easiest things first.

<?php
session_start();
$invoker = $_SESSION['invoker'];

/* I'm not sure what's in here, so I'll put it here:*/
require_once ('config.php');

/* First check: if $sid is not set, all the rest is useless */
if(!isset($_REQUEST['sid'])) die("Kill session: sid cannot be empty!");

/* On a cancel the user will also be directed back asap */
if(isset($_POST['kill'] && strtolower($_POST['kill'])!='yes'){
header("Location: $invoker");
exit;
}
$sid = $_REQUEST['sid'];
$serial = $_REQUEST['serial'];

/* a simple check wether we should delete or display the form: */
if(strtolower($_POST['kill'])=='yes'){
$DSN = $_SESSION['DSN'];
/* If you're that worried about your db-connection, let's make a nice
shutdown: */
function closedb(){
global $db;
$db->close();
}
register_shutdown_function('closedb');

$db = NewADOConnection("oci8");
$SQL = "alter system disconnect session '$sid,$serial' immediate";
try {
$db->Connect($DSN['database'], $DSN['username'], $DSN['password']);
$rs = $db->Execute($SQL);
$db->close();
header("Location: $invoker");
exit;
}
catch(Exception $e) {
die($e->getMessage());
}
/* If the user get's here we need to display HTML */
?>
<html>
<head>
<title>Kill Session</title>
</head>
<body bgcolor="#EFECC7" style="text-align:center">
<h2>Warning: kill session <?php
echo $_REQUEST['sid'].', '.$_REQUEST['serial']; ?>?</h2>
<hr>
<?php
/* only now do we need a form, so we require it */
require_once ('HTML/Form.php');
$form = new HTML_Form($_SERVER['PHP_SELF'], "POST");
$form->addSubmit("kill", "Yes");
$form->addSubmit("kill", "No");
$form->addHidden('sid', $sid);
$form->addHidden('serial', $serial);
$form->display();
/* we had an exit here, let's not begin to tell you why that's bullshit, and
even very bad */
}
?>
</body>
</html>

This took me about 4 minutes with the code you made (no, I haven't checked
for typo's/copy paste errors). Hell, if you take out the comments and empty
lines, it's even shorter.

Also, seeing your code my statement:" When using this kind of 'hack' to use
sessions, possibilities are you use a lot more bad coding practices." has
proven right. Note this is not a personal attack, it's still only an attack
on using ob_start() to use sessions/headers, and will now also go one about
<?= ?syntax, and a warning to let you HTML tags close if you exit;, unless
on fatal errors.

If this was alt.html, I'd add that <centerhas been deprecated for a very
long time now, since HTML4.0.....

Grtz,
Better be careful, Rik. You came up with an intelligent argument. Hi
just might plonk you, too! :-)

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Aug 15 '06 #22

P: n/a
Rik
Jerry Stuckle wrote:
Better be careful, Rik. You came up with an intelligent argument. Hi
just might plonk you, too! :-)
Well, if we're both plonked, he will no longer disagree with us. Problem
solved :-)

Grtz,
--
Rik Wasmus
Aug 15 '06 #23

This discussion thread is closed

Replies have been disabled for this discussion.