I am reading "Learning PHP, MySQL, JavaScript, and CSS: A Step-by-Step Guide to Creating Dynamic Websites" 4th edition. I came across request-response procedure. After fetch page, the data should be sent to web browser and the web browser should send the data to web server after it detects PHP in it. Am I wrong?
You are wrong.
The browser will never detect PHP in a page. PHP is executed by the server and the output of the PHP program is sent to the browser. The browser only sees HTML (or an image, or whatever else you want the PHP to output).
The web browser doesn't care what the server is running. It talks HTTP to the server, and the server talks HTTP back. The server's configuration is what tells the server that a URL should be routed to a particular PHP script.
Related
Why do we have to use url while accessing a php file from some other file but cannot do the same by mentioning file path. If I mention the file path then it is showing code.
PHP is a scripting language. It is used to make dynamic web pages.
By using a URL (with an IP, such as 127.0.0.1, localhost or any other IP), you are actually pinging a web server like Apache. By using a file path, you are not running any PHP parser (interpreter/compiler), thats why it simply shows you the code.
When you are entering a URL (e.g. http://localhost:8000), Apache receives your request, forwards it to PHP interpreter which is responsible to parse the requested PHP file, it then generates pure HTML and sends it back to the web server. At the end, web server is only responsible to send back the generated HTML to browser for rendering, that's why you are seeing a real web page and not plain PHP code.
Note: PHP code can also run without using any web server. It is also used by command line, it only need PHP Parser. For more information read this- https://www.php.net/manual/en/intro-whatcando.php
I am learning HTTP and web programming and I was surprised to find out that you can set HTTP headers using php. I thought PHP was used to generate dynamic HTML web pages and create applications. It seems strange to me that PHP can set headers that are sent by the web server (e.g. Apache). I know PHP interpreter reads the PHP file and generates an output usually in the form of HTML.
Does this process work with pipes? In my opinion the apache server has to be able to receive commands from the PHP interpreter or it has to be able to interpret PHP functions itself. They are separate processes I think.
What mechanism is used by PHP to set headers to the web server application (httpd or Apache or something else)
Do all web servers support receiving and setting headers that are received via PHP?
Is it possible to set HTTP headers with all backend languages?
I searched through the website and I did not find an aswer to my question.
More specifically I want to know what command can apache or other web server send to PHP.exe application or PHP-CGI.exe application to receive other information besides the outputted HTML file.
Indeed an interesting question. Using command-line tools, I can only access the produced HTML output. Hence php -r"header('Location: http://someurl.com');" will produce nothing from command line.
When I would look at my setup with IIS (not Apache) though, I see that IIS is using PHP-CGI.exe to communicate with PHP. Looking at the optional arguments of PHP-CGI.exe, I see -b can be used to set a Bind Path for external FASTCGI Server mode. I guess in this server mode there will be room to communicate header information separate from produced HTML.
I don't know the exact details of the FASTCGI protocols to go more indepth. But I guess this is what you wanted to know.
EDIT:
When googling about this, I came upon this thread:
How does PHP interface with Apache?
Sending headers from PHP is very useful, for example, you can send headers that force the browser to download a file vs. displaying it on screen (for file scripts, reports that output CSV), controlling cache headers and performing page redirection.
As stated in one of the comments, PHP being a module of Apache in many installs, it sends headers directly through that. Otherwise, the headers would be sent via CGI / FastCGI, or PHP-FPM for nginx.
What you're thinking of more or less is of a templating engine, which PHP performs well at, but PHP has other functions that would normally not be seen in a template engine, such as opening sockets, handling files, and so on.
Any backend language I've had experience with has support for sending HTTP headers, and I would consider any web-oriented back-end language incomplete without this ability.
header('Location: http://www.google.com/');
In this way we can set header in php
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).
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.
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