Introduction to HTTP

The HTTP protocol first appeared in yearly 90’s as a solution for document management in CERN, a huge European research center. They needed to maintain and manage a large number of scientific documents, each having many links to other documents (think of Wikipedia).



Using hypertext (which was not a new concept itself, it existed decades before) to build the documents was an obvious decision. Then, Sir Tim Berners-Lee came up with a quite elegant solution: to store documents on a server and manage them using client applications (browsers). To build the link between the server and the client application, the HTTP was invented.



Nowadays, HTTP/1.1 is the most commonly used version of the HTTP protocol, which is specified in RFC2616 internet standard document.



URL

Before I go into HTTP itself, I would like to give a brief description to a URL, a term that is tightly related to the HTTP. URL stands for Uniform Resource Locator, a sequence of symbols, allowing to identify and to fetch resource (document, image, and video) from the Internet. URL is often called "link" or a "address". URL looks the like following:



scheme://hostname:port/path?query_string



Where:



scheme — identifies protocol that can be used to fetch the resource (e.g. http, https, ftp, etc.),

hostname — is the domain name of the server, which holds this resource (e.g. example.com)

port — is the TCP port that server uses to accept connections to. This part of the URL is not required. If omitted, then default scheme’s port is used (default port for HTTP is 80)

path — is the path to the resource (like a path to the file) on the server

query_string — is a string that contains parameters that are passed to the program if requested resource is a program.

Here is a example of URL: http://www.worksforweb.com/company/. Here, scheme is "http", "www.worksforweb.com" is hostname, port is not given (defaults to 80), and requested path is "/company/". No parameters are passed to the resource because it is a static HTML document.



Request — Response

The interaction between the client and server is pretty straightforward: the client sends an HTTP request to the server, then server sends an HTTP response to the client. No magic.



An HTTP request contains identification of the information requested, so that server can tell whether this information is available, and if so send it back to the client (browser). The identification of requested resource is in the URL of the resource requested.



Both request and response have two parts: the headers and the body, the later being optional and required only for certain request methods and response statuses.



Request and Response Example

Let up look closely into the HTTP request and response. Let user enter the following URL into the address bar: http://www.worksforweb.com/company/. The browser then connects to the www.worksforweb.com server at port 80 and sends the following:



GET /company/ HTTP/1.1

Host: www.worksforweb.com

Accept-Encoding: gzip,deflate



Then the server at www.worksforweb.com sends the following response:



HTTP/1.1 200 OK

Content-Type: text/html






The response is truncated because the body of the response contains the page’s HTML which is 16Kb. The request contains no body, only headers, which is standard for the GET requests (see "Request Methods" paragraph below). The body of the response comes after a blank line, which separates body from headers.



The shown request has three headers:



1.The request itself, with path to the requested resource and protocol version

2.The name of the host as it appears in the URL. This allows server software to identify which of the virtual hosts was requested.

3.The Accept-Encoding header which says that browser is capable of accepting compressed content in "gzip" or "deflate" formats.

The response contains two headers and a body. The two headers shown in the example are mandatory:



1.Protocol version and response status (see below)

2.The type of the response’s body

The body of the response (the requested resource itself) comes after a blank line.



Typically, there are more request and response headers then shown in this example. The number and constitution of request and response headers depends on browser and server software, their configuration, type of the resource requested and other factors.



Read more at http://www.worksforweb.com/publications/introduction-to-http/