Do a 'od -c include.php' and see what is at the end of your included file.  I bet you have extra carriage returns.

So I do indeed! Thanks.

The immediate problem is solved; however, it seems strange to me that carriage returns should be causing "header like" output. Wouldn't it make more sense to make the require and include functions function not generate output from extraneous whitespace?

No, it would be a really bad idea to have PHP swallow up whitespace and other chars.  And any http body output, including whitespace, must be preceded by the HTTP headers, so PHP has to force them out.

Understood. However, what makes this appear like a bug rather than a feature is that once a session is successfully registered, the code works as suspected, carriage returns and all. It's only in the very first initial session_start() that the problem appears, which is weird if, as you suggest, the problem simply has to remain in PHP. How come PHP can read cookies fine even if preceded by carriage returns or other whitespace, but cannot set cookies if preceded by carriage returns or other whitespace junk? I was under the impression both operations are performed in the headers, and if that's the case, and one works fine with whitespace preceding it, and the other doesn't, that would seem to indicate that this is a bug and not a feature.

I just think it's odd that I have to eliminate all comments and blank lines in a PHP include file if I want to use sessions later in the document.

BTW, I have the problem now WITHOUT any carriage returns in the include file.

When starting a new session we need to set a cookie which happens in the response headers.  When simply reading a cookie we get that cookie out of the request headers.  That's a completely different operation and is done before you even start executing the script, so it is done long before the include.

And you only have to eliminate blank lines outside of PHP tags in include files.  You can have as many blank lines or PHP comments as you want in include files.

Email me your include file as an attachment please or put it up online somewhere so I can see it.

Rasmus,

After looking through your generous answers, I realize I did not fully understand you until now. I was making tests with files like this...

<?php
/* A comment which seemed to be generating output */
?>

EOF, and reacting against the fact that a comment line was being spit out as a blank line in the headers (even though I saw no evidence of blank headers when I requested the script via "curl -I").

What you really meant was that whitespace OUTSIDE of the <?php?> tags were the problem. This makes much more sense, and I humbly withdraw the bug.

However, since this took the better part of two days to troubleshoot, I am wondering if it would be possible to have PHP generate some kind of warning, or at least a "real" header when something like this happens. For example, if I call the non-working version of the script via curl, with the -I option, I get this:
~>curl -I http://x.qyn/page.php/9/
HTTP/1.1 200 OK
Date: Sat, 28 Dec 2002 02:52:37 GMT
Server: Apache/1.3.27 (Darwin) PHP/4.1.2 mod_ssl/2.8.10 OpenSSL/0.9.6b
X-Powered-By: PHP/4.1.2
Set-Cookie: PHPSESSID=959cf428d5e5b199fbba1533d249fe4f; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: text/html
There is no indication that there is a blank header being sent, or any carriage returns or anything, before the Set-Cookie: header flies out. The return from curl -I is the same regardless of whether the script has extra carriage returns in an early include or not. Nor is there an error message generated by PHP, even with error_reporting set to ALL. In short, there is no indication that something is wrong except for the fact that the cookie doesn't actually get set. Which makes the programmer (me) use various browsers, clear cookies, reset cookie preferences, read hours and hours of postings about cookies, many of which remind you not to send a header before setting a cookie, returning to the code and seeing that sure enough, you aren't sending any results (as far as you can SEE) to the browser (no print statements, no header() calls) before the session_start or session_register gets called. You're stumped, and you find yourself finally filing a bug report which ends up wasting Rasmus Lerdorf's time.

Thank you so much for your time. Summary suggestion: A simple notice in the PHP parser for white space outside of <?php tags would save us a lot of time.

Kristofer Widholm