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
Related
I have to include or require files from one server to another solution through php code . Is there any way to do so
It's some kind of design flaw that you need to include some codes from another server.
Write code in your server or the other solution is using Web Services.
PHP is a server-side language.
Any PHP source file is (supposedly) processed inside the context of the Web Front (Apache, Nginx, etc.) in order to produce resulting, printable output (which is, in general, some HTML or JSON, but could also be an image binary or anything else).
The moment a Web front receives an HTTP request for a given PHP file, this file will get executed in-place, rather than its source dumped directly into the response stream.
If it is not so, then you have a serious misconfiguration in your Apache (or other) because it would mean that anyone can access your source files rather than your actual running application.
Therefore, it is the same for your own attempt to include 'http://remote-server/remote-file.php' ; : the remote server will receive an HTTP request, and will process the remote-file.php, and deliver the outcome to your requesting script. This is totally different from including a source file into your PHP script.
If files on that other server are not accessible, then require cannot include them.
This question already has answers here:
How does PHP interact with HTML and vice versa?
(4 answers)
Closed 7 years ago.
When PHP is embedded in HTML what is happening?
Isn't it the case that the html response object is interpreted in the browser, so how does the browser handle the php? Does it make a separate request?
PHP is a server side language that can be embedded in client side languages?
Here is what happens:
Someone goes to your site in their browser. This triggers at HTTP request to your server
Your server decides how it wants to handle the request. Let's say you're using Apache: by default then, this is to serve the index page within your DocumentRoot
Let's assume your index page is index.php. On the server, all PHP code within index.php is executed once. After it has executed, the HTML result of that page is served to the client
Once served to the client, the only thing that can modify the page is JavaScript. PHP only runs on the server. No PHP code will be sent to the client.
If your JavaScript wants to dynamically edit the page with information from the server without a reload, it can perform an AJAX request to the server. This entails the JavaScript making a network request to an endpoint (let's say, getNames.php). getNames.php runs on the server, and returns it's result (usually in the form of echo <something> back to the JavaScript, which can then edit the page based on the received data.
Questions?
The browser issues an HTTP request to the server
The server reads the URL and resolves it (usually to a file with the same name)
The server recognises (usually by matching file extensions) the file as containing a PHP program
The server passes the program through a PHP compiler and executes it
The server sends the output of the program (usually along with some extra HTTP response headers) to the browser
The PHP source code is never sent to the browser. Only one request is made (unless the output of the PHP is, for instance, an HTML document that tells the browser to load (for example) images).
What I want to do is the following:
A User initates a HTTP GET request for a static file (for example an image or an mp3 file for HTML5 audio)
A PHP script intercepts these requests (for example via mod_rewrite) and checks the cookie for valid authentification
If successful, the file is delivered to the User, or the User gets a 401
Now, it would be perfect and most simple if the PHP script could "pass through" a successful request and return control to Apache, so that Apache can deliver the file as if it was the original request. Since we have also caching and the need to deliver audio files (including chunked requests) this would free the php script from manually creating the response headers etc.
Is this possible at all?
And if not, what would be the easiest, simplest solution to achieve this, so that caching and (chunked) requests for audio files still works as intended?
I think what you want is X-Sendfile.
Indeed, you can use mod_rewrite to let PHP deal with whatever-mime files, and then return an error or the wanted file via the X-Sendfile header (note that you’ll have to activate the eponymous module within apache).
Didn’t test it though. It seems to be a pretty important issue. OwnCloud, for example, still use PHP to serve files...
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.
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.