HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

Figure 9.7  Netscape Navigator 3 browser rendering of the FORM example in Figure 9.6.

GET /cgi-bin/form1?srch=dogfish&srch_type=Exact+Match&srvr=Canada&srvr=Sweden HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/3.02 (Win95; I)
Host: smaug.java.utoronto.ca:2021
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en-US, fr, fr-CA
  [a blank line, containing only CRLF ]

Lesson from Example 17

1.  When an HTML FORM submits data to an HTTP server using the GET method, the FORM data are appended to the URL as a query string. Consequently, the FORM data are sent to the server in the query string part of the locator string, in the request header method field. The FORM data are encoded according to the FORM -URL encoding scheme discussed in Chapters 6 and 8.

Example 18: Submitting a FORM Using the POST Method

This example uses the FORM shown in Figure 9.7 to submit the same data to the server, but with one subtle modification: The form requests the POST method instead of GET. This is done by changing the first two lines in Figure 9.6 to:

<FORM ACTION="http://smaug.java.utoronto.ca:2021/cgi-bin/form1"
      METHOD=POST >

(The change is noted in boldface.)

As in Example 16, this form has variable names srch, srch_type, and srvr. These have been assigned values srch=dogfish, srch_type=Exact Match, srvr=Canada, and srvr=Sweden. Figure 9.9 shows the data sent to the server, again from the Netscape Navigator 3.0 browser.

The POST method sends data in a message body and not in the URL. The difference is indicated in Figure 9.9 in the four places noted in boldface: the method header, which now specifies the POST method and which has no data appended to the URL; the additional request header fields Content-type and Content-length, which give the type and length of the data message being sent; and last, the actual data following the header.

There are currently two valid content-types for sending FORM data to a server. In this example, the type is

Content-type: application/x-www-form-urlencoded

which indicates that the data is from a FORM and that it is encoded in the same manner as when appended to a URL. You can compare the message body at the bottom of Figure 9.9 with the data appended to the URL in Figure 9.8 to verify this equivalence. The details of how the data are passed from the server to a CGI program are described in Chapter 10.

Alternatively, FORM data sent via the POST method can be encoded as a MIME multipart/form-data message. On a browser, this encoding is selected by changing the first two lines in Figure 9.6 to (the changes are noted in boldface):

<FORM ACTION="http://leonardo.utirc.utoronto.ca:8080/cgi-bin/form1"
      METHOD=POST ENCTYPE="multipart/form-data" >

POST /cgi-bin/form1 HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/3.0b5 (Win95; I)
Host: smaug.java.utoronto.ca:2021
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en-US, fr, fr-CA
Content-type: application/x-www-form-urlencoded
Content-length: 58
   [a blank line, containing only CRLF]
srch=dogfish&srch_type=Exact+Match&srvr=Canada&srvr=Sweden

POST /cgi-bin/form1 HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/3.02 (Win95; I)
Host: smaug.java.utoronto.ca:2021
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en-US, fr, fr-CA
Content-type: multipart/form-data; boundary=-----------------80006273428
Content-Length: 443
  [a blank line, containing only CRLF]
-------------------80006273428
Content-Disposition: form-data; name="srch"
   [a blank line, containing only CRLF]
dogfish
-------------------80006273428
Content-Disposition: form-data; name="srch_type"
   [a blank line, containing only CRLF]
Exact Match
-------------------80006273428
Content-Disposition: form-data; name="srvr"
   [a blank line, containing only CRLF]
Canada
-------------------80006273428
Content-Disposition: form-data; name="srvr"
   [a blank line, containing only CRLF]
Sweden
-------------------80006273428--

Figure 9.10 shows the data sent to the server by the Netscape Navigator browser. The important changes from Figure 9.9 are noted in boldface. Once again the method is POST—content-type and content-length header fields are again present, and data is sent following the header. Note, however, the encoding of the data: The FORM data are encoded as a special multipart MIME type, with each block of the message corresponding to a different form input element.

This encoding has several advantages. First, you can use multipart/form-data to upload data files from a client to a server—indeed, if a form contains INPUT TYPE =“file” elements (for selecting a file to upload with the form data), then multipart/form-data is the only supported encoding. Second, the multipart/form-data allows for text input that is not coded in the ISO Latin-1 character set (recall that URLs must use ISO Latin-1). These issues are discussed in more detail in Chapter 10; see also the MIME types appendix (Appendix B) available at the book’s companion Web site at www.wiley.com/compbooks/graham.

Lesson from Example 18

1.  When an HTML FORM submits data to an HTTP server using the POST method, the FORM data are sent to the server as a message body that follows the request header. This message body is encoded in the same manner as when appended to the URL. Additional request header fields tell the server the content-type of the arriving message, as well as the length of the message. No data are appended to the URL.

Sending Data to a Server: PUT and DELETE

The methods PUT and DELETE are designed for sending data to and deleting data from an HTTP server. For example, the HTTP request

PUT /project/dir1/file.html HTTP/1.0
Content-type: text/html
Content-length: 103
   [a blank line, containing only CRLF]
<HTML><HEAD><TITLE>Silly Test Stuff</TITLE></HEAD>
<BODY><H1>Really Silly Test Stuff</H1></BODY><HTML>

instructs the server to create the file ../project/dir/file.html (the root location is determined by the server configuration files) and put the sent message data into this file. If this file already exists, it should be replaced by the new file. If successful, the response status field line should be

HTTP/1.0 201 created

to indicate that the resource was created.

The DELETE method is the converse of PUT. Thus, the request

DELETE /project/dir1/file.html HTTP/1.0
  [a blank line, containing only CRLF]

asks that the server delete the resource at the indicated URL.

There are currently no major browsers that implement PUT or DELETE. Some servers do implement these methods, usually through special gateway programs or application-specific server plug-ins. Obviously PUT and DELETE are not terribly practical without mechanisms for controlling how objects are put onto, modified, or deleted from a server. In this regard, there are several document management systems (e.g., Microsoft FrontPage or MKS Web Integrity) that use PUT and DELETE methods to manage document archives on Web servers.