Cannot send session cache limiter - head

bundschuh

Hello,

i have a script with the following code:

<?
session_start();
if ((!$PHPSESSID) || (!$item_count_total)) {
session_register("item_count_total");
}
if (!$item_count_total) {
$item_count_total = "0";
}

?>

I always get the error-code
"Warning: Cannot send session cache limiter - headers already sent (output started at /..../htdocs/shop/index.php:7) in /..../htdocs/shop/shop_menu-session.php on line 2"
when i try to include the file in my index.php. Where is the error ?

Thanks.

Philipp

[deleted]

The error is where PHP says it is.

You have printed something (can be anything) before using session_start(). Session start sends an HTTP header and you may NOT print ANYTHING untill you have sent all the headers.

thewitt

I'm having the same problem, and it's with phpshop-core and it's admin demo, logoiut function.

The programmer thinks I'm whacked.

There are others having the same problems I am, and I've searched high and low for any place where something might be output.

Any ideas on how to debug this one? Any way to tell exactly where or what the first byte output is?

Thanks,

-t

[deleted]

It can be anything. you'll have to go through the sources and make sure there are no empty lines or spaces outside the <? ?> markers.

If all else fails you can use output-buffering to cheat. That will gather all the outputted data into a buffer, and make sure that all headers are put at the top.
That way you can print the headers in any order you like, and still get away with it.
NoteL: that is a workaround!
http://www.php.net/manual/en/function.ob-start.php

Anon

After looking hard at output buffering, why would you consider this a work-around?

Why not wrap your PHP pages that depend on sessions and header manipulation in the buffering calls ob_start() and ob_end_flush() and simply put this potential problem behind you, rather than dink around trying to locate where you might have an extra blank line or some piece of output out of order.

In testing, I see no perceivable performance penalty, and the warning message is gone.

I've in fact gone so far as to output real HTML and then set my session variables, and everything still works great.

I don't see any reason not to simply use these calls and move on. Comments are welcome.

-t

[deleted]

There is a performance penalty, but you don't notice it until your server gets a high load.

It is a workaround for the headers thing because the 'proper' way to use headers is to print them in the correct order, before you print any other output. If you use output buffering because you can't find the part where you print a non-header before a header, then output buffering is a workaround for the real problem.

Output buffering has it's uses, especially for error-checking and reporting. But if you only use it to catch header errors, then in my opinion you are taking the easy way out. 🙂

Anon

I would like to try to quantify the performance penalty, as I'm not sure exactly where it would come in. I may set up a real world benchmark test and try to measure it, as a subjective view that it will cause performance problems on a high traffic site is not really a reason to avoid these calls. I suspect the time I spend in my database will far outweight any performance penalty for buffering a page of HTML output and headers.

I've continued to search the web and read what I can on output buffering - specifically using ob_start() and ob_end_flush(), and I'm not so sure it's not the correct way to handle sessions in a real application after all. There seem to be some real good reasons for using it, and none for avoiding it from what I can tell so far. If you have any specific references to problem associated with output buffering, I'd love to see them.

I'm not about to remove all the whitespace from all my scripts and include files in order to find that elusive blank like that's throwing off my ability to use sessions. That seems like a real waste of time, and indeed a serious PHP flaw. What I find even more interesting in my case, is that this sofware is distributed from a website, and there are apparently other people who can run this software with no errors at all. This without editing any include or script files to remove the elusive blank line. There are people complaining as well, but they - with me - are in the minority.

All comments are welcome.

-Tim

[deleted]

"I suspect the time I spend in my database will far outweight any performance penalty for buffering a page of HTML output and headers."

Bad argument. The fact that one action takes longer than the other does not mean that it doesn't matter how long the other action takes.
'Walking from my house to my work takes 2 hours, but that doesnt matter because I am staying at my work for 8 hours'

"That seems like a real waste of time, and indeed a serious PHP flaw."

A serious PHP flaw? this has nothing to do with PHP, but everything with the way HTTP works. HTTP expects to get headers first, content later. If you write a script that sends content first and headers later, then YOU are at fault, because your script works illogically.

"What I find even more interesting in my case, is that this sofware is distributed from a website"

Then complain about it, and complain again... and again... and again.

thewitt

We'll simply have to agree to disagree.

I have been unable to find anything official in any PHP documentation that describes the performance penalty of buffering output when using sessions, and in testing, I've been unable to measure any performance differences that result when calling ob_start and ob_end_flush in all my scripts that use sessions. The added flexibility in header management has also made my program logic far more flexible.

As for PHP outputing a premature header when it encounters a spurious blank line somewhere in an include file - I do consider this a flaw in the parser. I did not give PHP any command or instruction to output HTTP headers, I simply left a blank line in an include file somewhere. How can you possibly blame this on poor programming - it's a parser error as far as I'm concerned. No language parser should be that hung up on whitespace.

And as for my real world example of my application spending the majority of it's time in the database, so any minor time spent in buffering output (which did not exist in my testing by the way) would not be apparent to the user - it is exactly the right example.

Far too many programming "experts" spend their time optomizing the wrong parts of their application to get a 2% improvement, when a change in the database schema or in their program logic will have a 1000% improvement in performance and the user experience. Cost effective programming is not about hunting down that elusive extra blank line that causes the parser to break your application, but in getting the application logic and flow right the first time.

Again, we will agree to disagree on what is important or is proper programming practice in this case.

-t

[deleted]

We definately disagree, you like it quick'n'dirty and I like it 'good' 🙂

thewitt

Not exactly how I would characterise it, but after making a very living at software engineering for over 20 years, I'll stick to my methods.

-t

[deleted]

lol whatever you say mate.

Anon

Vincent, your assessment of the situation saved me! I had a blank line at the top of the file, immediately before the <? marker. I removed the line, and all the session stuff works fine. Thank you.