- Hypertext Transfer Protocol
- The Structure of an HTTP Message
- The Structure of an HTTP Request
- The Structure of an HTTP Response
- Testing an HTTP Connection
- Passing Request Parameters
- Client Page Caching
- URI Redirection and Page Refresh
- Persistent Connections
- Using HTTP from Within a Java Program
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Passing Request Parameters
Information you enter on an HTML form is passed as parameters with the HTTP GET or POST request, defined in the METHOD parameter to the FORM tag. With GET requests, the parameters are encoded with the request URI, but POST requests use the request body for the parameters.
The following example shows a simple form that can be used to register a name and email address with a servlet path of SAMS/Register (this example uses a GET request):
<HTML><BODY> <FORM METHOD="get" ACTION="http://localhost:8080/SAMS/Register"> Name: <INPUT TYPE="text" NAME="name"><P> Email: <INPUT TYPE="text" NAME="email"><P> <INPUT TYPE="submit"> </FORM> </BODY></HTML>
CAUTION
This example is fictitious, and you should not use this form or try to access the URI using Telnet.
Using this form to specify a name of Martin Bond and a fictitious email address of martin@samspublishing results in the following request:
GET /SAMS/Register?name=Martin+Bond&email=martin%40samspublishing HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:0.9.4)Gecko/20011128 Netscape6/6.2.1 Accept: text/xml, application/xml, application/xhtml+xml,
As you can see, the GET header line has the form parameters encoded with the request URI. The form parameters are appended to the URI after the question mark (?), and each parameter is defined by a name and value pair, such as
name=Martin+Bond
HTTP only permits certain characters in a URI (letters, digits, and a few related characters such as the underscore); other character values must be encoded using a scheme defined in RFC 2277, "IETF Policy on Character Sets and Languages" (available from http://www.ietf.org). RFC 2277 defines character encoding as a percent sign and the two-digit hexadecimal value for that character (using the UTF-8 character set); a space is a special case and may be encoded using a plus sign (+) instead of its hex value of %20.
Although the HTTP specification does not impose a limit on the length of the request URI, an individual Web server is permitted to reject requests that contain a URI that is considered too long. In practical terms, you should avoid generating a request URI that contains more than 255 characters, as older browsers, Web servers, and proxy servers might not properly support longer URIs.
When using large HTML forms that might create GET requests of more than 255 characters, you should use the POST request instead. Here's the same form data passed as a POST request:
GET /SAMS/Register HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:0.9.4)
The form data is passed in the body of the request rather than encoded on the request URI. The length of the request body is specified in the Content-length header. The Content-type header shows that the body type is application/ x-www-form-urlencoded, which indicates that the form parameters are encoded using the RFC 2277 scheme.
One other difference between GET and POST requests shows up when you bookmark them within your browser. If a GET request is bookmarked, the parameters are included with the bookmark. However, if a POST request is bookmarked, no parameters are included, so you will not be able to successfully bookmark a POST request with form data.