HTTP
Internet protocol suite |
---|
Application layer |
Transport layer |
Internet layer |
Link layer |
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), optionally 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. 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 page by specifying a URL.
- POST Similar to GET, except that, additionally, key-value pairs are appended to the request. Most often used as part of a HTML form.
- 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".
There is a secure version of HTTP called HTTPS that can use any given encryption method as long as it is understood by both sides.
The locations of HTTP (and HTTPS) pages are given as Uniform Resource Locators or URLs. This address location syntax was created for HTML linking.
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
- List of HTTP status codes
- 404 error
- Uniform resource locator
- Basic authentication scheme
- Digest access authentication
- Captive portal
- HTTP proxy
External links
- Tim Berners-Lee's original 1992 Internet-Draft http://www.w3.org/Protocols/HTTP/HTTP2.html
- RFC 2616 - The current HTTP/1.1 specification
- HTTP/1.1 specification errata
- HTTP Made Really Easy
- HTTP header viewer
- List of HTTP status codes
- Command-line HTTP clients: cURL, Wget