PHP GET vs. POST
Both GET and POST create an array (e.g. array( key => value, key2 => value2, key3 => value3, ...)). This array holds key/value pairs, where keys are the names of the form controls and values are the input data from the user.
Both GET and POST are treated as $_GET and $_POST. These are superglobals, which means that they are always accessible, regardless of scope - and you can access them from any function, class or file without having to do anything special.
$_GET is an array of variables passed to the current script via the URL parameters.
$_POST is an array of variables passed to the current script via the HTTP POST method.
The example below displays a simple HTML form with two input fields and a submit button:
Example
<html> <body> <form action="welcome.php" method="post"> Name: <input type="text" name="name"><br> E-mail: <input type="text" name="email"><br> <input type="submit"> </form> </body> </html>When the user fills out the form above and clicks the submit button, the form data is sent for processing to a PHP file named "welcome.php". The form data is sent with the HTTP POST method.
To display the submitted data you could simply echo all the variables. The "welcome.php" looks like this:
<html> <body> Welcome <?php echo $_POST["name"]; ?><br> Your email address is: <?php echo $_POST["email"]; ?> </body> </html>The output could be something like this:
Welcome John
Your email address is john.doe@example.com
The same result could also be achieved using the HTTP GET method:
Example
<html> <body> <form action="welcome_get.php" method="get"> Name: <input type="text" name="name"><br> E-mail: <input type="text" name="email"><br> <input type="submit"> </form> </body> </html>and "welcome_get.php" looks like this:
<html> <body> Welcome <?php echo $_GET["name"]; ?><br> Your email address is: <?php echo $_GET["email"]; ?> </body> </html>The code above is quite simple. However, the most important thing is missing. You need to validate form data to protect your script from malicious code.
|
History
|
Parameters remain in browser history because they are part of
the URL
|
Parameters are not saved in browser history.
|
|
Bookmarked
|
Can be bookmarked.
|
Can not be bookmarked.
|
|
BACK button/re-submit
behaviour
|
GET requests are re-executed but may not be re-submitted to
server if the HTML is stored in the browser cache.
|
The browser usually alerts the user that data will
need to be re-submitted.
|
|
Encoding type (enctype
attribute)
|
application/x-www-form-urlencoded
|
multipart/form-data or application/x-www-form-urlencoded Use
multipart encoding for binary data.
|
|
Parameters
|
can send but the parameter data is limited to what we can stuff
into the request line (URL). Safest to use less than 2K of parameters, some
servers handle up to 64K
|
Can send parameters, including uploading files, to the server.
|
|
Hacked
|
Easier to hack for script kiddies
|
More difficult to hack
|
|
Restrictions on form
data type
|
Yes, only ASCII characters allowed.
|
No restrictions. Binary data is also allowed.
|
|
Security
|
GET is less secure compared to POST because data sent is part of
the URL. So it's saved in browser history and server logs in plaintext.
|
POST is a little safer than GET because the parameters are not
stored in browser history or in web server logs.
|
|
Restrictions on form
data length
|
Yes, since form data is in the URL and URL length is restricted.
A safe URL length limit is often 2048 characters but varies by browser and
web server.
|
No restrictions
|
|
Usability
|
GET method should not be used when sending passwords or other
sensitive information.
|
POST method used when sending passwords or other sensitive
information.
|
|
Visibility
|
GET method is visible to everyone (it will be displayed in the
browser's address bar) and has limits on the amount of information to send.
|
POST method variables are not displayed in the URL.
|
|
Cached
|
Can be cached
|
Not cached
|
No comments:
Post a Comment