This question already has answers here:
What is the difference between client-side and server-side programming?
(3 answers)
Can Firefox's "view source" be set to not make a new GET request?
(12 answers)
Closed 5 years ago.
I have three web servers running identical code. On main, one failover and one development server. Let's call them server1, server2 and server3.
If I load a page from server1, then view the source, the browser reloads the source from the server.
If I load the same page from server2 or server3 they both show the page source without reloading. This is true for both Chromium and Firefox.
The servers are running the same php scripts. They have AFAIK identical nginx/php-fpm installations.
It must be server-side issue because I am using the same browsers in all cases, just changing the IP of the domain from one physical server to another.
What directive could the server be sending to the browser to tell it not to reload? Not an HTTP directive, because there is no difference in the php code from one server to another. I am thinking something at the web server level?
If I reload the page it actually reloads. Only View Source avoids reloading on server2 and server3, which is the behaviour I want. server1 is the one I want to force the browser not to reload on View Source
Edit: I don't believe it is a duplicate because the above question is written by a newbie wanting to know why they can't execute a php script on the client side. The question I have is why does an identical page get reloaded on View Source when it is served by one server but not get reloaded when it is served by a different server? Same browser. Page served by same php code on both servers.
Edit: As to the second "duplicate", thank you for pointing out the post on Firefox. I did read this post when I began researching but the problem affects Chromium as well.
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.
I have a python script that listen to specific port on a server and waits until it gets an http request from browser or program to run.
I want that script to run when the admin on my Joomla site clicks on the save button.
That means that I need a way to go to the link that the server listens to without showing it to the the user (a way to do it in the background).
Any ideas?
Thanks!
PHP is server side, so anything implemented there would not be visible to your user, unless it gets rendered as HTML output.
Does the request need to come from the client machine? Or can it come from your web server?
If it needs to come from the client, I would recommend using PHP headers.
Script 1
header("Location: exec_something_private.php");
exec_something_private.php
exec("do something");
header("Location: success.php");
The above implementation could call a php file, do what you need to do, and then redirect them immediately to a new page?
If the function can be called by the webserver, simply uses exec to run a curl request or something, no?
Is it possible for the same web page to be viewed by two different remotely separated web browser such that when input is put into one browser the same data is displayed in the other browser? Think GoogleDocs (I know this works) or perhaps a document in SharePoint (I'm told this works).
PHP is a server-side scripting language, this means that when the client asks to view the page the PHP-script will render an HTML-page that the client then receives. Any changes that are then done on the client-side will not affect the file on the server.
The way of doing this would be (as already suggested by VWGolf2) to use JavaScript and upload the changes to the server once the client has made any changes. These can then be downloaded (using JavaScript) to the other client and then updated on their webpage.
You can ofcourse write this all in PHP, but it will not be the PHP that is performing the actual logic on the client-side, it will most likely be JavaScript.
You can not solve this problem in php. You will need to use JavaScript and ajax.
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