PHP GET & POST precedence

First of all, it is a very bad practice that a URL contains a parameter which has the same name with a parameter in a POST form. For example:

<form method="POST" action="submit.php?action=doThis">

...

...

<input type="hidden" name="action" value="doThat">

</form>

You shall always avoid this.

But here, we are not talking about good practice in development. We are just looking into this issue form the technology point of view.

So, in case the above situation happened, what would be the value of "action"?

If we var_dump($_GET['action']), we can find the value is 'doThis'. If we var_dump($_POST['action']), the value is 'doThat'.

So far so good, no confusion. But what if we are using $_REQUEST['action']? It turns out that if we var_dump($_REQUEST['action']), we will get 'doThat'! The POST one takes the precedence.

In PHP, By default, POST has higher priority than GET. We can change that in php.ini if we want. Take PHP5.3.3's php.ini as an example. We can find a directive request_order = "GP". The document states "This directive determines which super global data (G,P,C,E & S) should be registered into the super global array REQUEST. If so, it also determines the order in which that data is registered".

G = GET, P = POST, C = COOKIE, E=ENV, S = SERVER.

So request_order = "GP" means GET data will be registered into the $_REQUEST array first, and then POST. So POST data will override the GET data in $_REQUEST.

You may also want to have a look at variables_order = "GPCS". Just check it through in your php.ini.

So how to avoid this potential confusion? For me, the only correct and clean solution is don't ever try this bad practice in your development. Some developers may bring another suggestion: don't use $_REQUEST. Well, personally, i don't completely agree with this suggestion, but i think i should talk about this issue in another post. 

GET or POST method

A very old topic. But always remember the guiding rules:

1. No matter how many times a http request is submitted anew, if the http request will not result in a state-changing action, use GET.

For example, searching repeatedly will not change the database's contents(Well, you may want to record the statistic of keywords being searched which may cause change in database, but when i say the db's content won't get changed, you know what i mean: the request should not have detrimental effect if submitted repeatedly), so the search form could be a good candidate for GET method.

2. If a http request will cause state-changing action, use POST. For instance, charging a credit card.

Now let's explain why these rules. First of all, we have to know the distinction between GET and POST.

The first and very obvious difference is using GET, the data is submitted via the URL. And you may also know that the maximum URL length depends on the browser.

Another distinction is if a request had been submitted using POST method, and the user tries to reload the page, the browser will warn the user if he wants to submit the data again so it can prevent the request from being executed again accidently.

Now, let's assume we just submit our credit card data and get charged. If the method is GET, and we accidently reload the page, the browser will not warn us anything and we may get charged twice. So we better use POST in this case.

Anyway, they are just guiding rules. It doesn't mean you have to follow every time. Come to the end, it all depends on the requirements. For example, if you are developing a bunch of APIs and decide that all requests must be submitted using POST method, then just do it.