HTTP (for HyperText Transfer Protocol) is the primary method used to convey information on the World Wide Web. The original purpose was to provide a way to publish and receive HTML pages.
Development of HTTP was co-ordinated by the World Wide Web Consortium and working groups of the Internet Engineering Task Force, culminating in the publication of a series of RFCs, most notably RFC 2616, which defines HTTP/1.1, the version of HTTP in common use today.
HTTP is a request/response protocol between clients and servers. An HTTP client, such as a web browser, typically initiates a request by establishing a TCP/IP connection to a particular port on a remote host (port 80 by default). An HTTP server listening on that port waits for the client to send a request string, such as "GET / HTTP/1.1" (which would request the default page of that web server), followed by an email-like MIME message which has a number of informational header strings that describe aspects of the request, followed by an optional body of arbitrary data. Some headers are optional, while others (such as Host) are required by the HTTP/1.1 protocol. Upon receiving the request string (and message, if any), the server sends back a response string, such as "200 OK", and a message of its own, the body of which is perhaps the requested file, an error message, or some other information.
HTTP request methods
- GET By far the most common, for statically requesting a resource by specifying a URL.
- POST Similar to GET, except that a message body, typically containing key-value pairs from an HTML form submission, is included in the request.
- PUT Used for uploading files to a specified URI on a web-server.
- DELETE Rarely implemented, and self-explanatory.
- HEAD Identical to GET, except that the page content is not returned; just the headers are. Useful for retrieving meta-information.
- TRACE Echoes back the received request, so that a client can see what intermediate servers are adding or changing in the request.
- CONNECT Rarely implemented, for use with a proxy that can change to being an SSL tunnel.
HTTP differs from other TCP-based protocols such as FTP, in that connections are usually terminated once a particular request (or related series of requests) has been completed. This design makes HTTP ideal for the World Wide Web, where pages regularly link to pages on other servers. It can occasionally pose problems for Web designers, as the lack of a persistent connection necessitates alternative methods of maintaining users' "state". Many of these methods involve the use of "cookies".
HTTPS is the secure version of HTTP, using SSL/TLS to protect the traffic. The protocol normally uses TCP port 443. SSL, originally created to protect HTTP,
is especially suited for HTTP since it can provide (some) protection even if only one side to the communication, the server, is authenticated. This is typically the case in HTTP transactions over the Internet.
The locations of HTTP (and HTTPS) pages are given as Uniform Resource Locators or URLs. This address location syntax was created for linking Web pages.
Sample
Below is a sample conversation between an HTTP client and an HTTP server running on www.google.com, port 80.
Client request:
GET / HTTP/1.1
Host: www.google.com
(followed by a new line, in the form of a carriage return followed by a line feed.)
The "Host" header distinguishes between various DNS names sharing a single IP address. While optional in HTTP 1.0, it is mandatory in HTTP 1.1.
Server response:
HTTP/1.1 200 OK
Content-Length: 3059
Server: GWS/2.0
Date: Sat, 11 Jan 2003 02:44:04 GMT
Content-Type: text/html
Cache-control: private
Set-Cookie: PREF=ID=73d4aef52e57bae9:TM=1042253044:LM=1042253044:S=SMCc_HRPCQiqy
X9j; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Connection: keep-alive
(followed by a blank line and HTML text comprising the Google home page.)
In HTTP 1.0, a client sends a request to the server, the server sends a response back to the client. After this, the connection will be released. On the other hand, HTTP 1.1 supports persistent connections. This enables the client to send a request and get a response, and then send additional requests and get additional responses immediately. The TCP connection is not released for the multiple additional requests, so the relative overhead due to TCP is much less per request. It is also possible to send more than one (usually two) request before getting responses from previous requests. This technique is known as "pipelining".
See also
External links