According to the PHP documentation:
header() must be called before any actual output is sent, either by normal HTML tags, blank lines in a file, or from PHP. It is a very common error to read code with include, or require, functions, or another file access function, and have spaces or empty lines that are output before header() is called. The same problem exists when using a single PHP/HTML file.
but when I tried the example that the documentation reports (with a little change):
<html>
<?php
/* This will give an error. Note the output
* above, which is before the header() call */
header('X-Header: http://www.example.com/');
exit;
?>
all worked just fine, no error poped up and I smoothly got my <html> tag in the output and my X-Header in the headers.
I'm using PHP 7.1.9, so is still correct what the documentation says?
The documentation is still correct.
For performance purposes, the interpreter puts the output in a buffer. When the buffer is filled for the first time, the interpreter sends the headers then it sends the content of the buffer (and empties the buffer). After this point any call of the function header() fails. The headers cannot be modified any more and other headers cannot be added because the headers have already been sent.
This lets the script produce a small amount of output before sending the headers.
Read more about output buffering configuration settings.
The option output_buffering allows turning the feature off or on and even setting the size of the buffer.
The option implicit_flush tells the interpreter to flush the buffer after every output block. This forces your script to send the headers correctly, before any output.
edit your php.ini and enable Output Buffering ..
Related
(I set output_buffering and implicit_flush to Off.)
I know PHP has its own output buffering. (Not output buffering that starts with ob_start())
<?php
echo 'hello';
header('HTTP/1.1 200 OK');
echo 'hello';
?>
So I expected that the above source code would work fine because of the output buffering unless I call flsuh().
However, a warning occurs. (Warning: Cannot modify header information - headers already sent by)
I do not know why. I want you to let me know if I have misunderstood.
You cannot output anything before setting headers.
Functions that send or modify HTTP headers must be invoked before any output is made, regardless of php.ini settings.
This is why sometimes the unintentional space before or after <?php, ?> will cause this error to be thrown.
In any request, headers are sent first and then output. You are effectively outputting, then sending/modifying headers, and then outputting again.
At the first invocation of any output, PHP will flush header buffers meaning they are already set, so trying to change them after is impossible; and that is why the error occurs.
I have written a class which outputs content type information as a header, however this does not work. After reading PHP.net it states
Remember that header() must be called before any actual output is
sent, either by normal HTML tags, blank lines in a file, or from PHP.
It is a very common error to read code with include(), or require(),
functions, or another file access function, and have spaces or empty
lines that are output before header() is called.
I am unsure what to do as I cannot hard code the content type everywhere needed. Does anyone know if it is possible to set headers in functions / classes at all?
The restriction is that the headers must be sent before any other output is sent.
The easiest solution would be to enable output buffering. So you can set headers anywhere till the buffer is flushed.
You can do this ether by using the function ob_start
Or using the output_buffering ini directive in php.ini file.
As pointed out by Brad, it is not the most efficient solution as it takes up server memory to buffer the output and delays the sending of first byte.
The best solution would be to find what is sending the output before the header call and delay the output if possible.
A good trade-off I found was to enable output buffering using ob_start at beginning and flushing the buffer just after the page <head> element is generated and all the needed headers are set. This way any further output is not buffered. The only thing to take care of is that all header calls are made before the ob_end_flush call.
The headers were sending correctly all along but I was checking the response of the file I was using and not properly getting the response from the CURL, if that makes sense! I just needed to use:
$httpcode = curl_getinfo($curl, CURLINFO_HTTP_CODE);
I'm trying to design a page which does some database actions, then redirects to user back to the page they came from. The problem is that I use a require() function to get the connection to the database, so the headers are already sent. A meta tag is out of the question since I want it to look like all the processes are done from the page they came from. Any tips? Is there a way I can use the require() and the header() or do I have to drop one? Is there an alternative to header()?
If you can't send the header() before some content gets sent, use output buffering by placing an ob_start(); at the beginning of your script before anything is sent. That way, any content will be stored in a buffer and won't be sent until the end of the script or when you manually send the buffer's contents.
On another note, simply requireing another file would not generate any headers/content unless that included script sends them. The most common "hidden" cause of this is unnoticed whitespace before or after the <?php ?> tags.
As Artefacto noted, connecting to the database should not require any output. Fix whatever you're including (e.g. database_connect.php) not to output. See this search on the "headers already sent" issue, which may help you find "hidden" output.
ob_start(); // start output buffering
echo "<html......"; // You can even output some content, it will still work.
.
.
.
.
.
header("Location: mypage.php");
ob_flush(); //flush the buffer
In this case, all output is buffered. This means, the headers are processed first, then the output comes to play...
You cannot send any headers after some content has already been sent. Move the header() call to be before the require() call.
You cannot send headers after any data has been sent to the client.
However, using require does not meen that you output something. If i understand your right, you can include your database files, run your queries and then redirect the user. This is perfectly valid.
If you need to send some output (why if you need to do a redirect?) another option is to use output buffering. By using output buffering, you're not sending the data to the browser when you echo it, but you store it in a buffer. The data will be sent when you call ob_end_flush or you reach the end of the script. After ob_end_flush, you won't be able to send any new headers. You start output buffering with ob_start.
It is possible to use header() with require() when I use output buffering. That means that the whole script is buffered and first send when the script has come to an end.
I have done it by doing this
ob_start("ob_gzhandler"); //begin buffering the output
require_once('/classes/mysql.php');
// Some code where I access the database.
header('/somepage.php');
exit;
ob_flush(); //output the data in the buffer
I have created a PHP application with output_buffering = On.
Now, if i do output_buffering = Off then i have get following error
"Cannot modify header information - headers already sent by ".
How can i remove this error?
What can be the drawback if i upload application on live site with output_buffering = Off?
From PHP Tag Wiki:
Q. "Headers have already been sent..."
A. You're outputting content and triggering PHP's default content-type:text/html header before making your own call to header(). There are a few ways this can happen, check for a stray echo or print, whitespace before and after the tags or maybe a Unicode BOM. Consider using output buffering. With many scripts, there is no need to include the ending ?> and the problem is easily fixed by removing the ending ?> tag from your files.
There is also a myriad of duplicates for this.
Send out your headers before any output goes to the browser.
header('Foo: bar');
echo "foo";
If you turn output buffering off, you are not allowed to send any additional headers (this includes cookies e.g.) after you've send any piece of data to the client (namely using echo or some other output function).
You can use headers_sent() to check where you started to output data to the client.
Ensure all header('') tags go right at the top of the script with no white space!
EG:
<?php
header('type of header');
?>
If you really have to do it further down the page you can call ob_start() at the top of the script. Call ob_end_flush() at the end of the script too.
I don't think it's reasonable.
Why is it actually such a rule?
In the "normal case", I don't think ob_start has to be called before session_start -- nor the other way arround.
Quoting the manual page of session_start, though :
session_start() will register internal
output handler for URL rewriting when
trans-sid is enabled. If a user uses
ob_gzhandler or like with ob_start(),
the order of output handler is
important for proper output. For
example, user must register
ob_gzhandler before session start.
But this is some kind of a special case : the thing is, here, that the order of output handlers is important : if you want one handler to modify things the other did, they have to be executed in the "right" order.
Generally, if you don't use that kind of handlers (Apache and mod_deflate do a great job when it comes to compressing output, for instance), the only thing that matters is that headers must not be sent before you call session_start (because, depending on your configuration, session_start sends cookies, which are passed as HTTP headers).
And headers are sent as soon as any piece of data has to be sent -- ie, as soon as there is any output, even one whitespace outside of <?php ?> tags :
Note: If you are using cookie-based
sessions, you must call
session_start() before anything is
outputted to the browser.
ob_start indicates that PHP has to buffer data :
This function will turn output
buffering on. While output buffering
is active no output is sent from the
script (other than headers), instead
the output is stored in an internal
buffer.
This way, output is not sent before you actually say, yourself, "send the data". This means headers are not send immediatly -- which means session_start can be called later, even if there should have been output, if ob_start had not been used.
Hope this makes things a bit more clear...
If by default your output_buffering is Off and you have been unfortunate enough to send a single byte of data back to the client then your HTTP headers have already been sent. Which effectively prevents session_start() from passing the cookie header back to the client. By calling ob_start() you enable buffering and therefore delay sending http headers.
session_start might want to modify the HTTP header if certain configuration options are set. One for example is session.use_cookies that requires to set/modify the Set-Cookie header field.
Modifying the HTTP header requires that there isn’t any output that’s already sent to the client as the HTTP header is sent right before the first output is sent.
So you either ensure that there is absolutely no output before the call of session_start. Or you use the output buffering control to buffer the output so that the HTTP header can be modified even if there already is output.
session_start() will register internal output handler for URL rewriting when trans-sid is enabled. If a user uses ob_gzhandler or like with ob_start(), the order of output handler is important for proper output.
For example, the user must register ob_gzhandler before session start.
But this is some kind of a special case. The thing is, here, that the order of output handlers is important. If you want one handler to modify things the other did, they have to be executed in the "right" order.
Generally, if you don't use that kind of handlers (Apache and mod_deflate do a great job when it comes to compressing output, for instance), the only thing that matters is that headers must not be sent before you call session_start (because, depending on your configuration, session_start sends cookies, which are passed as HTTP headers).
And headers are sent as soon as any piece of data has to be sent -- ie, as soon as there is any output, even one whitespace outside of <?php ?> tags :
Note: If you are using cookie-based sessions, you must call session_start() before anything is outputted to the browser.
ob_start indicates that PHP has to buffer data :
This function will turn output buffering on. While output buffering is active no output is sent from the script (other than headers), instead the output is stored in an internal buffer.
This way, output is not sent before you actually say, yourself, "send the data". This means headers are not send immediatly -- which means session_start can be called later, even if there should have been output, if ob_start had not been used.
session_start(); should be called before any headers are sent out. ob_start() will suppress the output for a while and you can break this rule. Usually ob_start() on the top is a quick fix in case you are debugging something unknown; everything below works as expected (not just as written ;-)). I prefer to use ob_start() later to session_start().
In PHP, ob_start() is used to start output buffering. Output buffering captures all output sent to the browser and stores it in a buffer, allowing you to manipulate it before sending it to the browser.
When using sessions in PHP, it is important to call ob_start() before starting the session, as sessions rely on cookies, which are sent to the browser as part of the HTTP headers. If any output has already been sent to the browser before the session is started, the headers will have already been sent and it will not be possible to set the session cookies.
By calling ob_start() before starting the session, any output that is generated before the session is started will be captured by the buffer and will not be sent to the browser. This allows the session cookies to be set correctly, even if some output has already been generated.
In summary, ob_start() is necessary for session in PHP because it ensures that headers can be sent correctly even if there is output generated before the session is started.