method = “post”>

♦ Data is gathered and encoded, just like it is in the get method. When the user clicks the submit button, the data is encoded in a format similar to the get request, but it’s not attached to the URL.

♦ The form data is sent directly to the server. The PHP program can still retrieve the data (usually through a mechanism called environment variables) even though the data is not encoded on the URL. Again, you won’t be responsible for the details of extracting the data. PHP makes it pretty easy.

The post method is often preferable to get because

♦ The URL is not polluted with form data. The data is no longer passed through the URL, so the resulting URL is a lot cleaner than one generated by the get method.

♦ The data is not visible to the user. Because the data isn’t presented in the URL, it’s slightly more secure than get data.

♦ There is no practical size limit. The size of the URL isn’t a limiting factor. If your page will be sending a large amount of data, the post method is preferred.

With all these advantages, you might wonder why anybody uses get at all. Really, there are two good reasons. The get approach allows you to embed requests in URLs (which can’t be done with post). Also, get is sometimes a better choice for debugging because it’s easier to see what’s being passed to the server.

Getting data from the form

PHP includes a number of special built-in variables that give you access to loads of information. Each variable is stored as an associative array; see Chapter 5 of this minibook for more on associative arrays. These special variables are available anywhere in your PHP code, so they’re called superglobals. Here’s a few of the most important ones:

♦ $_GET: A list of variables sent to this program through the get method

♦ $_POST: A list of variables sent to this program through the post method

♦ $_REQUEST: A combination of $_GET and $_POST

Can’t I just have automatic access to form variables?

The earliest forms of PHP had a feature called register_globals that automatically did the $_REQUEST extraction for you. If your program comes from a userName field, the program will “magically” just have a $userName variable preloaded with the value of that field. Although this was a very convenient option, evildoers soon learned how to take advantage of this behavior to cause all kinds of headaches. Convenient as it may be, the register_globals feature is now turned off on most servers and isn’t even available on the next version of PHP. The $_REQUEST approach is safer and not much harder. If you want even more control of how information is passed to your programs, investigate the filter_input() functions that are in the latest versions of PHP. They are not quite complete (as of this writing), but by the time PHP6 rolls around, they’ll probably become an even better way to extract data from forms.

You can use these variables to look up information posted in the form. For example, the askName.html page contains a field called userName. When the user views this page, it sends a request to greetUser.php via the get method. greetUser.php can then check its $_GET variable to see whether a field named userName exists:

$userName = $_GET[“userName”];

This line checks all the data sent via get, looks for a field named userName, and copies the contents of that field to the variable $userName.

If you want to retrieve a value sent through the post method, use this variation:

$userName