CODEWITHSUNDEEP
phphtmlmysql
mbm
mbm

Reputation: 23

Order of execution between php and POST (html)

I have read and understand the answers regarding the order of execution but I still am unclear about how POST works since it is an HTML command. If php executes before HTML, how do php variables get data from POST unless they are sent to a second file?

I realize that if I use $_SERVER['php_SELF'] the form is essentially sent to itself in a sort of recursive manner. This part confuses me: ($_SERVER["REQUEST_METHOD"] == "POST") How can this line ever evaluate if the POST method executes after the php?

I wouldn't mind using the $_SERVER['PHP_SELF'] because then the other piece makes sense BUT, what if I want to use those variables in an mysql search and the loading of a subsequent form based on the results.

Obviously I am new to this and I apologize if my question seems simple but I I can just get these concepts clear in my mind, I am sure I will be able to move forward.

Upvotes: 0

Views: 1082

Answers (2)

Luis Masuelli
Luis Masuelli

Reputation: 12333

Let me explain you how PHP works.

PHP is a Preprocessor. This means it process an HTTP request and, after processing the data in the request, a result is sent to the browser.

That result is an HTTP response, which holds "headers" and "content".

The content is what you see (an image, text, html, a css, a script, or even binary files like PDFs).

The headers are a set of values telling the state of the request. Some important headers are Content-Type which tells the size in bytes of the content to be received, and the status code, which will give the result of the operation. This is important because such values are numbers with different meanings like:

  • 200 (good response)
  • 500 and upper (server errors)
  • 400 and upper (up to 499, request errors),
  • 300 to 399 which could mean redirections. Actually 301 and 302 are important because they FORCE the browser to redirect to a given URL.
  • many others like 100 to 199, but you will rarely use them.

Well... get back to how PHP processes everything:

  1. Your server (which supports PHP) receives http://a.request.to/a/specific.url.php
  2. The server tells the target is a php file and, instead of returning it, it "executes" it.
  3. The PHP script begins an isolated execution (this means: the execution of the script is totally independent of the execution of other scripts -or even other accesses to the same script- now, before, and in the future). The PHP script knows stuff like PHP_SELF var in $_SERVER, because it holds the uri of the resource that was invoked.
  4. When the scripts is executing, it is sending (unless using a special config or call) the contents with each echo command the script has (basically; it has other output sentences).
  5. Finally, the content is served to the client.

In this way: you need data to get passed, and so you need a form beforehand.

That's where GET comes to us: it's to GET a content from a specific URL. Given an URL it is expected that the returned content by GET is "essentially the same" after many subsequent GET requests. This means: GET does not alter the server resource, and so it's the best candidate to retrieve the form (which would be printed by your PHP script) beforehand.

To process the data via a resource which performs an alteration in the server you use the POST method. The post method AFFECTS the server and it does not necessarily produce the same output after subsequent requests.

Both GET and POST (I don't discuss PUT and DELETE here because they're not supported in forms) should return content OR return an HTTP response justifying there's no content (like 201, 204, 301, 302, or an error code). So, when you visit a normal page like www.facebook.com you GET the resource (the displayed page) and when you send data to the login form you POST data to the server (the server sessions and caches are altered).

So the order is: Get (GET) the resource (which provides the "tool" to send data back), display the resource (the browser builds it in your browser), and send data (POST) back (you populate the form and press the submit button).

So you would execute TWICE the same script (one for GET, one for POST).

A script could help you with this issue:

<?php

    //code before this line executes in the first and second access
    if ($_SERVER["REQUEST_METHOD"] == "POST") {
        //code here executes when you send data by pressing a Submit button
    } else {
        //code here executes when you access the url via link, address bar, or javascript url change methods
    }
    //code after this line executes in the first and second access

Upvotes: 1

R3dclient
R3dclient

Reputation: 36

When a browser first connects to the page, it's very likely using a GET request. If you just type the URL or click a link you'll be sending a GET. At this point, $_POST is empty. However, $_SERVER["REQUEST_METHOD"] contains "GET". Hence if you check against this variable, you differentiate between a person visiting the page or submitting the form.

Now the person submits the form (using POST) and the $_POST superglobal is populated. When you check the request method (possibly with an if) it now contains "POST" and you can drop into code which handles the input.

So the chain of events looks like: GET -> PHP code executed -> Form submitted -> POST -> PHP code executed again. The important distinction is that when your code executes you can tell if it was a GET or POST request. If it's a GET request, you may want to display a HTML form. If it's a POST you may want to forgo generating the form, instead showing a results page. Of course you can also do validation: If form entries are invalid, re-display the form with an error message.

Upvotes: 0

Related Questions