<?php
header("Location: secondone.html");
exit();
die();
?>
Ah, the header() function redirects the page to a new page.
Therefore, the exit and die do not ever execute. This code just switches to the secondone.html page.
And, you would not put a DIE after and EXIT as it will never get to the DIE line. Exit stops processing that script. Hope that helps.
Not entirely true.
They are executed even if not needed.
The header redirect is performed by the client.
The server is just sending the header like every other header and continues script execution normally. It isn’t aware of any redirect. It’s just sending data to the client.
Everything else you said however is correct.
The header command happens in the server since it is a PHP command.
It never happens in the broswer, the client. NO PHP is ever executed in any browser.
I am not sure who told you that but, you are 100% incorrect.
ALL PHP commands are executed before anything is ever sent to the browser.
Therefore, it will never get to the other commands.
The header function is executed on the server.
But it does nothing but sending the header to the client.
The client upon receiving the header follows the redirect (or not). The decision to follow the redirect in a new request is a 100% client action.
The server cannot enforce any client action.
Thus it continues to run the script.
You can easily verify that by adding some simple file put contents after the header command before the exist command. You will observe the following:
- a normal browser will follow the redirect
- the server however still will write that file
Also it is not true that all php is executed before anything is send to the client.
Just take a look at ob_flush for example.
And please don’t shout at me, if you have no idea what you are actually talking about.
I’m out since you seem to be quite resistant to learn anything.
Well, you were talking about OJECT creation. That is totally different. And, no, PHP does not just send the new URL to the client. First, it opens that page stopping the processing of the old page, and processes the new page’s PHP code, then sends that new page to the client.
Ernie, you are claiming that a header() redirect causes the web server/php to open and process the new page, directly on the server? This is most certainly, and observantly incorrect. The header() statement only sets the HTTP response headers that will be sent to the browser.
From the documentation -
header() is used to send a raw HTTP header.
More specifically for a location header -
The second special case is the “Location:” header. Not only does it send this header back to the browser, but it also returns a REDIRECT (302) status code to the browser unless the 201 or a 3xx status code has already been set.
This status code is the only case where php does more than just set and send the header() you have coded.
A header() does not stop php code execution, in any case. This would prevent multiple headers from being sent, such as when forcing a file download, followed by the file contents -
<?php
header('Content-Type: application/pdf');
header('Content-Disposition: attachment; filename="downloaded.pdf"');
readfile('original.pdf');
?>Or sending a json content type header followed by the json encoded data -
<?php
$jsonData = array(
'organization' => 'Your Organization',
'founder' => 'Your founder',
'employee' => 'Your Name'
);
header('Content-Type: application/json');
echo json_encode($jsonData);
?>And finally, you can observe this yourself by creating two files, the first one with a header() redirect to the second file, followed by a nonsense header() -
header('location:second_file.php');
header("X-Foo: Bar");If you open your browser, open the developer tools, go to the network tab, and browse to/enter the URL of the first file, you can see the resulting two http requests in the timing diagram and in the list of requests. When you click on the entry for the first request and view the raw response headers, you will find the php added 302 status code as the first entry. You will find the location: second_file.php header somewhere down in the list, followed by the nonsense X-Foo: Bar header. You can also click on the second entry, click on the timing diagram, and see the specific steps the browser takes to request the second page.
Another test case to prove that php code execution does not stop on the first page due to the header() redirect, is to add code after the header() to write a value to a log file, then observe that the data will get written to the log file. This is why there must be an exit/die statement in all those login session check code redirects on protected pages, to prevent the rest of the code on the protected page from being executed.
Okay, but, if the header sends out the URL, it switches to that page and no further processing goes on the old page, correct? I have never added in an exit(); after a header and it has never been an issue. I guess that could be tested by saving a note into a text file after a header() is executed and see if it does save the file. So, okay, I am wrong about the header handled in the client, but, processing doesn’t still continue on the old page? That would be wrong as all kinds of things could happen that way. Thanks.
If you won’t take my statement as evidence that php code execution continues and runs the remainder of the code on the page, you will need to perform the experiment and observe the result yourself.
Edit: here’s a line of code to write to a log file that you can put after the header redirects -
file_put_contents('log.txt','code runs past a header statement', FILE_APPEND);I believe you. I just don’t believe PHP would want that to be allowed. It’s a security issue in my mind.
I went back and looked at various places I have used header() and most are if-then’s where a selection moves to another page. So, the redirect has little to continue with. Does it time out or just keep going?
It’s hard to believe that the server keeps going and going. If there was a loop then it could use up the server’s resources eventually…
Okay, I just did some further research. Yes, the script keeps running, BUT, there is nobody to receive any output from it. Therefore, if the rest of the script has computations or DB handling those keep processing. But, once it tries to output something to the browser, it should stop functioning. So, in my humble opinion, you need to add the exit and die if you have more processing that should not run. But, if the page is set up to just display the html page, it should stop processing because it can not send anything. So, the real test would be to execute the header(), send something to the browser for display and then save the text file. Maybe you might want to try that.
Just the bot scripts that ignore the redirect and receive the output. Which, again, you can observe by using a curl script to request the page, since the default is for curl to not follow redirects.
You are ignoring all the code that performs an action on the server, such as inserting, updating, or deleting data, sending emails, …
Yes, I have been reading a lot more on this. It is a big issue in my opinion.
I found a Stackoverflow page that explained it as you both did. But, it used a scary example.
Something like, loosely…
If (something like password failed) {
setcookie(…, “not logged in”);
header(“admin page”);
}
setcookie(…, “logged in”);
And, both setcookies would execute. That’s bad coding of course, not using the ELSE in the IF …
But, I can see where this could cause lots of issues. I am glad you both cleared me up on this one!
I don’t use a lot of header() functions these days, but, nice to learn this issue!
You need to consider when headers are getting send and when output is getting send.
A cookie when created is as well nothing but a header sent to the client.
This could either fail with “headers already sent” or work.
Furthermore the cookie can only be stored by the client, if the client is still listening.
But yes, in your example both would be executed.
If you want your script to be terminated at a certain point, you explicitly need to terminate it by calling die() or exit() or by skipping the rest of the code conditionally.
This leaves the responsibility but also the freedom to do or not do things with the developer.
Cheers