HTML Forms

The contents of a web page often changes depending on how you requested that page. For example, when you perform a web search, the contents of the search list changes depending on your query. This is done by way of HTTP request variables (about which you will learn more in Module 2).

The most fundamental way to make a web page sent HTTP request variables to another page is by using HTML Forms. This article describes this process and how to implement it in your code.

HTTP Request Variables

Visit your favorite search engine, and search for "QUERY". Now, look at your address bar. Can you find your query "QUERY" somewhere in the URL?

Your search engine probably used an HTTP Request Variable to send your desired query to the search page. Here is how it might have worked:

You can see that we didn't just go to example.com/search; we also incorporated the search query into the query string of the URL, where query stream

Code Example

The syntax for making a form in HTML is relatively straightforward. The HTML for the above example could be:

<form action="http://example.com/search" method="GET">
	<label>Search Query: <input type="text" name="q" /></label>
	<input type="submit" value="Search" />
</form>

The <label> tag above allows text to "label" an input field. When anything in the label is clicked, the input field will become focussed.

HTTP Request Methods

In the above example, we used the GET method for transferring variables from our form to our destination page. There are two widely supported options for transferring the variables:

1. GET transfers the variables in the URL.
2. POST transfers the variables as an HTTP header.

What does "as an HTTP header" mean?

HTTP Headers

Whenever you request a page on the http:// protocol, your browser sends a request header. Your server responds with a response header followed by the content of your page. You never see the request or response headers unless you have tools that let you see them.

To let you have an idea, here are the request and response headers when I visit http://www.w3.org/ in Firefox:

Request Headers:

GET / HTTP/1.1
Host: www.w3.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
If-Modified-Since: Sat, 16 Mar 2013 09:16:37 GMT
If-None-Match: "8c8c-4d80736774740;89-3f26bd17a2f00"
Cache-Control: max-age=0

Response Headers:

HTTP/1.1 200 OK
Date: Sat, 16 Mar 2013 19:42:55 GMT
Server: Apache/2
Content-Location: Home.html
Vary: negotiate,accept
TCN: choice
Last-Modified: Sat, 16 Mar 2013 09:16:37 GMT
Etag: "8cc6-4d80736774740;89-3f26bd17a2f00"
Accept-Ranges: bytes
Content-Length: 36038
Cache-Control: max-age=600
Expires: Sat, 16 Mar 2013 19:52:55 GMT
P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
Connection: close
Content-Type: text/html; charset=utf-8

You can see that in the request header, information is sent about what browser and operating system I'm using (my user agent), what language I prefer (in my case, en-US), and the like. If you have cookies for a site, they get transfered via a request header. In the response header, we can see that the request was successful (HTTP code 200), that I am receiving an HTML document with the UTF-8 charset (in Content-Type), and other various information. All of these headers are standard; you can implement less-common headers as well.

When to use GET vs. POST

Here are some rules of thumb to help you decide whether to use GET or POST for a certain form.

• If you would like the user of your application to be able to bookmark the destination page for later use (e.g. search results), you need to use GET, because the bookmark will contain the entire URL, including the request variables.
• If you are transmitting sensitive information like passwords, you should use POST, because POST variables will not appear in a user's browsing history, but GET variables will.
• If the data you are transmitting is large (over about 200 bytes), you need to use POST, since some browsers will truncate the URL string after 256 characters.
• If the destination page takes the information from the form and modifies something in a database, it is best practice to use POST.

Technicalities

Although it is safe to think about POST variables as being transmitted as a header, this is technically not the case. In reality, POST variables are sent in the request body. The server knows to read the POST variables from the request body because of a application/x-www-form-urlencoded request content type header.

Additionally, there has been a recent resurgence in so-called CRUD; that is, additional HTTP request types beyond GET and POST: PUT, DELETE, OPTIONS, etc. CRUD request types are beyond the scope of this course, but it is worth the time reading up on their meaning if you find yourself working with a RESTful web framework like Ruby on Rails.

Input Types

In the example above, we used just two input types: a text field and a submit button. In reality, there are over 20 different types. Some of the more common types include:

• hidden: allows for a variable to be passed as part of a form without requiring that the user input any data.
• password: allows for text to be hidden while typed.
• number: like a text box, but forces the content to be numerical.
  • Note: You can set the step, min, and max attributes on your number input to change the precision of the number accepted. For example, the following input field would accept only integers between 0 and 100 inclusive:

    <input type="number" name="percentage" step="1" min="0" max="100" />
    

• checkbox: a yes-or-no checkbox.
• radio: a multiple-choice question. Use multiple input fields, all with the same name but different value.
• file: allows for file uploads. (We will deal with this more in module 2.)

For a complete list, see section 4.10.7 of the HTML5 spec.