I have implemented a verification system for my website, where every time the user requests a page, a PHP script is run that checks if the user is currently logged in. If not, then the user is redirected to a login page. This is done by having a single "redirect.php" file which is 'required' by each page, using the syntax <?php require 'redirect.php' ?>.
Every page that has the above statement has all the code in the <head> element removed and put at the beginning of the <body>. Also, a HTML entity is inserted in quotes: " ".
The result is that in DevTools my HTML looks like this:
Whereas, in my editor, it looks like this:
<?php require 'redirect.php' ?>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
<h1>Stuff</h1>
</body>
</html>
I know that the code inside the 'redirect.php' file is irrelevant because even if I empty that file I get the same odd behaviour. I've checked for invisible unicode characters that somehow made it into my code; there aren't any.
Does anyone know what this is and how to fix it?
If it helps, I'm with InfinityFree hosting.
is a Byte Order Mark.
The file you are requiring must be saved in a format that starts with one (typically UTF-8 With BOM).
It gets inserted into your output stream as a character. Since it isn't a character allowed before the start of the body element it implicitly starts the body element (as well as the html and head elements) and gets inserted at the start of it.
The DOM inspector then normalises it as an HTML entity because it isn't a visible character.
When the rest of the document is parsed, some of what you intended to be put in the head is backfilled through the HTML 5 error recovery rules.
Check your editor and make sure the file format you save the PHP files in doesn't include a BOM.
As it has been answered, represents a Byte-Order-Mark (BOM). Quentin was so kind to clear this up early.
And as you have found out already, <?php require 'redirect.php' ?> is inserting it.
However with what you experience there is more. You've not shared your browser version, but a single BOM alone at the top of redirect.php would not result in the problem you were able to demonstrate (with a common browser).
Here's the differentiation:
It is true that there is an insertion of the BOM. However if it would be at the very beginning of the HTTP response body (the top of the document), it would not be shown in the browser nor via the devtools / in the DOM.
Next to the BOM there must be as well at least one additional character. And it must be positioned before a BOM.
That could be for example another BOM character (or some other whitespace or any other character).
This is important to note when you're looking forward to troubleshoot the issue, as it is most likely not redirect.php (alone), or it must not be at its very beginning, but somewhere there-in, e.g. another require/include.
This could result in a cleaning strategy that orders things differently:
Fix the other files first and then when the browser shows clean, fix the first file (so redirect.php second-last and then the file that has the <?php require 'redirect.php' ?> statement last).
(only an example, this depends on the concrete files in use which I don't know. point in case is it might appear clean by accident)
It might be fine in your usage scenario to keep the one BOM. Personally I would not suggest that, but with the browses and interoperability requirements you have, this can vary.
https://www.w3.org/International/questions/qa-utf8-bom.en.html
http://www.unicode.org/faq/utf_bom.html#bom5
https://www.w3.org/International/questions/qa-byte-order-mark#problems
When I open open this code sample in VSCode and use DevTools the format never changes. Try wrapping your required file in quotes and parenthesis like the example below.
<?php require("redirect.php")?>
DevTools shows the interpreted code. It's possible that your free host inject some ADs into your code. Look at your real source code with CTRL+U in your browser. This should show whats going on
I have a file with .php extension.
I am following a tutorial and it has both and in a same file.
So the file looks something like:
<?php
?>
<!DOCTYPE html>
<html>
</html>
I was wondering which gets executed first?
BTW, this is a sidetrack to this problem.
This particular file has to do with preventing CSRF attack.
Inside HTML, there is a PHP snippet that looks like
<?php Token::generate() ?>
in one of the hidden text fields.
I am not sure why he put both front end and back end in one file.
Is this the necessity to do CSRF prevention?
Thanks in advance.
PHP gets executed on the server, output of this execution is a HTML code.
The browser takes the HTML code and displays it.
I think the execution is based on the order written in the file. Since PHP is on the top, PHP gets executed first.
Hypothetical Question
I'm working on a thing, that is difficult to explain, but take a page PHP file like this
<html>
...content...
</html>
<?php
code();
?>
Is there a way for the code function to cause the contents of the html not to render. This is the goal. Keep in mind, I specifically don't want to place code at the head, like you normally would. Ultimately, I am trying to discount the procedural loading, I suppose.
Is there a way for the code function to cause the contests of the html not to render
<html>
...content...
</html>
Nope, you have lost all those rights after this point. So there is no Way following PHP code can stop it now. Unless you use auto_prepend_file or any webserver related hacks to process any other PHP code first which uses output buffering which stops any output being sent to the browser in the first place. But if in any case its ever sent you can't stop it after that.
<?php
code();
?>
I am using MAMP. None of my code after the PHP tags displays in a browser.
I suspect it's something related to what content I can send to the browser after sending PHP? Or what content can be sent before the HTML doc?
Code:
<?php
/* Web Controller for searching music */
session_start();
echo "I display fine!";
?>
<html>
<head>
<title>Listen2me</title>
</head>
<body>
<h1>Listen2.me</h1>
<input type="text" name="songChoice" value="Search songs">
</body>
</html>
Maybe the missing doctype declaration could affect the display:
<!DOCTYPE html>
Did you try uploading the file to a different server to see if it's a problem with your localhost or a problem with your file?
When I run into issues where the code looks fine but it's not working fine, I always run it through BBEdit's "zap gremlins" feature. You might have an invisible bad character in there somewhere that's messing stuff up. If you don't have BBEdit, you can recreate the document from scratch. Don't copy-paste, because you'd just be copy-pasting any bad characters right back into the new document.
I want to send some response codes in response (what else?) to various conditions.
The header is being sent - I tripped over the various errors you can make using header(), such as having output before the call before. I figured out those sort of issues, for instance, I now use ob_start() and ob_clean() before the header() function call.
Now I need to understand why my browser/server/whatever is not showing me an error page.
Here's the HTML page which I'm using for testing:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title>Header Testing</title>
</head>
<body>
<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');
ob_start();
ob_clean();
header("HTTP/1.1 403 - Forbidden", true, 403); // I get the same results with or without "true, 403"
ob_flush();
?>
Here's the header from the access log:
127.0.0.1 - - [11/Feb/2012:19:14:35 -0600] "POST /commentprocessing.php HTTP/1.1" 403 266 "http://127.0.0.1/submitcomments.php" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24 ( .NET CLR 3.5.30729; .NET4.0C)"
Here is the HTML source:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title>Header Testing</title>
</head>
<body>
</body></html>
That is exactly what I'd get if I removed out the PHP code from the test page.
Is there any way to have an "error" page display automatically based on the return code in the header?
I am running Abyss server locally for this sort of testing. I have a custom error page defined in Abyss for 403 errors and I've checked that it is spelled correctly in the Abyss setup and the page actually exists.
That page is not being displayed for the header with the 403 response code - which seems to be sent properly since it shows in the access log.
Could this be an issue with my using Abyss locally and not the server of my hosting company?
Any suggestions?
EDIT***
tftd,
If what you said is true, that the server is ignoring my code, why is it logged in the access log with the code I specified?
And, if what you said about being unable to change the response code, why even have the header() statement OR why does not the documentation clearly point out that such as things as using ob_start() and ob_clean() won't resolve get around it.
I've see, in more than one place, references to using ob_start() and ob_clean() to delete generated output so that the header() call will work.
heera,
Thank you, at least for showing me that material can be placed above the doctype statement and still be effective. I would not have thought that would work. So, thank you for that.
However, your example merely outputs exactly what would be output if you stripped out all of the PHP and had just the HTML.
I have removed your onload call to eliminate the 'function not defined' error which would have occurred since you did not include a script containing the referenced function.
The following will produce the same output as your example:
<!DOCTYPE html>
<html>
<head></head>
<body>
This is some text
</body>
</html>
Here's your example, which produces the same output as the straight HTML above.
<?php ob_start();?>
<!DOCTYPE html>
<html> <head></head>>
<body>
This is some text
</body>></html>
<?php
$ob=ob_get_clean();
echo $ob;
ob_end_flush(); ?>
You take a convoluted journey to the same output.
Also, why get the contents of the buffer and turn around and echo it out? What does that demonstrate other than a call to ob_get_clean() returns the contents of the buffer, erases it, and, unlike ob_clean(), deletes the buffer and if you want to send the output you just erased, you have to use ob_get_clean() and save it and then use echo to write it out.
Doesn't that just demonstrate that you had better do something to save the contents of the buffer, if you want to output, before calling a clean function?
And, ob_end_flush() is documented, everywhere I've encountered it, as being automatically called went the script/page finishes. Why demonstrate something that happens automatically, unless you were showing that with our with out a flush call, of one type or another, results in the same output, provided additional out is not created after the flush call.
Seems like your ob_end_clean() call doesn't demonstrate anything at all, hmmm, or does it?
So, why generate output, get it from the buffer, erase and delete the buffer, and then output the contents you saved? What exactly, does that demonstrate? How to do something simple in a convoluted, strange way?
Now, if you wanted to demonstrate the difference the placement of the ob_start() makes on the output and that ob_clean() deletes previous output, why not start with an example like this:
<?php ob_start();?>
<!DOCTYPE html>
<html>
<head></head>
<body>
This is some text
</body>
</html>
<?php
ob_clean(); // erase output buffer
echo "It was the best of times, it was the worst of times."
?>
The only output from that would be
It was the best of times, it was the worst of times.
If you comment out the ob_clean() call:
<?php ob_start();?>
<!DOCTYPE html>
<html>
<head></head>
<body>
This is some text
</body>
</html>
<?php
//ob_clean(); // erase output buffer
echo "It was the best of times, it was the worst of times."
?>
The output is now:
<!DOCTYPE html>
<html>
<head></head>
<body>
This is some text
</body>
</html>
This is some textIt was the best of times, it was the worst of times.
If you take my original example and move the ob_start() down into the second piece PHP code, like this:
<!DOCTYPE html>
<html>
<head></head>
<body>
This is some text
</body>
</html>
<?php
ob_start();
ob_clean(); // erase output buffer
echo "It was the best of times, it was the worst of times."
?>
The output is:
<!DOCTYPE html>
<html>
<head>
</head>
<body>
This is some text
</body>
</html>
This is some text It was the best of times, it was the worst of times.
Those are the examples I would provide to show the effect of the placement of the ob_start() and ob_clean() calls.
Again your example does exactly what the HTML would do were the PHP not there.
If you were saying that you must use ob_start, ob_get_clean(), echo, and ob_end_flush() to produce output - well, I would expect that from a programmer who only knew about ob_get_clean() and ob_end_flush().
I'd expect that from a programmer who, for some reason, thought he or she had to take charge to get the output to the user; that they had to take the buffer contents and use echo to send it to the user.
I simply don't understand why your wrote that example as you did or what, besides placement of the ob_start(), you were trying to demonstrate.
As for the "real world" - in the real world programmers are expected to understand the language features they use and any alternatives to them. They are expected to understand concepts - such as PHP automatically sending any generated output without the programmer having to call a function to get it to the user.
You called my use of buffering wrong. Well, it was, as regards the placement of the ob_sat() call, but everything else is just fine.
If you had posted your example in a question of some sort, my reply would have been -
There is absolutely no need to use an PHP to achieve what you are tyring to do. Take out the PHP and use the straight HTML - the output will be the same.
I'm sorry, but that example, except for the ob_start placement, demonstrates nothing but a strange and convo9luted way to get a HTML to a user.
Perhaps you just didn't take the time to consider the best example to use, after, first deciding what the example was to demonstrate.
If we ignore that fact that the example does nothing that the straight HTML does and it goes about outputting the buffer in a convoluted way, all your example did was set me straight on one thing - you can put something before the doctype and it will be "processed. And I thank you for pointing that out to me.
mc_kennedy,
I read the page you pointed me at but I don't think that applies since the first line of output does no start with HTTP/, as the page specifies.
I'm basing that on what I see in the source view window in my browser. The first line is either the doctype or a
To everyone in general --
It seems that what is being said, by some people, is that you have to have the header() call at the very top of the file and that will allow you to send response codes correctly.
Well, I tried that, with the PHP at the very top and followed by standard HTML, and I don't see any difference.
Am I wrong is thinking that a server will react differently to, say, a 200 than to a 403?
Do I have this all wrong and what I'm expecting - to have the server react, somehow, to the 403 or 500 error - is simply something that does not exist?
If the approach I was using would cause the header() call to be ignored, why does the log show the code I was sending?
I now understand that I should generate the error pages myself, I suspected (well, more than suspected, more like figured that was required.)
But am I expecting a server to react to different responses codes in different ways and this simply does not happen?
Bob
The header() function only alters the existing headers which are sent by your web server.
In your case you can't alter the status. By opening http://localhost/index.php you're sending a request to Abyss, which searches for index.php. If it finds the file - it opens/executes it. And because your file actually exists Abyss/Apache/Nginx will act if you're sending Status: 200.
Even if you send header('Status: 403'); the server will not honor it.
I'm not sure if there's an option to override the server's response the way you want it but with apache,nginx you can't do this.
Edit:
As #Alex Lunix said - you can redirect the user to the error page via
header("Location: path/to/your/error/page");
You might want to check how your Abyss server is treating your PHP script. As the log entry is indicating you are sending a 403 response, the server is probably treating the script as an NPH script and thus sending the output, headers included, directly to the browser with no other actions (such as checking if it should go to the configured 403 page). See http://www.aprelium.com/data/doc/2/abyssws-win-doc-html/cgiinternals.html for more details.
Addition to other answers your use of object buffering is wrong, here's a simple example of that
<?php ob_start();?>
<!DOCTYPE html>
<html>
<head></head>
<body onload="initialize()">
This is some text
</body>
</html>
<?php
$ob=ob_get_clean();
echo $ob;
ob_end_flush();
?>
In real world you have to use it differently, it's just an example.
Sending the response code in PHP is not supposed to also forward them to the error page.
Use header("Location: /error/page/url"); to forward them to the page, and if your error pages already send the response code you don't need to send it before forwarding them.
And the problem with the headers already sent thing is due to have already sent content, headers need to be sent before all other content. So placing it above the html would fix that.
<?php
if(Condition for 403){
header("HTTP/1.1 403 - Forbidden", true, 403);//Tell the user that this page is forbidden (not necessary if /error/file/ sends response)
header("Location: /error/file/"); //Forward user to your error page
exit; //Used to prevent php from executing further in the script
}
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title>Header Testing</title>
</head>
<body>
EDIT:
The reason you place it at the top is so that they send before any output (which is what output buffering would do, but that adds unnecessary code). Sending the response code tells the user the nature of the page, if you were writing a 404 error page, then you would send a 404 response. If on this page you want to 403, you need to forward them to your 403 page using the Location header.