Cache-limiter error

[STEPHEN GOODE]

I am getting the following error. I've changed the paths and file names here
to protect my client's confidentiality.

Warning: session_start(): Cannot send session cache limiter - headers
already sent (output started at
/www/html/app/includes/someincludescript.php:2) in
/www/html/app/includes/session.php on line 3

The main script has

<?
include("/www/html/app/includes/someincludescript.php");
include("/www/html/app/includes/session.php");
....
?>

Of course, session.php has a session_start() in it.

My understanding of this error is that someincludescript.php has some kind
of output going out of it at line 2. This would cause the session_start()
function to hiccup and give the warning. Examining someincludescript.php, it
has nothing that should be outputting to the browser. The earliest output in
the main script comes after session.php is included.

To complicate my problem more, all of it works fine on my development
server. When I ship the scripts off to my client and he installs them on his
server, the warning happens. I have taken steps to ensure that the DOS/UNIX
difference in line endings is not a problem. Both the development and
production servers run RedHat Linux. However, the scripts are sent via ftp
(ASCII xfer mode) to my Windows machine, emailed to client's Windows
machine, ftp'd (ASCII xfer mode) to his machine. His doesn't work.

Part of my frustration is that I have no direct influence over the
production server. I can accept that, but it makes it very hard to debug
problems like this. He says that his PHP errors log doesn't show any errors.

I have three suspicions:

1. There is some system setting somewhere, perhaps in php.ini, that is
different between the two servers.
2. My client is not installing the scripts correctly (unintentionally) and
causing the error.
3. The someincludescript.php script is causing an error at line 2 that tries
to write a warning to the browser, which triggers the warning.

Setting me straight on any of the above is welcome.

Rex

[Daniel Tryba]

STEPHEN GOODE <re******@verizon.net> wrote:

I have three suspicions:

1. There is some system setting somewhere, perhaps in php.ini, that is
different between the two servers.
2. My client is not installing the scripts correctly (unintentionally) and
causing the error.
3. The someincludescript.php script is causing an error at line 2 that tries
to write a warning to the browser, which triggers the warning.

Setting me straight on any of the above is welcome.

Those are all posibilities, 1 and 3 could be traced with a custom error
handler, to trace 2 supply the customer with a *very* simple sample code
that in essence does the some whater is on line 2 opse
someincludescript.php but has the sole purpose to give some fedback.

It might help if tell what secrect code is on line 2.

BTW you have checked the differences between dev and producion machines?
You do develop with E_ALL!

[STEPHEN GOODE]

"Daniel Tryba" <sp**@tryba.invalid> wrote in message
news:41**********************@news.xs4all.nl...

STEPHEN GOODE <re******@verizon.net> wrote:

I have three suspicions:

1. There is some system setting somewhere, perhaps in php.ini, that is
different between the two servers.
2. My client is not installing the scripts correctly (unintentionally)
and
causing the error.
3. The someincludescript.php script is causing an error at line 2 that
tries
to write a warning to the browser, which triggers the warning.

Setting me straight on any of the above is welcome.
Those are all posibilities, 1 and 3 could be traced with a custom error
handler, to trace 2 supply the customer with a *very* simple sample code
that in essence does the some whater is on line 2 opse
someincludescript.php but has the sole purpose to give some fedback.

It might help if tell what secrect code is on line 2.

That's part of my problem. Line 1 is "<?". Line 2 is blank. I suspect,
however, that on the production server, there is a blank line before what I
sent him as 1 and 2. The entirety of that include file is a class
definition. It does nothing until the object is instantiated later, long
after the session is started. If there is a blank line or two at the top of
the include file, before the <?, that would account for the output the
warning is complaining about.
BTW you have checked the differences between dev and producion machines?
Another part of my problem, is that I don't have access to the production
machine at all, other than as a user. I can't see the php source as it
exists on production, so I can't check these things out for myself. I have
to rely on the man who pays me to code to report back to me what he sees. I
don't think he is answering my questions accurately. Could be a classic
example of a managerial type not understanding the technospeak of a
developer, but every time I ask him what is in the file after he installs
it, the answers I get from him don't seem to jive with the problem he is
reporting.
You do develop with E_ALL!

Another problem I'm having is that he doesn't want to set display_errors off
and log_errors on. He says that it's inconvenient to check phperrors.log and
would rather see errors in the browser so he can know they're happening. I
tried to convince him that he didn't want his users seeing errors, but he
takes the position that if there are no errors (perfect code), it won't
matter. There will be no errors for his users to see.

I think it is highly possible that something in the installation of
someincludescript.php is creating a warning that is thrown to the browser
(because he has display_errors on). That warning is the output the second
warning is complaining about. I've asked him again to set display_errors to
off and log_errors to on, and send me the error log. I think that will clear
the whole mystery up.

Rex

[Daniel Tryba]

STEPHEN GOODE <re******@verizon.net> wrote:

It might help if tell what secrect code is on line 2.

That's part of my problem. Line 1 is "<?". Line 2 is blank.

The the recent thread about shorttags.

Subtile hint: _DON'T USE THEM_ if you want to make sure your script will
work anywhere :)

[STEPHEN GOODE]

Have never used them before. The developer who created this system used them
and I haven't bothered to change them. I will definitely do the <?php thing
on this script too, but he's been working with it as <? for a couple of
years now. I don't think is the cause of the current problem.

Rex

[Daniel Tryba]

STEPHEN GOODE <re******@verizon.net> wrote:

Have never used them before. The developer who created this system
used them and I haven't bothered to change them. I will definitely do
the <?php thing on this script too, but he's been working with it as
<? for a couple of years now. I don't think is the cause of the
current problem.

Oneway to find out: request someincludescript.php directly and see what
you get servered.

[STEPHEN GOODE]

HOw would I do that?

"Daniel Tryba" <sp**@tryba.invalid> wrote in message
news:41**********************@news.xs4all.nl...

STEPHEN GOODE <re******@verizon.net> wrote:

Have never used them before. The developer who created this system
used them and I haven't bothered to change them. I will definitely do
the <?php thing on this script too, but he's been working with it as
<? for a couple of years now. I don't think is the cause of the
current problem.

Oneway to find out: request someincludescript.php directly and see what
you get servered.

[R. Rajesh Jeba Anbiah]

STEPHEN GOODE wrote:

"Daniel Tryba" <sp**@tryba.invalid> wrote in message
news:41**********************@news.xs4all.nl... <snip> Another problem I'm having is that he doesn't want to set display_errors off and log_errors on. He says that it's inconvenient to check phperrors.log and would rather see errors in the browser so he can know they're happening. I tried to convince him that he didn't want his users seeing errors, but he takes the position that if there are no errors (perfect code), it won't matter. There will be no errors for his users to see.

I think it is highly possible that something in the installation of
someincludescript.php is creating a warning that is thrown to the browser (because he has display_errors on). That warning is the output the second warning is complaining about. I've asked him again to set display_errors to off and log_errors to on, and send me the error log.

Are you aware of ini_set() <http://in2.php.net/ini_set>

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Daniel Tryba]

STEPHEN GOODE <re******@verizon.net> wrote:

HOw would I do that?

The same as you do with other php scripts, use a browser and inserty the
url to the php file.