Difference between revisions of "HTML Forms"

From CSE330 Wiki
Jump to: navigation, search
(Created page with '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 …')
 
m (Added HTTPS to links where appropriate.)
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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 (aout which you will learn more in Module 2).
+
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.
 
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.
Line 5: Line 5:
 
== HTTP Request Variables ==
 
== 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 up there?
+
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:
 
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:
Line 15: Line 15:
 
=== Code Example ===
 
=== Code Example ===
  
The syntax for making a form in HTML is relatively straightforward:
+
The syntax for making a form in HTML is relatively straightforward.  The HTML for the above example could be:
  
 
<source lang="html4strict">
 
<source lang="html4strict">
<form action="ACTION" method="GET">
+
<form action="http://example.com/search" method="GET">
<input type="text" name="q" />
+
<label>Search Query: <input type="text" name="q" /></label>
 
<input type="submit" value="Search" />
 
<input type="submit" value="Search" />
 
</form>
 
</form>
 
</source>
 
</source>
  
where '''ACTION''' is the URL of your destination page, with no query strings.  (
+
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:
 +
 
 +
# '''GET''' transfers the variables in the URL.
 +
# '''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 browser 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:'''
 +
<source lang="text">
 +
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
 +
</source>
 +
 
 +
'''Response Headers:'''
 +
<source lang="text">
 +
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
 +
</source>
 +
 
 +
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 [[wikipedia:CRUD|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:
 +
**: <source lang="html4strict"><input type="number" name="percentage" step="1" min="0" max="100" /></source>
 +
* '''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 [https://www.w3.org/TR/html5/forms.html#the-input-element section 4.10.7 of the HTML5 spec].
 +
 
 +
[[Category:Module 1]]

Latest revision as of 10:55, 11 February 2017

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:

HTMLForm.png

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 browser 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.