![]() |
![]() |
Dealing with Forms |
One of the biggest reasons for using server side scripting is to be able to deal with forms submitted by the viewer - whether we're mailing that information somewhere, storing it in a log file, or just giving back other information based on what was entered to the form. To deal with this form, we need to be able to get the information from the form and bring it into our program.
The difference between the GET and POST methods is in the way they pass form items back to the server. GET type forms send their form parameters as part of the URL being requested, so a form with an item called "name" having a value of "this" would end up with the URL http://whatever.com/form.php?name=this. The same form being submitted with the POST method would result in just the http://whatever.com/form.php part of the URL being used, and the form items themselves being submitted separately, after all of the HTTP headers from the request had been sent. Below, we have two forms, one GET, and one POST type - along with the resulting requests that would be sent to the web server when those forms were submitted:
In the GET form above, the only change from a normal web page request is the extra parameters after the filename - which are indicated by a ?, to keep them separate. (Note: for this reason, you should never create a file with a ? in it's name - the web server will think that the part before the ? is the file's real name, and the rest would be thought of as form parameters.) Each of the items in the form is represented in the list of parameters, including the submit button.
With the POST method, there is a considerable difference - the browser must now send a completely different type of request, called a POST request - in addition to needing a Host line (for HTTP/1.1 compliance), the POST request also requires two other items - a header line specifying exactly how many characters there will be in the form items being submitted, and after the header is finished, the actual contents of the form. Note that if the Content-length line says "32", only the first 32 bytes of this information will be read - the rest would be ignored by the server. The Content-length line tells the server how much to read of the information given, and if it is not there, the server will not even look to see if anything was submitted.
It should be noted that there are places where either GET type requests are not appropriate, and places where they are. The GET type request places all of the form items in the URL - a distinct disadvantage if any of those items were of a confidential nature, such as a credit card number, user login information, or other personal information. In many cases, if you wish to print out the output from a web page, the browser places the URL of the page you are printing at the top or bottom of each page for reference - if your credit card number is now part of that URL, giving someone a copy of the printout means giving them access to your credit card as well. Also, the web server itself logs the URL of every web page which is requested from it - if you do not wish for anyone with access to the server logs to see your information, you should not be using a GET type request.
On the other hand, if your script requires only a small amount of information to function, or you do not wish to have to type in an entire HTML form to run it, GET type requests can be very useful. As an example, many counter scripts which produce an image of the number of people visiting your page so far require parameters to identify which counter you are using, or other settings for the counter, such as colours, fonts, or other information. Since it would be impractical to make everyone visiting your page click on a submit button just to see your counter, a GET request is much more practical - then instead of a large form with each parameter for the counter being set by input tags, you can merely set them as part of the URL, inside of the img tag where the counter belongs, like this:
Here, the file name is counter.php, and the rest of the URL, after the ? is just a list of parameters being passed to the counter - each parameter following the format of name=value, and having a & symbol between them as a separator. (*remember that you should only submit letters and numbers here - anything else should be converted into a % and a two-digit hex code to represent that character. Otherwise, you risk causing the server to read your parameters incorrectly.) In the above example, three parameters are being submitted to the script - id, font, and bgcolor.
GET type requests are appropriate in any situation where you only need a few simple, non-private parameters to run the script, or where you need to load the script from something other than an HTML form, such as in the src attribute of an img tag, or the href of an a tag - any file loaded in this manner can only be retrieved via a GET type request anyways, so if you need to submit parameters to such a script, you need to use the GET method for them.
While the GET request type can be useful in some situations, POST should be used in any location where you are submitting an HTML form. There are several reasons for this, including the privacy issues which were mentioned earlier. If your form requires a large amount of input, (let's say it's for a literary web site, and you wish prospective authors to submit a 30-page writing sample to your server, or a web-log type site where large articles are frequently posted,) then some servers and browsers may not even allow all of the submitted information to get through the GET type request due to size constraints on header lines in the HTTP protocol. Since the form items in a POST request are not part of the header, such limits do not apply to them. Also, since the URL of each request is placed into a log file by the server, not filling the log file with the contents of every form submitted to your site will save space on the server. This could become an extreme problem on a site such as Slashdot, which deals with thousands of large, text-filled form submissions every hour.
On the other hand, the main, and largest disadvantage to POST requests is that it is only possible to use them from a form tag - if you have any information you wish to keep private which needs to be submitted to a script, you must use an actual HTML form with a submit button to send the information by the POST method. No other reliable method of keeping that information private while sending it as a parameter to a script exists.