What are different Parts of an HTTP request?
Underlying the user interface represented by browsers, is the network and the protocols that travel the wires to the servers or "engines" that process requests, and return the various media. The protocol of the web is known as HTTP. HTTP is the underlying mechanism on which CGI operates, and it directly determines what you can and cannot send or receive via CGI.
HTTP provides two primary methods to request documents: GETÂ or POST.
The foundation of HTTP/0.9 (the first implementation of the HTTP protocol) was the definition of the GET method that was used by a web browser to request a specific document.
For example, the following HTTP request would return the document "index.html" that was located in the web server's root directory called "webdocs."
Notice that the GET request began with the GET keyword, included a document to retrieve, and ended with a carriage return and line feed combination.
If you would like, you can try making a GET request by connecting to your favorite web server and sending the GET request yourself (as if you were a web browser).
The beauty of web browsers of course, is that they take care of the HTTP protocol specifications so that the user only needs to enter the URL of the page they want to see. The web browser formulates the actual GET request, sends it to the web server, receives the HTML document back, and then displays the HTML document according to the HTML instructions.
Besides allowing web browsers (or you pretending to be one) to get documents from a web server, the GET method also implements a method for a web browser to send optional search parameters as well; (it was used with ISINDEX HTML files originally).
The search parameters were encoded in a special way that the web server can deal with.
Encoding works like this:
Since you may want to have multiple search parameters, the GET method specifies that parameters are differentiated by placing an ampersand sign (&) between them. Thus, the encoded URL above becomes something like the following:
https://www.domain.com/dir/file?search1&search2&search3
Next, search parameters themselves are specified as "name/value pairs" separated by an equal sign (=) such as in the following example that sets the variable "name" equal to "Sol" and the variable "fname" equal to "Selena":
https://www.domain.com/dir/file?lname=Sol&fname=Selena
Further, any spaces in the encoding string are replaced by plus signs (+) as in the following example:
https://www.domain.com/dir/file?name=Selena+Sol&age=28
Finally, any non-alphanumeric characters are replaced with their hexadecimal equivalents that are escaped with the percent sign (%). For example, a single quote character (') is encoded as %27 and a line break (which is a carriage return plus a line feed) is encoded as %0D%0A. Thus, we might see the following example that specifies that the variable pageName is equal to "Selena Sol's Page":
https://www.domain.com/dir/file?pageName=Selena+Sol%27s+Page
Though the GET method was very useful, a couple of serious problems remained.
First, the GET method only allowed a limited amount of data (1024 characters) to be sent as URL encoded data.
If there were too many name/value pairs, some of them would be clipped and data would get lost.
This all changed with the development of HTTP/1.0.
The HTTP/1.0 protocol was developed from 1992 to 1996 in order to satisfy the need to exchange more than simple text information.
The first major change from the HTTP/0.9 specification was the use of MIME-like headers in the request and response messages.
The next HTTP change was the definition of new request methods: HEAD and POST.
Let's look at both of these changes in greater depth. Under HTTP/1.0 an HTTP transaction consisted of a header followed by an empty line and then some extra data.
We have already talked about the header. The POST method of input was the other important change brought about by the introduction of HTTP/1.0.
The POST method allowed web browsers to send an unlimited amount of data to a web server by allowing them to tag it on to an HTTP request after the request headers as the message body.
