Dealing with Forms

One of the most powerful features of PHP is the way it handles HTML
forms. The basic concept that is important to understand is that any
form element will automatically be available to your PHP
scripts. Please read the manual section on
Variables from external
sources for more information and examples on using forms
with PHP. Here is an example HTML form:

There is nothing special about this form. It is a straight HTML form
with no special tags of any kind. When the user fills in this form
and hits the submit button, the action.php page
is called. In this file you would write something like this:

Apart from the htmlspecialchars() and
(int) parts, it should be obvious what this does.
htmlspecialchars() makes sure any characters that are
special in html are properly encoded so people can't inject HTML tags
or Javascript into your page. For the age field, since we know it is a
number, we can just convert
it to an integer which will automatically get rid of any
stray characters. You can also have PHP do this for you automatically by
using the filter extension.
The $_POST['name'] and $_POST['age']
variables are automatically set for you by PHP. Earlier we
used the $_SERVER superglobal; above we just
introduced the $_POST
superglobal which contains all POST data. Notice how the
method of our form is POST. If we used the
method GET then our form information would live in
the $_GET superglobal instead.
You may also use the $_REQUEST
superglobal, if you do not care about the source of your request data. It
contains the merged information of GET, POST and COOKIE data.

You can also deal with XForms input in PHP, although you will find yourself
comfortable with the well supported HTML forms for quite some time.
While working with XForms is not for beginners, you might be interested
in them. We also have a short introduction
to handling data received from XForms in our features section.

User Contributed Notes 4 notes

According to the HTTP specification, you should use the POST method when you're using the form to change the state of something on the server end. For example, if a page has a form to allow users to add their own comments, like this page here, the form should use POST. If you click "Reload" or "Refresh" on a page that you reached through a POST, it's almost always an error -- you shouldn't be posting the same comment twice -- which is why these pages aren't bookmarked or cached.

You should use the GET method when your form is, well, getting something off the server and not actually changing anything. For example, the form for a search engine should use GET, since searching a Web site should not be changing anything that the client might care about, and bookmarking or caching the results of a search-engine query is just as useful as bookmarking or caching a static HTML page.

The reasons for choosing GET vs POST involve various factors such as intent of the request (are you "submitting" information?), the size of the request (there are limits to how long a URL can be, and GET parameters are sent in the URL), and how easily you want the Action to be shareable -- Example, Google Searches are GET because it makes it easy to copy and share the search query with someone else simply by sharing the URL.

Security is only a consideration here due to the fact that a GET is easier to share than a POST. Example: you don't want a password to be sent by GET, because the user might share the resulting URL and inadvertently expose their password.

However, a GET and a POST are equally easy to intercept by a well-placed malicious person if you don't deploy TLS/SSL to protect the network connection itself.

All Forms sent over HTTP (usually port 80) are insecure, and today (2017), there aren't many good reasons for a public website to not be using HTTPS (which is basically HTTP + Transport Layer Security).

As a bonus, if you use TLS you minimise the risk of your users getting code (ADs) injected into your traffic that wasn't put there by you.

It is worth noting that GET request parameters can be cached while POST request parameters are not. Meaning that if a password is GETted it is stored at various points on the way to the server (Your browser and anyone it's sharing info with, the people manning the firewall at the Org that is receiving the GET, the server logs, etc.)

While it is true that HTTPS encrypts the URL and GET request parameters, nothing guarantees that there is not a Web Application Firewall (that decrypts all traffic going into the Org for inspection) and is logging user info or that one will be implemented in the future at your org. Logs in plain-text are (hopefully) a LOT easier to compromise than a database of hashed passwords.