.html files can translate html and css code. But .php files can do all that an html file can do plus use php. Are there any advantages in using html files over php files, especially in development of a responsive website?
Semantic:
By using *.html/*.htm the reader immediately know, it is just plain HTML
Performance*:
Every html file, that is been requested, is sended by the webserver immediately to the browser.
For every php file, the webserver first starts the PHP interpreter, which is processing the file. After the file is processed, the output is send to the browser.
This means: html takes less cpu power/memory on your webserver. However you will never realy notice it, if you are not serving thousands of requests per second.
* not as much relavant as it's used to be, due to new caching technologies.
Php is a Hypertext Processor that work's on server side. It generate content and send it to a browser which reads the content sent by php. Once it is in the client window, the page is fixed. That's why we use JavaScript on client side so the page can work on its own. It is the server that deal with the php file not the browser. You browser only reads markup language like html.
Related
I have page caching going on and I am trying to improve server response time and when I grab the cached page content via php, for whatever reason it takes about 800ms to output it to the browser.
require_once(PATH_TO_CACHED_FILE);
When I copy this exact same content and put it into a .html file, I get the same content in the browser in about 250ms.
I also get about 250ms when I switch the above require_once to this =>
echo 'a';
So with all this in mind - I'm thinking this is probably related to the buffer size as the bigger the buffer the longer it takes to output it)? Right? I mean - this is a huge difference - what could one do in order to more or less match outputting the content via php to simply loading html since both files do virtually the same thing (grab content / push to browser)?
Thanks!
btw: I also testing copying the output to a .php file (so it just echoed the cached HTML, there are no calculations done in this file) and it still takes ~800ms -- how can simply changing the extension from .php to .html make 500ms difference?
btw2: not sure if it's important, php is on nginx
what could one do in order to more or less match outputting the content via php to simply loading html since both files do virtually the same thing (grab content / push to browser)?
Nothing, see below.
how can simply changing the extension from .php to .html make 500ms difference?
The PHP/PHP-FPM scripting engine is quite heavy compared to simple HTML access because it has to (potentially, based on current state) fork a worker process, do the necessary bootstrapping, load modules if they were not, parse the script and even in a simple HTML you requireing, it must parse it and look for <?php tags to process.
With direct HTML access, there is no PHP engine involved. Nothing of the above happens if you simply link/access your HTML file directly.
Aside from that, buffering can be an issue as well, if you use zlib on the PHP side.
If you must insist on some parent PHP code to be used to serve cache HTML files, then it probably makes sense to experiment with using readfile in lieu of require, as the former won't be subject to parsing the file content for PHP tags.
Otherwise, the best route to go with, if you already have complete HTML files (as in full page cache), is completely avoiding PHP invocation for them. This can be accomplished by using NGINX (or your webserver's of choice) rewrites to route requests directly to HTML-cache files, based on their presence (e.g. for NGINX this can be implemented using try_files directive).
I was wondering how php files are actually secured. How come one can not download a php file, even if the exact location is known?
When I upload a php file to my webserver, lets say to domain.com/files, and I call the domain.com/files page, I can clearly see the php file and its actual size. Downloading the file however leads to an empty file.
The question then is: How does the security mechanism work exactly?
The web server's responsibility is to take the PHP script and hand it to the PHP interpreter, which sends the HTML (or other) output back to the web server.
A mis-configured web server may fail to handle the PHP script properly, and send it down to the requesting browser in its raw form, and that would make it possible to access PHP scripts directly.
Your web hosting may have a mechanism to list the contents of a directory, but the unless it supplies a download mechanism to supply the PHP script with plain text headers (as opposed to HTML) without handing it to the PHP interpreter, it will be executed as PHP rather than served down.
In order to be able to download the raw PHP file, the server would have to do some extra work (possibly via another PHP script) which reads the PHP file from disk and sends its contents down to the browser with plain text headers.
When you request domain.com/files your web server is setup to show all the files in that directory.
When you request the actual php file the web server executes it and outputs the results back to you - not the source code.
Of course, both of the above can be configured. You could switch of directory listing and disable parsing of php files so the actual file contents/source code is output.
Its usually a good practice to switch off directory listing.
When you first install PHP on your server, it reconfigures Apache so that when a .php file is requested, Apache hands processing over to PHP. PHP then processes the code in the file, and returns whatever text the PHP code echoed or printed to Apache, which then sends that back over the network to the person that requested the PHP file.
The "security" comes simply in that Apache does not simply serve the PHP file, but rather hands it over to the PHP processor for execution. If Apache is not configured correctly or you use a server software that does not recognize PHP, the raw PHP file will be sent to the client.
Short answer: since the server is configured to execute PHP files and return the results, you will never be able to access the PHP source from the outside. All code is executed immediately by the server. So, to answer your question:
The security mechanism is that .php files are executed automatically by the server when they are requested.
This is a huge misconception. When you attempt to access a PHP file over port 80, your request is likely being run through a web server which does something with the file. In the case of PHP, it runs that file through the PHP interpreter, which causes that file to create some output, and that is what is sent to you.
You can easily allow downloading of PHP files by removing the interpreter for that file type. If the web server doesn't have anything special for it and doesn't understand the file, it will just have the client download it.
I am having a .php file with the following code. While I am changing the extension of the file as .html then also it is behaving in the same way. Can anyone explain the following:
Why the file is behaving in the same manner with both the
extensions?
What is the difference between the .php and .html file extensions?
.php file
<html>
<head>
<!-- some html code -->
</head>
<body>
<?php echo "Hello!" ?>
</body>
</html>
The filetype is just a way to identify the file, you can't always trust them.
Depending on your web server configuration, you will see different results.
.html is generally use just for html with no serverside code.
.php is used for serverside php code and html if required.
They can be used for anything, it just depends on the setup.
You can configure your web server to handle .php and .html files differently. Your webserver is configured to interpret both as PHP. Most servers handle .php as PHP, and serve .html as-is. That is, if you put your code in an HTML file, the PHP code will not run and will show up in the output.
Some people find it nicer to have .html in the URL instead of .php. It may be useful if your users download your page and try opening them by double-clicking on them.
A php indicates that it is dynamically generated using PHP language. However, you don't see the page as it was originally written, but rather the end result. The end result is, in fact, an html file.
So to answer your question, to the client, a page ending in php or html will support exactly the same contents (which is to say, an html document). Even though browsers shouldn't, they often attempt to visualize tags which make no sense to them (browser interpreting <?php echo "Hello!" ?> for instance might decide "Hello" is the text to display).
Though an html really should never have php tags in it because it isn't meant to be in an html document (php documents are traslated into html documents, thus removing php tags).
an extension is how your operating system recognizes your file and decides what to do do with it i.e. which application should it be opened with.
php is a server side scripting language. It is interpreted by a web server that has php installed on it . For eg in a XAMPP the php.exe file in XAMPP/php folder interprets the php file/commands.
HTML is the standard for sending information over the internet . So the final result of your file is a html page despite whichever serverside scripting language you use. The web server you are using will process the php commands and convert them to corresponding html and send them to your browser. The browser then processes (compiles) the html code to display you your web page.
HTML is essentially all that you see on your browser. PHP is used to interact with the web server and process information that is entered by the user into a web browser via forms or execute underlying third party scripts (such as TCL scripts) under a link to perform a automation functionality in the background hidden from the user who is using on the web site or parse a XML file or extract information from a database or maintain session information and much more.
In general PHP handles the interaction of a web application with a server that is configured to run PHP. HTML simply dumps the results in browser.
You can think of it this way- HTML is simply how your web site looks ... PHP is what makes your site intelligent so that it can interact with a user...
your getting the same result because php can be embedded in html and your web server processes both the files to give you identical results. However if you didn't have php installed on your web server you would get as output in your browser.
The difference lies in how your web server is configured, or whether you need a web server at all when trying to run the files locally (ie - with them on the computer you're currently using).
For example, if you were to run both versions on a computer with no web server installed, the .html file will open in a browser just fine, though without doing anything with any PHP tags. The .php file, however, won't necessarily run and the browser may even try to "download" the file.
What the file extensions are for is to tell a computer what to do with a given extension. Just like your computer will open .doc files in a word processor, or .txt files in a basic text editor. And just like you can tell your computer to open .txt files in your word processor, you can tell the web server to handle .html files the same way as .php files (which is what yours is evidently set up to do).
php is a server side scripting language. Every thing that have a tag php
will be generated by the server and put in the html response.
As far as I Know, depending on the extension the web server will process your file on one way or another. Also, for example, you could have a PHP file that doesn't generate any HTML output, but it redirects to another file.
If you want to give a *.html ended page, you could do it programatically.
you can set any extension to be parsed as PHP, so difference in your case is only in extension. If you disable html files in your Apache configuration to be parsed as php than content of file won't be parsed by PHP. That is all
For example you can add any extension in your Apache configuration to be parsed by php, like this
application/x-httpd-php myextension
where myextension is extension of the file you want to parse.
PHP: Pre Hyper Processot : a server side script language
HTML: Hyper text markup language
".php" and ".html" are just the file extensions however if you want to use php code you must run it off a server which supports php.
PhP is server side.
HTML is client side.
Plus, on the web, filetypes mean nothing. They are overridden by the !DOCTYPE declaration.
So if you have a PHP page, while if someone loads that page they may not see the server side run PHP code; if they grab the source, the file itself is still publicly available, because if you make it not publicly available the person would not be able to load that page.
Thus someone could with the right knowledge 'grab' that file and then read the serverside script stuff.
So is it not safer to make a 'proxy'. for example, AJAX post call to a PHP page (called script handler) and pass a string with the first 2 char being the id to the PHP script to run and the rest of the string being the data for that script, then the script handler runs and include based on the number and returns the echoed back HTML that is then displayed.
What do you guys think? I have done this and it works quite nice, if I grab source all I get is an HTML page with a div container and a javascript file with ajax calls to script handler.
No. Your 'workaround' does not fix the problem, if there ever was one.
If a client (a browser) asks a 'resource' (a page, for example) from a webserver, the webserver won't just serve the resource as it finds it on disk.
If you configured your webserver well, it will know that
An .html, .gif, .png, .css, .js file can just be served as-is.
A .php, .php5, .cgi, .pl file has to be executed first, and the resulting output has to be served.
So with a properly configured server (and most decent webservers are properly configured by default), grabbing the PHP source just by calling the page is impossible - the webserver will know to execute the source and return the result.
But
One of the most encountered bugs when writing your own 'upload/download script' is allowing users to upload/download .php (or other executable) files. If your own script 'serves' the .php file by reading it from disk and writing it to the net, users will be able to see your code.
Solution:
Don't write scripts unless you know what you are doing.
Avoid the not-invented-here syndrome (don't reinvent the wheel unless you are sure you NEED a better wheel AND can MAKE a better wheel)
Don't solve problems that don't exist!
By the by:
if your webserver was mal-configured and is just serving .php files as viewable/downloadable files, your 'solution' of calling it by ajax would not change this... Ajax still is client-side, so any client could bypass the ajax and fetch the script itself.
If your web server is configured correctly, users should never be able to view the actual contents of the PHP file. If they try, they should see the actual output of the PHP script as your web server reads and executes it, then passes that as the response to the HTTP request.
Furthermore, you need to understand that users can easily still look at the file the AJAX request is fetching; all they need to do is install Firebug, or use the Chrome developer tools, and they'll be able to see the full URL the file is fetched from.
So to sum up, firstly you shouldn't need to use this kind of 'security technique' for PHP files, and secondly, the 'security technique' will not stop anyone with more than a passing interest in your data.
Got asked this interesting interview question today.
Explain in detail the process by which a client machine requests a file (say file.php) from the server, and then receives that desired file along with its necessary JS/CSS/images/video files and they appear on the client's browser screen.
Here is what I do know and what I did say:
So a request is sent, then the server sees that the file.php file is being requested, and because it has a .php extension, it first uses the PHP engine to parse any PHP code inside the file, and then once it is done, it outputs back to the client machine the resulting file.php file (as a response). The browser then takes that response and parses the HTML and necessary JS and CSS code, then displays it to the browser.
My answer is pretty basic and not as detailed as it should be. I thought about my response and came up with new questions:
What, literally, is a "request"? Is it basically just the textual header file that gets sent to the server?
What about a "response"? Is the response itself the parsed file.php file that gets sent back to the client machine?
What if the file.php file contains a reference to a script.js file and a style.css file? At which stage do those files get served back to the client machine? Do they come in as separate headers or what?
Above in my answer, I'm not sure if I was correct when I said "...because it has a .php extension, it first uses the PHP engine to parse any PHP code inside the file." Is that really the reason why the server parses the code inside the file, or does the server scan ALL kinds of files by default to check for any PHP code they might contain?
First of all, I think your answer was quite good. It definitely describes the basic process you were asked about.
1) What, literally, is a "request"? Is it basically just the textual header file that gets sent to the server?
Yes, an HTTP request is a text message to a server including, mostly: the requested path, any parameters to that path, client info (user agent, session, cookies etc.).
2) What about a "response"? Is the response itself the parsed file.php file that gets sent back to the client machine?
Sort of. An HTTP response consists of a header text that describes: the response status (success or errors such as file not found, internal server error etc.), some content metadata (content type, encoding...) and the content.
The content could be an HTML document. It could also be a CSS or Javascript file, a PNG image or whatever other files the web server serves. The meta-data in the header describes the content in a way that the browser (or any client) can figure out how to handle it.
3) What if the file.php file contains a reference to a script.js file and a style.css file? At which stage do those files get served back to the client machine? Do they come in as separate headers or what?
Firstly, the process you just described would finish. Meaning, a request was sent and then a response was returned. Assuming the response is an HTML document, the browser parses the document and looks for external content: CSS stylesheets, Javascript files, image files, flash embeds and the like.
For each of these external files, the browser sends a new request using the exact same process. After getting a CSS file, for example, the browser knows to apply it to the document it just parsed.
4) Above in my answer, I'm not too sure if I was correct when I said "...because it has a .php extension, it first uses the PHP engine to parse any PHP code inside the file." Is that really the reason why the server parses the code inside the file, or does the server scan ALL kinds of files by default to check for any PHP code they might contain?
Well, it depends on the server configuration, but most of the times, yes;
The server is usually configured to handle all .php files the same, meaning pass them to the PHP parser and wait for its response.
By the way, this differs for different server-side software technologies. While this is the way PHP works, other technologies (e.g. Ruby on Rails, some .NET languages) are handled in a different way.
Great question, and good for you for showing interest!
For additional information, I suggest you check out HTTP on Wikipedia.
A HTTP request looks like GET /index.html HTTP/1.1. It is sent as plain text to the web server.
A simplified HTTP response (with most header stuff removed) might look like this:
HTTP/1.1 200 OK
Content-Length: 20
Content-Type: text/html; charset=UTF-8
<html>Hello</html>
If the page contains images or stylesheets or other external files, the web browser sends new requests for them, one request per file. The web server returns them in pretty much the same way it returned the HTML. When the browser has requested and received all the files it wants, the page is complete.
It is up to the web server to decide how it wants to process things like PHP. The browser doesn't need to know what goes on behind the curtains. From its perspective, it simply asks for content and (hopefully) receives it.
A simple web server might be configured to do exactly as you said. If it receives a request for a file ending in ".php", it would first run it through the PHP interpreter. But this is totally up to the web server owner to decide.
I think this is what you are looking for: What really happens when you navigate to a URL
To summarize:
1. You enter a URL into the browser: facebook.com
2. The browser looks up the IP address for the domain name
3. The browser sends a HTTP request to the web server
4. The facebook server responds with a permanent redirect
5. The browser follows the redirect
6. The server ‘handles’ the request
7. The server sends back a HTML response
8. The browser begins rendering the HTML
9. The browser sends requests for objects embedded in HTML
10. The browser sends further asynchronous (AJAX) requests