HTTPGetting started with HTTP


Hypertext Transfer Protocol (HTTP) uses a client-request/server-response model. HTTP is a stateless protocol, which means it does not require the server to retain information or status about each user for the duration of multiple requests. However, for performance reasons and to avoid TCP' connection-latency issues, techniques like Persistent, Parallel or Pipelined connections may be used.


VersionNote(s)Estimated Release Date
HTTP/0.9"As Implemented"1991-01-01
HTTP/1.0First version of HTTP/1.0, last version that has not made it into an RFC1992-01-01
HTTP/1.0r1First official RFC for HTTP1996-05-01
HTTP/1.1Improvements in connection handling, support for name-based virtual hosts1997-01-01
HTTP/1.1r1Disambiguous keyword usage cleaned up, possible issues with message framing fixed1999-06-01
HTTP/1.1r2Major overhaul2014-06-01
HTTP/2First spec for HTTP/22015-05-01

HTTP requests and responses

HTTP clients and servers send HTTP requests and responses, respectively

HTTP describes how an HTTP client, such as a web browser, sends an HTTP request via a network to an HTTP server, which then sends an HTTP response back to the client.

The HTTP request is typically either a request for an online resource, such as a web page or image, but may also include additional information, such as data entered on a form. The HTTP response is typically a representation of an online resource, such as a web page or image.


The first version of HTTP that came into existence is 0.9, often referred to as "HTTP As Implemented." A common description of 0.9 is "a subsect of the full HTTP [i.e. 1.0] protocol." However, this greatly fails to illustrate the disparity in capabilities between 0.9 and 1.0.

Neither requests nor responses in 0.9 feature headers. Requests consist of a single CRLF-terminated line of GET , followed by a space, followed by the requested resource URL. Responses are expected to be a single HTML document. The end of said document is marked by dropping the connection server-side. There are no facilities to indicate success or failure of an operation. The only interactive property is the search string which is closely tied to the <isindex> HTML tag.

Usage of HTTP/0.9 is nowadays exceptionally rare. It is occasionally seen on embedded systems as an alternative to tftp.


HTTP/1.0 was described in RFC 1945.

HTTP/1.0 does not have some features that are today de-facto required on the Web, such as the Host header for virtual hosts.

However, HTTP clients and servers sometimes still declare they use HTTP/1.0 if they have incomplete implementation of the HTTP/1.1 protocol (e.g. without chunked transfer encoding or pipelining), or compatibility is considered more important than performance (e.g. when connecting to local proxy servers).

GET / HTTP/1.0
User-Agent: example/1

HTTP/1.0 200 OK
Content-Type: text/plain



HTTP/1.1 has originally been specified in 1999 in RFC 2616 (protocol) and RFC 2617 (authentication), but these documents are now obsolete and should not be used as a reference:

Don’t use RFC2616. Delete it from your hard drives, bookmarks, and burn (or responsibly recycle) any copies that are printed out.

Mark Nottingham, chair of the HTTP WG

The up-to-date specification of HTTP/1.1, that matches how HTTP is implemented today, is in new RFCs 723x:

HTTP/1.1 added, among other features:

  • chunked transfer encoding, which allows servers to reliably send responses of unknown size,
  • persistent TCP/IP connections (which were non-standard extension in HTTP/1.0),
  • range requests used for resuming downloads,
  • cache control.

HTTP/1.1 tried to introduce pipelining, which allowed HTTP clients to reduce request-response latency by sending multiple requests at once without waiting for responses. Unfortunately, this feature was never correctly implemented in some proxies, causing pipelined connections to drop or reorder responses.

GET / HTTP/1.0
User-Agent: example/1

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 6
Connection: close



HTTP/2 (RFC 7540) changed on-the-wire format of HTTP from a simple text-based request and response headers to binary data format sent in frames. HTTP/2 supports compression of the headers (HPACK).

This reduced overhead of requests, and enabled receiving of multiple responses simultaneously over a single TCP/IP connection.

Despite big changes in the data format, HTTP/2 still uses HTTP headers, and requests and responses can be accurately translated between HTTP/1.1 and 2.