note 80653 deleted from function.session-start by cmb
| From: | cmb@php.net | Date: | Mon, 21 Nov 2016 19:06:01 +0000 |
| Subject: | note 80653 deleted from function.session-start by cmb | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-207285@lists.php.net to get a copy of this message | ||
Note Submitter: rudylattae at gmail dot com
----
File Encoding was causing my session_start() statement to generate an unexpected warning.
Environment:
OS: Windows XP Pro (32bit)
PHP: v5.2.5
Apache: v2.0.61
I was having this warning:
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers
already sent (output started at ...
I was rather pissed off because I know of this issue and I know how to fix it:
1) Just make sure the session_start() directive is processed before any other statements that modify
the content headers.
2) Failing #1 above, you should also make sure that your script files do not have any
beginning/trailing space or carriage return characters.
3) As a last stand, you could use output buffering to hold your stuff in memory and then spit it out
at the very end. This would essentially allow you to manipulate the headers to your heart's
content without getting any crap from php.
Note: with regards to #2 above, I know some devels use the interesting construct of no closing php
braces e.g.:
> info.php
<?php
phpinfo();
?> (they omit this)
It seems the tag is not required by php (at least php does not puke) so the parser does not treat
any trailing spaces as output to be sent to the user agent. I'm not using this loop-hole at the
moment.
Anyway the above resolutions *did not* work for me (yer even #3) and I was about to give up and just
gag php with good ol "@".
It was then that I thought to check the encoding of my php file. Turns out I had left my editor in
UTF-8 encode mode from some previous (i18n) work I had done. I switched to ANSI and that fixed the
problem. Suddenly the same file that had caused php to scream in pain was being processed without
any issues.
I also noted that I could set the editor to "Encode in UTF-8 without BOM" and that also
works. The BOM is the byte order mark which php probably glosses over (or does not understand). I
didn't look too far into it.
I hope this helps someone else.
Cheers!